CHAPTER 2

SOFTWARE DESIGN

ACRONYMS We can also examine and evaluate alternative

solutions and tradeoffs. Finally, we can use the
Architecture Description resulting models to plan subsequent development
ADL
Language activities, such as system verification and valida-
CBD Component-Based Design tion, in addition to using them as inputs and as the
CRC Class Responsibility Collaborator starting point of construction and testing.
DFD Data Flow Diagram In a standard list of software life cycle pro-
cesses, such as that in ISO/IEC/IEEE Std. 12207,
ERD Entity Relationship Diagram Software Life Cycle Processes [2], software design
IDL Interface Description Language consists of two activities that fit between software
MVC Model View Controller requirements analysis and software construction:
OO Object-Oriented
• Software architectural design (sometimes
PDL Program Design Language called high-level design): develops top-level
structure and organization of the software
and identifies the various components.
INTRODUCTION • Software detailed design: specifies each
component in sufficient detail to facilitate its
Design is defined as both “the process of defin- construction.
ing the architecture, components, interfaces, and
other characteristics of a system or component” This Software Design knowledge area (KA)
and “the result of [that] process” [1]. Viewed as a does not discuss every topic that includes the
process, software design is the software engineer- word “design.” In Tom DeMarco’s terminology
ing life cycle activity in which software require- [3], the topics discussed in this KA deal mainly
ments are analyzed in order to produce a descrip- with D-design (decomposition design), the goal
tion of the software’s internal structure that will of which is to map software into component
serve as the basis for its construction. A software pieces. However, because of its importance in
design (the result) describes the software archi- the field of software architecture, we will also
tecture—that is, how software is decomposed address FP-design (family pattern design), the
and organized into components—and the inter- goal of which is to establish exploitable com-
faces between those components. It should also monalities in a family of software products. This
describe the components at a level of detail that KA does not address I-design (invention design),
enables their construction. which is usually performed during the software
Software design plays an important role in requirements process with the goal of conceptu-
developing software: during software design, alizing and specifying software to satisfy discov-
software engineers produce various models ered needs and requirements, since this topic is
that form a kind of blueprint of the solution to considered to be part of the requirements process
be implemented. We can analyze and evaluate (see the Software Requirements KA).
these models to determine whether or not they This Software Design KA is related specifi-
will allow us to fulfill the various requirements. cally to the Software Requirements, Software

2-1
2-2 SWEBOK® Guide V3.0

Figure 2.1. Breakdown of Topics for the Software Design KA

Construction, Software Engineering Manage- understanding the limits of design. A number of

ment, Software Engineering Models and Meth- other notions and concepts are also of interest in
ods, Software Quality, and Computing Founda- understanding design in its general sense: goals,
tions KAs. constraints, alternatives, representations, and
solutions (see Problem Solving Techniques in the
BREAKDOWN OF TOPICS FOR Computing Foundations KA).
SOFTWARE DESIGN
1.2. Context of Software Design
The breakdown of topics for the Software Design [4*, c3]
KA is shown in Figure 2.1.
Software design is an important part of the soft-
1. Software Design Fundamentals ware development process. To understand the
role of software design, we must see how it fits
The concepts, notions, and terminology intro- in the software development life cycle. Thus, it
duced here form an underlying basis for under- is important to understand the major characteris-
standing the role and scope of software design. tics of software requirements analysis, software
design, software construction, software testing,
1.1. General Design Concepts and software maintenance.
[4*, c1]
1.3. Software Design Process
In the general sense, design can be viewed as a [4*, c2]
form of problem solving. For example, the con-
cept of a wicked problem—a problem with no Software design is generally considered a two-
definitive solution—is interesting in terms of step process:
 Software Design 2-3

