UML

Architecture Diagrams

Yvonne Dittrich
IT-University in Copenhagen
Software Development Group

© Dittrich February 06 1

Roadmap

• what is a software architecture

• which diagrams do we have for describing it
• example:
the tools and materials architecture
• architectural patterns and design

© Dittrich February 06 2

© Dittrich February 06 3
 Software architecture

• Designing the global organisation of a

software system
• Dividing software into subsystems
– Deciding how these will interact
– Determining their interfaces

© Dittrich February 06 4

Why develop an architectural model

• To enable everyone to better understand the

system
• To allow people to work on individual pieces
of the system in isolation
• To prepare for extension of the system
• To facilitate reuse and reusability

© Dittrich February 06 5

What to model

• Different views of the system

– Logical breakdown
– Dynamics of interaction among components at
runtime (topic of the next lectures)
– Data shared among subsystems
– The components that will exist at runtime, and the
machines and devices on which they are located

© Dittrich February 06 6
 Challenges

• Producing a relevant picture of a large and

complex system
• It should be easy to understand (even by
clients) by looking at different views and how
these relate to each other
• The architecture model should be stable,
allowing new features to be added with only
minor changes to the overall model

© Dittrich February 06 7

Architectural patterns

• Multi-Layer
• Client-Server
• Broker
• Transaction processing
• Pipe-and-Filter
• Model-View-Controller
• Service-Oriented
• Message-Oriented

© Dittrich February 06 8

How to develop an architectural model?

1. Sketch outline
• Domain model and use cases
• Main components
• Architectural patterns
2. Identify interaction between components
• Decide how data and functionality will be distributed
among components
• Consider reusing existing frameworks
3. Finalize the interfaces of each component
4. Define final class diagrams and interaction
diagrams

© Dittrich February 06 9
 Describing an architecture using UML

• All UML diagrams can be useful, but here we

will cover
– Package diagrams
– Component diagrams
– Deployment diagrams

© Dittrich February 06 10

Package diagrams

• When designing packages, use the principles

of cohesion and coupling
– The content can be reused together
– Minimize the number of dependencies
• Dependencies are shown with dashed arrows
• It is dependencies between elements of
different packages
• A change made to the interface of a package
will require modification to packages that
depend upon it

© Dittrich February 06 11

a good design …

… has no major weaknesses.

… represents a trade-off between different
criteria.
… is (at least) usable, flexible and
understandable.

© Dittrich February 06 12
 layers or (abstract machines)

interface

logic

database

© Dittrich February 06 13

generic architecture pattern

interface

user interface system interface

function

model

technical platform

ui-system database sys. network

© Dittrich February 06 14

client server architecture pattern

Client 1
Client 2 … Client 3

Server

© Dittrich February 06 15
 thick clients - thin clients

Client

interface

function Server

model
Oracle DBMS

© Dittrich February 06 16

thick clients - thin clients

Server
Client

interface function

model

Oracle DBMS

© Dittrich February 06 17

Deployment diagrams

• Show the physical layout of the system

– Where the artifacts (files) physically reside
– Sometimes the files are grouped together in components
– They can be represented in a class notation, with additional
comments
• The artifacts are located at nodes
– Devices or execution environments
• The nodes are connected with communication paths

© Dittrich February 06 18
 Component diagrams

• Whereas package diagrams show the logical

grouping of design elements, component diagrams
show the physical grouping
• What is a component?
– Something that can be sold and upgraded independently
– Provides an interface to other components
• Relationships between components:
– A component may execute another component, or a method
in the other component
– A component may generate another component
– Two components may communicate with each other using a
network

© Dittrich February 06 19

the Tools & Materials Approach

© Züllighoven et al, http://www.jwam.de
combines
• use oriented development
• iterative process model
• a set of related analysis and design
metaphors that anchor the design to the work
practice of the future users
• an architectural style
• design patterns

© Dittrich February 06 20

the metaphor

• materials ‘lie around’ and are used for specific tasks:

paper, folder, schedule, mails, kayaks, courses
• materials are only accessible through the tools manipulating
them
• materials are often organised in specific containers
• tools are used on materials to perform tasks:
pens, punch, editor, browser, viewer
• tools are passive: the hammer does not jump on you
• tools might be specialised, but can also be generic
• one might need automatons as well:
printer, compiler

© Dittrich February 06 21
 How does that relate to the pattern
architecture
• materials can be seen as partitions of the model component,
that is meaningful from a use pov
• tools are partitions in the view and function component. A tool
component consists of a functional part and an interaction part
and so connects a partition I the view and a partition in the
function part
• a tool is a meaningfully related set of functions and related
interface elements
• the overall program is designed as an environment where tools,
materials and automatons ‘lie around’

© Dittrich February 06 22

interface

mat 1 mat 2 printer

browser editor
function

model

material 1 material 2

technical platform
© Dittrich February 06 23

what do we gain?

• tools & materials allow for a modeling that is close to

the use context
• it introduces a way of partitioning the model
component and the interface/function component
• the partitions on the both layers are independent of
each other.
• and architecture that provides a frame for highly
incremental development
• as an architectural style, one can use design and
programming patterns for the connections of the
different elements.

© Dittrich February 06 24
 the pattern template used in the
following slides
• its name: describing the problem and the solution in
1-2 words
• the problem: describing when to apply the pattern
• the solution: the elements of the design, their
relationships, responsibilities, and collaborations
• the consequences: the result and trade-offs of
applying the pattern

© E. Gamma et al.

© Dittrich February 06 25

patterns in the Tools&Materials design

• I only can present part of the design patterns

