5. Moving from Software Architecture to Software Design—Building a Mobile Trading System – Software Architecture: A Case Based Approach

Chapter 5. Moving from Software Architecture to Software Design—Building a Mobile Trading System

ContributorsBhudeb ChakravartiVamsi STPKirti Garg

Background

What Is Design?

Design is the bridging activity between gathering and implementation of software requirements that satisfies the required needs. Software design has three distinct activities:

  • External—Planning externally observable characteristics of a software product, for example, external data sources, functional requirements, and so on.

  • Architectural design—Architectural design refines the conceptual view of the system, decomposing it into sub-systems.

  • Detailed design—Detailed design specifies the data structures, functions and algorithms needed to implement the system.

The last two activities are referred to as internal design, as they deal with specifying the internal structure and processing details of the software product.

The fundamental goal of design is to reduce the number of dependencies between modules, thus reducing the complexity of the system. This is also known as coupling; lesser the coupling the better is the design. On the other hand, higher the binding between elements within a module (known as cohesion) the better is the design. Fundamental concepts of software design include abstraction (functional, data and control), information hiding, modularity (to enhance design clarity and ease of implementation), concurrency and design aesthetics. Apart from these concepts, the following design guidelines help organize the design activities and come up with a good design:

  • Review requirements specification

  • Expand the external interfaces and other artefacts developed during requirements analysis

  • Refine documents (UML diagrams) and data flow diagrams developed during requirements analysis

  • Record functional and data abstractions, and define visible interfaces for each

  • Define modularity criteria to define the structure of the system

  • Verify if the resulting structure created using one of the design techniques satisfies the requirements

  • Conduct a preliminary design review

  • Create data representations and redesign as and when necessary

Design Notations

The major difficulties encountered in the design phase are due to insufficient requirements, providing too many details too early and failure to consider alternative design strategies. The use of systematic design notations improves the ability to conceive, communicate and verify design. A design model preserves the structure of the system imposed by the analysis model and includes elements such as sub-systems, dependencies, classes, use case realizations, and so on. Each model must describe a specific aspect of the system under consideration. It also gives us the flexibility to fail under controlled conditions.

Visual modelling gives us an understanding of the requirements, constraints and other issues by using a common notation. Also, the interfaces between sub-systems can be identified early in the life cycle.

The different artefacts of software design include design model (hierarchy of sub-systems), design class, use case realization along with class and interaction diagrams, architectural view of the design model, deployment model (nodes and connections, mapping of classes to nodes), and so on.

In software design, representation schemes such as data flow diagrams, structure charts and pseudo-code help represent the design of the system.

In response to the growing complexity of software systems, many design methods have evolved. Broadly, these methods can be classified as follows (Sommerville, 2004):

  • Top–down structured design

  • Data-driven design

  • Object-oriented design (OOD)

The earliest and one of the most influential techniques was the top–down design, which encouraged structural programming. The fundamental unit of decomposition in this approach is to divide a complex problem into sub-problems. Unfortunately, as the complexity of software increases the structural design fails to scale up as it does not address issues of data abstraction, information hiding and concurrency. In the data-driven approach, the system is mapped into inputs and outputs. This method fails in the case of time-critical event systems and is not suitable for object-based and object-oriented programming languages. OOD emphasizes on modelling the system as a collection of cooperating objects that are instances of classes within a class hierarchy.

Design can be defined as a disciplined approach to invent the solution of a problem, and software design helps come up with a blueprint of the system keeping in view the constraints on the system.

There is no silver bullet to come up with a good software design. The design of a complex system is often an incremental and iterative process. According to Grady Booch (2004):

OOD is a method of design encompassing the process of decomposition and a notation to depict the logical, physical as well as the static and dynamic models of a system.

The real purpose of a design is to create an architecture (including class and object structure) for implementation and common policies used by different elements of the system. The activities associated with design include the following (Booch, 2004):

  • Architecture planning—Logical and physical decomposition of the system

  • Tactical planning—Making decisions about common policies

  • Release planning—Helps create a development plan for the system

Postmortem