• Architectural design (also referred to as high- software is divided into a number of smaller
level design and top-level design) describes named components having well-defined
how software is organized into components. interfaces that describe component interac-
• Detailed design describes the desired behav- tions. Usually the goal is to place different
ior of these components. functionalities and responsibilities in differ-
ent components.
The output of these two processes is a set of • Encapsulation and information hiding means
models and artifacts that record the major deci- grouping and packaging the internal details
sions that have been taken, along with an explana- of an abstraction and making those details
tion of the rationale for each nontrivial decision. inaccessible to external entities.
By recording the rationale, long-term maintain- • Separation of interface and implementation.
ability of the software product is enhanced. Separating interface and implementation
involves defining a component by specify-
1.4. Software Design Principles ing a public interface (known to the clients)
[4*] [5*, c6, c7, c21] [6*, c1, c8, c9] that is separate from the details of how the
component is realized (see encapsulation and
A principle is “a comprehensive and fundamen- information hiding above).
tal law, doctrine, or assumption” [7]. Software • Sufficiency, completeness, and primitiveness.
design principles are key notions that provide Achieving sufficiency and completeness
the basis for many different software design means ensuring that a software component
approaches and concepts. Software design princi- captures all the important characteristics of
ples include abstraction; coupling and cohesion; an abstraction and nothing more. Primitive-
decomposition and modularization; encapsula- ness means the design should be based on
tion/information hiding; separation of interface patterns that are easy to implement.
and implementation; sufficiency, completeness, • Separation of concerns. A concern is an
and primitiveness; and separation of concerns. “area of interest with respect to a software
design” [8]. A design concern is an area of
• Abstraction is “a view of an object that design that is relevant to one or more of its
focuses on the information relevant to a stakeholders. Each architecture view frames
particular purpose and ignores the remain- one or more concerns. Separating concerns
der of the information” [1] (see Abstraction by views allows interested stakeholders to
in the Computing Foundations KA). In the focus on a few things at a time and offers a
context of software design, two key abstrac- means of managing complexity [9].
tion mechanisms are parameterization and
specification. Abstraction by parameteriza- 2. Key Issues in Software Design
tion abstracts from the details of data repre-
sentations by representing the data as named A number of key issues must be dealt with when
parameters. Abstraction by specification designing software. Some are quality concerns
leads to three major kinds of abstraction: that all software must address—for example,
procedural abstraction, data abstraction, and performance, security, reliability, usability, etc.
control (iteration) abstraction. Another important issue is how to decompose,
• Coupling and Cohesion. Coupling is defined organize, and package software components.
as “a measure of the interdependence among This is so fundamental that all design approaches
modules in a computer program,” whereas address it in one way or another (see section 1.4,
cohesion is defined as “a measure of the Software Design Principles, and topic 7, Soft-
strength of association of the elements within ware Design Strategies and Methods). In contrast,
a module” [1]. other issues “deal with some aspect of software’s
• Decomposition and modularization. Decom- behavior that is not in the application domain,
posing and modularizing means that large but which addresses some of the supporting
2-4 SWEBOK® Guide V3.0

domains” [10]. Such issues, which often crosscut 2.6. Interaction and Presentation
the system’s functionality, have been referred to [5*, c16]
as aspects, which “tend not to be units of soft-
ware’s functional decomposition, but rather to be This design issue is concerned with how to struc-
properties that affect the performance or seman- ture and organize interactions with users as well
tics of the components in systemic ways” [11]. as the presentation of information (for example,
A number of these key, crosscutting issues are separation of presentation and business logic
discussed in the following sections (presented in using the Model-View-Controller approach).
alphabetical order). Note that this topic does not specify user interface
details, which is the task of user interface design
2.1. Concurrency (see topic 4, User Interface Design).
[5*, c18]
2.7. Security
Design for concurrency is concerned with decom- [5*, c12, c18] [13*, c4]
posing software into processes, tasks, and threads
and dealing with related issues of efficiency, Design for security is concerned with how to pre-
atomicity, synchronization, and scheduling. vent unauthorized disclosure, creation, change,
deletion, or denial of access to information and
2.2. Control and Handling of Events other resources. It is also concerned with how to
[5*, c21] tolerate security-related attacks or violations by
limiting damage, continuing service, speeding
This design issue is concerned with how to repair and recovery, and failing and recovering
organize data and control flow as well as how securely. Access control is a fundamental con-
to handle reactive and temporal events through cept of security, and one should also ensure the
various mechanisms such as implicit invocation proper use of cryptology.
and call-backs.
3. Software Structure and Architecture
2.3. Data Persistence
[12*, c9] In its strict sense, a software architecture is
“the set of structures needed to reason about
This design issue is concerned with how to han- the system, which comprise software elements,
dle long-lived data. relations among them, and properties of both”
[14*]. During the mid-1990s, however, soft-
2.4. Distribution of Components ware architecture started to emerge as a broader
[5*, c18] discipline that involved the study of software
structures and architectures in a more generic
This design issue is concerned with how to dis- way. This gave rise to a number of interesting
tribute the software across the hardware (includ- concepts about software design at different lev-
ing computer hardware and network hardware), els of abstraction. Some of these concepts can
how the components communicate, and how be useful during the architectural design (for
middleware can be used to deal with heteroge- example, architectural styles) as well as during
neous software. the detailed design (for example, design pat-
terns). These design concepts can also be used
2.5. Error and Exception Handling and Fault to design families of programs (also known as
Tolerance product lines). Interestingly, most of these con-
[5*, c18] cepts can be seen as attempts to describe, and
thus reuse, design knowledge.
This design issue is concerned with how to pre-
vent, tolerate, and process errors and deal with
exceptional conditions.
 Software Design 2-5

