System Design

Based on Chapter 13 of Bennett, McRobb

and Farmer:
Object Oriented Systems Analysis and
Design Using UML, (2nd Edition), McGraw
Hill, 2002.
03/12/2001 © Bennett, McRobb and Farmer 2002 1
 In This Lecture You Will
Learn:
 The major concerns of system design
 The main aspects of system
architecture, in particular what is
meant by subdividing a system into
layers and partitions
 How to apply the MVC architecture
 Which architectures are most
suitable for distributed systems
 How design standards are specified
© Bennett, McRobb and Farmer 2002 2
 System Architecture
 A major part of system design is
defining the system architecture
– Containing potentially human, software
and hardware elements and how these
elements are structured and interact
 The software elements of the
system embody the software
architecture
© Bennett, McRobb and Farmer 2002 3
 System Design
 During system design the following
activities are undertaken:
– Sub-systems and major components are
identified
– Any inherent concurrency is identified
– Sub-systems are allocated to processors
– A data management strategy is selected
– A strategy and standards for human–
computer interaction are chosen

© Bennett, McRobb and Farmer 2002 4

 System Design
 Activities during system design:
– Code development standards are
specified
– The control aspects of the application are
planned
– Test plans are produced
– Priorities are set for design trade-offs
– Implementation requirements are
identified (for example, data conversion)
© Bennett, McRobb and Farmer 2002 5
 Software Architecture
 ‘A software architecture is a description of the
subsystems and components of a software
system and the relationships between them.
Sub-systems and components are typically
specified in different views to show the
relevant functional and non-functional
properties of a software system. The software
architecture of a system is an artefact. It is
the result of the software design activity.’

Buschmann et al. (1996)

© Bennett, McRobb and Farmer 2002 6

 Sub-systems
 A sub-system typically groups
together elements of the system
that share some common properties
 An object-oriented sub-system
encapsulates a coherent set of
responsibilities in order to ensure
that it has integrity and can be
maintained
© Bennett, McRobb and Farmer 2002 7
 Sub-systems
 The sub-division of an information
system into sub-systems has the
following advantages
– It produces smaller units of development
– It helps to maximize reuse at the component
level
– It helps the developers to cope with
complexity
– It improves maintainability
– It aids portability
© Bennett, McRobb and Farmer 2002 8
 Sub-systems
 Each sub-system provides services
for other sub-systems, and there
are two different styles of
communication that make this
possible
 These are known as client–server
and peer-to-peer communication

© Bennett, McRobb and Farmer 2002 9

Styles of communication
between sub-systems
«client» «peer»

Sub-system A Sub-system C

«server» «peer»

Sub-system B Sub-system D

The server sub-system does Each peer sub-system

not depend on the client sub- depends on the other and
system and is not affected by each is affected by changes
changes to the client’s interface. in the other’s interface.

© Bennett, McRobb and Farmer 2002 10

 Client–server
communication
 Client–server communication
requires the client to know the
interface of the server sub-system,
but the communication is only in
one direction
 The client sub-system requests
services from the server sub-
system and not vice versa
© Bennett, McRobb and Farmer 2002 11
Peer-to-peer communication
 Peer-to-peer communication
requires each sub-system to know
the interface of the other, thus
coupling them more tightly
 The communication is two way
since either peer sub-system may
request services from the other

© Bennett, McRobb and Farmer 2002 12

Layering and Partitioning
 Two general approaches to the division
of a software system into sub-systems
– Layering—so called because the different
sub-systems usually represent different
levels of abstraction
– Partitioning, which usually means that each
sub-system focuses on a different aspect of
the functionality of the system as a whole
 Both approaches are often used
together on one system

© Bennett, McRobb and Farmer 2002 13

 Schematic of a
Layered Architecture
Layer N Layer N
Layer N -1 Layer N -1

Layer 2 Layer 2
Layer 1 Layer 1

Closed architecture— Open architecture—

messages may only be messages can be sent
sent to the adjacent to any lower layer.
lower layer.

© Bennett, McRobb and Farmer 2002 14

 Layered Architecture
 A closed architecture minimizes
dependencies between the layers and
reduces the impact of a change to the
interface of any one layer
 An open layered architecture produces
