L12 System Architecture

8/9/2019 L12 System Architecture

1/55

System ArchitectureSystem Architecture

Background and InfluencesBackground and Influences

1


2/55

Learning Objectives

What we mean by system architecture in a

development project

Architecture views

Why we model the architecture of a system

What factors influence the architecture of a

new system

2


3/55

Architecture

Architects are trained to take your brief and can seethe big picture they look beyond your immediaterequirements to design flexible buildings that will

adapt with the changing needs of your business.

Architects solve problems creatively when they areinvolved at the earliest planning stage, they gainmore opportunities to understand your business,

develop creative solutions, and propose ways toreduce costs.

RIBA (2005)

3


4/55

System Architecture

System architects:

act on behalf of the client;

address the big picture; ensure that the required qualities of the system

are accounted for in the design;

solve problems;

ensure the required features are provided at the

right cost.

4


5/55

System Architecture

Key Definitions

System is a set of components that accomplishes aspecific function or set of functions.

Architecture is the fundamental organization of a

system embodied in its components, theirrelationships to each other, and to the environment,and the principles guiding its design and evolution.

Architectural Description is a set of products that

document the architecture.

5


6/55

System Architecture

Key Definitions

Architectural View is a representation of a particularsystem or part of a system from a particularperspective.

Architectural Viewpointis a template that describeshow to create and use an architectural view. Aviewpoint includes a name, stakeholders, concernsaddressed by the viewpoint, and the modelling andanalytic conventions.

(Garland & Anthony, 2003 & IEEE, 2000)

6


7/55

System Architecture

Architecture Types

Soni et al.

7


8/55

System Architecture

Architecture Views

Kruchten - RUPs 4 = 1 views

Bennett, McRobb and Farmer 2005 8


9/55

System Architecture

ADL

Architecture Description Language

UML 2.0 adds or changes features to support

modelling architecture

Package diagrams

Component diagrams

Composite structure diagrams

Deployment diagrams

9


10/55

System Architecture

Why model it?

Architects use models to reason about thesystem and its ability to deliver the requiredquality attributes (reliability, performance,

security etc.). Particular views help to reason about

particular quality attributes.

10


11/55

System Architecture

Why model it?

11


12/55

System Architecture

Influences

Existing Systems Standard architectures

Heritage systems May be wrapped using adapters

Services Wrapping systems with adapters

Reverse-engineering and MDA Generate platform-specific models (PSMs) from

platform-independent models (PIMs)

Reverse-engineer existing system logic to PIMs

12


13/55

System Architecture

Influences

Existing systems

Enterprise architectures

Technical reference architectures

13


14/55

System Architecture

Influences

Enterprise Architectures

Pressure in the United States

Clinger-Cohen Act 1996

Sarbanes-Oxley Act 2002

Frameworks

Federal Enterprise Architecture Framework Standards and Architectures for eGovernment

Applications

Zachman Framework

14


15/55

System Architecture

Influences

Technical Reference Architectures

Standards for technologies to apply

Guidance on how to apply them

The Open Group Architecture Framework(TOGAF)

Architecture Development Method

Enterprise Continuum

Resources

15


16/55

System Architecture

Architectural Styles

Architectural styles apply to physicalarchitecture and to software architecture

Bass et al identify five main types: Independent components

Data flow

Data centred Virtual machine

Call and return

16


17/55

Summary

In this lecture you have learned about:

What we mean by system architecture in a

development project

Architecture views

Why we model the architecture of a system

What factors influence the architecture of a new

system

17


18/55

SoftwareSoftware ArchitectureArchitecture

SCB2


19/55

Slide 18

SCB2 Include MVC in here.Copy from Chapter 17 if necessary.Simon Bennett, 7/29/2005


20/55

19

Learning Objectives

The main aspects of software 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


21/55

20

Software Architecture

A software architecture is a description of the subsystems

and components of a software system and the relationships

between them. Subsystems 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)


22/55

21

Architectural Aspects

of Software Design

Software architects undertake the followingactivities:

Subsystems and major components are identified

Any inherent concurrency is identified

Subsystems are allocated to processors

