Software architecture

Download Report

Transcript Software architecture

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


System analysis


Architecture may be used as a focus of
discussion by system stakeholders.
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.
Box and line diagrams


Very abstract - they do not show the
nature of component relationships nor
the externally visible properties of the
sub-systems.
However, useful for communication with
stakeholders and for project planning.
Packing robot control system
Architectural design decisions








Is there a generic application architecture that can be used?
How will the system be distributed?
What architectural styles are appropriate?
What approach will be used to structure the system?
How will the system be decomposed into modules?
What control strategy should be used?
How will the architectural design be evaluated?
How should the architecture be documented?
Architectural models






Used to document an architectural design.
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 that shows subsystem relationships.
Distribution model that shows how sub-systems are distributed
across computers.
Distributed system
characteristics





Resource sharing
 Sharing of hardware and software resources.
Openness
 Use of equipment and software from different vendors.
Concurrency
 Concurrent processing to enhance performance.
Scalability
 Increased throughput by adding new resources.
Fault tolerance
 The ability to continue in operation after a fault has
occurred.
Distributed system
disadvantages

Complexity


Security


More susceptible to external attack.
Manageability


Typically, distributed systems are more complex
than centralised systems.
More effort required for system management.
Unpredictability

Unpredictable responses depending on the system
organisation and network load.
Distributed systems
architectures

Client-server architectures


Distributed services which are called on by
clients. Servers that provide services are
treated differently from clients that use
services.
Distributed object architectures

No distinction between clients and servers.
Any object on the system may provide and
use services from other objects.
Multiprocessor architectures




Simplest distributed system model.
System composed of multiple processes
which may (but need not) execute on
different processors.
Architectural model of many large real-time
systems.
Distribution of process to processor may be
pre-ordered or may be under the control of a
dispatcher.
A multiprocessor traffic control
system
Senso r
p rocessor
Senso r
con trol
p rocess
Traffic flo w
p rocessor
Disp lay
p rocess
Traffic ligh t con trol
p rocessor
Ligh t
con trol
p rocess
Traffic ligh ts
Traffic flowsensors and
cameras
Op erato r con soles
Advantages of distributed object
architecture




It allows the system designer to delay decisions on
where and how services should be provided.
It is a very open system architecture that allows new
resources to be added to it as required.
The system is flexible and scaleable.
It is possible to reconfigure the system dynamically
with objects migrating across the network as
required.
Client-server model




Distributed system model which shows how data and
processing is distributed across a range of
components.
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.
Thin and fat clients

Thin-client model


In a thin-client model, all of the application processing and
data management is carried out on the server. The client is
simply responsible for running the presentation software.
Fat-client model
 In this model, the server is only responsible for data
management. The software on the client implements the
application logic and the interactions with the system user.
A 3-tier C/S architecture
An internet banking system
Client
Client
HTT P interaction
SQL query
Account serv ice
p rov isio n
Client
Client
Database server
Web server
SQL
Custo mer
acco unt
database
Film and picture library
Client-server characteristics


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.
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 (layered)
model




Used to model the interfacing of sub-systems.
Organises the system into a set of layers (or
abstract machines) each of which provide 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 artificial to structure systems
in this way.
Version management system
Configuration management system layer
Object management system lay er
Database system layer
Operating system layer
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.
Invoice processing system
Object model advantages




Objects are loosely coupled so their implementation
can be modified without affecting other objects.
The objects may reflect real-world entities.
OO implementation languages are widely used.
However, object interface changes may cause
problems and complex entities may be hard to
represent as objects.
Function-oriented pipelining




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
Call-return model
Real-time system control
Event-driven systems



Driven by externally generated events where the timing of the
event is outwith the control of the sub-systems which process
the event.
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
to some other component for processing.
Other event driven models include spreadsheets and production
systems.
Selective broadcasting
Interrupt-driven control
Use of application
architectures





As a starting point for architectural
design.
As a design checklist.
As a way of organising the work of the
development team.
As a means of assessing components
for reuse.
As a vocabulary for talking about
application types.
Application types




Data processing applications
 Data driven applications that process data in batches
without explicit user intervention during the processing.
Transaction processing applications
 Data-centred applications that process user requests and
update information in a system database.
Event processing systems
 Applications where system actions depend on interpreting
events from the system’s environment.
Language processing systems
 Applications where the users’ intentions are specified in a
formal language that is processed and interpreted by the
system.
Application type examples




Data processing systems
 Billing systems;
 Payroll systems.
Transaction processing systems
 E-commerce systems;
 Reservation systems.
Event processing systems
 Word processors;
 Real-time systems.
Language processing systems
 Compilers;
 Command interpreters.
Input-process-output model
System
Inp ut
Pro cess
Output
Prin ter
Database
Data-flow diagrams


Show how data is processed as it
moves through a system.
Transformations are represented as
round-edged rectangles, data-flows as
arrows between them and files/data
stores as rectangles.
Salary payment DFD
Transaction processing
I/O
p rocessing
Application
lo gic
Transactio n
manager
Database
ATM system organisation
Transaction management
E-commerce system
architecture


E-commerce systems are Internet-based resource
management systems that accept electronic orders
for goods or services.
They are usually organised using a multi-tier
architecture with application layers associated with
each tier.
Web
browser
Webserver
Ap plicatio n
server
Database
server
Event processing systems



These systems respond to events in the
system’s environment.
Their key characteristic is that event
timing is unpredictable so the
architecture has to be organised to
handle this.
Many common systems such as word
processors, games, etc. are event
processing systems.
Editing system components

Editing systems are naturally object-oriented:
 Screen - monitors screen memory and detects events;
 Event - recognises events and passes them for processing;
 Command - executes a user command;
 Editor data - manages the editor data structure;
 Ancillary data - manages other data such as styles and
preferences;
 File system - manages file I/O;
 Display - updates the screen display.
Editing system architecture
File System
Save
Open
Ancillary data
Editor data
Ancillary
commands
Editing
commands
Command
Display
Interp ret
Update
Event
Process
Screen
Refresh
Language processing systems



Accept a natural or artificial language as input and
generate some other representation of that language.
May include an interpreter to act on the instructions
in the language that is being processed.
Used in situations where the easiest way to solve a
problem is to describe an algorithm or describe the
system data
 Meta-case tools process tool descriptions, method
rules, etc and generate tools.
Language processing
components






Lexical analyser
Symbol table
Syntax analyser
Syntax tree
Semantic analyser
Code generator
Data-flow model of a compiler
Repository model of a
compiler