1. Chapter 10
Architectural Design
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman
1

2. Software Architecture
 The software architecture of a program or
computing system is the structure or
structures of the system, which comprise the
software components, the externally visible
properties of those components, and the
relationships among them.
— Bass. et al.
2

3. Why Architecture?

Architecture is a representation of a system
that enables the 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.
3

4. Data Design
 Architectural level → Database design
 data mining
 data warehousing
 Component level → Data structure
design
4

5. What principles are applicable to data design?
1. The systematic analysis principles applied to function
and behavior should also be applied to data.
2. All data structures and the operations to be
performed on each should be identified.
3. A mechanism for defining the content of each data
object should be established and used to define both
data and the operations applied to it.
4. Low-level data design decisions should be deferred
until late in the design process.
5

6. What principles are applicable to data design
5. The representation of a data structure should be
known only to those modules that must make direct
use of the data contained within the structure.
6. A library of useful data structures and the operations
that may be applied to them should be developed.
7. A software design and programming language should
support the specification and realization of abstract
data types.
6

7. 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.
7

8. Specific Styles





Data-centered architecture
Data flow architecture
Call and return architecture
Object-oriented architecture
Layered architecture
8

9. Data-Centered Architecture
9

10. Data-Centered Architecture
 Data store 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.
 Client software accesses a central repository.
 Some cases, the data repository is passive, that is client software
accesses the data independent of any changes to the data or the
actions of other client software.
 A variation on this approach transforms the repository into a
blackboard that sends notifications to client software when data of
interest to the client changes.
 A data-centered architecture promotes integrability. That is, existing
components can be changed and new client components added to the
architecture without concern about other clients.
10
 Client components independently execute processes.

11. Data-Flow Architecture
11

12. 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.
A pipe and filter structure has a set of components, called
filters, connected by pipes that transmit data from one
component to the next.
Each filter works independently of those components upstream
and downstream, is designed to expect data input of a certain
form, and produces data output of a specified form.
Filter does not require knowledge of the workings of its
neighboring filters.
12

13. Call and Return Architecture
13

14. Call and Return Architecture
This architecture style enables a software designer to achieve a
program structure that is relatively easy to modify and scale.
Two sub styles exist within this category:
1. Main program / sub program architecture: This classic program
structure decompose3s function into a control hierarchy where a
main program invokes a number of program components, which
in turn may invoke still other components.
2. Remote Procedure Call architecture: The components of a main
program / sub program architecture are distributed across
multiple computers on a network.
14

15. Object-Oriented Architecture
15

16. Object-Oriented Architecture
The components of a system encapsulate data and the
operations that must be applied to manipulate the data.
Communication and coordination between components is
accomplished via message passing.
16

17. Layered Architecture
17

18. Layered Architecture
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.
At the intermediate layers provide utility services and
application software functions.
18

19. Architectural Patterns Domains
 Concurrency
 operating system process management
 task scheduler
 Persistence
 database management system
 application level persistence
 Distribution
 broker
19

20. Architectural Design
 Architectural context diagrams model how
software interacts with external entities
 Archetypes are classes or patterns that
represent an abstraction critical to the system
 Architectural components are derived from
the application domain, the infrastructure, and
the interface.
20

21. Arch. Context Diagram
21

22. How do system interoperate with one
another?
 System that interoperate with the target system are
represented as:
 Superordinate systems –those system that use the
target system as part of some higher level processing
system.
 Subordinate system- those systems that are used by
the target system and provide data or processing that
are necessary to complete target system
functionality.
22

23. How do system interoperate with one
another?
Cont…
 Peer-level systems– those system that interact on a
peer-to-peer basis that is information is either
produced or consumed by the peers and the target
system.
 Actors- those entities (people, device) 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(small shaded
rectangles)
23

24. SafeHome ACD
24

25. Defining Archetypes
 An archetype is a class or pattern that 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.
 Eg Safe Home Security Function, following
archetypes can be defined:
 Node: represents a cohesive collection of input and
output elements of the home security function.eg. It
might be comprised of (1)various sensors (2) variety
of alarm indicators.
25

26. Defining Archetypes
cont…
 Detector: An abstraction that encompasses all
sensing equipment that feeds information into the
target system.
 Indicator: An abstraction that represents all
mechanisms(eg alarm, flashing lights, bell) for
indicating that an alarm condition is occurring.
 Controller: an abstraction that depicts the mechanism
that allows the arming or disarming of a node. If
controllers reside on a network, they have the ability
to communicate with one another.
26

27. SafeHome Archetype
27

28. Component Structure
28

29. Component Elaboration
29