1

Chapter 10Architectural Design

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

2

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

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.

3

Why Architecture?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.

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.

4

Data DesignData Design

Architectural level Database design data mining data warehousing

Component level Data structure design

Architectural level Database design data mining data warehousing

Component level Data structure design

5

What principles are applicable to data design?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.

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.

6

What principles are applicable to data designWhat 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.

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.

7

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

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.

8

Specific StylesSpecific Styles

Data-centered architecture Data flow architecture Call and return architecture Object-oriented architecture Layered architecture

Data-centered architecture Data flow architecture Call and return architecture Object-oriented architecture Layered architecture

9

Data-Centered ArchitectureData-Centered Architecture

10

Data-Centered ArchitectureData-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.

Client components independently execute processes.

11

Data-Flow ArchitectureData-Flow Architecture

12

Data-Flow ArchitectureData-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.

13

Call and Return ArchitectureCall and Return Architecture

14

Call and Return ArchitectureCall 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.

15

Object-Oriented ArchitectureObject-Oriented Architecture

16

Object-Oriented ArchitectureObject-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.

17

Layered ArchitectureLayered Architecture

18

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

19

Architectural Patterns DomainsArchitectural Patterns Domains Concurrency

operating system process management task scheduler

Persistence database management system application level persistence

Distribution broker

Concurrency operating system process management task scheduler

Persistence database management system application level persistence

Distribution broker

20

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

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.

21

Arch. Context DiagramArch. Context Diagram

22

How do system interoperate with one another?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.

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.

23

How do system interoperate with one another? Cont…

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)

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)

24

SafeHome ACDSafeHome ACD

25

Defining ArchetypesDefining ArchetypesAn 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.

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.

26

Defining Archetypes cont…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.

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.

27

SafeHome ArchetypeSafeHome Archetype

28

Component StructureComponent Structure

29

Component ElaborationComponent Elaboration