University of Toronto Lecture 4: Showing the...

1

University of Toronto Department of Computer Science

© 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1

Lecture 4:Showing the architecture

Coupling and Cohesion UML Package Diagrams Software Architectural Styles:

Layered Architectures Pipe-and-filter Object Oriented Architecture Implicit Invocation Repositories



Coupling and CohesionArchitectural Building blocks:

A good architecture:Minimizes coupling between modules:

Goal: modules donʼt need to know much about one another to interactLow coupling makes future change easier

Maximizes the cohesion of each moduleGoal: the contents of each module are strongly inter-relatedHigh cohesion means the subcomponents really do belong together

module moduleconnector

X

2

3


© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

Conwayʼs Law

“The structure of a software systemreflects the structure of the organisation

that built it”



People

Socio-Technical Congruence

C

G

B

EF

D

A

L

JH

IK

Modules

3 72

5 6

4

1

12

108

9

11

See: Valetto, et al., 2007.

3



People

Socio-Technical Congruence

C

G

B

EF

D

A

L

JH

IK

Modules

3 72

5 6

4

1

12

108

9

11

See: Valetto, et al., 2007.



Software ArchitectureA software architecture defines:

The components of the software systemHow the components use each otherʼs functionality and dataHow control is managed between the components

An example: client-serverServers provide some kind of service; clients request and use servicesReduced coupling: servers donʼt need to know what clients are out there

clientclient

client

methodinvocation

methodinvocation method

invocation

Server

4



Application Logic

Storage Layer

Presentation Layer

Example: 3-layer architecture

JavaAWT

ApplicationViews

ControlObjects

BusinessLogic

QueryEngine

DBMS

FileManagemt



UML PackagesWe need to represent our architectures

UML elements can be grouped together in packagesElements of a package may be:

other packages (representing subsystems or modules); classes; models (e.g. use case models, interaction diagrams, statechart diagrams, etc)

Each element of a UML model is owned by a single package

Criteria for decomposing a system into packages:Different owners

who is responsible for working on which diagrams?Different applications

each problem has its own obvious partitions;Clusters of classes with strong cohesion

e.g., course, course description, instructor, student,…Or: use an architectural pattern to help find a suitable decomposition…

5



java

Package notation

util

util

DateDate

util

java::util

Date

util

Date java::util::Date

named package package with listof contained classes

package containinga class diagram

package with qualified name nested packages

package with fully qualified name



Towards component-based design

control

Button

Check box

<<interface>> OnOff

turnOn()turnOff()isOn()isOff()

Furnace::Heater Lighting::Light

6



Or use Component Diagrams…

Till

Sales Server

messagequeue

transactionprocessor

accounting

driver

accountingsystem

salesmessage



Dependency cycles (to be avoided)

7



Application Logic Layer Package

Storage Layer Package

Presentation Layer Package

Architectural Patterns

E.g. 3 layerarchitecture:

PresentationLayer

ApplicationLogic Layer

StorageLayer

Java AWT

ApplicationWindows

ControlObjects

BusinessObjects

Object toRelationalJDBC

Java SQL



Or to show the interfaces…

Application Logic Layer Package

Storage Layer Package

Presentation Layer Package

Java AWT

ApplicationWindows

ControlObjects

BusinessObjects

Object toRelational

JDBC

Java SQL

E.g. 3 layerarchitecture:

PresentationLayer

ApplicationLogic Layer

StorageLayer

8



kernal

Layered Systems

ExamplesOperating Systemscommunication protocols

Interesting propertiesSupport increasing levels of abstraction during designSupport enhancement (add functionality) and re-usecan define standard layer interfaces

DisadvantagesMay not be able to identify (clean) layers

kernal

utilitiesapplication layer

users

Source: Adapted from Shaw & Garlan 1996, p25. See also van Vliet, 1999, p281.



Open vs. Closed Layered Architectureclosed architecture

Each layer only uses services of the layerimmediately below;

Minimizes dependencies between layers andreduces the impact of a change.

open architectureA layer can use services from any lower layer.More compact code, as the services of lower

layers can be accessed directlyBreaks the encapsulation of layers, so increase

dependencies between layers

Layer NLayer N-1

Layer 2Layer 1

Layer NLayer N-1

Layer 2Layer 1

9



How many layers?2-layers:

application layerdatabase layere.g. simple client-server model

3-layers:separate out the business logic

helps to make both user interface anddatabase layers modifiable

4-layers:Separates applications from the domainentities that they use:

boundary classes in presentation layercontrol classes in application layerentity classes in domain layer

Partitioned 4-layersidentify separate applications

Application (client)Database (server)

Presentation layer (user interface)Business Logic

Database

Presentation layer (user interface)Applications

Domain EntitiesDatabase

UI1 UI2 UI3 UI4

App1 App2 App3 App4

Domain Entities

Database



Pipe-and-filter

Examples:UNIX shell commandsCompilers:

Lexical Analysis -> parsing -> semantic analysis -> code generationSignal Processing

Interesting properties:filters donʼt need to know anything about what they are connected tofilters can be implemented in parallelbehaviour of the system is the composition of behaviour of the filters

specialized analysis such as throughput and deadlock analysis is possible

Source: Adapted from Shaw & Garlan 1996, p21-2. See also van Vliet, 1999 Pp266-7 and p279

filter filter

filter

filter filter

filter

pipe pipe

pipe

pipe pipe

pipe

10



Object Oriented Architectures

Examples:abstract data types

Interesting propertiesdata hiding (internal data representations are not visible to clients)can decompose problems into sets of interacting agentscan be multi-threaded or single thread

Disadvantagesobjects must know the identity of objects they wish to interact with

object

object

object

object

object


invocation


invocation

Source: Adapted from Shaw & Garlan 1996, p22-3.

Thisis

notUML!



Variant: Object Brokers

server

server

broker

clientclient

client

Interesting propertiesAdds a broker between the clients and serversClients no longer need to know which server they are usingCan have many brokers, many servers.

DisadvantagesBroker can become a bottleneckDegraded performance

Thisis

notUML!

11



Event based (implicit invocation)

Examplesdebugging systems (listen for particular breakpoints)database management systems (for data integrity checking)graphical user interfaces

Interesting propertiesannouncers of events donʼt need to know who will handle the eventSupports re-use, and evolution of systems (add new agents easily)

DisadvantagesComponents have no control over ordering of computations

broadcastmedium

agent

agent

agent

agent

announceevent

announceevent

listen forevent

listen foreventbroadcast

medium

Source: Adapted from Shaw & Garlan 1996, p23-4. See also van Vliet, 1999 Pp264-5 and p278

Thisis

notUML!



Repositories

Examplesdatabasesblackboard expert systemsprogramming environments

Interesting propertiescan choose where the locus of control is (agents, blackboard, both)reduce the need to duplicate complex data

Disadvantagesblackboard becomes a bottleneck

blackboard(shareddata)

agent

agent

agent

agent

agent

agent

Source: Adapted from Shaw & Garlan 1996, p26-7. See also van Vliet, 1999, p280

12



Variant: Model-View-Controller

controller

controllerview

model

view propagate propagate

update update

accessaccess

PropertiesOne central model, many views (viewers)Each view has an associated controllerThe controller handles updates from the user of the viewChanges to the model are propagated to all the views

University of Toronto Lecture 4: Showing the...

Documents

Transcript of University of Toronto Lecture 4: Showing the...