Transcript Software Engineering - College of Computing & Informatics

Software Design

Deriving a solution which
satisfies software requirements
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 1
Stages of Design

Problem understanding
–

Identify one or more solutions
–

Evaluate possible solutions and choose the most
appropriate depending on the designer's experience and
available resources.
Describe solution abstractions
–

Look at the problem from different angles to discover the
design requirements.
Use graphical, formal or other descriptive notations to
describe the components of the design.
Repeat process for each identified abstraction
until the design is expressed in primitive terms.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 2
The Design Process



Any design may be modelled as a directed
graph made up of entities with attributes which
participate in relationships.
The system should be described at several
different levels of abstraction.
Design takes place in overlapping stages. It is
artificial to separate it into distinct phases but
some separation is usually necessary.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 3
Phases in the Design Process
Re quire me nts
spec ifica
tion
De sign acvities
ti
Arc hite ctur
al
design
Abstra ct
spec ifica
tio
n
Interfa ce
design
Component
design
Data
structur
e
design
Algorithm
design
Syste m
a rc hite ctur
e
Softwa re
spec ifica
tion
Interfa ce
spec ifica
tion
Component
spec ifica
tion
Data
structur
e
spec ifica
tion
Algorithm
spec ifica
tion
De sign pr
oducts
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 4
Design Phases






Architectural design: Identify sub-systems.
Abstract specification: Specify sub-systems.
Interface design: Describe sub-system interfaces.
Component design: Decompose sub-systems
into components.
Data structure design: Design data structures to
hold problem data.
Algorithm design: Design algorithms for
problem functions.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 5
Hierarchical Design Structure
System level
Sub-system
level
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 6
Top-down Design


In principle, top-down design involves starting
at the uppermost components in the hierarchy
and working down the hierarchy level by level.
In practice, large systems design is never
truly top-down. Some branches are designed
before others. Designers reuse experience (and
sometimes components) during the design
process.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 7
Design Methods




Structured methods are sets of notations for
expressing a software design and guidelines for
creating a design.
Well-known methods include Structured Design
(Yourdon), and JSD (Jackson Method).
Can be applied successfully because the support
standard notations and ensure designs follow a
standard form.
Structured methods may be supported with
CASE tools.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 8
Method Components




Many methods support comparable views of a
system.
A data flow view showing data transformations.
An entity-relation view describing the logical
data structures.
A structural view showing system components
and their interactions.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 9
Method Deficiencies


They are guidelines rather than methods in the
mathematical sense. Different designers create
quite different system designs.
They do not help much with the early, creative
phase of design. Rather, they help the designer
to structure and document his or her design
ideas.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 10
Design Description


Graphical notations: Used to display component
relationships.
Informal text: Natural language description.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 11
Design Strategies

Functional design
–

The system is designed from a functional viewpoint. The system
state is centralized and shared between the functions operating
on that state.
Object-oriented design
–
The system is viewed as a collection of interacting objects.
The system state is decentralized and each object manages its
own state. Objects may be instances of an object class and
communicate by exchanging methods.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 12
Functional View of a Compiler
Source
program
Tokens
Scan
source
Syntax
tree
Tokens
Build
symbol
table
Symbols
Analyse
Symbols
Symbol
table
Object
code
Generate
code
Error
indicator
Output
errors
Error
messages
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 13
Object-oriented View of a Compiler
Scan
Source
program
Add
Token
stream
Symbol
table
Check
Syntax
tree
Get
Gr ammar
Print
Build
Err or
messages
Generate
Object
code
Abstract
code
Generate
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 14
Mixed-strategy Design


Although it is sometimes suggested that one
approach to design is superior, in practice, an
object-oriented and a functional-oriented
approach to design are complementary.
Good software engineers should select the
most appropriate approach for whatever
sub-system is being designed.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 15
Design Quality




Design quality is an elusive concept. Quality
depends on specific organizational priorities.
A “good” design may be the most efficient, the
cheapest, the most maintainable, the most
reliable, etc.
The attributes discussed here are concerned
with the maintainability of the design.
Quality characteristics are equally applicable to
function-oriented and object-oriented designs.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 16
Cohesion




A measure of how well a component “fits
together”.
A component should implement a single logical
entity or function.
Cohesion is a desirable design component
attribute as when a change has to be made, it
is localized in a single cohesive component.
Various levels of cohesion have been identified.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 17
Cohesion Levels

Coincidental cohesion (weak)
–

Logical association (weak)
–

Parts of a component are simply bundled together.
Components which perform similar functions are grouped.
Temporal cohesion (weak)
–
Components which are activated at the same time are grouped.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 18
Cohesion Levels