3.1. Architectural Structures and Viewpoints patterns describing the high-level organization
[14*, c1] of software, other design patterns can be used
to describe details at a lower level. These lower
Different high-level facets of a software design level design patterns include the following:
can be described and documented. These facets
are often called views: “A view represents a partial • Creational patterns (for example, builder,
aspect of a software architecture that shows spe- factory, prototype, singleton)
cific properties of a software system” [14*]. Views • Structural patterns (for example, adapter,
pertain to distinct issues associated with software bridge, composite, decorator, façade, fly-
design—for example, the logical view (satisfying weight, proxy)
the functional requirements) vs. the process view • Behavioral patterns (for example, command,
(concurrency issues) vs. the physical view (distri- interpreter, iterator, mediator, memento,
bution issues) vs. the development view (how the observer, state, strategy, template, visitor).
design is broken down into implementation units
with explicit representation of the dependencies 3.4. Architecture Design Decisions
among the units). Various authors use different [5*, c6]
terminologies—like behavioral vs. functional vs.
structural vs. data modeling views. In summary, a Architectural design is a creative process. Dur-
software design is a multifaceted artifact produced ing the design process, software designers have
by the design process and generally composed of to make a number of fundamental decisions that
relatively independent and orthogonal views. profoundly affect the software and the develop-
ment process. It is useful to think of the archi-
3.2. Architectural Styles tectural design process from a decision-making
[14*, c1, c2, c3, c4, c5] perspective rather than from an activity perspec-
tive. Often, the impact on quality attributes and
An architectural style is “a specialization of ele- tradeoffs among competing quality attributes are
ment and relation types, together with a set of the basis for design decisions.
constraints on how they can be used” [14*]. An
architectural style can thus be seen as providing 3.5. Families of Programs and Frameworks
the software’s high-level organization. Various [5*, c6, c7, c16]
authors have identified a number of major archi-
tectural styles: One approach to providing for reuse of software
designs and components is to design families of
• General structures (for example, layers, pipes programs, also known as software product lines.
and filters, blackboard) This can be done by identifying the commonalities
• Distributed systems (for example, client- among members of such families and by designing
server, three-tiers, broker) reusable and customizable components to account
• Interactive systems (for example, Model-View- for the variability among family members.
Controller, Presentation-Abstraction-Control) In object-oriented (OO) programming, a key
• Adaptable systems (for example, microker- related notion is that of a framework: a partially
nel, reflection) completed software system that can be extended
• Others (for example, batch, interpreters, pro- by appropriately instantiating specific extensions
cess control, rule-based). (such as plug-ins).

3.3. Design Patterns 4. User Interface Design

[15*, c3, c4, c5]
User interface design is an essential part of the
Succinctly described, a pattern is “a common software design process. User interface design
solution to a common problem in a given context” should ensure that interaction between the human
[16]. While architectural styles can be viewed as and the machine provides for effective operation
2-6 SWEBOK® Guide V3.0

