Difference between revisions of "Chapter 2: Software Design"

From SWEBOK
Jump to: navigation, search
Line 12: Line 12:
  
 
{{IntroSection|title=Introduction|body=
 
{{IntroSection|title=Introduction|body=
−
{{NoIndent|The Software Requirements knowledge area (KA)  
+
{{NoIndent|Design is defined as both “the process of defining the architecture, components, interfaces, and
−
is concerned with the elicitation, analysis, speci
+
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 valida
 
-
 
-
−
fication, and validation of software requirements
+
tion, in addition to using them as inputs and as the  
−
as well as the management of requirements dur
+
starting point of construction and testing.
 +
In  a  standard  list  of  software  life  cycle  pro
 
-
 
-
−
ing the whole life cycle of the software product.  
+
cesses, such as that in ISO/IEC/IEEE Std. 12207,
−
It is widely acknowledged amongst researchers
+
Software
−
and industry practitioners that software projects
+
Life
−
are critically vulnerable when the requirements-
+
Cycle
−
related activities are poorly performed.
+
Processes
−
Software requirements express the needs and  
+
[2], software design
−
constraints placed on a software product that
+
consists of two activities that fit between software  
−
contribute to the solution of  some  real-world
+
requirements analysis and software construction:
−
problem.  
+
•
−
The term “requirements engineering” is widely
+
Software architectural design (sometimes
−
used in the field to denote the systematic handling
+
called high-level design): develops top-level
−
of requirements. For reasons of consistency, the  
+
structure and organization of the software
−
term “engineering” will not be used in this KA  
+
and identifies the various components.
−
other than for software engineering per se.
+
•
−
For the same reason, “requirements engineer,”
+
Software detailed design: specifies each
−
a term which appears in some of the literature,
+
component in sufficient detail to facilitate its
−
will not be used either. Instead, the term “software
+
construction.  
−
engineer” or,  in some specific cases,  “require
+
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 com
 
-
 
-
−
ments specialist” will be used, the latter where
+
monalities in a family of software products. This  
−
the role in question is usually performed by an
+
KA does not address I-design (invention design),  
−
individual other than a software engineer. This does not imply, however, that a software engineer
+
which is usually performed during the software
−
could not perform the function.
+
requirements process with the goal of conceptu
−
A risk inherent in the proposed breakdown is
+
−
that a waterfall-like process may be inferred. To
+
−
guard against this, topic 2, Requirements Process,  
+
−
is designed to provide a high-level overview of the  
+
−
requirements process by setting out the resources
+
−
and constraints under which the process operates
+
−
and which act to configure it.
+
−
An alternate decomposition could use a prod
+
 
-
 
-
−
uct-based  structure  (system  requirements,  soft
+
alizing and specifying software to satisfy discov
 
-
 
-
−
ware requirements, prototypes, use cases, and  
+
ered needs and requirements, since this topic is  
−
so  on).  The  process-based  breakdown  reflects
+
considered to be part of the requirements process  
−
the fact that the requirements process, if it is to
+
(see the Software Requirements KA).
−
be successful, must be considered as a process  
+
This  Software Design  KA is related specifi
−
involving complex, tightly coupled activities
+
−
(both sequential and concurrent), rather than as a
+
−
discrete, one-off activity performed at the outset
+
−
of a software development project.
+
−
The Software Requirements KA is related
+
−
closely to the Software Design, Software Testing,
+
−
Software Maintenance, Software Configuration
+
−
Management,  Software  Engineering Manage
+
 
-
 
-
−
ment, Software Engineering Process, Software  
+
cally to the Software Requirements, Software
−
Engineering Models and Methods, and Software  
+
−
Quality KAs.
+
 
}}
 
}}

Revision as of 20:22, 20 August 2015


Acronyms
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
Introduction

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 valida - tion, in addition to using them as inputs and as the starting point of construction and testing. In a standard list of software life cycle pro - cesses, 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 com - monalities 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 conceptu - alizing and specifying software to satisfy discov - ered 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 specifi - cally to the Software Requirements, Software

Retrieved from "http://swebokwiki.org/index.php?title=Chapter_2:_Software_Design&oldid=271"