Architectural Design

Objectives  To introduce architectural design and to discuss its importance  To explain the architectural design decisions that have to be made  To introduce three complementary architectural styles covering organisation, decomposition and contr

Trang 1

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 11 Slide 1

Objectives

discuss its importance

that have to be made

architectural styles covering organisation, decomposition and control

to communicate and compare architectures

Topics covered

Trang 2

Software architecture

sub-systems making up a system and the framework for sub-system control and

communication is architectural design.

description of the software architecture

Architectural design

and design processes

specification activities

components and their communications

Advantages of explicit architecture

discussion by system stakeholders.

meet its non-functional requirements is possible.

range of systems.

Trang 3

Architecture and system characteristics

• Localise critical operations and minimise communications Use large rather than fine-grain components.

• Use a layered architecture with critical assets in the inner layers.

• Localise safety-critical features in a small number of sub-systems.

 Availability

• Include redundant components and mechanisms for fault tolerance.

• Use fine-grain, replaceable components.

Architectural conflicts

performance but reduces maintainability

availability but makes security more difficult

means more communication so degraded performance

System structuring

into interacting sub-systems

expressed as a block diagram presenting an overview of the system structure

sub-systems share data, are distributed and interface with each other may also be developed

Trang 4

Packing robot control system

Vision

system

Object

identifica tion

system

Arm contr oller

Gripper contr oller

Packa g ing

selection

system

Packing

system Conveyorcontr oller

Box and line diagrams

of component relationships nor the externally visible properties of the sub-systems

stakeholders and for project planning

Architectural design decisions

the process differs depending on the type of system being developed

span all design processes

Trang 5

Architectural design decisions

 Is there a generic application architecture that can

be used?

Architecture reuse

similar architectures that reflect domain concepts

core architecture with variants that satisfy particular customer requirements

Chapter 13 and product lines in Chapter 18

Architectural styles

conform to a generic architectural model or style

the problem of defining system architectures

heterogeneous and do not follow a single architectural style

Trang 6

Architectural models

components.

structure of the system.

shows sub-system relationships.

distributed across computers.

System organisation

structure a system

The repository model

be done in two ways:

repository and may be accessed by all sub-systems;

and passes data explicitly to other sub-systems.

shared, the repository model of sharing is most commonly used

Trang 7

CASE toolset architecture

Project repository Design

transla tor

Pr ogram editor

Design

editor

Code gener ator

Design

anal yser

Repor t gener ator

Repository model characteristics

• Efficient way to share large amounts of data;

• Sub-systems need not be concerned with how data is produced Centralised management e.g backup, security, etc.

• Sharing model is published as the repository schema.

• Sub-systems must agree on a repository data model Inevitably a compromise;

• Data evolution is difficult and expensive;

• No scope for specific management policies;

• Difficult to distribute efficiently.

Client-server model

data and processing is distributed across a range of components

specific services such as printing, data management, etc

servers

Trang 8

Film and picture library

Catalogue

server

Library

ca talo gue

Video

server

Film clip

files

Pictur e server Digitised photo g raphs

Webserv er Film and photo info.

Internet

Client-server characteristics

• Distribution of data is straightforward;

• Makes effective use of networked systems May require cheaper hardware;

• Easy to add new servers or upgrade existing servers.

• No shared data model so sub-systems use different data organisation Data interchange may be inefficient;

• Redundant management in each server;

• No central register of names and services - it may be hard

to find out what servers and services are available.

Abstract machine (layered) model

machines) each of which provide a set of services.

sub-systems in different layers When a layer interface changes, only the adjacent layer is affected.

 However, often artificial to structure systems in this way.

Trang 9

Version management system

Configuration management system layer

Database system layer

Operating system layer Object management system layer

Modular decomposition styles

modules

organisation and modular decomposition

Sub-systems and modules

whose operation is independent of the services provided by other sub-systems

provides services to other components but would not normally be considered as a separate system

Trang 10

Modular decomposition

decomposed into modules.

• An object model where the system is decomposed into interacting object;

• A pipeline or data-flow model where the system is decomposed into functional modules which transform inputs to outputs.

delayed until modules are implemented.

Object models

coupled objects with well-defined interfaces

with identifying object classes, their attributes and operations

these classes and some control model used

