Design Modeling Principles
The software design model is analogous to an architect's plans for a house. It begins by representing the totality of the thing to be built (e.g., a three-dimensional rendering of the house) and slowly refines the thing to provide guidance for constructing each detail (e.g., the plumbing layout). Similarly, the design model that is created for software provides a variety of different views of the system.
There is no shortage of methods for deriving the various elements of a software design. Some methods are data-driven, allowing the data structure to dictate the program architecture and the resultant processing components. Others are pattern-driven, using information about the problem domain (the requirements model to develop architectural styles and processing patterns. Still, others are object-oriented, using problem domain objects as the driver for the creation of data structures and the methods that manipulate them. Yet all embrace a set of design principles that can be applied regardless of the method that is used:
Principle 1. The design should be traceable to the requirements model. The requirements model describes the information domain of the problem, user-visible functions, system behavior, and a set of requirements classes that package business objects with the methods that service them. The design model translates this information into architecture, a set of subsystems that implement major functions, and a set of components that are the realization of requirements classes. The elements of the design model should be traceable to the requirements model.
Principle 2. Always consider the architecture of the system to be built. Software architecture is the skeleton of the system to be built. It affects interfaces, data structures, program control flow and behavior, the manner in which testing can be conducted, the maintainability of the result-anti system, and much more. For all of these reasons, the design should start with architectural considerations. Only after the architecture has been established should component-level issues be considered.
Principle 3. The design of data is as important as the design of processing functions. Data design is an essential element of architectural design. The manner in which data objects are realized within the design cannot be left to chance. A well-structured data design helps to simplify program flow, makes the design and implementation of software components easier, and makes overall processing more efficient.
Principle 4. Interfaces (both internal and external) must be designed with care. The manner in which data flows between the components of a system has much to do with processing efficiency, error propagation, and design simplicity. A well-designed interface makes integration easier and assists the tester in validating component functions.
Principle 5. User interface design should be tuned to the needs of the end-user. However, in every case, it should stress ease of use. The user interface is the visible manifestation of the software. No matter how sophisticated its internal functions, no matter how comprehensive its data structures, no matter how well designed its architecture, a poot interface design often leads to the perception that the software is "bad."
Principle 6. The component-level design should be functionally independent. Functional independence is a measure of the "single-mindedness" of a software component. The functionality that is delivered by a component should be cohesive- that is, it should focus on one and only one function or subfunction.
Principle 7. Components should be loosely coupled to one another and to the external environment. Coupling is achieved in many ways via a component interface, by messaging, through global data. As the level of coupling increases, the likelihood of error propagation also increases, and the overall maintainability of the software decreases. Therefore, the component coupling should be kept as low as is reasonable.
Principle 8. Design representations (models) should be easily understandable. The purpose of design is to communicate information to practitioners who will generate code, to those who will test the software, and to others who may maintain the software in the future. If the design is difficult to understand, it will not serve as an effective communication medium.
Principle 9. The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity. Like almost all creative activities, design occurs iteratively. The first iterations work to refine the design and correct errors, but later iterations should strive to make the design as simple as is possible.
When these design principles are properly applied, you create a design that exhibits both external and internal quality factors [Mye78]. External quality factors are those properties of the software that can be readily observed by users (e.g., speed, reliability, correctness, usability). Internal quality factors are of importance to software engineers. They lead to a high-quality design from a technical perspective.
0 Comments