Chapter 13

 Architectural Design
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim

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

For non-profit educational use only

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, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 1
Why Architecture?
The architecture is not the operational software. Rather,
it is a representation 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, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 2
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
 Data-centered architectures
properties of its constituent parts.
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 3
ADL
 Architectural description language (ADL) provides a
semantics and syntax for describing a software
architecture
 Provide the designer with the ability to:
 decompose architectural components
 compose individual components into larger architectural blocks
and
 represent interfaces (connection mechanisms) between
components.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 4
 Architectural Context Diagram
 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 5
Architectural Context Diagram

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 6
 Architectural Context Diagram
 Referring to the figure, systems that interoperate with the target
system (the system for which an architectural design is to be
developed) are represented as:
 Superordinate systems—those systems that use the target system as
part of some higher-level processing scheme.
 Subordinate systems—those systems that are used by the target
system and provide data or processing that are necessary to complete
target system functionality.
 Peer-level systems—those systems that interact on a peer-to-peer basis
(i.e., information is either produced or consumed by the peers and the
target system.
 Actors—entities (people, devices) that interact with the target system by
producing or consuming information that is necessary for requisite
processing.
 Each of these external entities communicates with the target system
through an interface (the small shaded rectangles). 7
Architectural Context Diagram

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 8
 Refining the Architecture into
Components
 Continuing the SafeHome home security function
example, you might define the set of top-level
components that address the following functionality:
 External communication management —coordinates
communication of the security function with external entities such
as other Internet-based systems and external alarm notification.
 Control panel processing—manages all control panel
functionality.
 Detector management —coordinates access to all detectors
attached to the system.
 Alarm processing—verifies and acts on all alarm conditions.

9
Component Structure: Level 1

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 10
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.
Component Structure: Level 1
 Transactions are acquired by external communication
management as they move in from components that
process the SafeHome GUI and the Internet interface.
This information is managed by a SafeHome executive
component that selects the appropriate product function
(in this case security).
 The control panel processing component interacts with
the homeowner to arm/disarm the security function.
 The detector management component polls sensors to
detect an alarm condition, and the alarm processing
component produces output when an alarm is detected.

11
Describing Instantiations of
the System
 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
within the problem domain have been defined, the
overall structure of the system is apparent, and 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, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 12
Refined Component Structure: Level 2

13
 Figure 13.9 illustrates an instantiation of the
SafeHome architecture for the security system.
Components shown in Figure 13.8are elaborated to
show additional detail.
 For example, the detector management component
interacts with a scheduler infrastructure component
that implements polling of each sensor object used by
the security system.
 Similar elaboration is performed for each of the
components represented in Figure 13.8 .

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 14
 Open Task: 10 min
Using the architecture of a house or building
as a metaphor, draw comparisons with
software architecture. How are the
disciplines of classical architecture and the
software architecture similar? How do they
differ?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 15
 Highlighted Topic
 Architectural Design with ADL

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 16
 Break Time: 10 min
 Think about the baseline context diagram
for a Bank Management Software.

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