Unit 6: Software Design
After requirements and analysis, a software engineer must transform the analysis model into a design model that can be implemented in a specific hardware and software environment. In this unit, we will discuss design and architecture design principles. Just as there are various methodologies for requirements analysis, we will look at three corresponding methodologies of the design model (data-oriented, process-oriented, and object-oriented). As you review this unit, focus on the object-oriented methodology and how it applies to software design. You will put it all together later in this course as part of a case study. However, in addition, start putting it all together now by applying what we have covered to this course. View this course as a system – having requirements, a design, an implementation, and verifications and validations. The application domain for this course is education, and the terminology used differs from that of software engineering. For example, the requirements for this system are called learning objectives; the design is called a syllabus. As we continue this course, consider how you would apply the software engineering models to this course: the CS302 system.
Completing this unit should take you approximately 9 hours.
Upon successful completion of this unit, you will be able to:
- explain the software design principles used to create well-designed software that is easy to understand, test, modify, and develop;
- apply the main activities of software design, such as creating class diagrams, sequence diagrams, and activity diagrams;
- interpret a software system's architectural design in terms of its decisions, organization, modular decomposition, and flow and control; and
- use design diagrams to determine the way data is represented and processes are executed in process-oriented, data-oriented, and object-oriented methodologies.
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.
6.2: Architectural Design
This section focuses on conceptual high-level or architecture design. The following section uses the conceptual model to develop an object model for the high-level design or architecture.
A major task of the design phase is creating the interaction diagrams for the system operations. Read this section to learn more about collaboration diagrams. As you review the examples, consider general principles in assigning responsibilities. Ask yourself, how do you determine the relationship between objects? How can you extract the classes? How do you determine whether a mentioned feature can be considered a class attribute? How would you determine class methods?
Watch this video on creating collaboration diagrams. Earlier units and sections have presented UML diagrams, and we have seen that the names of some diagrams vary with different releases of UML. Note that a collaboration diagram is an activity diagram called a "communication diagram".
One part of the software design process is to record the methods corresponding to responsibilities and group these methods in classes. These classes with methods are software classes representing the conceptual classes in the conceptual models. Read this section to walk through the steps of making a class diagram.
This video is an example of a complete project that reviews what we've discussed in this course. What is the difference between functional and non-functional requirements? Give an example of each presented in this sample software project. Which life cycle is it using? The second hour of the video uses an enterprise view to give program examples of the concepts discussed in this unit.
6.3: Software Design Approaches
This section elaborates on the object model of the architecture to develop a detailed design model. The following sections present techniques and methods that guide the design development. These include process-oriented design, data-oriented design, and (an integration of those) object-oriented design. Give attention to elements, patterns, quality attributes, and software architecture principles, including encapsulation, polymorphism, and dependencies. Also, consider tool support for each design method's diagrams and transition from phase to phase as computing advances to newer technologies like more powerful processors (such as parallel and image processors), massive storage (for "big data"), worldwide networks, new devices and sensors, new programming languages (like Python), databases (like non-SQL), new architectures (like network, decentralized, and distributed architectures), services (like cloud computing), new software construction techniques (like application-specific apps and libraries), and new problem-solving techniques (like AI and augmented reality), SDLC tool support advances from representations and translation for low-level implementation components, to detail design components, to high-level components, to architectures, and unsolved problems. Current technology provides automatic tool support for representing and translating components from construction to design and is moving up the SDLC model hierarchically from low to higher-level components.
The goal of design is to map the application's requirements to a hardware and software environment. The result of process-oriented analysis – data flow diagrams, data dictionary entities, and so on – is translated into detailed specifications for hardware and software. The main output of process-oriented design includes structure charts, physical databases, and program specifications.
In this chapter, you will learn about the concepts and terminologies for process-oriented design and the steps of process-oriented design, including transaction analysis, transform analysis and structure charts, physical database design, program packages, and program design. You will also learn about the strengths and weaknesses of process-oriented design.
This text uses the Martin (1990) version of Information Engineering to illustrate data-oriented design. The result of data-oriented analysis – entity-relationship diagrams, data flow diagrams, CRUD matrices, and so on – is translated into screen designs, production database designs, action diagrams, procedural structures, and security plans. Compared to other approaches, data-oriented design strongly emphasizes security, recovery, and audit controls, relating each to data and processes in the application.
In this chapter, you will learn about the concepts and terminologies for data-oriented design, analyzing data and defining system controls, and the action diagram. The action diagram shows the processing details for an application in a structured format, which can be translated into programs and modules. You will also learn about menu structure, dialogue flow, and hardware and software installation and testing.
The text uses the Booch (1991) methodology to illustrate object-oriented design. The result of object-oriented analysis is translated into time-event diagrams, Booch diagrams, message communications, service objects, and process diagrams. Collectively, they constitute a set of holistic specifications to effectively allocate functionality over program modules at the lowest level and multiprocessor configurations at the highest level.
The Booch notation has been unified with other object-oriented notations (Rumbaugh and Jacobsen) into Unified Modeling Language (UML). In Unit 10, we will look at another example of object-oriented analysis and design using the UML notation. Therefore, you may skim this chapter to gain familiarity with OOD, which you will apply in Unit 10.
Unit 6 Assessment
- Receive a grade
Take this assessment to see how well you understood this unit.
- This assessment does not count towards your grade. It is just for practice!
- You will see the correct answers when you submit your answers. Use this to help you study for the final exam!
- You can take this assessment as many times as you want, whenever you want.