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

Requirements
specification
Design acti
vities
Architectur
al
design

Abstract
specificatio
n

Interface
design

Component
design

Data
structur
e
design

Algorithm
design

System
architectur
e

Software
specification

Interface
specifica
tion

Component
specification

Data
structur
e
specification

Algorithm
specifica
tion

Design 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

Source
program

Scan

Add

Token
stream

Symbol
table

Check
Syntax
tree

Get

Gr ammar
Build

Print

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
As data

Module B
Bs data

Module C
Cs data

Module D
Ds 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
P

Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)

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 dont 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 messa ge 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

Presentation

Presentation

Session

Session

Transport

Transport

Network

Network

Network

Data link

Data link

Data link

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

Designissue
Resource
identification

Communications

Qualityofservice

Software
architectures

Description
Theresourcesinadistributedsystemarespreadacrossdifferent
computersandanamingschemehastobedevisedsothatuserscan
discoverandrefertotheresourcesthattheyneed.Anexampleof
suchanamingschemeistheURL(UniformResourceLocator)that
isusedtoidentifyWWWpages.Ifameaningfulanduniversally
understoodidentificationschemeisnotusedthenmanyofthese
resourceswillbeinaccessibletosystemusers.
TheuniversalavailabilityoftheInternetandtheefficient
implementationofInternetTCP/IPcommunicationprotocolsmeans
that,formostdistributedsystems,thesearethemosteffectiveway
forthecomputerstocommunicate.However,wherethereare
specificrequirementsforperformance,reliabilityetc.alternative
approachestocommunicationsmaybeused.
Thequalityofserviceofferedbyasystemreflectsitsperformance,
availabilityandreliability.Itisaffectedbyanumberoffactorssuch
astheallocationofprocessestoprocessesinthesystem,the
distributionofresourcesacrossthesystem,thenetworkandthe
systemhardwareandtheadaptabilityofthesystem.
Thesoftwarearchitecturedescribeshowtheapplication
functionalityisdistributedoveranumberoflogicalcomponentsand
howthesecomponentsaredistributedacrossprocessors.Choosing
therightarchitectureforanapplicationisessentialtoachievethe
desiredqualityofservice.

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

Trafficflowsensors
andcameras

Trafficflow
processor

Display
process

Trafficlightcontrol
processor
Light
control
process

Trafficlights
Operatorconsoles

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

Serverprocess

s4
c10

c5
s2
c6

c7

Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999)

Clientprocess
s3

c9
c8

Software Engineering, 5th edition. Chapters 10,11

Slide 65

Computers in a C/S network

CC1

c1

CC2

c2

CC3

Network

s1,s2

s3,s4

Server
computer

SC1

SC2

c5,c6,c7

c3,c4

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
Presentationlayer

Applicationprocessing
layer

Datamanagement
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
Thinclient
model

Server
Datamanagement
Application
processing

Client

Presentation
Applicationprocessing
Fatclient
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

Accountserver
Tele
Customer
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

HTTPinteraction
Webserver

Client

Accountservice
provision

SQLquery

Datab aseserver
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

Architecture
TwotierC/S
architecturewith
thinclients

TwotierC/S
architecturewith
fatclients

Threetieror
multitierC/S
architecture

Applications
Legacysystemapplicationswhereseparatingapplication
processinganddatamanagementisimpractical
Computationallyintensiveapplicationssuchascompilerswith
littleornodatamanagement
Dataintensiveapplications(browsingandquerying)withlittle
ornoapplicationprocessing.
Applicationswhereapplicationprocessingisprovidedby
COTS(e.g.MicrosoftExcel)ontheclient
Applicationswherecomputationallyintensiveprocessingof
data(e.g.datavisualisation)isrequired.
Applicationswithrelativelystableenduserfunctionalityused
inanenvironmentwithwellestablishedsystemmanagement
Largescaleapplicationswithhundredsorthousandsofclients
Applicationswhereboththedataandtheapplicationare
volatile.
Applicationswheredatafrommultiplesourcesareintegrated

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)

Softwarebus

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

Database1

Integrator1

Database2

Reportgen.

Visualiser
Integrator2

Database3
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
CORBAfacilities

Objectrequestbroker

CORBAservices

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

ObjectRequestBroker

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

ObjectRequestBroker

ObjectRequestBroker
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 HelloApp.*;

import org.omg.CosNaming.*; // package used for name service

import org.omg.CosNaming.NamingContextPackage.*;
import 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
(Contd)
// 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 HelloApp.*;

import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import 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
(Contd)
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
(Contd)
// 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