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 the principles of design and architecture design. 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.
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
Software design is an activity that identifies software components and their relationships based on a customer’s requirements. Design is about how to solve a problem. This section gives detailed information about main software design concepts and principles such as abstraction, coupling and cohesion, and encapsulation.
6.2: Architectural Design
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 go through the examples, pay attention to 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 as a class attribute or not? How would you determine class methods?
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 is an example of a complete project that reviews what we've discussed so far 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 we've discussed in this unit.
6.3: Software Design Approaches
Read this section to learn about the main elements, patterns, quality attributes, and principles of software architecture, including encapsulation, polymorphism, and dependencies. Pay attention to design patterns and their importance in software design.
The goal of design is to map the requirements of the application 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, as well as 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 has a strong emphasis on 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 methodology (1991) 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 as well as 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 quickly 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.