©ian sommerville 2000, tom dietterich 2001 slide 1 architectural design and software architecture l...

©Ian Sommerville 2000, Tom Dietterich 2001 Slide 1

Architectural Design and Software Architecture

The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design

The output of this design process is a description of the software architecture


Architectural Design

An early stage of the system design process

Represents the link between specification and design processes

Often carried out in parallel with some specification activities

It involves identifying major system components and their communications


Advantages of explicit architecture

Stakeholder communication• Architecture may be used as a focus of discussion by

system stakeholders

System analysis• Means that analysis of whether the system can meet

its non-functional requirements is possible

Large-scale reuse• The architecture may be reusable across a range of

systems


Architectural design activities

System structuring• The system is decomposed into several principal sub-

systems and communications between these sub-systems are identified

Control modelling• A model of the control relationships between the

different parts of the system is established

Modular decomposition• The identified sub-systems are decomposed into

modules


Sub-systems and modules

A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.

A module is a system component that provides services to other components but would not normally be considered as a separate system


Architectural models

Different architectural models may be produced during the design process

Each model presents different perspectives on the architecture


Architectural models

Static structural model that shows the major system components

Dynamic process model that shows the process structure of the system

Interface model that defines sub-system interfaces

Relationships model such as a data-flow model


Architectural styles

The architectural model of a system may conform to a generic architectural model or style

An awareness of these styles can simplify the problem of defining system architectures

However, most large systems are heterogeneous and do not follow a single architectural style


Architecture attributes Performance

• Localize operations to minimize sub-system communication (use tightly-coupled design)

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


Performance

Tightly-coupled components • Rich communication• Shared variables• Shared subroutines

Smaller memory footprint Less subroutine-call overhead Less parameter checking


Security

Critical assets (databases, communications links) should be isolated in “innermost” layers

Access to these assets can be carefully controlled through a small number of interfaces that can be more easily validated.

Creates bottlenecks in communication (and design)


Safety

Safety-critical operations should be isolated to a small number of small subsystems• Reduces the cost of safety validation (either through

formal methods or careful testing or both)• Reduces efficiency


Availability Include redundant components and failure

fall-backs.• Detect failures using time-outs and exceptions• Invoke back-up components if first-choice

components fail• Distribute workload across many components

Permits live updating and replacement of defective components

Reduces performance by requiring redundant computations


Maintainability

Use fine-grained, self-contained components• Self-contained components help to localized future

changes to a single component

Separate produces of data from consumers of data• No shared data structures• Clean interfaces


Trade-offs

Performance conflicts with all of the other attributes: Security, Safety, Availability, and Maintainability

High performance typically requires large, tightly-integrated routines; the other attributes require small, de-coupled routines

Compromises must be made Usually it is best to design for the other attributes

and then change the design as necessary to achieve the desired performance. “Get it right, then make it fast”

Premature optimization is a major source of bugs and high development and maintenance costs.


A Catalogue of Architectural Styles

Structural Styles• The Repository architecture

• The Client-Server architecture

• The Abstract machine architecture

Control Styles• Fixed, Centralized control (Procedure call/return)

• Flexible, Centralized control (Manager)

• Fixed, Decentralized control (Interrupts)

• Flexible, Decentralized control (Blackboard)

Modular Decomposition Styles• Object-Oriented decomposition

• Data-Flow decomposition

Domain-Specific Styles


Activity 1:System structuring

Concerned with decomposing the system into interacting sub-systems

The architectural design is normally expressed as a block diagram presenting sub-systems and communications links

More specific models showing how sub-systems share data, how they are distributed, and how they interface with each other may also be developed


Example: Packing robot control system

Visionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller


The repository model

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

When large amounts of data are to be shared, the repository model of sharing is most commonly used


Repository Example : CASE toolset architecture

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator


Repository model characteristics

Advantages• Efficient way to share large amounts of data• Sub-systems need not be concerned with how data is

produced. Centralized management e.g. backup, security, etc.

• Sharing model is published as the repository schema

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 architecture

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

Set of clients which call on these services Network which allows clients to access

servers

Film and picture library

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network


Client-server characteristics

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

support cheaper hardware• Easy to add new servers or upgrade existing servers

Disadvantages• No shared data model, so sub-systems use different

data organization. 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 model

Used to model the interfacing of sub-systems Organizes the system into a set of layers (or

abstract machines) each of which provides a set of services

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

However, often difficult to structure systems in this way


Abstract Machine Example:Version management system

Operatingsystem

Database system

Object management

Version management


Abstract Machine Example 2: Multiple Language Support