and control of the machine. For software to and presentation for the software, the background
achieve its full potential, the user interface should and experience of the software users, and the
be designed to match the skills, experience, and available devices.
expectations of its anticipated users.
4.3. The Design of User Interaction Modalities
4.1. General User Interface Design Principles [5*, c29-web] [17*, c2]
[5*, c29-web] [17*, c2]1
User interaction involves issuing commands and
• Learnability. The software should be easy to providing associated data to the software. User
learn so that the user can rapidly start work- interaction styles can be classified into the fol-
ing with the software. lowing primary styles:
• User familiarity. The interface should use
terms and concepts drawn from the experi- • Question-answer. The interaction is essen-
ences of the people who will use the software. tially restricted to a single question-answer
• Consistency. The interface should be consis- exchange between the user and the software.
tent so that comparable operations are acti- The user issues a question to the software,
vated in the same way. and the software returns the answer to the
• Minimal surprise. The behavior of software question.
should not surprise users. • Direct manipulation. Users interact with
• Recoverability. The interface should provide objects on the computer screen. Direct
mechanisms allowing users to recover from manipulation often includes a pointing
errors. device (such as a mouse, trackball, or a fin-
• User guidance. The interface should give ger on touch screens) that manipulates an
meaningful feedback when errors occur and object and invokes actions that specify what
provide context-related help to users. is to be done with that object.
• User diversity. The interface should pro- • Menu selection. The user selects a command
vide appropriate interaction mechanisms from a menu list of commands.
for diverse types of users and for users with • Form fill-in. The user fills in the fields of a
different capabilities (blind, poor eyesight, form. Sometimes fields include menus, in
deaf, colorblind, etc.). which case the form has action buttons for
the user to initiate action.
4.2. User Interface Design Issues • Command language. The user issues a com-
[5*, c29-web] [17*, c2] mand and provides related parameters to
direct the software what to do.
User interface design should solve two key issues: • Natural language. The user issues a com-
mand in natural language. That is, the natural
• How should the user interact with the language is a front end to a command lan-
software? guage and is parsed and translated into soft-
• How should information from the software ware commands.
be presented to the user?
4.4. The Design of Information Presentation
User interface design must integrate user [5*, c29-web] [17*, c2]
interaction and information presentation. User
interface design should consider a compromise Information presentation may be textual or graphi-
between the most appropriate styles of interaction cal in nature. A good design keeps the information
presentation separate from the information itself.
The MVC (Model-View-Controller) approach is
1 Chapter 29 is a web-based chapter available an effective way to keep information presentation
at http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/
separating from the information being presented.
WebChapters/.
 Software Design 2-7

Software engineers also consider software 4.6. Localization and Internationalization

response time and feedback in the design of infor- [17*, c8, c9]
mation presentation. Response time is generally
measured from the point at which a user executes User interface design often needs to consider inter-
a certain control action until the software responds nationalization and localization, which are means
with a response. An indication of progress is desir- of adapting software to the different languages,
able while the software is preparing the response. regional differences, and the technical require-
Feedback can be provided by restating the user’s ments of a target market. Internationalization is the
input while processing is being completed. process of designing a software application so that
Abstract visualizations can be used when large it can be adapted to various languages and regions
amounts of information are to be presented. without major engineering changes. Localization
According to the style of information presenta- is the process of adapting internationalized soft-
tion, designers can also use color to enhance the ware for a specific region or language by adding
interface. There are several important guidelines: locale-specific components and translating the
text. Localization and internationalization should
• Limit the number of colors used. consider factors such as symbols, numbers, cur-
• Use color change to show the change of soft- rency, time, and measurement units.
ware status.
• Use color-coding to support the user’s task. 4.7. Metaphors and Conceptual Models
• Use color-coding in a thoughtful and consis- [17*, c5]
tent way.
• Use colors to facilitate access for people User interface designers can use metaphors and
with color blindness or color deficiency conceptual models to set up mappings between the
(e.g., use the change of color saturation and software and some reference system known to the
color brightness, try to avoid blue and red users in the real world, which can help the users to
combinations). more readily learn and use the interface. For exam-
• Don’t depend on color alone to convey ple, the operation “delete file” can be made into a
important information to users with different metaphor using the icon of a trash can.
capabilities (blindness, poor eyesight, color- When designing a user interface, software engi-
blindness, etc.). neers should be careful to not use more than one
metaphor for each concept. Metaphors also pres-
4.5. User Interface Design Process ent potential problems with respect to internation-
[5*, c29-web] [17*, c2] alization, since not all metaphors are meaningful
or are applied in the same way within all cultures.
User interface design is an iterative process;
interface prototypes are often used to determine 5. Software Design Quality Analysis and
the features, organization, and look of the soft- Evaluation
ware user interface. This process includes three
core activities: This section includes a number of quality anal-
ysis and evaluation topics that are specifically
• User analysis. In this phase, the designer ana- related to software design. (See also the Software
lyzes the users’ tasks, the working environ- Quality KA.)
ment, other software, and how users interact
with other people. 5.1. Quality Attributes
• Software prototyping. Developing prototype [4*, c4]
software help users to guide the evolution of
the interface. Various attributes contribute to the quality of
• Interface evaluation. Designers can observe a software design, including various “-ilities”
users’ experiences with the evolving interface. (maintainability, portability, testability, usability)
2-8 SWEBOK® Guide V3.0