The case study discusses at length several design issues that came up during the development of the MTS. For example, the application had to run on handheld devices providing ‘anytime, anywhere’ access to users. Also, the application had to provide comprehensive market information, analytical tools and recommendations. The team moved carefully from architecture to detailed design considering several issues such as ability to conduct secure transactions over all the exchanges through different types of handheld devices. Thus, the requirements were interesting and are representative of the new genre of requirements, as seen in this age of information and communication. Under such conditions, it is preferred that the team moves forward in a guided manner, from requirements to architecture, and create a detailed design from architecture. The MTS team was careful to use standard methodologies such as the use case methodology to come up with the design and its artefacts. This was a good move as it provided a common language to communicate design decisions and system requirements.

But is the process of design as easy as its description? What are the issues that become prominent, at times? How do we move from architecture to detailed design? What are the tools and techniques available to a designer on this journey? Can there be a well-defined process that, when followed, ensures a ‘good’ or a ‘perfect’ design? We will try to seek answers to these questions.

The Design Process

Developing a solution is a challenging task. The software designer needs to acquire a degree of domain knowledge to undertake the design task.

There are two phases in the process of designing. In the first phase, the software designer decomposes the solution into a set of large and complex software components that interact with each other. This is called high-level design. The details of the components and the interactions are at a very abstract level. In the second phase, each of these high-level components is further detailed with their attributes and methods. The interactions between these components and sub-components are also specified. At the end of second phase, the so-called low-level design is ready. During the low-level design phase, it is possible to identify all the objects (either new or existing) that can be reused and group them into various object libraries.

A simple design process could be followed to make life easier for the designers. According to David Budgen (2004), a usual design process consists of the following steps:

  • Postulate a solution clarifying the nature of requirements.

  • Build a model of the solution: Construct both black box and white box models of the problem. The black box model describes the external functionality and behaviour of the system as a whole, without any reference to how this is to be achieved. On the other hand, a white box model describes the internal workings of a system.

  • Evaluate the model against the original requirement: Validate the solution including use of prototypes.

  • Elaborate the model to produce a detailed specification of the solution: Use suitable forms of software for implementation of the design plan.

Design models allow the designers to explore the potential limitations of the solution, its behaviour and its structure. A design method can be regarded as providing a procedural description of how to go about the task of producing a design solution for a given problem. There are several software design methods that support building initial abstract models to explore ideas. The major components of such design methods are representation, process and heuristics.

Due to the abstract nature of software, identifying and specifying all the needs of the system can be problematic. As a result, the solution space may be ill-defined and give raise to the following problems:

  • Design is not self-consistent

  • Design and specifications are not consistent

  • Design and requirements are not consistent

These inconsistencies must be identified and dealt with early in the design phase. The design should be flexible to accommodate important changes in design decisions and plan for reuse. Also, the design stage is the ideal time to plan for maintenance of the system.

Communicating the design decisions is an important activity of the design process. All the design decisions must be recorded and transferred to the team.

Design notations come to aid here. Many standard notations for representing design are available, with UML being the most prominent.

Moving from Architecture to Design

The process of designing the architecture typically starts with formulating problems that need to be solved and ends with a conceptual solution. The design process starts with this high-level solution and fills all the details that are required before constructing the software system. The architectural design is concerned with the overall form of the solution to be adopted, such as what the major elements are and how they interact. Detailed design, on the other hand, is concerned with developing descriptions of the elements identified in the architectural design phase and the interactions between these elements. To move to detailed design, we need to map the architectural design decisions to the logical design. After the candidate architecture is defined, we need to analyse the behaviour of the system and design the components and database accordingly. The idea is to move from architectural model to detailed design. The architectural model is used to describe the intended form that the system will take and is very abstract in nature, while the design model gives a concrete shape to the elements of the architectural model.

Theoretically, one should not tamper with business objects unless absolutely necessary in order to maintain their basic properties and behaviour.

To move from architecture to detailed design we need to identify design elements and their relationships. This process includes the following (Budgen, 2004):

  • Defining system context

  • Identifying the modules

  • Describing the components and connectors

