Chapter 8

 Design Concepts
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
Design Concepts
 Software design encompasses the set of principles, concepts,
and practices that lead to the development of a high-quality
system or product

 Design concepts must be understood before the mechanics of

design practice are applied

 Design is pivotal to successful software engineering

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2
DESIGN WITHIN THE CONTEXT
OF SOFTWARE ENGINEERING

 Beginning once software requirements have

been analyzed and modeled

 Software design is the last software

engineering action within the modeling activity
and sets the stage for construction

3
 Translating the requirements
model into the design model

The requirements model, manifested by scenario-based, class-based, flow-

oriented, and behavioral elements, feed the design task. 4
Do it yourself
 Do it to yourself
 Section 8.2 – Design Process
 Section 8.3 – Design Concepts

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5
Design Model (Section 8.4)
 Design Elements of each of the Design
Component

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6
Data/Class Design
 The data/class design transforms class models (Chapter 6)
into design class realizations and the requisite data
structures required to implement the software.

 The objects and relationships defined in the CRC diagram

and the detailed data content depicted by class attributes
and other notation provide the basis for the data design
action.

 More detailed class design occurs as each software

component is designed.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7
Architectural Design
 Defines the relationship between major structural elements
of the software
 The architectural design representation—the framework of a
computer-based system—is derived from the requirements
model.
 The architectural design for software is the equivalent to
 the floor plan of a house.
 The floor plan depicts the overall layout of the rooms; their size, shape,
and relationship to one another; and the doors and windows that allow
movement into and out of the rooms.
 Architectural design elements give us an overall view of the software.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8
 The interface design elements for software
depict information flows into and out of the
system and how it is communicated among
the components defined as part of the

Interface Design architecture.

Element of Interface Design
1)User Interface,
2)External Interface to other SW/HW,
3)Internal Interface (Components
interfaces)
 The interface design describes how the software communicates
with systems that interoperate with it, and with humans who use it.
 Therefore, usage scenarios and behavioral models provide much
of the information required for interface design.
 The interface design for software is analogous to
 a set of detailed drawings (and specifications) for the doors, windows, and
external utilities of a house.
 These drawings depict the, the manner in which doors and windows operate,
the way in which utility connections (e.g., water, electrical, gas, telephone) come
into the house and are distributed among the rooms depicted in the floor plan

9
10
Component-level Design
 The component-level design transforms structural elements
of the software architecture into a procedural description of
software components.
 Information obtained from the class-based models, flow
models, and behavioral models serve as the basis for
component design.
 The component-level design for software is the equivalent to
 a set of detailed drawings (and specifications) for each room in a house.
 These drawings depict wiring and plumbing within each room, the
location of electrical receptacles and wall switches, faucets, sinks,
showers, tubs, drains, cabinets, and closets.

11
The design details of a component can be modeled at many different levels of
abstraction.

1)UML activity diagram can be used to represent processing logic.

2)Detailed procedural flow for a component can be represented using either

pseudocode or Algorithmic structure

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 12
 Deployment-level Design

Deployment-level design elements

indicate how software functionality and
subsystems will be allocated within the
physical computing environment that
will support the software

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
Chapter 9
 Architectural Design
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
Architecture?

The software architecture of a program or computing system is the

structure of the system, which comprise

-software components,
-the externally visible properties of those components, and
- the relationships among components

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 15
Architecture?
The architecture is not the operational software.
Rather, it is a representation (a graspable model) that
enables a software engineer to:
(1) analyze the effectiveness of the design in meeting its
stated requirements,
(2) consider architectural alternatives at a stage when
making design changes is still relatively easy, and
(3) reduce the risks associated with the construction of
the software.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
Why is Architecture Important?
 Representations of software architecture are an enabler
for communication between all parties (stakeholders)
interested in the development of a computer-based
system.

 The architecture highlights early design decisions that will

have a profound impact on all software engineering work
that follows and, as important, on the ultimate success of
the system as an operational entity.

 Architecture “constitutes a relatively small, intellectually

graspable mode of how the system is structured and how
its components work together” [BAS03].

17
 Architectural Descriptions
 The IEEE Standard defines an architectural description (AD)
as a “a collection of products to document an architecture.”
 The description itself is represented using multiple views, where
each view is “a representation of a whole system from the
perspective of a related set of [stakeholder] concerns.”

Software Engineer
Owner Stable
Aesthetically pleasing Accommodate changes
Ensure its profitability

End-user
Ease my work
Ease of interaction
18
Architectural Decisions
 Each view developed as part of an architectural
