Академический Документы
Профессиональный Документы
Культура Документы
Architecture Diagrams
Yvonne Dittrich
IT-University in Copenhagen
Software Development Group
© Dittrich February 06 1
Roadmap
© Dittrich February 06 2
© Dittrich February 06 3
Software architecture
© Dittrich February 06 4
© Dittrich February 06 5
What to model
© Dittrich February 06 6
Challenges
© 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
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
© Dittrich February 06 10
Package diagrams
© Dittrich February 06 11
a good design …
© Dittrich February 06 12
layers or (abstract machines)
interface
logic
database
© Dittrich February 06 13
function
model
technical platform
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
interface function
model
Oracle DBMS
© Dittrich February 06 17
Deployment diagrams
© Dittrich February 06 18
Component diagrams
© Dittrich February 06 19
© Dittrich February 06 20
the metaphor
© 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
model
material 1 material 2
technical platform
© Dittrich February 06 23
what do we gain?
© 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
© Dittrich February 06 26
© 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
© Dittrich February 06 29
target adaptee
client
request spec.request ()
adapter
request ()
© Dittrich February 06 30
listable books
lister
GiveList ListKayaks ()
listable_books
GiveList ()
© Dittrich February 06 31
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
© 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
© Dittrich February 06 38
© 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
• 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
© 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