Chapter 3. SOFTWARE DESIGN

ACRONYMS
ADL: Architecture Description Languages
CRC: Class Responsibility Collaborator card
ERD: Entity-Relationship Diagram
IDL: Interface Description Language
DFD: Data Flow Diagram
PDL: Pseudo-Code and Program Design Language
CBD: Component-Based design

Design is defined in [IEEE610.12-90] as both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of [that] process.” Viewed as a process, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction. More precisely, a software design (the result) must describe the software architecture—that is, how software is decomposed and organized into components—and the interfaces between those components. It must also describe the components at a level of detail that enable their construction. Software design plays an important role in developing software: it allows software engineers to produce various models that form a kind of blueprint of the solution to be implemented. We can analyze and evaluate these models to determine whether or not they will allow us to fulfill the various requirements. We can also examine and evaluate various alternative solutions and trade-offs. Finally, we can use the resulting models to plan the subsequent development activities, in addition to using them as input and the starting point of construction and testing.

Software design consists of two activities that fit between software requirements analysis and software construction:
- Software architectural design (sometimes called toplevel design): describing software’s top-level structure
and organization and identifying the various components
- Software detailed design: describing each component sufficiently to allow for its construction.

The Software Design KA description is related specifically to Software Requirements, Software Construction, Software Engineering Management, Software Quality, and Related Disciplines of Software Engineering.

1. Software Design Fundamentals
The concepts, notions, and terminology introduced here form an underlying basis for understanding the role and scope of software design.

1.1. General Design Concepts
Software is not the only field where design is involved. In the general sense, we can view design as a form of problemsolving. For example, the concept of a wicked problem–a problem with no definitive solution–is interesting in terms of understanding the limits of design. A number of other notions and concepts are also of interest in understanding design in its general sense: goals, constraints, alternatives, representations, and solutions.

1.2. Context of Software Design
To understand the role of software design, it is important to understand the context in which it fits, the software engineering life cycle. Thus, it is important to understand the major characteristics of software requirements analysis vs. software design vs. software construction vs. software testing.

1.3. Software Design Process
Software design is generally considered a two-step process:
1.3.1. Architectural design
Architectural design describes how software is decomposed and organized into components (the software architecture)
1.3.2. Detailed design
Detailed design describes the specific behavior of these components. The output of this process is a set of models and artifacts that record the major decisions that have been taken.

1.4. Enabling Techniques
According to the Oxford English Dictionary, a principle is “a basic truth or a general law … that is used as a basis of reasoning or a guide to action.” Software design principles, also called enabling techniques, are key notions considered fundamental to many different software design approaches and concepts. The enabling techniques are the following:
1.4.1. Abstraction
Abstraction is “the process of forgetting information so that things that are different can be treated as if

they were the same.” In the context of software design, two key abstraction mechanisms are parameterization and specification. Abstraction by specification leads to three major kinds of abstraction: procedural abstraction, data abstraction, and control (iteration) abstraction. 

1.4.2. Coupling and cohesion

Coupling is defined as the strength of the relationships between modules, whereas cohesion is defined by how the elements making up a module are related.
1.4.3. Decomposition and modularization
Decomposing and modularizing large software into a number of smaller independent ones, usually with
the goal of placing different functionalities or responsibilities in different components.
1.4.4. Encapsulation/information hiding
Encapsulation/information hiding means grouping and packaging the elements and internal details of an
abstraction and making those details inaccessible.
1.4.5. Separation of interface and implementation
Separating interface and implementation involves defining a component by specifying a public
interface, known to the clients, separate from the details of how the component is realized.

1.4.6. Sufficiency, completeness and primitiveness

Achieving sufficiency, completeness, and primitiveness means ensuring that a software component captures all the important characteristics of an abstraction, and nothing more.