description addresses a specific stakeholder concern.

 To develop each view (and the architectural description

as a whole) the system architect considers a variety of
alternatives and ultimately decides on the specific
architectural features that best meet the concern.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 19
Architectural Genres
 Genre implies a specific category within the
overall software domain.
 Within each category, you encounter a number
of subcategories.
 For example, within the genre of buildings, you
would encounter the following general styles:
houses, apartment buildings, office buildings,
industrial building, warehouses, and so on.
 Within each general style, more specific styles might
apply. Each style would have a structure

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20
Architectural Genres

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 21
Architectural Genres

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22
Architectural Styles/
Taxonomy of Architectural
Styles
Each style describes a system category that encompasses: (1) a
set of components (e.g., a database, computational modules)
that perform a function required by a system, (2) a set of
connectors that enable “communication, coordination and
cooperation” among components, (3) constraints that define
how components can be integrated to form the system, and
(4) semantic models that enable a designer to understand the
overall properties of a system by analyzing the known
properties of its constituent parts.
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23
 Data-Centered Architecture

A data store (e.g., a file or database) resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or otherwise modify
data within the store. Figure illustrates a typical data-centered style. Client software
accesses a central repository.
24
 Data Flow Architecture

This architecture is applied when input data are to be transformed through a series of
computational or manipulative components into output data.

25
 Call and Return Architecture

This architectural style enables you to achieve a program structure that is relatively easy
to modify and scale. 26
Object-oriented architectures

The components of a system encapsulate data and the operations that

must be applied to manipulate the data. Communication and coordination
between components are accomplished via message passing.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27
 Layered Architecture

The basic structure of a layered architecture is illustrated in Figure. A number of different

layers are defined, each accomplishing operations that progressively become closer to
the machine instruction set. At the outer layer, components service user interface
operations. At the inner layer, components perform operating system interfacing.
Intermediate layers provide utility services and application software functions. 28
Architectural Design
 The software must be placed into context
 the design should define the external entities (other systems,
devices, people) that the software interacts with and the nature
of the interaction
 Once context is modeled and all external software
interfaces have been described, you can identify a set of
architectural archetypes.
 An archetype is an abstraction (similar to a class) that
represents one element of system behavior
 The set of archetypes provides a collection
of abstractions that must be modeled architecturally
 The designer specifies the structure of the system by defining
and refining software components that implement each
archetype

29
Representing the System in
Context
 At the architectural design level, a software architect
uses an architectural context diagram (ACD) to model
the manner in which software interacts with entities
external to its boundaries. The generic structure of the
architectural context diagram is illustrated in Figure.

30
Example ACD

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31
Designing Archetypes
 An archetype represents a core abstraction that is critical
to the design of an architecture for the target system.
 In general, a relatively small set of archetypes is required
to design even relatively complex systems.
 The target system architecture is composed of these
archetypes
 In many cases, archetypes can be derived by examining
the analysis classes defined as part of the
requirements/analysis model

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 32
Example - Archetypes
 Continuing the discussion of the SafeHome
home security function, you might define the
following archetypes:

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33
Example - Archetypes

34
Refining the Architecture into
Components
 As the software architecture is refined into components, the structure of the
system begins to emerge.
 But how are these components chosen?
 In order to answer this question, we begin with the classes that were described as part of the
requirements model. These analysis classes represent entities within the application (business)
domain that must be addressed within the software architecture. Hence,
the application domain is one source for the derivation and refinement of components.
 Another source is the infrastructure domain. The architecture must accommodate many
infrastructure components that enable application components but have no business connection
to the application domain, for example, communication components, database components
 The interfaces depicted in the architecture context diagram imply
one or more specialized components that process the data that flows across the interface. (e.g.,
a graphical user interface),

35
Example – Refining
 Continuing the SafeHome home security function example, you might
define the
set of top-level components that address the following functionality:

 Design classes (with appropriate attributes and operations) would be

defined for each

36
Example – Refining

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 37
Describing Instantiations of the
System – Further Refinement
 The architectural design that has been
modeled to this point is still relatively high
level.
 The context of the system has been represented
 archetypes that indicate the important abstractions
have been defined
 the major software components have
been identified.
 However, further refinement is still necessary.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 38
Describing Instantiations of the
System – Further Refinement
 To accomplish this, an actual instantiation of
the architecture is developed

 It means that the architecture is applied to a

specific problem with the intent of
demonstrating that the structure and
components are appropriate

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 39
Describing Instantiations of the
System – Further Refinement

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 40
Do it yourself
 Section 9.5
 Section 9.6
 Will not be part of the examination

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 41