CS302: Software Engineering

6a. Use software design principles

1. What are the software design principles?
2. What is the purpose of the software design principles?

Design principles include information hiding, modularization, cohesion, and coupling. These principles are applicable to the 'divide and conquer' problem solving strategy that is most often used in system design. 'Divide and conquer' decomposes a large problem or task into smaller ones that we can solve. The decomposition may be repeated several times until a level of problems or tasks is reached that are solvable. A decomposition of the problem or task is represented in the Requirements Model produced by Requirements Analysis. This model specifies the objects and classes and what is to be done. Software Design continues the decomposition to extend the model to a Design Model that specifies how the problem or task will be solved or performed. The solution will be in terms of solutions to small subproblems and how the subsolutions are composed to solve or perform the requirements.

Design principles guide the decomposition by describing desirable properties of the modules that result from the decomposition: namely, modules that abstract or hide their internal data (information hiding), have minimal connections (low coupling), and have internal elements that are closely related or highly unified (high cohesion).

Software Design activities and the decisions made are challenging because they bring about the transition from the problem domain to the solution domain. Software Design activities include data collection at a detailed level, and that data is used to extend the Requirements Model to a Design Model. Software design principles provide guidance to make the best decisions in carrying out the design activities. To review, read pages 279-280 of The New Software Engineering.

6b. Interpret architectural design in terms of decisions, system organization, modular decomposition, and flow-and-control

1. Describe software architecture.

Software architecture has two aspects, static and dynamic. Static structure is the set of components, modules, classes, objects and their association relationships: either, generalization and composition, depending on the methodology. In general, 'component' and 'module' are terms that are independent of methodology. The static structure is a description of the decomposition and organization of the components or modules of the design. Dynamic structure is the subset of the static structure that corresponds to the flow of control, timing, and concurrency of the execution of the modules.

Software Design is often performed at two levels: the software architecture level, also referred to as high-level design, and a detailed design level. The description of a software architecture should include the decisions made in defining the architecture to address a problem or requirement. To review, watch this video, which discusses System Design (high-level design) at 31:00 and Detailed Design at 55:00.

6c. Employ design activities and their major representations in data-oriented, process-oriented, and object-oriented methodologies

1. What are the activities of Design Phase?
2. How are the work products of the design activities represented?

Before studying software design activities and products of the three methodologies, review pages 26-35 and 202-209 of The New Software Engineering for a generic list of design activities.

Consider Object-oriented design first, since it emphasizes both data and processes. Its design activities utilize an object-oriented requirements model, which has defined the objects (objects consist of data and processes) and the relationships between classes. Combined with the additional data collected in the design phase, these objects and relationships are used to build a design model.

To document the transition from the requirements model to the design model, trace information is captured and documented. This traceability information, for example, links a requirement to the design element(s) that support and satisfy that requirement. Design activities identify the solution domain objects that correspond to the problem domain objects in the requirements model, including human-computer interaction, physical hardware, software services, and object instances. Can you name some software service objects? What are some artifacts used to document and communicate the solution objects to stakeholders? What are some artifacts used to document and communicate relationships, intra-object flow of control, inter-object event coordination? What does a process diagram communicate? To review, read pages 503-534 of The New Software Engineering.

Diagrams are concise representations for communicating phases, phase activities, and work products. UML diagrams are often used for representing objects and processes. IDEF diagrams are an alternative for identifying activities and artifacts. UML (or adaptations) are artifacts for Object-oriented methods and are shown on pages 514-528 of The New Software Engineering.

The following IDEF diagrams depict activities of the Object-Oriented design phase and of Object-Oriented analysis (named object/class elaboration in the diagram), which is one of the Phase activities. Representations, i.e. artifacts, are indicated in the second diagram.

Data-oriented activities and representations can be considered using the same approach used for Object-orientation above. What are data-oriented design activities and artifacts? To review, read pages 401-445 of The New Software Engineering.

Consider process-oriented methods in a similar manner. What are process-oriented design activities and artifacts? To review, read pages 293-317 of The New Software Engineering.

This video on Technical Documentation describes various UML diagrams, typically used for Object-oriented software design. Some of those diagrams can be used for data-oriented and process-oriented design methodologies as well, especially those that do not depend on inheritance. You can find each diagram discussed in the video at the following times:

Unit 6 Vocabulary

This vocabulary list includes terms that might help you with the review items above and some terms you should be familiar with to be successful in completing the final exam for the course.

Try to think of the reason why each term is included.

• Data collection
• Software architecture
• Design principles
• Design decision
• Design Model
• Elaborate design
• Problem space or model
• Solution space or model
• Trace and traceability
• Service objects
• Object instance
• Booch Diagram