and “-nesses” (correctness, robustness). There is 5.3. Measures

an interesting distinction between quality attri- [4*, c4] [5*, c24]
butes discernible at runtime (for example, per-
formance, security, availability, functionality, Measures can be used to assess or to quanti-
usability), those not discernible at runtime (for tatively estimate various aspects of a software
example, modifiability, portability, reusability, design; for example, size, structure, or quality.
testability), and those related to the architecture’s Most measures that have been proposed depend
intrinsic qualities (for example, conceptual integ- on the approach used for producing the design.
rity, correctness, completeness). (See also the These measures are classified in two broad
Software Quality KA.) categories:

5.2. Quality Analysis and Evaluation Techniques • Function-based (structured) design mea-
[4*, c4] [5*, c24] sures: measures obtained by analyzing func-
tional decomposition; generally represented
Various tools and techniques can help in analyz- using a structure chart (sometimes called a
ing and evaluating software design quality. hierarchical diagram) on which various mea-
sures can be computed.
• Software design reviews: informal and for- • Object-oriented design measures: the design
malized techniques to determine the quality structure is typically represented as a class
of design artifacts (for example, architecture diagram, on which various measures can be
reviews, design reviews, and inspections; computed. Measures on the properties of the
scenario-based techniques; requirements internal content of each class can also be
tracing). Software design reviews can also computed.
evaluate security. Aids for installation, oper-
ation, and usage (for example, manuals and 6. Software Design Notations
help files) can be reviewed.
• Static analysis: formal or semiformal static Many notations exist to represent software design
(nonexecutable) analysis that can be used artifacts. Some are used to describe the structural
to evaluate a design (for example, fault- organization of a design, others to represent soft-
tree analysis or automated cross-checking). ware behavior. Certain notations are used mostly
Design vulnerability analysis (for example, during architectural design and others mainly
static analysis for security weaknesses) can during detailed design, although some nota-
be performed if security is a concern. Formal tions can be used for both purposes. In addition,
design analysis uses mathematical models some notations are used mostly in the context of
that allow designers to predicate the behavior specific design methods (see topic 7, Software
and validate the performance of the software Design Strategies and Methods). Please note that
instead of having to rely entirely on testing. software design is often accomplished using mul-
Formal design analysis can be used to detect tiple notations. Here, they are categorized into
residual specification and design errors (per- notations for describing the structural (static)
haps caused by imprecision, ambiguity, and view vs. the behavioral (dynamic) view.
sometimes other kinds of mistakes). (See
also the Software Engineering Models and 6.1. Structural Descriptions (Static View)
Methods KA.) [4*, c7] [5*, c6, c7] [6*, c4, c5, c6, c7]
• Simulation and prototyping: dynamic tech- [12*, c7] [14*, c7]
niques to evaluate a design (for example,
performance simulation or feasibility The following notations, mostly but not always
prototypes). graphical, describe and represent the structural
aspects of a software design—that is, they are
 Software Design 2-9