C++ Java C

Java Abstract Machine

CPU


System Structure for CMS

What architecture should we use? What are the primary system

components?• Web server• Database (papers, assignments, reviews, decisions)• Special-purpose interfaces for referee assignments

and PC-member assignment• External programs (acroread, ghostview) for viewing

and printing papers• External files (copies of papers) on local machine


Architectural Diagram

CentralDatabase

WebServer

PaperViewers

WebBrowser

LocalFiles

ActiveInterfaces

InterfaceServer


CMS Styles

Overall design: Client-Server + Repository Database is central repository Two servers: Web server, Interface server Interface server can be abstract machine

• Register multiple clients• Distribute updates to all• Pass through database operations• Serialize database operations?


Activity 2: Control Modeling

Design the control flow between sub-systems. Distinct from designing the system decomposition

Attributes of Control• Centralized versus Decentralized• Fixed versus Dynamic


Centralized versus Decentralized

Centralized Control• Manager or main program is responsible for all

control decisions

Decentralized Control• Interrupts or messages are routed to separate

subcomponents• Subcomponents decide whether to respond to them.


Fixed versus Dynamic Control

Fixed (Static) Control• Connections between Caller and Callee are fixed at

compile time• Order of execution of components is predictable

Dynamic Control• Order of execution is determined by dynamic events• May be mediated by a global data structure (event

queue, message buffer)


Architectural Combinations

Subroutine Call and Return

Event-queue, agenda, etc.

Interrupt-driven Systems

Broadcast Systems

Blackboard Architecture

Fixed Dynamic

Centralized

Decentralized


Fixed, Centralized Control

Traditional control structure in single-threaded imperative programming languages

Control by procedure call and return


Call-return model

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram


Fixed, Centralized Control:Advantages and Disadvantages

Advantages:• Efficient: very little overhead in subroutine calls• Predictable: flow of control is easy to predict and

understand

Disadvantages:• Exceptional conditions are hard to handle• Caller must know name of callee (early binding)


Dynamic, Centralized Control: The Manager

Manager maintains a central data structure (agenda, schedule, event queue, process queue)

Repeat• Choose next item from data structure• Invoke the corresponding routine

» Routine may add or delete items from the central data structure

• External events may also add or delete items from the central data structure


The Manager Model

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses


Manager Example 1: Spacecraft control

Central data structure: Schedule of desired activities • Data collection (observe stars)• Navigation (fire rockets)• Data transmission (send and receive from earth)

Manager monitors schedule, starts and stops (concurrent) activities according to the schedule

Ground controllers can upload new schedules


Manager Example 2:Discrete Event Simulation

Priority queue of future events to simulate• Sorted by time (soonest first)

Global simulated clock Repeat:

• Pop next event off queue• Call appropriate subroutine to simulate the event

» Subroutine can push new events onto the event queue


Manager Example 3:GUI Event Loop

Central data structure: list of events (mouse clicks, keystrokes, mouse motion, window minimize, maximize, close, create)

Events can result from user at keyboard or from program execution


Manager Example 4:Operating System

Process scheduling in operating system Central data structure: Process queues:

Ready queue, blocked queue Events:

• Process blocks• Fork(); Exit()• Process unblocks• CPU timer expires


Manager Model Summary

Advantages:• Exact sequence of events is determined at run time• Allows system to respond to external events

asynchronously (without waiting for them)

Disadvantages:• Flexible control can lead to combinatorially many

event sequences – you can’t test them all.


Fixed, decentralized control:Interrupt-driven systems Used in real-time systems where fast response

to an event is essential There are known interrupt types with a handler

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

and a hardware switch causes transfer to its handler• Mapping is fixed and does not require a central manager.

Allows fast response but complex to program and difficult to validate


Interrupt-driven control

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector


Flexible, Decentralized Control: Broadcast model

Sub-systems register an interest in specific events. When these occur, a message is sent to the sub-system which can handle the event

Control policy is not embedded in a central manager. Sub-systems decide on events of interest to them

Events aren’t really “broadcast”, but the system behaves as if they were


Broadcast System Structure

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4


Example 1: HEARSAY Speech Recognition

Central data structure: BLACKBOARD• Data objects describe speech signal, phonemes,

words, sentences

Subsystems:• Map speech signal to phoneme hypotheses• Map phoneme hypotheses to word hypotheses• Map word hypotheses to sentence hypotheses• Map sentence hypotheses to word hypotheses• Map word hypotheses to phoneme hypotheses

Posting a new hypothesis causes other systems to execute


