Difference between revisions of "Chapter 2: Software Design"
| Line 15: | Line 15: | ||
Software design plays an important role in developing software: during software design, software engineers produce various models that form a kind of blueprint of the solution to be implemented. We can analyze and evaluate these models to determine whether or not they will allow us to fulfill the various requirements. | Software design plays an important role in developing software: during software design, software engineers produce various models that form a kind of blueprint of the solution to be implemented. We can analyze and evaluate these models to determine whether or not they will allow us to fulfill the various requirements. | ||
| + | |||
We can also examine and evaluate alternative solutions and tradeoffs. Finally, we can use the | We can also examine and evaluate alternative solutions and tradeoffs. Finally, we can use the | ||
resulting models to plan subsequent development activities, such as system verification and validation, in addition to using them as inputs and as the starting point of construction and testing. | resulting models to plan subsequent development activities, such as system verification and validation, in addition to using them as inputs and as the starting point of construction and testing. | ||
| Line 37: | Line 38: | ||
the field of software architecture, we will also | the field of software architecture, we will also | ||
address FP-design (family pattern design), the | address FP-design (family pattern design), the | ||
| − | goal of which is to establish exploitable | + | goal of which is to establish exploitable commonalities in a family of software products. This |
| − | + | ||
| − | + | ||
KA does not address I-design (invention design), | KA does not address I-design (invention design), | ||
which is usually performed during the software | which is usually performed during the software | ||
| − | requirements process with the goal of | + | requirements process with the goal of conceptualizing and specifying software to satisfy discovered needs and requirements, since this topic is |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
considered to be part of the requirements process | considered to be part of the requirements process | ||
(see the Software Requirements KA). | (see the Software Requirements KA). | ||
| − | This Software Design KA is related | + | This Software Design KA is related specifically to the Software Requirements, Software |
| − | + | ||
| − | + | ||
}} | }} | ||
| + | |||
| + | ==Software Design Fundamentals== | ||
| + | ===General Design Concepts=== | ||
| + | ===Context of Software Design=== | ||
| + | ===Software Design Process=== | ||
| + | ===Software Design Principals=== | ||
| + | ==Key Issues in Software Design== | ||
Revision as of 20:30, 20 August 2015
Contents
- ADL
- Architecture Description Language
- CBD
- Component-Based Design
- CRC
- Class Responsibility Collaborator
- DFD
- International Council on Systems Engineering
- ERD
- Entity Relationship Diagram
- IDL
- Interface Description Language
- MVC
- Model View Controller
- OO
- Object-Oriented
- PDL
- Program Design Language
Design is defined as both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of [that] process” [1]. Viewed as a process, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction. A software design (the result) describes the software architecture—that is, how software is decomposed and organized into components—and the interfaces between those components. It should also describe the components at a level of detail that enables their construction.
Software design plays an important role in developing software: during software design, software engineers produce various models that form a kind of blueprint of the solution to be implemented. We can analyze and evaluate these models to determine whether or not they will allow us to fulfill the various requirements.
We can also examine and evaluate alternative solutions and tradeoffs. Finally, we can use the resulting models to plan subsequent development activities, such as system verification and validation, in addition to using them as inputs and as the starting point of construction and testing. In a standard list of software life cycle processes, such as that in ISO/IEC/IEEE Std. 12207, Software Life Cycle Processes[2], software design consists of two activities that fit between software requirements analysis and software construction: • Software architectural design (sometimes called high-level design): develops top-level structure and organization of the software and identifies the various components. • Software detailed design: specifies each component in sufficient detail to facilitate its construction. This Software Design knowledge area (KA) does not discuss every topic that includes the word “design.” In Tom DeMarco’s terminology [3], the topics discussed in this KA deal mainly with D-design (decomposition design), the goal of which is to map software into component pieces. However, because of its importance in the field of software architecture, we will also address FP-design (family pattern design), the goal of which is to establish exploitable commonalities in a family of software products. This KA does not address I-design (invention design), which is usually performed during the software requirements process with the goal of conceptualizing and specifying software to satisfy discovered needs and requirements, since this topic is considered to be part of the requirements process (see the Software Requirements KA). This Software Design KA is related specifically to the Software Requirements, Software