Communicational cohesion (medium)
–

Sequential cohesion (medium)
–

The output for one part of a component is the input to another
part.
Functional cohesion (strong)
–

All the elements of a component operate on the same input or
produce the same output.
Each part of a component is necessary for the execution of a
single function.
Object cohesion (strong)
–
Each operation provides functionality which allows object
attributes to be modified or inspected.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 19
Cohesion as a Design Attribute




Not well-defined. Often difficult to classify
cohesion.
Inheriting attributes from super-classes
weakens cohesion.
To understand a component, the super-classes
as well as the component class must be
examined.
Object class browsers assist with this process.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 20
Coupling




A measure of the strength of the inter-connections
between system components.
Loose coupling means component changes are
unlikely to affect other components.
Shared variables or control information
exchange lead to tight coupling.
Loose coupling can be achieved by state
decentralization (as in objects) and component
communication via parameters or message
passing.
28
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 21
Tight Coupling
Module A
Module B
Module C
Module D
Shared data
area
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 22
Loose Coupling
Module A
A’s data
Module B
B’s data
Module C
C’s data
Module D
D’s data
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 23
Coupling and Inheritance


Object-oriented systems are loosely
coupled because there is no shared state and
objects communicate using message passing.
However, an object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 24
Understandability

Related to several component characteristics
–
–
–
–

Can the component be understood on its own?
Are meaningful names used?
Is the design well-documented?
Are complex algorithms used?
Informally, high complexity means many
relationships between different parts of the
design.
32
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 25
Adaptability

A design is adaptable if:
–
–
–
–

Its components are loosely coupled.
It is well-documented and the documentation is up to date.
There is an obvious correspondence between design levels
(design visibility).
Each component is a self-contained entity (tightly cohesive).
To adapt a design, it must be possible to trace the
links between design components so that change
consequences can be analyzed.
33
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 26
Design Traceability
C
F
B
Object interaction
level
D
A
D
P
O
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
R
Object decomposition
level
Software Engineering, 5th edition. Chapters 10,11
Slide 27
Adaptability and Inheritance


Inheritance dramatically improves adaptability.
Components may be adapted without change
by deriving a sub-class and modifying that
derived class.
However, as the depth of the inheritance
hierarchy increases, it becomes increasingly
complex. It must be periodically reviewed and
restructured.
35
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 28
Architectural Design

Establishing the overall
structure of a software system
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 29
Architectural Parallels




Architects are the technical interface between the
customer and the contractor building the system.
A bad architectural design for a building cannot
be rescued by good construction; the same is true
for software.
There are specialist types of building and
software architects.
There are schools or styles of building and
software architecture.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 30
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 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 31
Architectural Models



Structure, control and modular decomposition
may be based on a particular model or
architectural style.
However, most systems are heterogeneous in that
different parts of the system are based on
different models and, in some cases, the system
may follow a composite model.
The architectural model used affects the
performance, robustness, distributability and
maintainability of the system.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 32
System Structuring



Concerned with decomposing the system into
interacting sub-systems.
The architectural design is normally expressed as
a block diagram presenting an overview of the
system structure.
More specific models showing how sub-systems
share data, are distributed and interface with each
other may also be developed.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 33
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 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 34
CASE Tool Set Architecture
Design
editor
Design
translator
Code
generator
Project
repository
Design
analyser
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Program
editor
Report
generator
Software Engineering, 5th edition. Chapters 10,11
Slide 35
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.
Data evolution is difficult and expensive.
No scope for specific management policies.
Difficult to distribute efficiently.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 36
Client-server Architecture




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.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 37
Film and Picture Library
Client 1
Client 2
Client 3
Client 4
Wide-bandwidth network
Catalogue
server
Video
server
Picture
server
Hypertext
server
Catalogue
Film clip
files
Digitiz ed
photographs
Hypertext
web
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 38
Client-server Characteristics

Advantages:
–
–
–

Distribution of data is straightforward.
Makes effective use of networked systems.
Easy to add new servers or upgrade existing servers.
Disadvantages:
–
–
–
No shared data model so sub-systems may use different data
organizations.
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 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 39
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 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 difficult to structure systems in this way.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 40
Version Management System
Version management
Object management
Database system
Operating
system
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 41
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.
Control policy is not embedded in the event and message
handler. Sub-systems decide on events of interest to them.
However, sub-systems don’t know if or when an event
will be handled.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 42
Selective Broadcasting
Sub-system
1
Sub-system
2
Sub-system
3
Sub-system
4
Event and message handler
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 43
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 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 44
Invoice Processing System
Customer
customer #
name
address
credit period
Payment
invoice #
date
amount
customer #
Receipt
Invoice
invoice #
date
amount
customer
invoice #
date
amount
customer #
Issue
Send reminder
Accept payment
Send receipt
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 45
Pipe and Filter 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 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 46
Invoice Processing System
Read issued
invoices
Invoices
Issue
receipts
Receipts
Find
payments
due
Issue
payment
reminder
Identify
payments
Reminders
Payments
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 47
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 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 48
Generic Models

