6.1: Software Design Principles
In the design phase of the SDLC, we encounter new principles in addition to those we have seen in prior phases. What are some of those principles? Do you remember abstraction, analysis vs. design, data vs. procedure? Note that different terms often represent the same or similar principle: "hierarchy" is related to abstraction, "problem domain vs. solution domain" corresponds to analysis vs. design, "static vs. behavior" corresponds to data vs. procedure, and so on. Principles apply to all activities and phases of the SDLC. Further, each phase has models describing a phase's products and activities. The models for each phase, however, are compatible. Thus, we will see that design models are compatible with requirements models.
This section gives insight into software design principles: abstraction, coupling and cohesion, decomposition and modularization, encapsulation/information hiding, separation of interface and implementation, sufficiency and completeness, and primitiveness. Software architecture discusses architectural views and design strategies (function-oriented, data-oriented, and object-oriented. The transition from "what" (the problem domain) to the "how" (the solution domain) takes place in the design phase from high-level to detail-level design.
We have studied UML diagrams for the requirements phase of the SDLC, particularly use case and sequence diagrams. In addition, we have read about other UML diagrams (like static or structure diagrams) and other concept modeling diagrams (like entity-relation diagrams). We focused on use cases and sequence ones because those provide key support in capturing requirements and transitioning to design. In design, the diagrams created in the Requirements phase are extended by adding details to those diagrams or creating other diagrams (like collaboration diagrams). It is important to recognize the concepts represented in each type of diagram and that a diagram is a language for communicating those concepts. Those concepts can be represented in different ways, involving one type of diagram, several types of diagrams, or a diagram and associated narratives. Recall the detailed textual/narrative information for contracts associated with a use case diagram; also, recall the references we've made to other or optional or additional textual information. These concepts will be elaborated by evolving their diagram representations in the design and construction phases.