• the ones I selected should show
– why to use patterns
– how to reason about patterns
• we take the ones
– coupling tools and materials
– division of tools in interaction and functional parts and how they
interact
– composite tools
– the event handler of the environment

© Dittrich February 06 26

Coupling tools and materials

- the problem
• tools and materials have to fit together
• tools might work on different materials - e.g. a
lister would work on different containers
• a material might be accessed and updated by
different tools

© Dittrich February 06 27
 coupling tools and materials
- the first solution
lister
• design an abstract class, an
aspect, that represents the
interface a tool needs and a listable
material has to implement. GiveList
MarkItem
• the materials inherit the aspect GiveMarkedItem
class and implement the GiveListName
abstract methods
• the tool only has to know about books
the aspect, not about the
material
© Dittrich February 06 28

coupling of tools and materials

- consequences of solution 1
+ the compiler can check that the interface is correctly
implemented
+ information hiding: the tool only knows aout the aspect
+ the aspect classes can be used to specify the interface for
parallel development
- uncommon usage of inheritance
- that might make the design difficult to understand
- what if you do not have multiple inheritance?

© Dittrich February 06 29

coupling of tools and materials

- solution 2
• implement the adapter pattern (Gamma et al.)

target adaptee
client
request spec.request ()

adapter
request ()

© Dittrich February 06 30
 listable books
lister
GiveList ListKayaks ()

listable_books
GiveList ()

© Dittrich February 06 31

coupling of tools and materials

- consequences of solution 2
+ aspects are clearly visible in the design
+ you can use that pattern also when the
interfaces are not exactly matching
+ the designer can distinguish between
professionally motivated operations on the
material and the interface for specific tools
- an additional class for each tool-material pair
- the identity problem
- who is creating the adapter object and when
© Dittrich February 06 32

coupling of tools and materials

- solution 3
lister
if you have the possibility to
define an interface in a
listable
programming language this
GiveList
can be used to implement MarkItem
aspects GiveMarkedItem
GiveListName
(interfaces in Java and C#)

books

© Dittrich February 06 33
 coupling of tools and materials
- consequences of solution 3
+ aspects are clearly visible in the design
+ the compiler can check that the interface is
correctly implemented
+ information hiding: the tool only knows about
the aspect
+ the aspect interfaces can be used to specify
the interface for parallel development
- you need a special language construct

© Dittrich February 06 34

interaction between interaction part and

function part of a tool
- the problem

• you want to split the interaction part and the

function part of a tool, to be able to implement
and change them independently
• the interaction part knows the function part
but should not make assumptions about the
result of operations
• the function part should definitely not make
assumptions about what is displayed or how
© Dittrich February 06 35

interaction between interaction part and

function part of a tool
- solution 1

implement he observer pattern between

interaction and function part of a tool

© Dittrich February 06 36
 subject observer
observers
attach (observer) Update ()
detach (observer)
notify () for all o in observers {
o->Update()}

FPLister
subject
IPLister
marked_changed
get_marked Update()
list_changed
get_list_descr
fp FPLister
if (fp->marked_changed){… fp->get_marked …}
if (fp->list_changed){… fp->get_list …}

© Dittrich February 06 37

interaction between interaction part and

function part of a tool
- consequences of solution 1
+ the interaction part knows the function part, but the function
part does not know about the interaction part
+ the interaction part does not make any assumptions about
the result of the method of a function part
- if the request for information changes the state of a
material you might get into a loop.
you can handle that by implementing reading methods
without side effects
- for complex tools the observer pattern might lead to
runtime difficulties.
you can expand the update-method with a parameter,
indicating the type of change that occurred

© Dittrich February 06 38

interaction between interaction part and

function part of a tool
- solution 2
Implement an event handler:
– design a class ‘event’
– the function part creates a specific event-object for each relevant
change
– the interaction part registers at the event-object that are relevant for
it and hands over a method to be called for updating
– the event object keeps a list of all objects registered
– the function part announces a change to the respective event-
object
– the event-object calls the methods that they handed over.

© Dittrich February 06 39
 interaction between interaction part and
function part of a tool
- consequences of solution 2
+ differentiated notification of the objects that
have to be informed about an event
+ the possible changes a function part can
announce are visible in the event-object it
creates
- there is the danger that the function parts get
designed for specific interaction parts. this is
actually the problem, we wanted to avoid…

© Dittrich February 06 40

what more about tools and materials

• combination of tools
– how to manage the communication between different tools
• different tools might change the same material
• administration of materials, especially when accessing a
database server that is used by more than one of such tools &
materials clients
• containers is an own chapter
• framework support

© Dittrich February 06 41

limitations of tools & materials

• complex dependencies between materials?

where to handle them?
• what when the world outside the workshop
gets involved?
• sometimes media metaphors might be better
suited…

© Dittrich February 06 42
 References (besides the course book

• L. Mathiassen et al. Object Oriented Analysis & Design. Marko Publishing ApS, Aalborg,
Denmark 2000.
• D. Garlan, M. Shaw ‘An Introduction to Software Architecture’ in: V. Ambriola, D. Tortoga:
Advances in Software Engineering and Knowledge Engineering, Volume1, New Jersey,
1993.
• H. Züllighonen et al. Object-Oriented Construction Handbook. D-Punkt Verlag, October
2004
• D. Riehle, H. Züllighoven ‘A Pattern Language for Tool Construction and Integration Based
on the Tools&Materials Metaphor.’ Proceedings of the PLOP '94, Monticello, Illinois, August
4-6, 1994.
• E. Gamma et al. Design Patterns. Addison-Wesley 1995.

© Dittrich February 06 43