Compiler model is a well-known example
although other models exist in more specialized
application domains.
–
–
–
–
–
–

Lexical analyzer
Symbol table
Syntax analyzer
Syntax tree
Semantic analyzer
Code generator
Generic compiler model may be organized
according to different architectural models.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 49
Compiler Model
Symbol
table
Lexical
analysis
Syntactic
analysis
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Semantic
analysis
Code
generation
Software Engineering, 5th edition. Chapters 10,11
Slide 50
Language Processing System
Lexical
analyser
Syntax
analyser
Semantic
analyser
Prettyprinter
Abstract
syntax tree
Grammar
definition
Optimizer
Editor
Symbol
table
Output
definition
Code
generator
Repository
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 51
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 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 52
OSI Reference Model
7
Application
Application
6
Presentation
Presentation
5
Session
Session
4
Transport
Transport
3
Network
Network
Network
2
Data link
Data link
Data link
1
Physical
Physical
Physical
Communica tions medium
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 53
Distributed Systems Architectures
Architectural design for software
that executes on more than one
processor
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 54
Distributed systems



Virtually all large computer-based systems are
now distributed systems
Information processing is distributed over several
computers rather than confined to a single
machine
Distributed software engineering is now very
important
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 55
System types

Personal systems that are not distributed and that
are designed to run on a personal computer or
workstation.

Embedded systems that run on a single processor
or on an integrated group of processors.

Distributed systems where the system software
runs on a loosely integrated group of cooperating
processors linked by a network.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 56
Distributed system characteristics






Resource sharing
Openness
Concurrency
Scalability
Fault tolerance
Transparency
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 57
Distributed system disadvantages




Complexity
Security
Manageability
Unpredictability
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 58
Design issue
Resource
identification
Descri ption
The resources in a dist ributed system are spread across different
computers and a naming scheme has to be devised so that users can
discover and refer to the resources that they need. An example of
such a naming scheme is t he URL (Uniform Resource Locator) that
is used to identify WWW pages. If a meaningful and universally
understood ident ificat ion scheme is not used then many of these
resources will be inaccessible to system users.
Communications The universal availability of t he Internet and the efficient
implementat ion of Internet TCP /IP communicat ion protocols means
that, for most distributed systems, these are the most effect ive way
for the comput ers to communicate. However, where there are
specific requirements for performance, reliability etc. alternat ive
approaches to communicat ions may be used.
Quality of service The quality of service offered by a system reflects its performance,
availability and reliability. It is affected by a number of factors such
as the allocat ion of processes to processes in t he system, the
distribut ion of resources across the syst em, the network and the
system hardware and the adaptability of the system.
Software
The software architecture describes how the applicat ion
architectures
funct ionalit y is distributed over a number of logical component s and
how these components are distributed across processors. Choosing
the right archit ecture for an applicat ion is essent ial to achieve the
desired quality of service.
Issues in distributed system design
Distributed systems archiectures

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
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 60
Middleware



Software that manages and supports the different
components of a distributed system. In essence, it
sits in the middle of the system
Middleware is usually off-the-shelf rather than
specially written software
Examples
–
–
–
Transaction processing monitors
Data converters
Communication controllers
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 61
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 preordered or may be under the control of a
despatcher
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 62
A multiprocessor traffic control system
Sensor
processor
Sensor
control
process
Traffic flow
processor
Display
process
Traffic light control
processor
Light
control
process
Traffic lights
Traffic flow sensors
and cameras
Operator consoles
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 63
Client-server architectures




The application is modelled as a set of services
that are provided by servers and a set of clients
that use these services
Clients know of servers but servers need not
know of clients
Clients and servers are logical processes
The mapping of processors to processes is not
necessarily 1 : 1
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 64
A client-server system
c3
c2
c4
c12
c11
c1
s1
Server process
s4
c10
c5
s2
c6
c7
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Client process
s3
c9
c8
Software Engineering, 5th edition. Chapters 10,11
Slide 65
Computers in a C/S network
c1
CC1
c2
CC2
CC3
Network
s1, s2
c3, c4
s3, s4
Server
computer
SC1
SC2
c5, c6, c7
CC4
c8, c9
CC5
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
c10, c11, c12
Client
computer
CC6
Software Engineering, 5th edition. Chapters 10,11
Slide 66
Layered application architecture