to coordinate object operations

Invoice processing system

issue () sendReminder () acceptP ayment () sendReceipt ()

invoice#

date amount customer

invoice#

date amount customer#

invoice#

date

amount

customer#

name

ad dress

credit period

Customer

Payment

Invoice

Receipt

Trang 11

Object model advantages

implementation can be modified without affecting other objects

used

cause problems and complex entities may

be hard to represent as objects

Function-oriented pipelining

inputs to produce outputs

(as in UNIX shell)

When transformations are sequential, this is

a batch sequential model which is

extensively used in data processing systems

Invoice processing system

Read issued

invoices

Identify

payments

Issue receipts

Find

pa yments due

Receipts

Issue

pa yment reminder

Reminders Invoices Payments

Trang 12

Pipeline model advantages

communication

concurrent or sequential system

transfer along the pipeline and difficult to support event-based interaction

Control styles

sub-systems Distinct from the system decomposition model

control and starts and stops other sub-systems.

generated events from other sub-systems or the system’s environment.

Centralised control

managing the execution of other sub-systems.

• Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards Applicable to sequential systems.

• Applicable to concurrent systems One system component controls the stopping, starting and coordination of other system processes Can be implemented in sequential systems as a case statement.

Trang 13

Call-return model

Routine 1.2

Routine 1

Main pro gram

Real-time system control

System contr oller

User inter face

Fault handler Computa tion

pr ocesses

Actua tor processes Sensor

pr ocesses

Event-driven systems

timing of the event is outwith the control of the sub-systems which process the event.

• Broadcast models An event is broadcast to all sub-systems Any sub-system which can handle the event may do so;

• Interrupt-driven models Used in real-time systems where interrupts are detected by an interrupt handler and passed

to some other component for processing.

and production systems.

Trang 14

Broadcast model

 Effective in integrating sub-systems on different computers in a network.

 Sub-systems register an interest in specific events When these occur, control is transferred to the sub-system which can handle the event.

message handler Sub-systems decide on events of interest to them.

event will be handled.

Selective broadcasting

Sub-system

1

Event and messa ge handler

Sub-system

2 Sub-system 3 Sub-system 4

Interrupt-driven systems

response to an event is essential

handler defined for each type

location and a hardware switch causes transfer to its handler

and difficult to validate

Trang 15

Interrupt-driven control

Handler

1

Handler

2 Handler 3 Handler 4

Process

1

Process

2 Process 3 Process 4

Interrupts

Interrupt

vector

Reference architectures

application domain.

• Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems Covered in Chapter 13.

• Reference models which are more abstract, idealised model Provide a means of information about that class of system and of comparing different architectures.

Reference models are top-down models.

Reference architectures

of the application domain rather than from existing systems

implementation or to compare different systems It acts as a standard against which systems can be evaluated

communication systems

Trang 16

OSI reference model

Presenta tion

Session

Transpor t

Netw ork

Data link

Physical

7

6

5

4

3

2

1

Comm unica tions medium

Netw or k Data link Physical

Applica tion Presenta tion Session Transpor t Netw or k Data link Physical Applica tion

Case reference model

• Storage and management of data items.

• Managing groups of entities.

• Definition and enaction of process models.

• Tool-tool and tool-environment communication.

• User interface development.

The ECMA reference model

Tool

slots

Message services Task management services

User inter face services

Data repository services Data integ ration services

Trang 17

Key points

framework for structuring the system.

the application architecture, the distribution and the architectural styles to be used.

model, a control model and a decomposition model may be developed.

models, client-server models and abstract machine models.

Key points

object models and pipelining models

and event-driven models

communicate domain-specific architectures and to assess and compare architectural designs

Architectural models

produced during the design process

on the architecture

Trang 18

Architecture attributes

 Performance

• Localise operations to minimise sub-system communication

 Security

• Use a layered architecture with critical assets in inner layers

 Safety

• Isolate safety-critical components

 Availability

• Include redundant components in the architecture

 Maintainability

• Use fine-grain, self-contained components

Tiêu đề	Architectural design
Tác giả	Ian Sommerville
Trường học	Software Engineering
Thể loại	Chương
Năm xuất bản	2004

Định dạng
Số trang	18
Dung lượng	86,87 KB