Step 1: Defining System Context

Defining the system from an external perspective helps establish the overall purpose of the system. It is related to understanding the problem domain that the system addresses. This utilizes the abstraction design technique and allows focusing on a particular level of detail without having to focus on all aspects of the system. The input for this step is the initial requirements list. The external behaviour of the system is mapped to the interfaces of the system. Each interface represents some coherent sub-set of system functions. A use case diagram is a common way to depict system context. An initial model of the enterprise context of the system can be created by diagramming the existing business processes, artefacts, people and existing systems.

Step 2: Identifying the Modules

In this phase, we identify discrete units that contain component definitions. This step also utilizes the abstraction design technique and applies design operators to split the system into module types. These design operators include the following:

  • Decomposition: Separating functionality into distinct components that have well-defined interfaces, that is, separating the system into sub-systems. It is used to achieve a variety of quality attributes. Two types of decomposition are part/whole and generalization/specialization.

  • Replication: Also known as redundancy, replication is the operation of duplicating a component to enhance its reliability and performance. Redundancy (identical copies of a component) and N-version programming (several different implementations of same functionality) are two types of runtime replication.

  • Compression: It is the opposite of decomposition. It involves merging of components into a single component or removing layers or interfaces between components. It involves coupling and improves performance by removing indirection.

  • Abstraction: It hides the implementation details. This makes components portable with respect to the component that has been abstracted and can be used to improve adaptability.

  • Resource sharing: This refers to encapsulating data or services in order to share them among multiple independent components. This is useful when a resource is scarce and enhances portability and modifiability. For example, repository of user information can be a shared resource.

Step 3: Describing the Components and Connectors

The last step involves creating descriptions of instances of module types in runtime configurations. Identification of modules and components is the central activity of software architecture design. Many of the quality attributes are embodied in the components and their connectors. Components typically refer to runtime instances of software units. Connectors can refer to software components or mechanisms of communication. Some examples of connectors are user interface design and common data representation, where two applications are connected by shared data that are stored in a file or database.

The rational workflow for design can be sought as an example. It gives a view of how to move to design from the use cases:

  • Use case analysis: Coming up with possible scenarios.

  • Use case design: Identifying actors and use cases. Establishing the functionality of the prospective product.

  • Sub-system design: A general understanding of how the individual parts work together to provide the desired functionality.

  • Class design: Determine necessary classes and their data. Also discover inter-relationships among classes.

If we consider the OOD or the use case method of designing, then the design process will take the following course of action as per the steps given above.

Guided by the architectural decisions, a detailed design effort takes place. It addresses details such as the specification of all classes, including the necessary implementation attributes, their detailed interfaces and pseudo-code or plain text descriptions of the operation. The specification should be detailed enough that, together with model diagrams, it provides all the necessary coding information. In many automated software production processes, one can generate code skeletons from object-oriented diagrams.

Guided by architectural specifications, the design technically expands and adapts the analysis result. Further, detailed use case specification documents detailing all the use cases, actors, pre- and post-conditions and alternative courses can be prepared. The next step would be to identify boundary, entity and control classes from the use case flow of events in order to come up with the sequence diagrams.

The next logical step is to come up with the class diagrams that describe the static structure of the system, including the object classes, their internal structures and the relationships in which they participate. This is followed by object design, which is the conceptual representation of an implementation of the solution to a business problem. The object design, typically represented with a class diagram, is technology dependent and specific to architecture, computer language, screen and report layouts and other real-world restrictions. It is during this stage in the life cycle that the implementation of each class, association, attribute and operation is determined.

Thus, OOD builds on the products developed by refining candidate objects into classes, defining message protocols for all objects, defining data structures and procedures and mapping these into an object-oriented programming language. OOD groups these classes into packages. A package is a general purpose mechanism for organizing elements into groups. Packages help organize the model under development and are a unit of configuration management.

In order to produce a good design, it becomes important to assess the quality of both static and dynamic attributes of the system. The design attributes include simplicity, modularity (coupling and cohesion), information hiding, and so on. These design attributes provide a set of measurable characteristics of the entities and provide mapping between the abstract idea and the identifiable features of the actual design.