Presentation layer
–

Application processing layer
–

Concerned with presenting the results of a computation to
system users and with collecting user inputs
Concerned with providing application specific functionality e.g.,
in a banking system, banking functions such as open account,
close account, etc.
Data management layer
–
Concerned with managing the system databases
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 67
Application layers
Presentation layer
Application processing
layer
Data management
layer
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 68
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.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 69
Thin and fat clients
Presentation
Thin-client
model
Server
Data management
Application
processing
Client
Presentation
Application processing
Fat-client
model
Client
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Server
Data
management
Software Engineering, 5th edition. Chapters 10,11
Slide 70
Thin client model

Used when legacy systems are migrated to client
server architectures.
–

The legacy system acts as a server in its own right with a
graphical interface implemented on a client
A major disadvantage is that it places a heavy
processing load on both the server and the
network
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 71
Fat client model



More processing is delegated to the client as the
application processing is locally executed
Most suitable for new C/S systems where the
capabilities of the client system are known in
advance
More complex than a thin client model especially
for management. New versions of the application
have to be installed on all clients
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 72
A client-server ATM system
ATM
ATM
Account server
TeleCustomer
processing account
monitor
database
ATM
ATM
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 73
Three-tier architectures



In a three-tier architecture, each of the
application architecture layers may execute on a
separate processor
Allows for better performance than a thin-client
approach and is simpler to manage than a fatclient approach
A more scalable architecture - as demands
increase, extra servers can be added
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 74
A 3-tier C/S architecture
Presentation
Client
Server
Server
Application
processing
Data
management
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 75
An internet banking system
Client
HTTP interaction
Datab ase server
Web server
Client
Account service
provision
SQL query
SQL
Customer
account
database
Client
Client
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 76
Use of C/S architectures
Arch i te cture
Two-t ier C/S
architecture with
thin client s
Two-t ier C/S
architecture with
fat client s
Three-t ier or
mult i-t ier C/S
architecture
Appl ication s
Legacy system applicat ions where separat ing applicat ion
processing and data management is impract ical
Computat ionally-intensive applicat ions such as compilers with
lit tle or no data management
Data-intensive applicat ions (browsing and querying) with lit t le
or no applicat ion processing.
Applicat ions where applicat ion processing is provided by
COT S (e.g. Microsoft Excel) on the client
Applicat ions where computat ionally-intensive processing of
data (e.g. data visualisat ion) is required.
Applicat ions with relat ively stable end-user funct ionality used
in an environment with well-established system management
Large scale applicat ions wit h hundreds or thousands of clients
Applicat ions where both the data and the applicat ion are
volat ile.
Applicat ions where data from mult iple sources are integrated
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 77
Distributed object architectures




There is no distinction in a distributed object architectures
between clients and servers
Each distributable entity is an object that provides
services to other objects and receives services from other
objects
Object communication is through a middleware system
called an object request broker (software bus)
However, more complex to design than C/S systems
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 78
Distributed object architecture
o1
o2
o3
o4
S (o1)
S (o2)
S (o3)
S (o4)
Software bus
o5
o6
S (o5)
S (o6)
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 79
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
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 80
Uses of distributed object architecture


As a logical model that allows you to structure
and organise the system. In this case, you think
about how to provide application functionality
solely in terms of services and combinations of
services
As a flexible approach to the implementation of
client-server systems. The logical model of the
system is a client-server model but both clients
and servers are realised as distributed objects
communicating through a software bus
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 81
A data mining system
Database 1
Integrator 1
Database 2
Report gen.
Visualiser
Integrator 2
Database 3
Display
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 82
Data mining system



The logical model of the system is not one of
service provision where there are distinguished
data management services
It allows the number of databases that are
accessed to be increased without disrupting the
system
It allows new types of relationship to be mined by
adding new integrator objects
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 83
CORBA




CORBA is an international standard for an Object
Request Broker - middleware to manage
communications between distributed objects
Several implementations of CORBA are available
DCOM is an alternative approach by Microsoft to
object request brokers
CORBA has been defined by the Object
Management Group
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 84
Application structure




Application objects
Standard objects, defined by the OMG, for a
specific domain e.g. insurance
Fundamental CORBA services such as directories
and security management
Horizontal (i.e. cutting across applications)
facilities such as user interface facilities
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 85
CORBA application structure
Application
objects
Domain
facilities
Horizontal
CORBA facilities
Object request broker
CORBA services
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 86
CORBA standards