Example 2: Distributed Object Systems

Components register with object broker, which acts as a kind of name server for objects

Clients that want to invoke an object ask the name server to give them a pointer to an implementation.

A call to a remote object ships the arguments to the remote object where it is processed and the result is returned.

Component may be in same process, on same computer, on same network, or on the internet

Examples: CORBA, DCOM, Java/RMI


Advantages and Disadvantages of Broadcast Model

Advantages:• Easy to add or remove new components• Components are completely decoupled• Components are bound at run time

Disadvantages:• Multiple components may register for same events• Some events may not have any components, so

caller does not know for sure that it will receive a response!» CORBA throws RemoteException

• Flow of control can be very confusing, hard to debug


Choosing a Control Architecture

Is sequence of execution static and known in advance • If YES, then Procedure Call and Return

Is this a hard real-time system?• If YES, then Interrupt Architecture

Is a Manager needed to prioritize events? Can a Manager prioritize events?• If YES, then Manager• Else, Broadcast


CMS Control Model

Web Server uses Manager Model Interface Server could use Manager

Model or Broadcast Model• Need dynamic control, because multiple users will be

creating events• Events may simultaneously involve PC assignments,

referee assignments, and interacting with the decision interface.


Activity 3:Modular decomposition

Decompose each subsystem into modules Two modular decomposition models

covered• An object model where the system is decomposed into

interacting objects• A data-flow model where the system is decomposed

into functional modules which transform inputs to outputs. Also known as the pipeline model

If possible, decisions about concurrency should be delayed until modules are implemented


Object models Structure the system into a set of loosely

coupled objects with well-defined interfaces

Object-oriented decomposition is concerned with identifying object classes, their attributes and operations

When implemented, objects are created from these classes and some control model used to coordinate object operations


Example Object Decomposition:Invoice processing system

issue ()sendReminder ()acceptPayment ()sendReceipt ()

invoice#dateamountcustomer

Invoice

invoice#dateamountcustomer#

Receipt

invoice#dateamountcustomer#

Payment

customer#nameaddresscredit period

Customer


Data-flow models

Functional transformations process their inputs to produce outputs

May be referred to as a pipe and filter model (as in UNIX shell)

Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems

Not really suitable for interactive systems


Invoice processing system

Read issuedinvoices

Identifypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments


Talk on Project Management

Who: Tektronix What: This presentation talks about things

we as engineers can do to improve hitting our forecast end date and covers best practices in the area of scheduling, estimating, project lifecycles, etc.

When: Monday, Nov 5th, 5:30pm Where: Covell 216 There's also free pizza


Midterm ResultsN: 28 Min: 13.5 Max: 43.5 Mean 27.57142813.500 xx17.250 xx21.000 xxxxx24.750 xxxxxx28.500 xxxxx32.250 xxxxx36.000 xx39.750 43.500 xValue = 33 points


System Requirements Document

See Sommerville p. 117 and examples online Suggested outline:

• 1. Introduction: Purpose, users, scope of system. Reason for implementation

• 2. Glossary of all entities in the system

• 3. Overall system models:» Context model showing context and scope of system» Class model of major system entities» State diagrams for system states or subsystem states

• 4. Non-functional requirements

• 5. Functional requirements


Domain-specific architectures

Architectural models which are specific to some application domain

Two types of domain-specific model• Generic models which are abstractions from a number of

real systems and which encapsulate the principal characteristics of these systems

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

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


Generic models

Compiler model is a well-known example, although other models exist in more specialized application domains• Lexical analyser

• Symbol table

• Syntax analyser

• Syntax tree

• Semantic analyser

• Code generator

Generic compiler model may be organized according to different architectural models


Compiler model

Lexicalanalysis

Syntacticanalysis

Semanticanalysis

Codegeneration

Symboltable


Language processing system

Syntaxanalyser

Lexicalanalyser

Semanticanalyser

Abstractsyntax tree

Grammardefinition

Symboltable

Outputdefinition

Pretty-printer

Editor

Optimizer

Codegenerator

Repository


Reference architectures

Reference models are derived from a study of the application domain rather than from existing systems

May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated

OSI model is a layered model for communication systems


OSI reference model

Application

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

Application


Key points

The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model

Large systems rarely conform to a single architectural model

System decomposition models include repository models, client-server models, and abstract machine models

Control models are centralized or decentralized and fixed or dynamic.


Key points

Modular decomposition models include data-flow and object models

Domain-specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealized reference models

©ian sommerville 2000, tom dietterich 2001 slide 1 architectural design and software architecture l...

Documents