used to describe the major components and how • Activity diagrams: used to show control flow
they are interconnected (static view): from activity to activity. Can be used to rep-
resent concurrent activities.
• Architecture description languages (ADLs): • Communication diagrams: used to show
textual, often formal, languages used to the interactions that occur among a group
describe software architecture in terms of of objects; emphasis is on the objects, their
components and connectors. links, and the messages they exchange on
• Class and object diagrams: used to repre- those links.
sent a set of classes (and objects) and their • Data flow diagrams (DFDs): used to show
interrelationships. data flow among elements. A data flow dia-
• Component diagrams: used to represent a gram provides “a description based on model-
set of components (“physical and replace- ing the flow of information around a network
able part[s] of a system that [conform] to of operational elements, with each element
and [provide] the realization of a set of inter- making use of or modifying the information
faces” [18]) and their interrelationships. flowing into that element” [4*]. Data flows
• Class responsibility collaborator cards (and therefore data flow diagrams) can be
(CRCs): used to denote the names of compo- used for security analysis, as they offer iden-
nents (class), their responsibilities, and their tification of possible paths for attack and dis-
collaborating components’ names. closure of confidential information.
• Deployment diagrams: used to represent a • Decision tables and diagrams: used to rep-
set of (physical) nodes and their interrela- resent complex combinations of conditions
tionships, and, thus, to model the physical and actions.
aspects of software. • Flowcharts: used to represent the flow of
• Entity-relationship diagrams (ERDs): used control and the associated actions to be
to represent conceptual models of data stored performed.
in information repositories. • Sequence diagrams: used to show the inter-
• Interface description languages (IDLs): actions among a group of objects, with
programming-like languages used to define emphasis on the time ordering of messages
the interfaces (names and types of exported passed between objects.
operations) of software components. • State transition and state chart diagrams:
• Structure charts: used to describe the calling used to show the control flow from state to
structure of programs (which modules call, state and how the behavior of a component
and are called by, which other modules). changes based on its current state in a state
machine.
6.2. Behavioral Descriptions (Dynamic View) • Formal specification languages: textual lan-
[4*, c7, c13] [5*, c6, c7] [6*, c4, c5, c6, c7] guages that use basic notions from math-
[14*, c8] ematics (for example, logic, set, sequence)
to rigorously and abstractly define software
The following notations and languages, some component interfaces and behavior, often in
graphical and some textual, are used to describe terms of pre- and postconditions. (See also
the dynamic behavior of software systems and the Software Engineering Models and Meth-
components. Many of these notations are use- ods KA.)
ful mostly, but not exclusively, during detailed • Pseudo code and program design languages
design. Moreover, behavioral descriptions can (PDLs): structured programming-like lan-
include a rationale for design decision such as guages used to describe, generally at the
how a design will meet security requirements. detailed design stage, the behavior of a pro-
cedure or method.
2-10 SWEBOK® Guide V3.0

7. Software Design Strategies and Methods design of the mid-1980s (noun = object; verb
= method; adjective = attribute), where inheri-
There exist various general strategies to help tance and polymorphism play a key role, to the
guide the design process. In contrast with general field of component-based design, where metain-
strategies, methods are more specific in that they formation can be defined and accessed (through
generally provide a set of notations to be used reflection, for example). Although OO design’s
with the method, a description of the process to roots stem from the concept of data abstraction,
be used when following the method, and a set of responsibility-driven design has been proposed
guidelines for using the method. Such methods as an alternative approach to OO design.
are useful as a common framework for teams of
software engineers. (See also the Software Engi- 7.4. Data Structure-Centered Design
neering Models and Methods KA). [4*, c14, c15]

7.1. General Strategies Data structure-centered design starts from the data
[4*, c8, c9, c10] [12*, c7] structures a program manipulates rather than from
the function it performs. The software engineer
Some often-cited examples of general strategies first describes the input and output data structures
useful in the design process include the divide- and then develops the program’s control structure
and-conquer and stepwise refinement strategies, based on these data structure diagrams. Various
top-down vs. bottom-up strategies, and strategies heuristics have been proposed to deal with special
making use of heuristics, use of patterns and pat- cases—for example, when there is a mismatch
tern languages, and use of an iterative and incre- between the input and output structures.
mental approach.
7.5. Component-Based Design (CBD)
7.2. Function-Oriented (Structured) Design [4*, c17]
[4*, c13]
A software component is an independent unit,
This is one of the classical methods of software having well-defined interfaces and dependen-
design, where decomposition centers on identify- cies that can be composed and deployed inde-
ing the major software functions and then elab- pendently. Component-based design addresses
orating and refining them in a hierarchical top- issues related to providing, developing, and
down manner. Structured design is generally used integrating such components in order to improve
after structured analysis, thus producing (among reuse. Reused and off-the-shelf software com-
other things) data flow diagrams and associated ponents should meet the same security require-
process descriptions. Researchers have proposed ments as new software. Trust management is
various strategies (for example, transformation a design concern; components treated as hav-
analysis, transaction analysis) and heuristics (for ing a certain degree of trustworthiness should
example, fan-in/fan-out, scope of effect vs. scope not depend on less trustworthy components or
of control) to transform a DFD into a software services.
architecture generally represented as a structure
chart. 7.6. Other Methods
[5*, c19, c21]
7.3. Object-Oriented Design
[4*, c16] Other interesting approaches also exist (see the
Software Engineering Models and Methods
Numerous software design methods based KA). Iterative and adaptive methods imple-
on objects have been proposed. The field has ment software increments and reduce emphasis
evolved from the early object-oriented (OO) on rigorous software requirement and design.
 Software Design 2-11

