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 drill down from the analysis model(s) to the design model(s) following the three corresponding methodologies (i.e., data-oriented, process-oriented, and object-oriented).
As you review the material in this unit, spend some time on the object-oriented methodology as it applies to software design. You will be applying this in a later unit to put it all together in a case study.
Completing this unit should take you approximately 9 hours.
Upon successful completion of this unit, you will be able to:
- use software design principles;
- interpret architectural design in terms of decisions, system organization, modular decomposition, and flow-and-control; and
- employ design activities and their major representations in data-oriented, process-oriented, and object-oriented methodologies.
6.1: Software Design Principles (Information Hiding, Cohesion, Coupling)
Read the "Conceptual Foundations" section in Chapter 8 (pages 279-280).
The principles of good software design have not changed much over the years. In design, we aim to divide and conquer the problem space into smaller solvable parts to better manage complexity and, therefore, cost of development/ maintenance.
6.2: Architectural Design
Watch and listen carefully to this video. Take lots of notes following the outline provided by the presenter.
This is a complete project reviewing the phases already presented in your previous activities as well as a lot of new material covered in this unit. 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 a enterprise view in showing program examples of unit 6 concepts. You will not be doing any of the coding the presenter uses to explain concepts.
6.3: Software Design Approaches
6.3.1: Process-Oriented Design
Read "Chapter 8: Process-Oriented Design" (pages 278-327). 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, etc. -- 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 reading, you will learn about the concepts and terminologies for process-oriented design. This reading covers 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 strengths and weaknesses of process-oriented design. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
6.3.2: Data-Oriented Design
Read "Chapter 10: Data-Oriented Design" (pages 391-458). The 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, etc. -- 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 reading, 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/software installation and testing in this reading. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
6.3.3: Object-Oriented Design OOD
Read "Chapter 12: Object-Oriented Design", on pages 501-553. 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.
As we discussed in 5.3.3, the Booch notation has been unified with other object-oriented notations (i.e., Rambaugh 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 to Unit 10. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or confusing).
End of Unit Assessment
Take this assessment to check your understanding of the materials presented in this unit.
Notes:
- There is no minimum required score to pass this assessment, and your score on this assessment will not factor into your overall course grade.
- This assessment is designed to prepare you for the Final Exam that will determine your course grade. Upon submission of your assessment you will be provided with the correct answers and/or other feedback meant to help in your understanding of the topics being assessed.
- You may attempt this assessment as many times as needed, whenever you would like.