©ian sommerville 2000, tom dietterich 2001 slide 1 architectural design and software architecture l...
Post on 11-Jan-2016
218 Views
Preview:
TRANSCRIPT
©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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 2
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 3
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 4
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 5
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 6
Architectural models
Different architectural models may be produced during the design process
Each model presents different perspectives on the architecture
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 7
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 8
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 9
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 10
Performance
Tightly-coupled components • Rich communication• Shared variables• Shared subroutines
Smaller memory footprint Less subroutine-call overhead Less parameter checking
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 11
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)
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 12
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 13
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 14
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 15
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.
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 16
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 17
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 18
Example: Packing robot control system
Visionsystem
Objectidentification
system
Armcontroller
Grippercontroller
Packagingselectionsystem
Packingsystem
Conveyorcontroller
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 19
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 20
Repository Example : CASE toolset architecture
Projectrepository
Designtranslator
Programeditor
Designeditor
Codegenerator
Designanalyser
Reportgenerator
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 21
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 22
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 24
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 25
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 26
Abstract Machine Example:Version management system
Operatingsystem
Database system
Object management
Version management
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 27
Abstract Machine Example 2: Multiple Language Support
C++ Java C
Java Abstract Machine
CPU
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 28
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 29
Architectural Diagram
CentralDatabase
WebServer
PaperViewers
WebBrowser
LocalFiles
ActiveInterfaces
InterfaceServer
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 30
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?
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 31
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 32
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.
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 33
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)
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 34
Architectural Combinations
Subroutine Call and Return
Event-queue, agenda, etc.
Interrupt-driven Systems
Broadcast Systems
Blackboard Architecture
Fixed Dynamic
Centralized
Decentralized
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 35
Fixed, Centralized Control
Traditional control structure in single-threaded imperative programming languages
Control by procedure call and return
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 36
Call-return model
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 37
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)
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 38
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 39
The Manager Model
Systemcontroller
Userinterface
Faulthandler
Computationprocesses
Actuatorprocesses
Sensorprocesses
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 40
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 41
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 42
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 43
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 44
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.
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 45
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 46
Interrupt-driven control
Handler1
Handler2
Handler3
Handler4
Process1
Process2
Process3
Process4
Interrupts
Interruptvector
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 47
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 48
Broadcast System Structure
Sub-system1
Event and message handler
Sub-system2
Sub-system3
Sub-system4
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 49
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 50
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 51
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 52
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 53
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.
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 54
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 55
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 56
Example Object Decomposition:Invoice processing system
issue ()sendReminder ()acceptPayment ()sendReceipt ()
invoice#dateamountcustomer
Invoice
invoice#dateamountcustomer#
Receipt
invoice#dateamountcustomer#
Payment
customer#nameaddresscredit period
Customer
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 57
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 58
Invoice processing system
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 59
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 60
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 61
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 62
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 63
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 64
Compiler model
Lexicalanalysis
Syntacticanalysis
Semanticanalysis
Codegeneration
Symboltable
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 65
Language processing system
Syntaxanalyser
Lexicalanalyser
Semanticanalyser
Abstractsyntax tree
Grammardefinition
Symboltable
Outputdefinition
Pretty-printer
Editor
Optimizer
Codegenerator
Repository
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 66
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 67
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
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 68
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.
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 69
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
top related