An object model for application objects
–



A CORBA object is an encapsulation of state with a welldefined, language-neutral interface defined in an IDL (interface
definition language)
An object request broker that manages requests
for object services
A set of general object services of use to many
distributed applications
A set of common components built on top of
these services
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 87
CORBA objects




CORBA objects are comparable, in principle, to
objects in C++ and Java
They MUST have a separate interface definition
that is expressed using a common language (IDL)
similar to C++
There is a mapping from this IDL to
programming languages (C++, Java, etc.)
Therefore, objects written in different languages
can communicate with each other
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 88
Object request broker (ORB)



The ORB handles object communications. It
knows of all objects in the system and their
interfaces
Using an ORB, the calling object binds an IDL
stub that defines the interface of the called object
Calling this stub results in calls to the ORB which
then calls the required object through a published
IDL skeleton that links the interface to the service
implementation
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 89
ORB-based object communications
o1
o2
S (o1)
S (o2)
IDL
stub
IDL
skeleton
Object Request Broker
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 90
Inter-ORB communications




ORBs are not usually separate programs but are a set of
objects in a library that are linked with an application
when it is developed
ORBs handle communications between objects executing
on the same machine
Several ORBS may be available and each computer in a
distributed system will have its own ORB
Inter-ORB communications are used for distributed object
calls
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 91
Inter-ORB communications
o1
o2
o3
o4
S (o1)
S (o2)
S (o3)
S (o4)
IDL
IDL
IDL
IDL
Object Request Broker
Object Request Broker
Network
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 92
CORBA services

Naming and trading services
–

Notification services
–

These allow objects to discover and refer to other objects on the
network
These allow objects to notify other objects that an event has
occurred
Transaction services
–
These support atomic transactions and rollback on failure
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 93
Example of a Simple
CORBA Application
Written in Java
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 94
Starting Clients, Servers, and
Name Servers
# Compile the IDL into a Java stub
idltojava -fno-cpp Hello.idl
# Compile the Java program and stub
javac *.java HelloApp/*.java
# Initiate the name server on king.mcs.drexel.edu on port 1050.
tnameserv -ORBInitialPort 1050 -ORBInitialHost king.mcs.drexel.edu
# Initiate the hello server (relies on the name server being on king's 1050 port.)
java HelloServer -ORBInitialPort 1050 -ORBInitialHost king.mcs.drexel.edu
# Initiate the hello client (relies on the name server being on king's 1050 port.)
java HelloClient -ORBInitialPort 1050 -ORBInitialHost king.mcs.drexel.edu
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 95
“Hello World” IDL Specification
module HelloApp
{
interface Hello
{
string sayHello();
};
};
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 96
“Hello World” Client
Java Program
import
import
import
import
HelloApp.*;
org.omg.CosNaming.*; // package used for name service
org.omg.CosNaming.NamingContextPackage.*;
org.omg.CORBA.*;
public class HelloClient {
public static void main(String args[])
{
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null); // args contain info. about
// name server port/host
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// casting ...
// continued on next page ...
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 97
“Hello World” Client
Java Program (Cont’d)
// resolve the Object Reference in Naming
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
Hello HelloRef = HelloHelper.narrow(ncRef.resolve(path));
// call the Hello server object and print results
String Hello = HelloRef.sayHello();
System.out.println(Hello);
}
}
} catch (Exception e) {
System.out.println("ERROR : " + e) ;
e.printStackTrace(System.out);
}
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 98
“Hello World” Server
Java Program
import
import
import
import
HelloApp.*;
org.omg.CosNaming.*;
org.omg.CosNaming.NamingContextPackage.*;
org.omg.CORBA.*;
class HelloServant extends _HelloImplBase
{
public String sayHello()
{
return "\nHello world !!\n";
}
}
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 99
“Hello World” Server
Java Program (Cont’d)
public class HelloServer {
public static void main(String args[])
{
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// create servant and register it with the ORB
HelloServant HelloRef = new HelloServant();
orb.connect(HelloRef); // HelloRef will be published ...
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// continued on next slide ...
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 100
“Hello World” Server
Java Program (Cont’d)
// bind the Object Reference in Naming
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
ncRef.rebind(path, HelloRef); // clobber old binding if any ...
// wait for invocations from clients
java.lang.Object sync = new java.lang.Object();
synchronized (sync) { // aquires a mutex lock on thread
sync.wait();
// server sleeps ...
}
}
}
} catch (Exception e) {
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)
Software Engineering, 5th edition. Chapters 10,11
Slide 101