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.
In a standard listing of software life cycle processes such as IEEE/EIA 12207 Software Life Cycle Processes [IEEE12207.0-96], software design consists of two activities that fit between software requirements analysis and software construction:
Concerning the scope of the Software Design Knowledge Area (KA), the current KA description does not discuss every topic the name of which contains the word "design." In Tom DeMarco's terminology (DeM99), the KA discussed in this chapter deals mainly with D-design (decomposition design, mapping software into component pieces). However, because of its importance in the growing field of software architecture, we will also address FPdesign (family pattern design, whose goal is to establish exploitable commonalities in a family of software). By contrast, the Software Design KA does not address I-design (invention design, usually performed during the software requirements process with the objective of conceptualizing and specifying software to satisfy discovered needs and requirements), since this topic should be considered part of requirements analysis and specification.
The Software Design KA description is related specifically to Software Requirements, Software Construction, Software Engineering Management, Software Quality, and Related Disciplines of Software Engineering.
The concepts, notions, and terminology introduced here form an underlying basis for understanding the role and scope of software design.
Software is not the only field where design is involved. In the general sense, we can view design as a form of problem-solving. [Bud03:c1] For example, the concept of a wicked problem - a problem with no definitive solution - is interesting in terms of understanding the limits of design. [Bud04:c1] A number of other notions and concepts are also of interest in understanding design in its general sense: goals, constraints, alternatives, representations, and solutions. [Smi93]
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. [IEEE12207.0-96]; Lis01:c11; Mar02; Pfl01:c2; Pre04:c2]
Software design is generally considered a two-step process: [Bas03; Dor02:v1c4s2; Fre83:I; IEEE12207.0-96]; Lis01:c13; Mar02:D]
Architectural design describes how software is decomposed and organized into components (the software architecture) [IEEEP1471-00]
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. [Bud04:c2; IEE1016-98; Lis01:c13; Pre04:c9]
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 [Bus96], are key notions considered fundamental to many different software design approaches and concepts. The enabling techniques are the following: [Bas98:c6; Bus96:c6; IEEE1016-98; Jal97:c5,c6; Lis01:c1,c3; Pfl01:c5; Pre04:c9]
Abstraction is "the process of forgetting information so that things that are different can be treated as if they were the same." [Lis01] 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. [Bas98:c6; Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1]
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. [Bas98:c6; Jal97:c5; Pfl01:c5; Pre04:c9]
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. [Bas98:c6; Bus96:c6; Jal97 :c5; Pfl01:c5; Pre04:c9]
Encapsulation/information hiding means grouping and packaging the elements and internal details of an abstraction and making those details inaccessible. [Bas98:c6; Bus96:c6; Jal97:c5; Pfl01:c5; Pre04:c9]
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. [Bas98:c6; Bos00:c10; Lis01:c1,c9]
Achieving sufficiency, completeness, and primitiveness means ensuring that a software component captures all the important characteristics of an abstraction, and nothing more. [Bus96:c6; Lis01:c5]
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 (see topic 1.4 Enabling Techniques and subarea 6 Software Design Strategies and Methods). 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." [Bos00] 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" (Kic97). A number of these key, cross-cutting issues are the following (presented in alphabetical order):
How to decompose the software into processes, tasks, and threads and deal with related efficiency, atomicity, synchronization, and scheduling issues. [Bos00:c5; Mar02:CSD; Mey97:c30; Pre04:c9]
How to organize data and control flow, how to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs. [Bas98:c5; Mey97:c32; Pfl01:c5]
How to distribute the software across the hardware, how the components communicate, how middleware can be used to deal with heterogeneous software. [Bas03:c16; Bos00:c5; Bus96:c2 Mar94:DD; Mey97:c30; Pre04:c30]
How to prevent and tolerate faults and deal with exceptional conditions. [Lis01:c4; Mey97:c12; Pfl01:c5]
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). [Bas98:c6; Bos00:c5; Bus96:c2; Lis01:c13; Mey97:c32] 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.
How long-lived data are to be handled. [Bos00:c5; Mey97:c31]
In its strict sense, a software architecture is "a description of the subsystems and components of a software system and the relationships between them." (Bus96:c6) 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 [Sha96]. 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.
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" [Bus96:c6]. 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. [Bas03:c2; Boo99:c31; Bud04:c5; Bus96:c6; IEEE1016-98; IEEE1471-00]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" [Bas03:c2]. 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. [Bas03:c5; Boo99:c28; Bos00:c6; Bus96:c1,c6; Pfl01:c5]
Succinctly described, a pattern is "a common solution to a common problem in a given context." (Jac99) 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). [Bas98:c13; Boo99:c28; Bus96:c1; Mar02:DP]
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. [Bos00:c7,c10; Bas98:c15; Pre04:c30]
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). [Bos00:c11; Boo99:c28; Bus96:c6]
This section includes a number of quality and evaluation topics that are specifically related to software design. Most are covered in a general manner in the Software Quality KA.
Various attributes are generally considered important for obtaining a software design of good quality - various "ilities" (maintainability, portability, testability, traceability), various "nesses" (correctness, robustness), including "fitness of purpose." [Bos00:c5; Bud04:c4; Bus96:c6; ISO9126.1-01; ISO15026-98; Mar94:D; Mey97:c3; Pfl01:c5] An interesting distinction is the one between quality attributes discernable at run-time (performance, security, availability, functionality, usability), those not discernable at run-time (modifiability, portability, reusability, integrability, and testability), and those related to the architecture's intrinsic qualities (conceptual integrity, correctness, and completeness, buildability). [Bas03:c4]
Various tools and techniques can help ensure a software design's quality.
Measures can be used to assess or to quantitatively estimate various aspects of a software design's size, structure, or quality. Most measures that have been proposed generally depend on the approach used for producing the design. These measures are classified in two broad categories:
Many notations and languages exist to represent software design artifacts. Some are used mainly to describe a design's structural organization, others to represent software behavior. Certain notations are used mostly during architectural design and others mainly during detailed design, although some notations can be used in both steps. In addition, some notations are used mostly in the context of specific methods (see the Software Design Strategies and Methods subarea). Here, they are categorized into notations for describing the structural (static) view vs. the behavioral (dynamic) view.
The following notations, mostly (but not always) graphical, describe and represent the structural aspects of a software design - that is, they describe the major components and how they are interconnected (static view):
The following notations and languages, some graphical and some textual, are used to describe the dynamic behavior of software and components. Many of these notations are useful mostly, but not exclusively, during detailed design.
There exist various general strategies to help guide the design process. [Bud04:c9, Mar02:D] In contrast with general strategies, methods are more specific in that they generally suggest and provide a set of notations to be used with the method, a description of the process to be used when following the method and a set of guidelines in using the method. [Bud04:c8] Such methods are useful as a means of transferring knowledge and as a common framework for teams of software engineers. [Bud03:c8] See also the Software Engineering Tools and Methods KA.
Some often-cited examples of general strategies useful in the design process are divide-and-conquer and stepwise refinement [Bud04:c12; Fre83:V], top-down vs. bottom-up strategies [Jal97:c5; Lis01:c13], data abstraction and information hiding [Fre83:V], use of heuristics [Bud04:c8], use of patterns and pattern languages [Bud04:c10; Bus96:c5], use of an iterative and incremental approach. [Pfl01:c2]
This is one of the classical methods of software design, where decomposition centers on identifying the major software functions and then elaborating and refining them in a top-down manner. Structured design is generally used after structured analysis, thus producing, among other things, data flow diagrams and associated process descriptions. Researchers have proposed various strategies (for example, transformation analysis, transaction analysis) and heuristics (for example, fan-in/fan-out, scope of effect vs. scope of control) to transform a DFD into a software architecture generally represented as a structure chart.
Numerous software design methods based on objects have been proposed. The field has evolved from the early object-based design of the mid-1980s (noun = object; verb = method; adjective = attribute) through OO design, where inheritance and polymorphism play a key role, to the field of component-based design, where meta-information can be defined and accessed (through reflection, for example). Although OO design's roots stem from the concept of data abstraction, responsibility-driven design has also been proposed as an alternative approach to OO design.
Data-structure-centered design (for example, Jackson, Warnier-Orr) starts from the data structures a program manipulates rather than from the function it performs. The software engineer first describes the input and output data structures (using Jackson's structure diagrams, for instance) and then develops the program's control structure based on these data structure diagrams. Various heuristics have been proposed to deal with special cases, for example, when there is a mismatch between the input and output structures.
A software component is an independent unit, having well-defined interfaces and dependencies that can be composed and deployed independently. Component-based design addresses issues related to providing, developing, and integrating such components in order to improve reuse. [Bud04:c11]
Other interesting but less mainstream approaches also exist: formal and rigorous methods [Bud04:c18; Dor02:c5; Fre83; Mey97:c11; Pre04:c29] and transformational methods. [Pfl98:c2]
[Smi93] G. Smith and G. Browne, "Conceptual Foundations of Design Problem-Solving," IEEE Transactions on Systems, Man and Cybernetics, vol. 23, iss. 5, 1209-1219, Sep.-Oct. 199uuid=efc2659c-9ab3-4e12-9d1e-9e29c1f702b7&groupId=319895NDIX A. LIST OF FURTHER READINGS