A data management strategy is selected

A strategy and standards for humancomputerinteraction are chosen


23/55

22

Subsystems

A subsystem typically groups together

elements of the system that share some

common properties

An object-oriented subsystem encapsulates a

coherent set of responsibilities in order to

ensure that it has integrity and can be

maintained


24/55

23

Subsystems

The subdivision of an information system into

subsystems 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


25/55

24

Subsystems

Each subsystem provides services for other

subsystems, and there are two different styles

of communication that make this possible

These are known as clientserverandpeer-to-

peercommunication


26/55

25

Styles of communication between

subsystems


27/55

26

Clientserver communication

Clientserver communication requires the

client to know the interface of the server

subsystem, but the communication is only in

one direction

The client subsystem requests services from

the server subsystem and not vice versa


28/55

27

Peer-to-peer communication

Peer-to-peer communication requires each

subsystem to know the interface of the other,

thus coupling them more tightly

The communication is two way since either

peer subsystem may request services from the

other


29/55

28

Layering and Partitioning

Two general approaches to the division of a softwaresystem into subsystems

Layeringso called because the different subsystemsusually represent different levels of abstraction

Partitioning, which usually means that each subsystemfocuses on a different aspect of the functionality of thesystem as a whole

Both approaches are often used together on one

system


30/55

29

Schematic of a

Layered Architecture

Closed architecturemessages may only be

sent to the adjacent

lower layer.

Open architecturemessages can be sent

to any lower layer.

Layer 1

Layer 2

Layer N -1

Layer N

Layer 1

Layer 2

Layer N -1

Layer N


31/55

30

Layered Architecture

A closed architecture minimizes dependenciesbetween the layers and reduces the impact of achange to the interface of any one layer

An open layered architecture produces morecompact code, the services of all lower level layerscan be accessed directly by any layer above themwithout the need for extra program code to passmessages through each intervening layer, but thisbreaks the encapsulation of the layers


32/55

31

OSI

7 Layer

Model

Layer 7: Application

Provides miscellaneous protocols for

common activities.

Layer 6: Presentation

Structures information and attachessemantics.

Layer 5: Session

Provides dialogue control and

synchronization facilities.

Layer 4: Transport

Breaks messages into packets andensures 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.

(Adapted from Buschmann et al., 1996)(Adapted from Buschmann et al., 1996)


33/55

32

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 lowerlayers

variations in the appropriate level of granularity forsubsystems

the further sub-division of complex layers

performance reductions due to a closed layered

architecture

(Buschmann et al., 1996)


34/55

33

Simple Layered Architecture.

Application

Data formatting

Data management


35/55

34

Developing a Layered Architecture

1. Define the criteria by which the application will begrouped into layers. A commonly used criterion islevel 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.


36/55

35

Developing a Layered Architecture

6. Specify interfaces for each layer.

7. Specify the structure of each layer. This mayinvolve partitioning within the layer.

8. Specify the communication between adjacentlayers (this assumes that a closed layer architectureis intended).

9. Reduce the coupling between adjacent layers. Thiseffectively means that each layer should be

strongly encapsulated.

(Adapted from Buschmann et al., 1996)


37/55

36

Three & Four Layer Architectures.

Business logic layercan be split into two

layers

Presentation

Business logic

Database

Presentation

Application logic

Domain

Database


38/55

37

Partitioned Subsystems

Four layer

architecture applied

to part of the Agatecampaign

management system

Campaign Costs

HCI Subsystem

Campaign Costs

Subsystem

Campaign Domain

Campaign Database

Advert

HCI Subsystem

Advert

Subsystem

A single domain

layer supports

two applicationsubsystems

Presentation

layer

Application

layer

Loosely coupled subsystems, each

delivering a single service or coherentgroup of services


39/55

38

Problems with some Architectures

Multiple interfaces for the same core functionality.Multiple interfaces for the same core functionality.

Campaign

Management

Campaign and AdvertDatabase Access

Advert

Development

Each subsystem

contains some

core functionality

Campaign

Forecasting

Changes to data in one

subsystem need to be

propagated to the others


40/55

39