No discussion on design is complete without a mention of design patterns. A pattern describes a recurring problem, the core of the solution to the problem that can be reused many times. Design patterns provide templates and encourage reuse. Examples of some design patterns include proxy and chain of responsibility. There are design anti-patterns too that describe the pitfalls to avoid by capturing the unsuccessful attempts at design solutions (Jacobson et al., 2002).

Characteristics of a Good Design

To improve the quality of the design process, it is important to provide inputs to design activities. Technical and managerial review and prototyping can be used to provide these inputs. Design reviews and inspections can be effective ways to asses the design quality. Parnas and Weiss (1985) identify eight requirements of a ‘good design’:

  • Well structured: Consistent with chosen properties

  • Simple: To the extent of ‘as simple as possible, but no simpler’

  • Efficient: Providing functions that can be computed using existing resources

  • Adequate: Meeting the stated requirements

  • Flexible: Able to accommodate likely changes in the requirements

  • Practical: Module interfaces should provide the required facilities

  • Ability to implement: Using current and available hardware and software technology

  • Standardized: Using well-defined and familiar notation for any documentation

Case Analysis

A detailed analysis of the case shows that the team worked in a rather systematic manner to move from requirements to architecture and then to design.

The architecture for the MTS is shown in Figure 5.6. The content provider and bank have a server that provides an interface to aggregate content from leading global content providers. It has open interfaces that provide interfaces with legacy databases of various enterprises. On the broker’s network resides the online trading platform interface (OTPI), which connects the system to the online trading platform used by securities companies. Between this and the client devices there is a security management system that protects the services and transactions that are being provided and monitors alerts raised, administration services and content aggregation. Over this there is a mobile network interface that helps the system communicate through the mobile network. This interface is available for different mobile networks such as GSM, GPRS and CDMA. Mobile device browser is the presentation software on the handheld device and provides the click screens to the user.

Figure 5.6. Mobile trading platform

The team moved in a structured manner to come up with the design. Object-oriented analysis and design techniques helped model the system as a set of cooperating and individual objects as instances of a class. The job included the identification of classes and objects, identification of their semantics, identification of their relationships and specifying class and object interfaces and implementation.

As the first step, the team captured the usage scenarios of the system. This identification of the major use cases and external systems helped the team understand how the system is being used, its interactions and system requirements. The detailed use case specifications explained the system flow very well and gave a deeper understanding of the usage scenarios. This proper and thorough understanding of the requirements is the first step towards a good design.

The major use cases that were identified include the following:

  • Login

  • Retrieve information and store

  • Perform online transaction

  • Personalize profile

  • Manage users

  • Generate bills

External systems were also identified during this process. These included online trading platform, content provider’s server and the bank’s server.

Use Case Specification

During the detailed design we produce detailed artefacts that specify what the system is going to be like, which are captured in a use case specification. The team developed such a specification for the mobile trading platform. It gives details about all the use cases in the system and describes the usage scenario, the entities using the functionality of the use case to interact with the system, the pre- and post-conditions, normal and alternative flow of events, associated use case and sequence diagrams, exceptions, assumptions, and so on.

For example, the ‘generate alert and sound’ use case describes what happens when alerts are generated, who can generate them and when. Also, the use case specification gives details about the normal flow and alternative flow when alerts are generated.

Use case ID: UC2

Use case name: Generate alert and send

Description

This use case checks the user database if any alert is requested by the subscriber. If there is any alert sent by the subscriber, it generates a message as per the subscriber’s request and sends the message to the subscriber.

Actors

System

Pre-conditions

The system is already connected to the user database during the start up.

Post-conditions

NA

Frequency of use

NA

Normal course of events

When the system is switched on, the system initiates this use case. The normal course of events is as follows:

  1. The system gets the time from the system clock

  2. The system checks whether any subscriber has set any alert

  3. It reads the alert and gets the content information from the content database

  4. System checks the alert condition and creates a message as per the request from the subscriber

  5. It sends the message to the subscriber through the mobile network interface

  6. It repeats steps 3-5 till all the alerts are read and taken care of