2. Key Issues in Software Design
A number of key issues must be dealt with when designing software. Some are quality concerns that all software must address—for example, performance. Another important issue is how to decompose, organize, and package software components. This is so fundamental that all design approaches must address it in one way or another. In contrast, other issues “deal with some aspect of software’s behavior that is not in the application domain, but which addresses some of the supporting domains.” Such issues, which often cross-cut the system’s functionality, have been referred to as aspects: “[aspects] tend not to be units of software’s functional decomposition, but rather to be properties that affect the performance or semantics of the components in systemic ways”. A number of these key, cross-cutting issues are the following (presented in alphabetical order):
2.1. Concurrency
How to decompose the software into processes, tasks, and threads and deal with related efficiency, atomicity, synchronization, and scheduling issues.
2.2. Control and Handling of Events
How to organize data and control flow, how to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs.
2.3. Distribution of Components
How to distribute the software across the hardware, how the components communicate, how middleware can be used to deal with heterogeneous software.
2.4. Error and Exception Handling and Fault Tolerance
How to prevent and tolerate faults and deal with exceptional conditions.
2.5. Interaction and Presentation
How to structure and organize the interactions with users and the presentation of information (for example,
separation of presentation and business logic using the Model-View-Controller approach). It is to be noted that this topic is not about specifying user interface details, which is the task of user interface design (a part of Software Ergonomics); see Related Disciplines of Software Engineering.
2.6. Data Persistence
How long-lived data are to be handled.

3. Software Structure and Architecture
In its strict sense, a software architecture is “a description of the subsystems and components of a software system and the relationships between them.” Architecture thus attempts to define the internal structure
— according to the Oxford English Dictionary, “the way in which something is constructed or organized” — of the resulting software. During the mid-1990s, however, software architecture started to emerge as a broader discipline involving the study of software structures and architectures in a more generic way. This gave rise to a number of interesting ideas about software design at different levels of abstraction. Some of these concepts can be useful during the architectural design (for example, architectural style) of specific software, as well as during its detailed design (for example, lower-level design patterns). But they can also be useful for designing generic systems, leading to the design of families of programs (also known as product lines). Interestingly, most of these concepts can be seen as attempts to describe, and thus reuse, generic design knowledge.

3.1. Architectural Structures and Viewpoints
Different high-level facets of a software design can and should be described and documented. These facets are often called views: “A view represents a partial aspect of a software architecture that shows specific properties of a software system”. These distinct views pertain to distinct issues associated with software design — for example, the logical view (satisfying the functional requirements) vs. the process view (concurrency issues) vs. the physical view (distribution issues) vs. the development view (how the design is broken down into implementation units). Other authors use different terminologies, like behavioral vs. functional vs. structural vs. data modeling views. In summary, a software design is a multi-faceted artifact produced by the design process and generally composed of relatively independent and orthogonal views.
Architectural Styles (macroarchitectural patterns) An architectural style is “a set of constraints on an
architecture [that] defines a set or family of architectures that satisfies them”. An architectural style can thus be seen as a meta-model which can provide software’s high-level organization (its macroarchitecture). Various authors have identified a number of major architectural styles.
- General structure (for example, layers, pipes, and filters, blackboard).
- Distributed systems (for example, client-server, threetiers, broker)
- Interactive systems (for example, Model-View-Controller, Presentation-Abstraction-Control)
- Adaptable systems (for example, micro-kernel, reflection)
- Others (for example, batch, interpreters, process control, rule-based).

3.2. Design Patterns (microarchitectural patterns)
Succinctly described, a pattern is “a common solution to a common problem in a given context.” While
architectural styles can be viewed as patterns describing the high-level organization of software (their
macroarchitecture), other design patterns can be used to describe details at a lower, more local level (their
microarchitecture).
- Creational patterns (for example, builder, factory, prototype, and singleton)
- Structural patterns (for example, adapter, bridge, composite, decorator, façade, flyweight, and proxy)
- Behavioral patterns (for example, command, interpreter, iterator, mediator, memento, observer, state,
strategy, template, visitor)

3.3. Families of Programs and Frameworks
One possible approach to allow the reuse of software designs and components is to design families of software, also known as software product lines. This can be done by identifying the commonalities among members of such families and by using reusable and customizable components to account for the variability among family members. In OO programming, a key related notion is that of the framework: a partially complete software subsystem that can be extended by appropriately instantiating specific plug-ins (also known as hot spots).