more compact code, the services of all
lower level layers can be accessed directly
by any layer above them without the need
for extra program code to pass messages
through each intervening layer, but this
breaks the encapsulation of the layers
© Bennett, McRobb and Farmer 2002 15
OSI Layer 7: Application
Provides miscellaneous protocols for
7 Layer common activities.
Layer 6: Presentation
Model Structures information and attaches
semantics.
(Adapted from Buschmann et al., 1996) Layer 5: Session
Provides dialogue control and
synchronization facilities.
Layer 4: Transport
Breaks messages into packets and
ensures delivery.
Layer 3: Network
Selects a route from sender to receiver.

Layer 2: Data Link

Detects and corrects errors in bit
sequences.
Layer 1: Physical
Transmits bits: sets transmission rate
(baud), bit-code, connection, etc.

© Bennett, McRobb and Farmer 2002 16

 Applying a Layered
Architecture
 Issues that need to be addressed
include:
– maintaining the stability of the interfaces of
each layer
– the construction of other systems using
some of the lower layers
– variations in the appropriate level of
granularity for sub-systems
– the further sub-division of complex layers
– performance reductions due to a closed
layered architecture (Buschmann et al., 1996)

© Bennett, McRobb and Farmer 2002 17

Simple Layered
Architecture.

Application

Data formatting

Data management library classes

© Bennett, McRobb and Farmer 2002 18

 Developing a Layered
Architecture
1. Define the criteria by which the
application will be grouped into layers.
A commonly used criterion is level of
abstraction from the hardware.
2. Determine the number of layers.
3. Name the layers and assign
functionality to them.
4. Specify the services for each layer.
5. Refine the layering by iterating
through steps 1 to 4.
© Bennett, McRobb and Farmer 2002 19
 Developing a Layered
Architecture
6. Specify interfaces for each layer.
7. Specify the structure of each layer. This
may involve partitioning within the layer.
8. Specify the communication between
adjacent layers (this assumes that a
closed layer architecture is intended).
9. Reduce the coupling between adjacent
layers. This effectively means that each
layer should be strongly encapsulated.
(Adapted from Buschmann et al., 1996)

© Bennett, McRobb and Farmer 2002 20

 Three & Four Layer
Architectures.

Presentation
Presentation
Application logic
Business logic
Domain
Database
Database

Business logic
layer
can be split into
two layers
© Bennett, McRobb and Farmer 2002 21
 Partitioned Sub-systems
Loosely coupled sub-systems, each
delivering a single service or coherent
group of services

Ad vert HCI Campaign Costs

Presentation layer Sub-system HCI Sub-system
Ad vert Campaign Costs Four layer
Application layer Sub-system Sub-system architecture applied
Campaign Domain A single domain to part of the Agate
layer supports campaign
Campaign Database two application management system
sub-systems.

© Bennett, McRobb and Farmer 2002 22

Problems with some
Architectures
Each sub-system
contains some core Changes to data in one sub-
functionality system need to be
propogated to the others

Campaign Advert Campaign

Forecastin Development Management
g

Campaign and Advert Database Access

Multiple interfaces for the same core functionality.

© Bennett, McRobb and Farmer 2002 23

 Difficulties
 We repeat below some of the difficulties that
need to be resolved for this type of application
– The same information should be capable of
presentation in different formats in different
windows
– Changes made within one view should be reflected
immediately in the other views
– Changes in the user interface should be easy to
make
– Core functionality should be independent of the
interface to enable multiple interface styles to co-
exist

© Bennett, McRobb and Farmer 2002 24

 Model-View-Controller
The propagation mechanism

«propagate» «propagate»
View A View B

«access» «access»
«access»
«access» Model

«access» «access»

Controller A Controller B

© Bennett, McRobb and Farmer 2002 25

(Adapted from Hopkins and Horan, 1995)
 Model-View-Controller
 Model—provides the central functionality of
the application and is aware of each of its
dependent view and controller components.
 View—corresponds to a particular style and
format of presentation of information to the
user. The view retrieves data from the
model and updates its presentations when
data has been changed in one of the other
views. The view creates its associated
controller.
© Bennett, McRobb and Farmer 2002 26
 Model-View-Controller
 Controller—accepts user input in the form
of events that trigger the execution of
operations within the model. These may
cause changes to the information and in
turn trigger updates in all the views
ensuring that they are all up to date.
 Propagation Mechanism—enables the