Alternative courses

In step 4, if the alert condition is not satisfied, system skips steps 4 and 5.

Associated use case diagrams/sequence diagrams/collaboration diagrams

The use case diagram is created in a Rose model called ‘MTS.mdl’. The sequence diagrams are created under the package ‘Logical view\Use case realization’ within the use case realization called ‘Generate alert’. The sequence diagram is shown in the annexure.

Exceptions

If the system fails to execute the use case for any reason, it should pop-up a message stating the same. In that case, the use case should be initiated again

Includes

NA

Special requirements

NA

Assumptions

NA

Notes and issues

NA

The ‘Get information’ use case explains how the subscriber can use the system to retrieve information and what the flow of events is when such a request is made.

Use case ID: UC4

Use case name: Get information

Description

This use case retrieves financial data, research data, analysis information, recommendations, and so on from the content database and displays them on the handheld device of the subscriber.

Actors

Subscriber

Pre-conditions

Login use case should be completed successfully by the subscriber before using this use case.

Post-conditions

NA

Frequency of use

NA

Normal course of events

When the subscriber has logged in, he can initiate this use case. The normal course of events is as follows:

  1. The subscriber selects his choice on the main menu

  2. The mobile device browser (MDB) interprets the request and sends it to the system through the mobile network interface.

  3. The content aggregation engine (CAE) retrieves the data as per the request from the customer

  4. CAE sends the information to the subscriber’s device

  5. CAE sends the information to the call data record (CDR) controller to create and store a CDR

  6. MDB displays the information on the handheld device

Alternative courses

NA

Associated use case diagrams/sequence diagrams/collaboration diagrams

The use case diagram is created in a Rose model called ‘MTS.mdl’. The sequence diagrams are created under the package ‘Logical view\Use case realization’ within the use case realization called ‘Get information’. The sequence diagram is shown in the Annexure.

Exceptions

NA

Includes

NA

Special requirements

NA

Assumptions

NA

Notes and issues

NA

The following use case specification gives details of how transactions are performed via the online trading interface. Again the preconditions and basic and alternative flow of events are described, giving an understanding of what course of action the system should take.

Use case ID: UC6

Use case name: Transact financial entity

Description

This use case allows the subscriber to perform any transaction through the OTPI of MET. The OTPI is connected to the online trading platform of the enterprise, which in turn allows the user the platform to do secure transactions.

Actors

Subscriber

Pre-conditions

Subscriber should complete the ‘Login’ use case before using this use case.

Post-conditions

NA

Frequency of use

Subscriber can use this case whenever he wants to perform a transaction.

Normal course of events

The normal course of events is as follows:

  1. The subscriber selects the option ‘Sell’ or ‘Buy’ on the main menu

  2. MDB formats the request and sends it to the ‘transaction engine (TNE)’ through the mobile network interface

  3. TNE sends the request to the online trading platform of the enterprise for the transaction

  4. TNE sends a confirmation to the subscriber after receiving confirmation from the online trading platform

  5. TNE sends the transaction information to the CDR controller to create and store a CDR

Alternative courses

During step 4, if the TNE does not receive the confirmation, it sends a message to the subscriber stating that the transaction is not successful.

Associated use case diagrams/sequence diagrams/collaboration diagrams

The use case diagram is created in a Rose model called ‘MTS.mdl’. The sequence diagrams are created under the package ‘Logical view\Use case realization’ within the use case realization called ‘Transact financial entity’. The sequence diagram is shown in the Annexure.

Exceptions

NA

Includes

NA

Special requirements

NA

Assumptions

NA

Notes and issues

NA

To specify the ‘Manage system’ use case consider all the activities that the system administrator is required to do. The normal action would be to login to his account and perform the necessary functions via the interface provided. The following use case specification provides these details:

Use case ID: UC7

Use case name: Manage system

Description

This use case allows the system administrator to monitor and maintain the system.

Actors

System administrator

Pre-conditions

NA

Post-conditions

NA

Frequency of use

NA

