Desirable Design Characteristics and Levels of Decomposition

Key Insight

A high-quality software design exhibits several internal characteristics that, while sometimes conflicting, contribute to overall system excellence. Foremost among these is minimal complexity, prioritizing simple and easy-to-understand designs over 'clever' ones, allowing developers to focus on specific parts without needing to grasp the entire program. Ease of maintenance is crucial, necessitating designs that are self-explanatory to future maintenance programmers. Loose coupling ensures minimal interconnections between program parts through good abstractions, encapsulation, and information hiding, which simplifies integration, testing, and maintenance.

Further desirable characteristics include extensibility, enabling system enhancements without disrupting the underlying structure; reusability, allowing system components to be used in other applications; and portability, facilitating easy migration to different environments. Design also benefits from high fan-in, indicating effective use of common utility classes, and low-to-medium fan-out (ideally not exceeding about seven), suggesting that a class does not depend on an overly complex number of other classes. Leanness, embodying the principle that a product is finished not when nothing more can be added but when nothing more can be taken away, emphasizes avoiding superfluous code to reduce development, testing, and maintenance overhead. Stratification maintains consistent views across decomposition levels, for example, by isolating interactions with problematic legacy code in a dedicated interface layer. Finally, employing standard techniques lends a familiar feeling to the system, making it more approachable.

Design is applied across distinct levels of detail within a software system. It begins at Level 1, encompassing the entire software system. Level 2 involves the division into major subsystems or packages (e.g., database, user interface, business rules), where the primary activity is defining communication rules to restrict interactions on a 'need to know' basis, ideally forming an acyclic graph to prevent circular dependencies. Common subsystems include business rules, user interfaces, database access, and system dependencies, which encapsulate specific concerns. Level 3 focuses on dividing subsystems into individual classes, defining their interfaces and ensuring sufficient detail for implementation. Level 4 details the division of each class into routines, including private ones, often refining the class's interface. Finally, Level 5, internal routine design, involves laying out the detailed functionality of individual routines, such as writing pseudocode or selecting algorithms, which is always performed, even if unconsciously.