1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software...

17
1 Software Engineering: A Practitioner’s Approach, 6/e Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Chapter 10a: Architectural Design Architectural Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

Transcript of 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software...

Page 1: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

1

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 10a:Chapter 10a:Architectural DesignArchitectural Design

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

Page 2: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

2

Why Architecture?Why Architecture?The architecture is not the operational software. The architecture is not the operational software. Rather, it is a representation that enables a Rather, it is a representation that enables a software engineer to: software engineer to:

(1) analyze the effectiveness of the design in (1) analyze the effectiveness of the design in meeting its stated requirements, meeting its stated requirements,

(2) consider architectural alternatives at a stage (2) consider architectural alternatives at a stage when making design changes is still relatively easy, when making design changes is still relatively easy, and and

(3) reduce the risks associated with the (3) reduce the risks associated with the construction of the software.construction of the software.

Page 3: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

3

Why is Architecture Why is Architecture Important?Important?

Representations of software architecture are an enablerRepresentations of software architecture are an enabler for for communication between all parties (stakeholders) interested in the communication between all parties (stakeholders) interested in the development of a computer-based system.development of a computer-based system.

The architecture highlights early design decisionsThe architecture highlights early design decisions that will have a that will have a profound impact on all software engineering work that follows and, as profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.important, on the ultimate success of the system as an operational entity.

Architecture “constitutes a relatively small, intellectually graspable modelArchitecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” of how the system is structured and how its components work together” [BAS03].[BAS03].

Page 4: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

4

Data DesignData Design

At the architectural level …At the architectural level … Design of one or more databases to support the Design of one or more databases to support the

application architectureapplication architecture Design of methods for ‘Design of methods for ‘miningmining’ the content of multiple ’ the content of multiple

databasesdatabases navigate through existing databases in an attempt to navigate through existing databases in an attempt to

extract appropriate business-level informationextract appropriate business-level information Design of a Design of a data warehousedata warehouse—a large, independent —a large, independent

database that has access to the data that are stored in database that has access to the data that are stored in databases that serve the set of applications required by a databases that serve the set of applications required by a businessbusiness

Page 5: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

5

Data Data DesignDesign At the component level …At the component level …

refine data objects and develop a set of data refine data objects and develop a set of data abstractionsabstractions

implement data object attributes as one or implement data object attributes as one or more data structuresmore data structures

review data structures to ensure that review data structures to ensure that appropriate relationships have been establishedappropriate relationships have been established

simplify data structures as requiredsimplify data structures as required

Page 6: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

6

Data Design—Component Data Design—Component LevelLevel

1. The systematic analysis principles applied to function 1. The systematic analysis principles applied to function and behavior should also be applied to data. and behavior should also be applied to data. 2. All data structures and the operations to be performed 2. All data structures and the operations to be performed on each should be identified. on each should be identified. 3. A data dictionary should be established and used to 3. A data dictionary should be established and used to define both data and program design. define both data and program design. 4. Low level data design decisions should be deferred 4. Low level data design decisions should be deferred until late in the design process. until late in the design process. 5. The representation of data structure should be known 5. The representation of data structure should be known only to those modules that must make direct use of the only to those modules that must make direct use of the data contained within the structure. data contained within the structure. 6. A library of useful data structures and the operations 6. A library of useful data structures and the operations that may be applied to them should be developed. that may be applied to them should be developed. 7. A software design and programming language should 7. A software design and programming language should support the specification and realization of abstract data support the specification and realization of abstract data types.types.

Page 7: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

7

Architectural StylesArchitectural Styles

Data-centered architecturesData-centered architectures Data flow architecturesData flow architectures Call and return architecturesCall and return architectures Object-oriented architecturesObject-oriented architectures Layered architecturesLayered architectures

Each style describes a system category that encompasses: (1) a Each style describes a system category that encompasses: (1) a set of componentsset of components (e.g., a database, computational modules) (e.g., a database, computational modules) that perform a function required by a system, (2) a that perform a function required by a system, (2) a set of set of connectorsconnectors that enable “communication, coordination and that enable “communication, coordination and cooperation” among components, (3) cooperation” among components, (3) constraintsconstraints that define that define how components can be integrated to form the system, and (4) how components can be integrated to form the system, and (4) semantic modelssemantic models that enable a designer to understand the that enable a designer to understand the overall properties of a system by analyzing the known overall properties of a system by analyzing the known properties of its constituent parts. properties of its constituent parts.

Page 8: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

8

Data-Centered ArchitectureData-Centered Architecture

Page 9: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

9

Data Flow ArchitectureData Flow Architecture

Page 10: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

10

Call and Return ArchitectureCall and Return Architecture

Page 11: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

11

Layered ArchitectureLayered Architecture

Page 12: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

12

Architectural PatternsArchitectural Patterns ConcurrencyConcurrency—applications must handle multiple tasks in a —applications must handle multiple tasks in a

manner that simulates parallelism manner that simulates parallelism operating system process managementoperating system process management patternpattern task schedulertask scheduler pattern pattern

PersistencePersistence—Data persists if it survives past the execution of —Data persists if it survives past the execution of the process that created it. Two patterns are common: the process that created it. Two patterns are common:

a a database management systemdatabase management system pattern that applies the storage and pattern that applies the storage and retrieval capability of a DBMS to the application architectureretrieval capability of a DBMS to the application architecture

an an application levelapplication level persistencepersistence pattern that builds persistence pattern that builds persistence features into the application architecturefeatures into the application architecture

DistributionDistribution— the manner in which systems or components — the manner in which systems or components within systems communicate with one another in a distributed within systems communicate with one another in a distributed environmentenvironment

AA brokerbroker acts as a ‘middle-man’ between the client component and a acts as a ‘middle-man’ between the client component and a server component.server component.

Page 13: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

13

Architectural DesignArchitectural Design

The software must be placed into contextThe software must be placed into context the design should define the external entities (other the design should define the external entities (other

systems, devices, people) that the software interacts systems, devices, people) that the software interacts with and the nature of the interactionwith and the nature of the interaction

A set of architectural archetypes should be A set of architectural archetypes should be identifiedidentified AnAn archetypearchetype is an abstraction (similar to a class) that is an abstraction (similar to a class) that

represents one element of system behaviorrepresents one element of system behavior The designer specifies the structure of the The designer specifies the structure of the

system by defining and refining software system by defining and refining software components that implement each archetypecomponents that implement each archetype

Page 14: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

14

Architectural ContextArchitectural Context

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses

Page 15: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

15

ArchetypesArchetypes

Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])

Controller

Node

communicates with

Detector Indicator

Page 16: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

16

Component StructureComponent StructureSafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing

Page 17: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:

17

Refined Component Refined Component StructureStructure

sensorsensorsensorsensor

sensorsensorsensor

sensor

External Communication Management

GUI Internet Interface

Security

Control

panelprocessing

detector

managementalarm

processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Executive