Normal course of events

The normal course of events is as follows:

  1. The system administrator performs login. The system displays the ‘Admin Menu’

  2. The system administrator selects the option

  3. The system performs the action

Alternative courses

NA

Associated use case diagrams/sequence diagrams/collaboration diagrams

The use case diagram is created in a Rose model called ‘MTS.mdl’. The sequence diagrams are created under the package ‘Logical view\Use case realization’ within the use case realization called ‘Manage system’. The sequence diagram is shown in the Annexure.

Exceptions

NA

Includes

NA

Special requirements

NA

Assumptions

NA

Notes and issues

NA

As the next step, the use case behaviour should be spread out to the classes. For this we can perform the following activities for each use case flow of events:

  • Identify analysis classes

  • Allocate use case responsibilities to analysis classes

  • Model analysis class interactions in interaction diagrams

Corresponding to each of these major components in the system, analysis classes were defined, which included classes for the following:

  • Mobile network interface

  • Web server and application server

  • Database server

  • Mobile device browser

  • Remote access server

  • Administration server

  • OTPI and CAI

Analysis classes were identified for each actor/use case pair. Analysis classes are later grouped and regrouped to come up with actual packages, components, sub-systems, and so on.

Three types of classes were defined: entity class, boundary class and control class. Boundary classes interact with external systems. They are the intermediates between the interface and classes outside the system and are environment dependent. The classes outside the system can be of the following types:

  • User interface classes

  • System interface classes

  • Device interface classes

There is only one boundary class per actor/use case pair.

Control classes represent the actual use case behaviour. There is one control class per use case. The entity classes represent the key abstractions of the system and stores the related information.

Figure 5.7 shows the purpose of each of these class types.

Figure 5.7. Analysis classes for a software system

To allocate the responsibilities to the classes, we can use the following guidelines:

  • Behaviour that involves communication with an actor should be assigned to boundary classes.

  • Behaviour that involves the data encapsulated within the abstraction should be assigned to entity classes.

  • Behaviour specific to a use case or part of a very important flow of events should be assigned to control classes.

As the next step, the interaction among the classes should be modelled in the form of interaction diagrams. Sequence diagrams and class collaboration diagrams (from the UML notation) fit into this. Next, the team created sequence diagrams for the use cases. These were created both for the normal and alternative flows that describe the other options available, in case the normal flow of events does not take place.

Sequence Diagrams

Figures 5.8 and 5.9 are sequence diagrams that were created during the detailed design phase. The ‘Personalize profile’ sequence diagram shows the steps that the user takes to personalize his profile. Similarly, the ‘Retrieve information’ diagram details the steps to retrieve and store information from the content server.

Figure 5.8. Sequence diagram for the ‘Personalize profile’ use case

Figure 5.9. Sequence diagram for the ‘Retrieve and store information’ use case

As the last step, the team grouped the real-world objects illustrated in the sequence diagrams into classes and packages. Hence, the classes were re-grouped and re-distributed as packages. The redundant classes were removed. Further, the packages can be grouped as sub-components, where each sub-component can be a component as described by the architecture.

Class Diagrams

The two class diagrams shown in Figures 5.10 and 5.11 give a mapping of the system to real-world components. Once we have the class diagrams we are ready to construct the actual system.

Figure 5.10. Class diagram for the ‘Personalize form’ use case

Figure 5.11. Class diagram for the ‘Retrieve and store information’ use case

Conclusions

The architecture of the system acts as a blueprint for the design phase. It is often represented as a set of interconnected modules or sub-systems that are organizational structures that structure the source code. Representing the architecture in terms of design elements helps in finding the interdependencies that govern the interfaces between modules.

Design is a very important phase in the software development life cycle for several reasons:

  • Thinking in advance always helps (and it is cheap!)

  • Cannot add quality at the end: this is in contrast to reliance on testing, more effective and much cheaper

  • Makes delegation and teamwork possible

  • Design flaws affect user: incoherent, inflexible and hard to use software

  • Design flaws affect developer: poor interfaces, bugs multiply and hard to add new features

