how to document the architecture of your application using uml and more
DESCRIPTION
Tutorial at SPLASH 2013.More at: http://splashcon.org/2013/program/861TRANSCRIPT
How to Represent your Software Architecture Using UML and More
1
© 2010 Carnegie Mellon University
How to Document the Architecture of Your ApplicationUsing UML and More
SPLASH 2013 – Indianapolis
October 30, 2013
Paulo Merson
2© 2010 Carnegie Mellon University
I created this diagram14 years ago
The design may be OK
But the design description is bad and by the end of this talk I’ll have told you why!
You cando better than this!
How to Represent your Software Architecture Using UML and More
2
3© 2010 Carnegie Mellon University
Before we start the powerpoint poisoning…
How many of you work in industry with software development?
How many are familiar with basic UML?
4© 2010 Carnegie Mellon University
Goals of this talk:
• Tell you what information about an architecture should be captured
• Discuss UML and other notations and guidelines for architecture representation
How to Represent your Software Architecture Using UML and More
3
5© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
6© 2010 Carnegie Mellon University
Motivation for Software Architecture (1)
The problem
???
Implementation
Requirements
How to Represent your Software Architecture Using UML and More
4
7© 2010 Carnegie Mellon University
Motivation for Software Architecture (2)
The role of software architecture
Implementation
Requirements
Architecture
8© 2010 Carnegie Mellon University
What is Software Architecture?
The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.1
1 P. Clements et al, Documenting Software Architectures: Views and Beyond, 2nd Edition. Addison-Wesley, 2010.
How to Represent your Software Architecture Using UML and More
5
9© 2010 Carnegie Mellon University
Why document the architecture?
In the software life cycle we:
• Create an architecture
o Using architectural patterns, design patterns, experience
• Evaluate the architecture
o Using ATAM for example
• Refine, update and refactor the architecture along the way
• Use the architecture to guide implementation
• (Try to) enforce the architecture during implementation andthroughout maintenance
Architecture documentation is a key artifact in all these
activities
10© 2010 Carnegie Mellon University
Architecture, design, architectural design
Architecture is design,but not all design is architectural
A better separation is:
• architectural design
• non-architectural design
The architect draws the line between the two
What’s the difference between
architecture and
design?
How to Represent your Software Architecture Using UML and More
6
11© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
12© 2010 Carnegie Mellon University
Views (1)
A software architecture is composed of many structures
• Code units, their decomposition and dependencies
• Processes and how they interact
• How software is deployed on hardware
• Many others
A view is the representation of a structure
Views are also known as viewpoints or
perspectives
How to Represent your Software Architecture Using UML and More
7
13© 2010 Carnegie Mellon University
Views (2)
Not all system elements, some of them
A view constrains the types of elements and the types of relations that can be represented in that view
A view is a representation of a set of system elements and relationships among them. 1
1 P. Clements et al, Documenting Software Architectures: Views and Beyond, 2nd Edition. Addison-Wesley, 2010.
14© 2010 Carnegie Mellon University
What views are available?
Kruchten’s 4+1:• Logical view
• Process view
• Development view
• Physical view
• “Plus one” view
RM-ODP:• Enterprise viewpoint
• Information viewpoint
• Computational viewpoint
• Engineering viewpoint
• Technology viewpoint
Rozansky and Woods• Functional viewpoint
• Information viewpoint
• Concurrency viewpoint
• Development viewpoint
• Deployment viewpoint
• Operational viewpoint
Philips CAFCR• Customer view
• Application view
• Functional view
• Conceptual view
• Realization view
TOGAF:• Business architecture views
• Data architecture views
• Application architecture views
• Technology architecture views
Siemens Four Views model: • Conceptual view
• Module interconnection view
• Execution view
• Code view
Garland and Anthony• Conceptual and analysis viewpoints
• Logical design viewpoints
• Environment/physical viewpoints
How to Represent your Software Architecture Using UML and More
8
15© 2010 Carnegie Mellon University
What is the “right” set of views?
It depends!
Choose what views to create (and what views do spend more time on) based on:
• The structures inherent to that software system
• The stakeholders of the documentation and what do they use it for
16© 2010 Carnegie Mellon University
Exercise: list typical stakeholders of the architec ture of a software system in an IT department
Software architect
. . .
How to Represent your Software Architecture Using UML and More
9
17© 2010 Carnegie Mellon University
What kinds of views are common?
An architect usually considers 4 perspectives of the system:
1. How is it structured as a set of code units?
Module Views
2. How is it structured as a set of elements that have runtime presence?
Runtime Views
3. How are artifacts organized in the file system and how is the system deployed to hardware?
Deployment Views
4. What are the data entities and their relationships?
Data Model
18© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
How to Represent your Software Architecture Using UML and More
10
19© 2010 Carnegie Mellon University
Module Views
Show structure of the system in terms of units of implementation
Elements : modules, i.e. implementation units
Relations :
• A is part of B : part-whole relation among modules
• A depends on B : dependency relation among modules
• A is a B : specialization/generalization relation among modules, or interface realization
20© 2010 Carnegie Mellon University
UML relations between modules
“Is part of”
Package contains subpackages or classes
“Depends on”
Dependency can be <<use>>, <<refine>>, <<instantiate>>, etc.
“Is a”
Generalization andinterface realization
UML has other standard relations, and you can specialize
any of them with stereotypes
How to Represent your Software Architecture Using UML and More
11
21© 2010 Carnegie Mellon University
Module view example – Adventure Builder application
Showing module usage dependency
Disclaimer about examples:• no need to understand the
design• are real hence not perfect
• not the latest version• diagram can’t tell everything
22© 2010 Carnegie Mellon University
Module view example – refinement of workflowmanager
How to Represent your Software Architecture Using UML and More
12
23© 2010 Carnegie Mellon University
Layered architecture of the OSGi framework
What two ambiguities exist in this diagram?
24© 2010 Carnegie Mellon University
Layered view with arrows showing allowed to use relation
How to Represent your Software Architecture Using UML and More
13
25© 2010 Carnegie Mellon University
What are module views good for?
Construction—they are the blueprints for the code
Budgeting, work assignment, tracking
Modifiability and impact analysis
Education of new developers
26© 2010 Carnegie Mellon University
Layers: stack of boxes and concentric rings
Are these layered designs
equivalent?
How to Represent your Software Architecture Using UML and More
14
27© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
28© 2010 Carnegie Mellon University
Runtime Views
Also known as Component and Connector (C&C) views
Show structure of the system when it’s executing
Elements :
• Components that have runtime presence (e.g., processes, threads, EJBs, Servlets, ASP.NET components, service agents)
• Data stores
• Complex connectors (e.g., queues, pipes)
Relations :
• Interaction mechanisms vary based on runtime platforms
• Architect should differentiate:
o Local from remote calls
o Synchronous from asynchronous invocation
The runtime view is clearly the most
suitable for showing SOA architectures
How to Represent your Software Architecture Using UML and More
15
29© 2008 Carnegie Mellon University
Informal notation
Adapted from Adventure Builder Application http://java.sun.com/developer/releases/adventure/
Runtime View example – Adventure Builder application
30© 2008 Carnegie Mellon University
Informal notation
Adapted from Adventure Builder Application http://java.sun.com/developer/releases/adventure/
Runtime View example – OPC refinement (1)
How to Represent your Software Architecture Using UML and More
16
31© 2008 Carnegie Mellon University
Runtime View example – OPC refinement (2)
Component (subtype of
class)
Delegation connector
Delegation connector
Assembly connector
Required interface
Provided interface
Port
Stereotype indicate type of
component
32© 2008 Carnegie Mellon University
Peer-to-Peer runtime view example
How to Represent your Software Architecture Using UML and More
17
33© 2008 Carnegie Mellon University
Architectural styles for runtime views
P. Clements et al, Documenting Software Architectures: Views and Beyond, 2nd Edition. Addison-Wesley, 2010.
34© 2010 Carnegie Mellon University
What are runtime views good for?
Education—starting point to show how the system works
Explaining:
• How components interact at runtime
• What components are replicated
• What components access data stores
Analysis of runtime properties
• Performance
• Security
• Reliability
How to Represent your Software Architecture Using UML and More
18
35© 2010 Carnegie Mellon University
Runtime View – Duke’s Bank – not so good example
BankAdmin
customer_account_xref
next_tx_id
next_customer_id
next_account_id
No key!What’s the green box?
Same arrow for different interactions
Missing elements and
relations
Incorrect interaction
Inconsistent naming
Original diagram of Duke’s Bank Application from Sun J2EE 1.3 tutorial (w/ our amendment)http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Ebank2.html
36© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
How to Represent your Software Architecture Using UML and More
19
37© 2010 Carnegie Mellon University
Deployment Views
Show the hardware infrastructure of the production environment, along with deployment files and components allocated to them
Elements :
• Processing and communication nodes (e.g., server machine, router)
• Deployment artifacts
• Components
Relations :
• Interaction mechanisms between hardware elements are usually communication channels
• A deployment artifact may contain other artifacts and is deployed tohardware elements
• Components are allocated to hardware elements and deployment artifacts
38© 2010 Carnegie Mellon University
Deployment View example – Adventure Builder (1)
Informal notation
How to Represent your Software Architecture Using UML and More
20
39© 2010 Carnegie Mellon University
Deployment View example – Adventure Builder (2)
40© 2010 Carnegie Mellon University
Deployment View example – ATIA
How to Represent your Software Architecture Using UML and More
21
41© 2010 Carnegie Mellon University
Deployment View showing installation files
42© 2010 Carnegie Mellon University
What are deployment views good for?
Planning purchasing options
Assessing:
• Availability
• Performance (e.g., throughput, bandwidth utilization)
• Security
• Reliability
Education and stakeholder communication
Defining deployment and operation procedures
Auditing runtime failures
Designing “automatic updates” feature
How to Represent your Software Architecture Using UML and More
22
43© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
44© 2010 Carnegie Mellon University
Data Model
Shows structure of data manipulated in the software system
Elements : data entities (persisted domain elements)
Relations :
• 1:1, 1:n and n:n relationships
• Generalization/specialization
• AggregationData modeling is more common in
information systems
How to Represent your Software Architecture Using UML and More
23
45© 2010 Carnegie Mellon University
Data Model example – Pet Shop .NET application
46© 2010 Carnegie Mellon University
What is the data model good for?
Blueprint for:
• physical database
• XML schemas
Input to normalization
Assess performance in data-centric systems
• Merged entities; derived attributes
• Indexes; lock type and granularity
Useful reference for developers of data access code
Modifiability impact analysis
database
schemas
How to Represent your Software Architecture Using UML and More
24
47© 2010 Carnegie Mellon University
Check your understanding
Mark true or false:
[ ] 1) A software architecture consists of multiple structures, which are documented as views.
[ ] 2) A module is a runtime element whereas a component is an implementation unit.
[ ] 3) An architecture document must contain at least a module view, a runtime view, a deployment view, and a data model.
[ ] 4) The diagram below shows a layered architecture.
48© 2010 Carnegie Mellon University
Check your understanding (cont.)
Mark true or false:
[ ] 5) The diagram below shows a layered architecture.
[ ] 6) The diagram below shows a layered architecture.
How to Represent your Software Architecture Using UML and More
25
49© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
50© 2010 Carnegie Mellon University
Behavior Documentation
Diagrams we see in the views are usually structural diagrams
Structural diagrams show all potential interactions among elements
Behavioral diagrams describe specific patterns of interaction—the system’s response to stimuli
Behavioral diagrams complement structural
diagrams
How to Represent your Software Architecture Using UML and More
26
51© 2010 Carnegie Mellon University
Notations for behavior documentation
UML
• sequence diagram
• communication diagram
• activity diagram
• timing diagram
• state machine diagram
Non UML
• BPMN and alike
• SDL
• informal overlay on structural diagrams
Examples follow…
52© 2010 Carnegie Mellon University
Sequence diagram – simple example
How to Represent your Software Architecture Using UML and More
27
53© 2010 Carnegie Mellon University
Sequence diagram – more interesting example
duration constraint
Interaction use (reference)
loop
alternative traces
54© 2010 Carnegie Mellon University
UML sequence diagram notation bits
Frames
Self call
Reentrant call
How to Represent your Software Architecture Using UML and More
28
55© 2010 Carnegie Mellon University
Activity diagram example (1)
Activity diagram for a simple dive computer
56© 2010 Carnegie Mellon University
Activity diagram example (2)
Activity diagram for processing a purchase order(Adventure Builder)
How to Represent your Software Architecture Using UML and More
29
57© 2010 Carnegie Mellon University
BPMN diagram example
BPMN diagram for processing a purchase order
58© 2010 Carnegie Mellon University
State machine diagram – simple example
State machine diagram for a vehicle’s cruise control system
How to Represent your Software Architecture Using UML and More
30
59© 2010 Carnegie Mellon University
State machine diagram – more interesting example
State machine for a car stereo with AM/FM tuner and CD player
60© 2010 Carnegie Mellon University
State machine diagrams – simple, powerful and yet misused and underutilized
Boxes in a state diagram are states, not components or modules;arrows are transitions, not connectors or calls
The diagram may model states of
• part of or the entire system,
• a component or module,
• a collection of components of modules, or
• even an attribute of a component/module
Be clear as to what is the scope of your state machine diagram
By definition, a state machine diagram should show
• All possible states
• All possible transitions out of any given state
Beware of the state explosion problem
How to Represent your Software Architecture Using UML and More
31
61© 2010 Carnegie Mellon University
Example of informal overlay on structural diagram
62© 2010 Carnegie Mellon University
What is behavior documentation good for? (1)
Explain how does the design in a structural diagram work
• In what order do modules/components interact?
• What’s the response time for a given transaction?
• What’s the startup and shutdown procedure?
• What’s the life cycle of a given software element?
• What components execute in parallel?
• What happens when specific stimulus arrive at the system?
How to Represent your Software Architecture Using UML and More
32
63© 2010 Carnegie Mellon University
What is behavior documentation good for? (2)
Perform different kinds of (formal) analyses
• Safety and liveness properties verification
— Safety: “something bad never happens”
o Example: thrust reverser cannot be activated during takeoff
— Liveness: “something good eventually happens”
o Example: OS process eventually gets CPU time (no starvation)
• Can the system ever deadlock?
• What trace leads to deadlock?
64© 2010 Carnegie Mellon University
Exercise
Create a state machine diagram for your laptop wireless connection.
Make whatever assumptions you need to make the problem simpler.
connectedconnecting connectionsare available
connected,but no Internet
access
not connected
How to Represent your Software Architecture Using UML and More
33
65© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
66© 2010 Carnegie Mellon University
Software interface
An interface is a boundary across which two elements meet and interact or communicate with each other.1
1 P. Clements et al, Documenting Software Architectures: Views and Beyond, 2nd Edition. Addison-Wesley, 2010.
Is the interface of a component or module part of the software architecture?
How to Represent your Software Architecture Using UML and More
34
67© 2010 Carnegie Mellon University
Principles about interfaces (1)
All software elements have interfaces
The interface of an element is different from its implementation
• Indeed, different elements may implement the same interface
An element may have multiple interfaces. Examples:
• To handle different groups of users,
• When 2+ versions of the same interface are available at the same time
68© 2010 Carnegie Mellon University
Principles about interfaces (2)
Many callers can interact with the same interface at the same time
• Any concurrent access restrictions should be documented
Interfaces can be extended through generalization
Elements provide interfaces and may require interfaces
How to Represent your Software Architecture Using UML and More
35
69© 2010 Carnegie Mellon University
How to document a software interface
How far we document depends on the needs of the stakeholders
Often interface documentation focuses too much on syntax, and overlooks quality
attributes and rationale
70© 2010 Carnegie Mellon University
Should we show interfaces in design diagrams?
Jazz for Service Management architecture
http://pic.dhe.ibm.com/infocenter/tivihelp/v3r1/topic/com.ibm.psc.doc_1.1.0/oview/psc_c_arch.html
How to Represent your Software Architecture Using UML and More
36
71© 2010 Carnegie Mellon University
Interfaces in UML
72© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
How to Represent your Software Architecture Using UML and More
37
73© 2010 Carnegie Mellon University
Software architecture documentation
How do we document a view?
How do we document everything else beyond the views?
74© 2010 Carnegie Mellon University
The value of templates
Reader can easily navigate and find information
Writer can record information as soon as it’s known
Writer doesn’t have to think about:
• what pieces of information should be documented
• what’s the best organization for the document
Helps to evaluate documents for completeness and consistency
Document doesn’t necessarily mean paper
or Word document
How to Represent your Software Architecture Using UML and More
38
75© 2010 Carnegie Mellon University
Documenting a view (1)
1. Primary Presentation
• Is usually graphical
• Shows elements and relations among them
• Should include a key that explains the notation
— Indicate the meaning of each symbol. Don’t forget the lines!
— Try to use consistent notation across diagrams
• May identify elements that are “external”
Many times, the primary presentation is all you
get.It’s not enough!
76© 2010 Carnegie Mellon University
Documenting a view (2)
2. Element Catalog
• Explains elements depicted in the primary presentation
• It’s usually just a list of element names and textual descriptions
• May contain interface specifications
• May contain behavior documentation
How to Represent your Software Architecture Using UML and More
39
77© 2010 Carnegie Mellon University
Documenting a view (3)
3. Context Diagram
• Shows what’s in and what’s out of the system (or the part of the system the view is focusing on)
• Common notation:
— System in the middle
— External entitiesaround
— Arrows indicating interactions
78© 2010 Carnegie Mellon University
Documenting a view (4)
4. Variability Guide
• Describe variability mechanisms, such as:
— Substitution of an element with another that has the same interface
— Optional inclusion (e.g., plug-ins, add-ons)
— Component replication
— Parameterization (build-time flags, config files, etc.)
• What should be documented:
— what can vary and the effect of the variation
— binding time (compile, build, install, start, or run time)
— how to exercise each variation/configuration
How to Represent your Software Architecture Using UML and More
40
79© 2010 Carnegie Mellon University
Documenting a view (5)
5. Architecture Background
• Rationale for design decisions (including relevant rejected alternatives)
• Results of analysis, prototypes and experiments
• Assumptions and constraints affecting this view
• Known patterns used in the design
6. Related Views
• Pointer to parent view and children views
80© 2010 Carnegie Mellon University
Outline of a documented view
This template can be used for any kind of view
How to Represent your Software Architecture Using UML and More
41
81© 2010 Carnegie Mellon University
Software Architecture Document (1)
1. Documentation Roadmap
• Shows how documentation is organized
• Has reference to template used
• Includes scenarios for different stakeholders to use the documentation
2. System Overview
• Description of the system and its purpose
• May point to overview elsewhere in the overall system documentation
82© 2010 Carnegie Mellon University
Software Architecture Document (2)
3. Views
• 3.1
• 3.2
• 3.3…
How to Represent your Software Architecture Using UML and More
42
83© 2010 Carnegie Mellon University
Software Architecture Document (3)
4. Mapping Between Views
• Tables showing how elements in one view map to elements in another view
Example from Adventure BuilderOnly relevant mappings
are documented
84© 2010 Carnegie Mellon University
Software Architecture Document (4)
5. Rationale
• Rationale for cross-view design decisions (including rejected alternatives)
• Results of architecture evaluation (e.g., ATAM report)
6. Mapping Requirements to Architecture
• Shows how each requirement is satisfied by one or more elements of the architecture, or an architectural approach
7. Glossary and Acronym List
• May point to a larger glossary elsewhere
How to Represent your Software Architecture Using UML and More
43
85© 2010 Carnegie Mellon University
Outline of a Software Architecture Document
86© 2010 Carnegie Mellon University
Agenda
Introduction
Multi-View Architecture
• Module Views
• Runtime Views
• Deployment Views
• Data Model
Behavior Documentation
Software Interface Documentation
Template for an Architecture Document
Outroduction
How to Represent your Software Architecture Using UML and More
44
87© 2010 Carnegie Mellon University
Code is king!
Code is king!
But often architecture is a much-needed advisor to the king
88© 2010 Carnegie Mellon University
Important takeaways
Describe the architecture in multiple views
Documentation should not appeal to reader’s intuition
• Always use a key or indicate the diagram notation
• Don’t forget the lines
• Use different symbols for different types of elements and relations
Define and use a template for architecture documentation
Choose notation based on the reader
• UML is not always the best notation
Indicate what patterns you’re using
How to Represent your Software Architecture Using UML and More
45
89© 2010 Carnegie Mellon University
What else is important?
Record rationale for design decisions
Select views to be documented (or documented in detail) based on:
• Stakeholders’ needs
• What structures are inherent to the system
Use view refinement
Combine views as appropriate
Document variability
Create context diagrams
Enforce the architecture
90© 2010 Carnegie Mellon University
For more information
“Documenting Software Architectures: Views and Beyond, 2nd Edition”
https://wiki.sei.cmu.edu/sad/ (for an example)
sei.cmu.edu/architecture
How to Represent your Software Architecture Using UML and More
46
91© 2010 Carnegie Mellon University
Questions – Now or LaterPaulo [email protected]
Suggestions:
• I use an Agile process. Should I care about all this?
• What if I follow RUP? What about the 4+1 views?
• Can you show more real world examples?
• Can I document my architecture using a wiki?
• Is UML a formal language?
• What is the difference between contract, interface, and port?
92© 2010 Carnegie Mellon University
Backup slides
How to Represent your Software Architecture Using UML and More
47
93© 2010 Carnegie Mellon University
A possible solution to the state machine exercise
94© 2010 Carnegie Mellon University
Module View example – Adventure Builder application (1)
Showing only module decomposition
Disclaimer about examples:• no need to understand the
design• are real hence not perfect
• not the latest version• diagram can’t tell everything
How to Represent your Software Architecture Using UML and More
48
95© 2010 Carnegie Mellon University
High-level module view – Duke’s Bank (1)
Is this a layered design?
Showing only module decomposition
96© 2010 Carnegie Mellon University
High-level module view – Duke’s Bank (2)
Showing module usage dependency
Reconstructed from Duke’s Bank Application—Sun J2EE 1.3 tutorial
How to Represent your Software Architecture Using UML and More
49
97© 2010 Carnegie Mellon University
UML for runtime viewsComponent (as subtype of class)Port (which can have multiple instances)Required and provided interface (optionally connected through ports)Assembly connectorInternal structure for classesDelegation connector
Delegation connector
1 to 5 instances of this port (suggesting
it can take up to 5 requests at a time)
Only 1 instance of
this port
Port Required interface
Provided interface
ComponentAssembly connector
Delegation connector
98© 2010 Carnegie Mellon University
soapatterns.org notation
Adapted from Adventure Builder Application http://java.sun.com/developer/releases/adventure/
Runtime View Example – OPC
Refinement (3)
How to Represent your Software Architecture Using UML and More
50
99© 2010 Carnegie Mellon University
Runtime View Example – Duke’s Bank (1)
Informal notation
Reconstructed from Duke’s Bank Application—Sun J2EE 1.3 tutorial
100© 2010 Carnegie Mellon University
Runtime View Example – Duke’s Bank (2)
Reconstructed from Duke’s Bank Application—Sun J2EE 1.3 tutorial
How to Represent your Software Architecture Using UML and More
51
101© 2010 Carnegie Mellon University
Runtime View Example – Gnutella P2P
Peer-to-peer example
102© 2010 Carnegie Mellon University
Deployment View Example – Deployment Files –Duke’s Bank
Informal notation
How to Represent your Software Architecture Using UML and More
52
103© 2010 Carnegie Mellon University
Deployment View Example – Duke’s Bank
104© 2010 Carnegie Mellon University
Deployment View Example – Deployment Files –Duke’s Bank
The
se a
re th
e tw
oto
p-le
vel a
rtifa
cts
<<manifest>> indicates the component is
inside the artifact
<<manifest>> may also indicate that
an artifact is inside another
How to Represent your Software Architecture Using UML and More
53
105© 2010 Carnegie Mellon University
Timing Diagram Example
Successful commit transaction in 2PC with two participants
106© 2010 Carnegie Mellon University
V&B Views and 4+1 Views Imprecise Mapping
Logical view
• Module views showing generalization and usage dependencies
Process view
• Runtime views in general
Development view
• Deployment view focusing on structure of files and folders
• High-level module view showing layers
Physical view
• Deployment view focusing on the hardware infrastructure
“Plus one” view
• Rational of design decisions
• Mapping to requirements
• Behavior documentation showing important traces (using sequence and activity diagrams for example)
How to Represent your Software Architecture Using UML and More
54
107© 2010 Carnegie Mellon University
What about UML associations?
108© 2010 Carnegie Mellon University
Aspects in the architecture
How to Represent your Software Architecture Using UML and More
55
109© 2010 Carnegie Mellon University
Dependency Structure Matrix (DSM)
110© 2010 Carnegie Mellon University
Layered View with Concentric Rings Example
How to Represent your Software Architecture Using UML and More
56
111© 2010 Carnegie Mellon University
Data-centric Runtime View Example
112© 2010 Carnegie Mellon University
Data Model UML Example – Duke’s Bank
How to Represent your Software Architecture Using UML and More
57
113© 2010 Carnegie Mellon University
Layered View in UML
114© 2010 Carnegie Mellon University
UML 2.2 Diagrams