model to inform each view that the model
data has changed and as a result the view
must update itself. It is also often called
the dependency mechanism.
© Bennett, McRobb and Farmer 2002 27
MVC applied to Agate
«component»
AdvertView
*
depends on viewData

Navigability arrows show the initialize()

1
directions in which messages displayAdvert()
will be sent.. update()
«component»
CampaignModel
1
coreData
setOfObservers [0..*]
attach(Observer) updates
1
detach(Observer)
notify()
getAdvertData() «component»
modifyAdvert() AdvertController
1
*
updates initialize()
changeAdvert()
update()

© Bennett, McRobb and Farmer 2002 28

MVC Component Interaction
:AdvertController :CampaignModel :AdvertView

changeAdvert()

modifyAdvert()
notify()

update()
displayAdvert()

getAdvertData()

update()
getAdvertData()

© Bennett, McRobb and Farmer 2002 29

Schematic of Simplified
Broker Architecture

Server 1
Client A

Broker Server 2

Client B Server 3

© Bennett, McRobb and Farmer 2002 30

 :ClientSide :ServerSide
:Client :Broker :Server
Proxy Proxy

callServer()

sendRequest()
packData()

sendRequest() findServer()

requestService() unPackData()

service()

packData()

sendResponse()

sendResponse()

unPackData()
Possible
process
boundaries

© Bennett, McRobb and Farmer 2002 31

(Adapted from Buschmann et al., 1996)
 Schematic of broker
architecture using bridge
components

Sub-system Sub-system
A C

Broker Bridge Bridge Broker

Sub-system
Sub-system
B
Possible process boundary D

© Bennett, McRobb and Farmer 2002 32

Concurrent activity in an
interaction diagram
:ClassA :ClassB :ClassC :ClassD

Asynchronous
messages

Simultaneous
execution
Do not execute
simultaneously

© Bennett, McRobb and Farmer 2002 33

 Scheduler Handling
Concurrency
This thread of Sub-system 2
Sub-system 1 execution generates a
system output.

Thread of control «invoke» «invokes»

invoked by
scheduler and
produces no output.

«interrupt» Scheduler «interrupt»

Interrupts generated in scheduler.

I/O Sub-system I/O Sub-system
A B

© Bennett, McRobb and Farmer 2002 34

 Processor Allocation
 Allocation of a system to multiple processors
– Application should be divided into sub-systems
– Estimate processing requirements for sub-systems
– Determine access criteria and location
requirements
– Identify concurrency requirements
– Each sub-system should be allocated to an
operating platform
– Communication requirements between sub-
systems should be determined
– The communications infrastructure should be
specified
© Bennett, McRobb and Farmer 2002 35
Data Management Issues
 DBMS provide
– Different views of the data by different users
– Control of multi-user access
– Distribution of the data over different platforms
– Security
– Enforcement of integrity constraints
– Access to data by various applications
– Data recovery
– Portability across platforms
– Data access via query languages
– Query optimization

© Bennett, McRobb and Farmer 2002 36

Development Standards
 HCI guidelines
 Input/output device guidelines
 Construction guidelines

© Bennett, McRobb and Farmer 2002 37

 I/O Device Hierarchy
I/O Hierarchy providing consistency for device handling

IODevice

handleEvent()

Sensor Actuator

handleEvent() handleEvent()

© Bennett, McRobb and Farmer 2002 38

Prioritizing Design Trade-offs
 Designer is often faced with design
objectives that are mutually
incompatible
 It is helpful if guidelines are
prepared for prioritizing design
objectives
 If design choice is unclear users
should be consulted
© Bennett, McRobb and Farmer 2002 39
Design for Implementation
 Initialization and implementation
issues should be considered
 There may be data transfer or data
conversion requirements or both

© Bennett, McRobb and Farmer 2002 40

 Summary
In this lecture you have learned about:
 The major concerns of system design
 The main aspects of system
architecture, in particular what is meant
by subdividing a system into layers and
partitions
 How to apply the MVC architecture
 Which architectures are most suitable
for distributed systems
 How design standards are specified
© Bennett, McRobb and Farmer 2002 41
 References
 Buschmann et al. (1996).
 Jacobson et al. (1997)
(For full bibliographic details, see
Bennett, McRobb and Farmer)

© Bennett, McRobb and Farmer 2002 42