Design activities are usually classified into two stages: preliminary (or high level) design and detailed. At the high-level design we first identify modules, control relationships among modules and interfaces among modules. The outcome of high-level design is a program structure (or software architecture). Several notations are available to represent high-level design, usually a tree-like diagram called structure chart. For each module, design data structure and algorithm, a high-level design maps functions into modules such that

  • Each module has high cohesion

  • Coupling among modules is as low as possible

  • Modules are organized in a neat hierarchy

The outcome of detailed design is module specification. A good design should implement all functionalities of the system correctly. It should be easily understandable, efficient and easily amenable to change, that is, easily maintainable. Understanding a design is a major issue as it determines the quality of the design; a design that is easy to understand is also easy to maintain and change. Unless a design is easy to understand, tremendous effort is needed to maintain it. A design having modules with high fan-out numbers is not a good design and lacks cohesion.

The characteristics of a good conceptual design include the following: it is in the customer’s language with no technical jargon, describes system functions, is independent of implementation up to a point and is linked to requirements.

Designing is not an ad hoc process. We can make the design process systematic and structured. This will add to the features of design by reducing errors and ambiguity, improving the readability and, most importantly, will ensure that the design is consistent and complete.

Best Practices and Key Lessons from the Case Study

  • A good system design is based on a sound conceptual model (architecture). A system design that has no conceptual structure and little logic to its organization is ultimately going to be unsuccessful. Good architecture will address all the requirements of the system at the right level of abstraction.

  • Consider the exceptional scenarios that lead to system failure in the design.

  • A good conceptual model is easy to communicate: Ease of communication of the conceptual model on which the design is based is essential for successful solutions.

  • Keep it simple and practice information hiding: Minimizing complexity and information hiding is perhaps the most powerful design heuristic because it explicitly focuses on hiding details.

  • Design for re-use: Re-factor classes to distribute responsibilities and behaviour.

  • To come up with a robust design there needs to be clarity of requirements.

  • Selecting a proper methodology for development based on the requirements and resources is the first step towards a good design.

  • Prioritizing requirements and charting use cases help produce a sound conceptual model.

  • Using case tools like Rational Rose to document the use case analysis aids in faster development and is useful to produce standard artefacts that ease communication of design issues and objectives.

  • From the block diagram of the system and the use case flow of events the boundary, entity and control classes can be identified to draw the sequence diagrams.

  • Class diagrams help map real-world entities to software. They present the static structural model of the system and help identify the relationships between the classes.

  • The design for the system must be flexible enough to be able to accommodate future changes.

  • An open environment in the team is recommended and user interaction is required to come with a strong set of relevant goals to aid design.

  • Good design is seldom arrived through a single-step procedure. It is arrived through a series of steps and iterations.

  • Important design considerations include the following:

    • Component independence

    • Coupling (degree of inter-dependence)

    • Cohesion (degree of internal relatedness)

    • Exception identification and handling

    • Fault prevention and tolerance

    • Active considerations (code to periodically check, react, etc.)

    • Passive considerations (code to assert, throw exceptions, etc.)

Further Reading

There are several good books on general software design. Some of the books we recommend are Object Oriented Analysis and Design With Applications by Grady Booch (Pearson Education) and Software Design by David Budgen (Pearson Education).

The software design concepts are also well covered in some of the undergraduate books on software engineering, including Software Engineering (7th edition) by Ian Sommerville (Addison Wesley) and Software Engineering Concepts by Richard Fairley (McGraw Hill).

Software Engineering Institute has some useful resources on this topic. Refer www.sei.cmu.edu/str/descriptions/oodesign.html for details.

Design patterns can be learnt from several sources. We have given some pointers at the end of the first chapter. Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (Addison-Wesley) is the original and is still one of the best books on this topic.

The Unified Software Development Process by Ivar Jacobson, Grady Booch and James Rumbaugh (Pearson Education) gives good design fundamentals using UML.

We were also benefited by an old article written by D. L. Parnas and D. Weiss on Active Design Reviews: Principles and Practices (Proceedings of Eighth International Conference on Software Engineering, 1985).