Aspect-oriented design is a method by which 8. Software Design Tools

software is constructed using aspects to imple- [14*, c10, Appendix A]
ment the crosscutting concerns and extensions
that are identified during the software require- Software design tools can be used to support the
ments process. Service-oriented architecture is creation of the software design artifacts during
a way to build distributed software using web the software development process. They can sup-
services executed on distributed computers. Soft- port part or whole of the following activities:
ware systems are often constructed by using ser-
vices from different providers because standard • to translate the requirements model into a
protocols (such as HTTP, HTTPS, SOAP) have design representation;
been designed to support service communication • to provide support for representing func-
and service information exchange. tional components and their interface(s);
• to implement heuristics refinement and
partitioning;
• to provide guidelines for quality assessment.
2-12 SWEBOK® Guide V3.0

MATRIX OF TOPICS VS. REFERENCE MATERIAL

Clements et al. 2010

Gamma et al. 1994

Sommerville 2011

Brookshear 2008
Page-Jones 1999
Budgen 2003

Nielsen 1993
Allen 2008
[12*]

[13*]

[15*]

[17*]
[14*]
[5*]
[4*]

[6*]
1. Software Design
Fundamentals
1.1. General Design
c1
Concepts
1.2. The Context of
c3
Software Design
1.3. The Software
c2
Design Process
1.4. Software Design c6, c7, c1, c8,
c1
Principles c21 c9
2. Key Issues in
Software Design
2.1. Concurrency c18
2.2. Control and
c21
Handling of Events
2.3. Data Persistence c9
2.4. Distribution of
c18
Components
2.5. Error and
Exception Handling c18
and Fault Tolerance
2.6. Interaction and
c16
Presentation
c12,
2.7. Security c4
c18
3. Software Structure
and Architecture
3.1. Architectural
Structures and c1
Viewpoints
c1, c2,
3.2. Architectural
c3, c4,
Styles
c5
c3, c4,
3.3. Design Patterns
c5
 Software Design 2-13

Clements et al. 2010

Gamma et al. 1994

Sommerville 2011

Brookshear 2008
Page-Jones 1999
Budgen 2003

Nielsen 1993
Allen 2008
[12*]

[13*]

[15*]

[17*]
[14*]
[5*]
[4*]

[6*]
3.4. Architecture
c6
Design Decisions
3.5. Families of
c6, c7,
Programs and
c16
Frameworks
4. User Interface
Design
4.1. General User
c29-
Interface Design c2
web
Principle
4.2. User Interface c29-
Design Issues web
4.3. The Design of
c29-
User Interaction
web
Modalities
4.4. The Design
c29-
of Information
web
Presentation
4.5. User Interface c29-
Design Process web
4.6. Localization and
c8, c9
Internationalization
4.7. Metaphors and
c5
Conceptual Models
5. Software Design
Quality Analysis and
Evaluation
5.1. Quality
c4
Attributes
5.2. Quality
Analysis and
c4 c24
Evaluation
Techniques
5.3. Measures c4 c24
2-14 SWEBOK® Guide V3.0

Clements et al. 2010

Gamma et al. 1994

Sommerville 2011

Brookshear 2008
Page-Jones 1999
Budgen 2003

Nielsen 1993
Allen 2008
[12*]

[13*]

[15*]

[17*]
[14*]
[5*]
[4*]

[6*]
6. Software Design
Notations
6.1. Structural
c4, c5,
Descriptions (Static c7 c6, c7 c7 c7
c6, c7
View)
6.2. Behavioral
c7, c13, c4, c5,
Descriptions c6, c7 c8
c18 c6, c7
(Dynamic View)
7. Software Design
Strategies and
Methods
7.1. General c8, c9,
c7
Strategies c10
7.2. Function-
Oriented c13
(Structured) Design
7.3. Object-Oriented
c16
Design
7.4. Data Structure- c14,
Centered Design c15
7.5. Component-
c17
Based Design (CBD)
c19,
7.6. Other Methods
c21
8. Software Design c10,
Tools App. A
 Software Design 2-15

