architectural design u establishing the overall structure ...bmitchell/course/mcs451/ch_13.pdf ·...

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 13 Slide 1

Architectural Design

u Establishing the overallstructure of a software system


Objectivesu To introduce architectural design and its role in

the software processu To describe a number of different types of

architectural modelu To show how the architecture of a system may be

modelled in different waysu To discuss how domain-specific reference models

may be used to compare software architectures


Topics coveredu System structuringu Control modelsu Modular decompositionu Domain-specific architectures


Architectural parallelsu Architects are the technical interface between the

customer and the contractor building the systemu A bad architectural design for a building cannot

be rescued by good construction; the same is truefor software

u There are specialist types of building andsoftware architects

u There are schools or styles of building andsoftware architecture


Architectural design processu System structuring

• The system is decomposed into several principal sub-systemsand communications between these sub-systems are identified

u Control modelling• A model of the control relationships between the different parts

of the system is established

u Modular decomposition• The identified sub-systems are decomposed into modules


Sub-systems and modulesu A sub-system is a system in its own right whose

operation is independent of the services providedby other sub-systems.

u A module is a system component that providesservices to other components but would notnormally be considered as a separate system


Architectural modelsu Structure, control and modular decomposition

may be based on a particular model orarchitectural style

u However, most systems are heterogeneous in thatdifferent parts of the system are based ondifferent models and, in some cases, the systemmay follow a composite model

u The architectural model used affects theperformance, robustness, distributability andmaintainability of the system


System structuringu Concerned with decomposing the system into

interacting sub-systemsu The architectural design is normally expressed as

a block diagram presenting an overview of thesystem structure

u More specific models showing how sub-systemsshare data, are distributed and interface with eachother may also be developed


Packing robot control systemVisionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller


The repository modelu Sub-systems must exchange data. This may be

done in two ways:• Shared data is held in a central database or repository and may

be accessed by all sub-systems• Each sub-system maintains its own database and passes data

explicitly to other sub-systems

u When large amounts of data are to be shared, therepository model of sharing is most commonlyused


CASE toolset architecture

Projectreposi tory

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator


Repository model characteristicsu Advantages

• 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

u Disadvantages• 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 architectureu Distributed system model which shows how data

and processing is distributed across a range ofcomponents

u Set of stand-alone servers which provide specificservices such as printing, data management, etc.

u Set of clients which call on these servicesu Network which allows clients to access servers


Film and picture library

Catalogueserver

Catalogue

Videoserver

Fi lm cl ipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network


Client-server characteristicsu Advantages

• Distribution of data is straightforward• Makes effective use of networked systems. May require cheaper

hardware• Easy to add new servers or upgrade existing servers

u Disadvantages• 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 modelu Used to model the interfacing of sub-systemsu Organises the system into a set of layers (or

abstract machines) each of which provide a set ofservices

u Supports the incremental development of sub-systems in different layers. When a layerinterface changes, only the adjacent layer isaffected

u However, often difficult to structure systems inthis way


Version management system

Operatingsystem

Database system

Object management

Version management


Control modelsu Are concerned with the control flow between

sub-systems. Distinct from the systemdecomposition model

u Centralised control• One sub-system has overall responsibility for control and starts

and stops other sub-systems

u Event-based control• Each sub-system can respond to externally generated events

from other sub-systems or the system’s environment


Centralised controlu A control sub-system takes responsibility for

managing the execution of other sub-systemsu Call-return model

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

u Manager model• Applicable to concurrent systems. One system component

controls the stopping, starting and coordination of other systemprocesses. Can be implemented in sequential systems as a casestatement


Call-return model

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram


Real-time system control

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses


Event-driven systemsu Driven by externally generated events where the

timing of the event is outwith the control of thesub-systems which process the event

u Two principal event-driven models• 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 tosome other component for processing

u Other event driven models include spreadsheetsand production systems


Broadcast modelu Effective in integrating sub-systems on different

computers in a networku Sub-systems register an interest in specific

events. When these occur, control is transferredto the sub-system which can handle the event

u Control policy is not embedded in the event andmessage handler. Sub-systems decide on eventsof interest to them

u However, sub-systems don’t know if or when anevent will be handled


Selective broadcasting

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4


Interrupt-driven systemsu Used in real-time systems where fast response to

an event is essentialu There are known interrupt types with a handler

defined for each typeu Each type is associated with a memory location

and a hardware switch causes transfer to itshandler

u Allows fast response but complex to program anddifficult to validate


Interrupt-driven control

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector


Modular decompositionu Another structural level where sub-systems are

decomposed into modulesu Two modular decomposition models covered

• An object model where the system is decomposed intointeracting objects

• A data-flow model where the system is decomposed intofunctional modules which transform inputs to outputs. Alsoknown as the pipeline model

u If possible, decisions about concurrency shouldbe delayed until modules are implemented


Object modelsu Structure the system into a set of loosely coupled

objects with well-defined interfacesu Object-oriented decomposition is concerned with

identifying object classes, their attributes andoperations

u When implemented, objects are created fromthese classes and some control model used tocoordinate object operations


Invoice processing system

IssueSend reminderAccept paymentSend receipt

invoice #dateamountcustomer

Invoice

customer #nameaddresscredi t period

Customer

invoice #dateamountcustomer #

Receipt

invoice #dateamountcustomer #

Payment


Data-flow modelsu Functional transformations process their inputs to

produce outputsu May be referred to as a pipe and filter model (as

in UNIX shell)u Variants of this approach are very common.

When transformations are sequential, this is abatch sequential model which is extensively usedin data processing systems

u Not really suitable for interactive systems


Invoice processing system

Read issuedinvoices

Identi fypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments


Domain-specific architecturesu Architectural models which are specific to some

application domainu Two types of domain-specific model

• Generic models which are abstractions from a number of realsystems and which encapsulate the principal characteristics ofthese systems

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

u Generic models are usually bottom-up models;Reference models are top-down models


Generic modelsu Compiler model is a well-known example

although other models exist in more specialisedapplication domains• Lexical analyser• Symbol table• Syntax analyser• Syntax tree• Semantic analyser• Code generator

u Generic compiler model may be organisedaccording to different architectural models


Compiler model

Lexicalanalysi s

Syntacticanalysi s

Semanticanalysi s

Codegeneration

Symboltable


Language processing system

Syntaxanalyser

Lexicalanalyser

Semanticanalyser

Abstractsyntax tree

Grammardefini tion

Symboltable

Outputdefini tion

Pretty-printer

Editor

Optimizer

Codegenerator

Reposi tory


Reference architecturesu Reference models are derived from a study of the

application domain rather than from existingsystems

u May be used as a basis for systemimplementation or to compare different systems.It acts as a standard against which systems can beevaluated

u OSI model is a layered model for communicationsystems


OSI reference model

Appl ication

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Appl ication

Presentation

Session

Transport

Network

Data link

Physical


Key pointsu The software architect is responsible for deriving

a structural system model, a control model and asub-system decomposition model

u Large systems rarely conform to a singlearchitectural model

u System decomposition models include repositorymodels, client-server models and abstractmachine models

u Control models include centralised control andevent-driven models


Key pointsu Modular decomposition models include data-flow

and object modelsu Domain specific architectural models are

abstractions over an application domain. Theymay be constructed by abstracting from existingsystems or may be idealised reference models

architectural design u establishing the overall structure ...bmitchell/course/mcs451/ch_13.pdf ·...

Documents