The data design transforms the information domain model created during analysis into the data structures that will be required to implement the software. The data objects and relationships
80 defined in the entity relationship diagram and the detailed data content depicted in the data dictionary provide the basis for the data design activity. Part of data design may occur in conjunction with the design of software architecture. More detailed data design occurs as each software component is designed.
The architectural design defines the relationship between major structural elements of the software, the “design patterns” that can be used to achieve the requirements the system architecture, the interface representation, and the component level detail. During each design activity, we apply basic concepts and principles that lead to high quality. The architectural design representation the framework of a computer based system can be derived from the system specification, the analysis model, and the interaction of subsystems defined within the analysis model.
The interface design describes how the software communicates within itself, with systems that interoperate with it, and with humans who use it. An interface implies a flow of information and a specific type of behavior. Therefore, data and control flow diagrams provide much of the information required for interface design.
The component-level design transforms structural elements of the software architecture into a procedural description of software components. Information obtained from the PSPEC, CSPEC, and STD serve as the basis for component design. During design we make decisions that will ultimately affect the success of software construction and, as important, the ease with which software can be maintained. The importance of software design can be stated with a single word quality.
Design is the place where quality is fostered in software engineering. Design provides us with representations of software that can be assessed for quality. Design is the only way that we can accurately translate a customer's requirements into a finished software product or system. Software design serves as the foundation for all the software engineering and software support steps that follow. Without design, we risk building an unstable system one that will fail when small changes are made; one that may be difficult to test; one whose quality cannot be assessed until late in the software process, when time is short and many dollars have already been spent.
9.2 THE DESIGN PROCESS
Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software. Initially, the blueprint depicts a holistic view of software. That is, the design is represented at a high level of abstraction a level that can be directly traced to the specific system objective and more detailed data, functional, and behavioral requirements. As design iterations occur, subsequent refinement leads to design representations at much lower levels of abstraction. These can still be traced to requirements, but the connection is more subtle.
81 9.2.1 DESIGN AND SOFTWARE QUALITY
Throughout the design process, the quality of the evolving design is assessed with a series of formal technical reviews or design walkthroughs. McGlaughlin suggests three characteristics that serve as a guide for the evaluation of a good design:
The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.
The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
Each of these characteristics is actually a goal of the design process. But how is each of these goals achieved? In order to evaluate the quality of a design representation, we must establish technical criteria for good design. Later in this Lesson, we discuss design quality criteria in some detail. For the time being, we present the following guidelines:
A design should exhibit an architectural structure that
(1) has been created using recognizable design patterns,
(2) is composed of components that exhibit good design characteristics, and
(3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.
A design should be modular; that is, the software should be logically partitioned into elements that perform specific functions and subfunctions.
A design should contain distinct representations of data, architecture, interfaces, and components (modules).
A design should lead to data structures that are appropriate for the objects to be implemented and are drawn from recognizable data patterns.
A design should lead to components that exhibit independent functional characteristics.
A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment.
A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
These criteria are not achieved by chance. The software design process encourages good design through the application of fundamental design principles, systematic methodology, and thorough review.
9.2.2 THE EVOLUTION OF SOFTWARE DESIGN
The evolution of software design is a continuing process that has spanned the past four decades. Early design work concentrated on criteria for the development of modular programs
82 and methods for refining software structures in a top-down manner. Procedural aspects of design definition evolved into a philosophy called structured programming. Later work proposed methods for the translation of data flow or data structure, into a design definition. Newer design approaches proposed an object-oriented approach to design derivation. Today, the emphasis in software design has been on software architecture and the design patterns that can be used to implement software architectures.
Many design methods, growing out of the work just noted, are being applied throughout the industry. Yet, all of these methods have a number of common characteristics:
(1) a mechanism for the translation of analysis model into a design representation, (2) a notation for representing functional components and their interfaces,
(3) heuristics for refinement and partitioning, and (4) guidelines for quality assessment.
Regardless of the design method that is used, a software engineer should apply a set of fundamental principles and basic concepts to data, architectural, interface and component-level design. Making design of object-oriented software is very hard and designing reusable object oriented software is even harder.
9.3 OBJECT ORIENTED DESIGN
The design of object oriented software requires the definition of a multilayered software architecture, the specification of subsystems that perform required functions and provide infrastructure support, a description of objects that form the building blocks of the system, and a description of the communication mechanisms that allow data to flow between layers, subsystems, and objects. Object-oriented design accomplishes all of these things.
An object-oriented system draws upon class definitions that are derived from the analysis model. Some of these definitions will have to be built from scratch, but many others may be reused if appropriate design patterns are recognized. OOD establishes a design blueprint that enables a software engineer to define the OO architecture in a manner that maximizes reuse, thereby improving development speed and end product quality.
OOD is divided into two major activities that are, system design and
object design
System design creates the product architecture, defining a series of “layers” that accomplish specific system functions and identifying the classes that are encapsulated by subsystems that reside at each layer. In addition, system design considers the specification of three components: the user interface, data management functions, and task that is the building block of an OO system. In addition, OOD must describe the specific data organization of attributes and the procedural detail of each individual operation.
These represent data and algorithmic pieces of an OO system and are contributors to overall modularity. The unique nature of object-oriented design lies in its ability to build upon four
83 important software design concepts: abstraction, information hiding, functional independence, and modularity. All design methods strive for software that exhibits these fundamental characteristics, but only OOD provides a mechanism that enables the designer to achieve all four without complexity or compromise. Object-oriented design, object-oriented programming, and object-oriented testing are construction activities for OO systems. In this Lesson, we consider the first step in construction.
9.4 DESIGN FOR OBJECT-ORIENTED SYSTEMS
The subsystem layer contains a representation of each of the subsystems that enable the software to achieve its customer-defined requirements and to implement the technical infrastructure that supports customer requirements.
The class and object layer contains the class hierarchies that enable the system to be created using generalizations and increasingly more targeted specializations. This layer also contains representations of each object.
The message layer contains the design details that enable each object to communicate with its collaborators. This layer establishes the external and internal interfaces for the system.
The responsibilities layer contains the data structure and algorithmic design for all attributes and operations for each object. management facilities. Object design focuses on the internal detail of individual classes, defining attributes, operations, and message detail.
An OO design model encompasses software architecture, user interface description, data management components, task management facilities, and detailed descriptions of each class to be used in the system. At each stage, the elements of the object-oriented design model are reviewed for clarity, correctness, completeness, and consistency with customer requirements and with one another.
The design pyramid focuses exclusively on the design of a specific product or system. It should be noted, however, that another “layer” of design exists, and this layer forms the foundation on which the pyramid rests. The foundation layer focuses on the design of domain
objects. Domain objects play a key role in building the infrastructure for the OO system by
providing support for human/computer interface activities, task management, and data management. Domain objects can also be used to flesh out the design of the application itself.
9.5 CONVENTIONAL VS. OBJECT ORIENTED APPROACHES
Conventional approaches to software design apply a distinct notation and set of heuristics to map the analysis model into a design model. Recalling Figure 8.1, each element of the conventional analysis model maps into one or more layers of the design model. Like conventional software design, OOD applies data design when attributes are represented, interface design when a messaging model is developed, and component-level design for the design of operations. It is important to note that the architecture of an OO design has more to do with the collaborations among objects than with the flow of control between components of the system.
84 Although similarity between the conventional and OO design models does exist, we have chosen to rename the layers of the design pyramid to reflect more accurately the nature of an OO design. Figure 9.1 illustrates the relationship between the OO analysis model and design model that will be derived from it. The subsystem design is derived by considering overall customer requirements and the events and states that are externally observable. Class and object design is mapped from the description of attributes, operations, and collaborations contained in the CRC model. Message design is driven by the object-relationship model, and responsibilities design is derived using the attributes, operations, and collaborations described in the CRC model.