FURTHER READINGS REFERENCES

Roger Pressman, Software Engineering: A [1] ISO/IEC/IEEE 24765:2010 Systems and

Practitioner’s Approach (Seventh Edition) Software Engineering—Vocabulary, ISO/
[19]. IEC/IEEE, 2010.

For roughly three decades, Roger Pressman’s [2] IEEE Std. 12207-2008 (a.k.a. ISO/IEC
Software Engineering: A Practitioner’s Approach 12207:2008) Standard for Systems and
has been one of the world’s leading textbooks in Software Engineering—Software Life Cycle
software engineering. Notably, this complemen- Processes, IEEE, 2008.
tary textbook to [5*] comprehensively presents
software design—including design concepts, [3] T. DeMarco, “The Paradox of Software
architectural design, component-level design, Architecture and Design,” Stevens Prize
user interface design, pattern-based design, and Lecture, 1999.
web application design.
[4*] D. Budgen, Software Design, 2nd ed.,
“The 4+1 View Model of Architecture” [20]. Addison-Wesley, 2003.

The seminal paper “The 4+1 View Model” orga- [5*] I. Sommerville, Software Engineering, 9th
nizes a description of a software architecture ed., Addison-Wesley, 2011.
using five concurrent views. The four views of
the model are the logical view, the development [6*] M. Page-Jones, Fundamentals of Object-
view, the process view, and the physical view. Oriented Design in UML, 1st ed., Addison-
In addition, selected use cases or scenarios are Wesley, 1999.
utilized to illustrate the architecture. Hence, the
model contains 4+1 views. The views are used to [7] Merriam-Webster’s Collegiate Dictionary,
describe the software as envisioned by different 11th ed., 2003.
stakeholders—such as end-users, developers, and
project managers. [8] IEEE Std. 1069-2009 Standard for
Information Technology—Systems
Len Bass, Paul Clements, and Rick Kazman, Design—Software Design Descriptions,
Software Architecture in Practice [21]. IEEE, 2009.

This book introduces the concepts and best prac- [9] ISO/IEC 42010:2011 Systems and Software
tices of software architecture, meaning how soft- Engineering—Recommended Practice for
ware is structured and how the software’s compo- Architectural Description of Software-
nents interact. Drawing on their own experience, Intensive Systems, ISO/IEC, 2011.
the authors cover the essential technical topics
for designing, specifying, and validating software [10] J. Bosch, Design and Use of Software
architectures. They also emphasize the impor- Architectures: Adopting and Evolving a
tance of the business context in which large soft- Product-Line Approach, ACM Press, 2000.
ware is designed. Their aim is to present software
architecture in a real-world setting, reflecting [11] G. Kiczales et al., “Aspect-Oriented
both the opportunities and constraints that orga- Programming,” Proc. 11th European Conf.
nizations encounter. This is one of the best books Object-Oriented Programming (ECOOP
currently available on software architecture. 97), Springer, 1997.
2-16 SWEBOK® Guide V3.0

[12*] J.G. Brookshear, Computer Science: An [17*] J. Nielsen, Usability Engineering, Morgan
Overview, 10th ed., Addison-Wesley, 2008. Kaufmann, 1993.

[13*] J.H. Allen et al., Software Security [18] G. Booch, J. Rumbaugh, and I. Jacobson,
Engineering: A Guide for Project The Unified Modeling Language User
Managers, Addison-Wesley, 2008. Guide, Addison-Wesley, 1999.

[14*] P. Clements et al., Documenting Software [19] R.S. Pressman, Software Engineering: A
Architectures: Views and Beyond, 2nd ed., Practitioner’s Approach, 7th ed., McGraw-
Pearson Education, 2010. Hill, 2010.

[15*] E. Gamma et al., Design Patterns: [20] P.B. Kruchten, “The 4+1 View Model of
Elements of Reusable Object-Oriented Architecture,” IEEE Software, vol. 12, no.
Software, 1st ed., Addison-Wesley 6, 1995, pp. 42–55.
Professional, 1994.
[21] L. Bass, P. Clements, and R. Kazman,
[16] I. Jacobson, G. Booch, and J. Rumbaugh, Software Architecture in Practice, 3rd ed.,
The Unified Software Development Addison-Wesley Professional, 2013.
Process, Addison-Wesley Professional,
1999.