Difficulties

We repeat below some of the difficulties thatneed 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


41/55

40

Model-View-Controller

The propagation mechanism

accessaccess

ViewA

ControllerA Controller B

View B

Model

access

access

access

access

propagatepropagate

(Adapted from Hopkins and Horan, 1995)


42/55

41


Modelprovides the central functionality of the

application and is aware of each of its dependent

view and controller components.

Viewcorresponds to a particular style and formatof 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 associatedcontroller.


43/55

Bennett, McRobb andFarmer 2005 42


Controlleraccepts user input in the form ofevents that trigger the execution of operationswithin the model. These may cause changes to

the information and in turn trigger updates in allthe views ensuring that they are all up to date.

Propagation Mechanismenables the model toinform each view that the model data has

changed and as a result the view must updateitself. It is also often called the dependencymechanism.


44/55

43

MVC applied to Agate

component

component

AdvertController

initialize()changeAdvert()

update()

componentCampaignModel

coreDatasetOfObservers [0..*]attach(Observer)detach(Observer)notify()getAdvertData()

modifyAdvert()

AdvertView

viewData

initialize()

displayAdvert()

update()

depends on *

1

1

updates*

updates

1

1

Navigability arrows show the

directions in which messages

will be sent..


45/55

44

MVC Component Interaction

displayAdvert

:AdvertView:CampaignModel

changeAdvert

modifyAdvert

getAdvertData

update

notify

:AdvertController

update

getAdvertData

sd Change advert


46/55

45

Schematic of Simplified Broker

Architecture

component

ClientA

component

Client B

component

Broker

component

Server 1

component

Server 2

componentServer 3


47/55

46

callServer

sendRequestpackData

:Client

sd Broker-based clientserver communication

:ClientSide

Proxy

:Broker :ServerSide

Proxy

:Server

sendRequestfindServer

requestServiceunpackData

service

packData

response

sendResponse

sendResponse

unpackData

response

serverResponse


48/55

47

Process Allocation

processClientProcess

components

Client

ClientSideProxy

processBrokerProcess

components

Broker

processServerProcess

components

Server

ServerSideProxy


49/55

48

Schematic of broker architecture using

bridge components

component

SubsystemA

component

Subsystem B

component

Bridge 1component

Broker 1

component

Subsystem C

component

Subsystem D

component

Bridge 2component

Broker 2


50/55

49

Concurrent activity in an interaction

diagram

msg b

:ClassA

sd Concurrent execution

:ClassB :ClassC :ClassD

msg a

msg c

par

msg d

Simultaneous

execution

Asynchronous

messages

Do not execute

simultaneously


51/55

50

Scheduler Handling Concurrency

Interrupts generated in scheduler.

invoke

I/O Subsystem A I/O Subsystem B

Subsystem 2

Scheduler

Subsystem 1This thread of

execution generates a

system output.

Thread of control

invoked by

scheduler and

produces no output.

invokes

interrupt interrupt


52/55

51

Processor Allocation

Allocation of a system to multiple processors

Application should be divided into subsystems

Estimate processing requirements for subsystems

Determine access criteria and location requirements

Identify concurrency requirements

Each subsystem should be allocated to an operatingplatform

Communication requirements between subsystemsshould be determined

The communications infrastructure should be specified


53/55

52

Agate Domain

Agate Case Study

Agate Boundary

Agate Control

Agate Domain

Agate Database

Agate Boundary

Agate Control

Agate Domain

Agate Database

Agate Control Server

Agate Database

Agate Boundary

Agate Control Client

Agate Business

Objects

Agate Value

Objects


54/55

53

Agate Case Study

process

AgateClientProcess

components

com.agate.boundary

com.agate.control.client

com.agate.domain.vo

process

AgateServerProcess

components

com.agate.control.server

com.agate.domain.bo

com.agate.domain.vo

com.agate.database


55/55

54

Summary

In this lecture you have learned about:

y The main aspects of system architecture, in

particular what is meant by subdividing a system

into layers and partitions

y How to apply the MVC architecture

y Which architectures are most suitable for

distributed systems

Documents

L12 System Architecture