Visualizing Architectures
INF 123 – Software architecture
tdebeauv@uci.edu
1
Outline
• Some theory
• The tools
• Examples
– Socket networking in the Linux kernel
– Vivox: VOIP for Second Life
2
SOME THEORY
3
Software Architecture
• The set of most important design decisions
• “Most important”
– According to the stakeholders
• “Design decisions”
– Aware of the options
– Also called constraints
– More than just the code structure
4
Architectural Model
• Aka architectural view
• A subset of the design decisions
• Focused on a particular concern
– Separation of concerns! MASC!
• Examples
– Server-side of an online game
– How the Linux kernel handles networking
– Authentication process
5
Architectural Model
Architecture
A visualization of the model
“protect an entrance”
6
How do we choose what to model?
• Stakeholders decide
– What should be modeled/modelled
• Components, connectors, configurations, rationales,
constraints, behaviors, non-functional requirements, …
– At what level of detail
– At what level of fidelity
• More faithful = more expensive to maintain
7
Example: level of detail (few details)
8
More details
9
Inconsistent models
• Models contradicting each other
10
Reasons for inconsistencies
• Architects with different opinions
• Level of detail
– High-level view has components absent in a lowerlevel view
• Static vs dynamic concerns
– Component structure != protocol
• Functional vs non-functional concerns
– Broadcast the message to everyone vs scalability
• Physical vs logical concerns
– 2 self-contained subsystems for 3 machines
11
Visualizing models
• A model is abstract
– Abstraction! MASC!
• A visualization must allow…
– Architects to present their models
– Stakeholders to discuss the models
• A visualization is concrete
12
TOOLS
13
Describing a Software Architecture
• “Just look at the source code!”
• Natural language
– Easy to discuss and contract-like, but long to read
• XML, JSON
– Good for hierarchical structures, but hard to read
• Images/screenshots
– Good for usability arch, not for system or deploy
• Box-and-arrow diagrams
– Back and forth with XML/JSON
14
Natural language
The system has 3 components: C1, C2, and C3.
C1 receives inputs from the user and forwards
them to C2. C1 also receives information from
C2 and displays it to the user.
C2 …
15
XML
<instance:xArch xsi:type=”instance:XArch”>
<types:archStructure xsi:type=”types:ArchStructure”
types:id=”ClientArch”>
<types:description xsi:type=”instance:Description”>
Client Architecture
</types:description>
<types:component xsi:type=”types:Component”
types:id=”WebBrowser”>
<types:description xsi:type=”instance:Description”>
Web Browser
</types:description>
<types:interface xsi:type=”types:Interface”
types:id=”WebBrowserInterface”>
<types:description xsi:type=”instance:Description”>
Web Browser Interface
</types:description>
<types:direction xsi:type=”instance:Direction”>
inout
</types:direction>
</types:interface>
</types:component>
</types:archStructure>
</instance:xArch>
16
JSON
xArch{
archStructure{
id = “ClientArch”
description = “Client Architecture”
component{
id = “WebBrowser”
description = “Web Browser”
interface{
id = “WebBrowserInterface”
description = “Web Browser Interface”
direction = “inout”
}
}
}
}
17
Screenshots
Fast, 12pts
Static, 1pt
Slow, 70pts
18
Box and Arrow
• The most appropriate most of the time
• UML
• Other standard diagrams
Display
Logic
State
19
UML
• Structure
– Class diagram
– Component diagram
• Behavior
– State machine
– Flowchart/Activity
diagram
• Interaction
– Communication diagram
– Sequence diagram
20
Other standard diagrams
• Control flow graph
• Data flow diagram
• Swimming lane diagram
21
Your own diagrams
•
•
•
•
Use the same symbol for the same things
Use standard symbols and representations
Don’t use the same symbol for different things
Add a legend if needed
Client 1
Client 2
Send position
Has a 2-way connection
server
22
Tools for diagrams
• Dia https://wiki.gnome.org/Apps/Dia
– Not just UML
•
•
•
•
•
ArgoUML http://argouml.tigris.org/
Eclipse UML plugins
Visio, PowerPoint
Gliffy, Lucidchart, online tools
Paint (please don’t …)
23
EXAMPLE: SOCKET NETWORKING IN
THE LINUX KERNEL
24
Swimming lane diagram
http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html
25
http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html
26
Flowchart
http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html
27
Data flow diagram
http://wiki.openwrt.org/doc/networking/praxis
28
29
30
VIVOX: VOIP FOR SECOND LIFE
31
High-level diagram
Why is Vivox a separate server process?
32
Separation of concerns!
Still working 
Still working.
But chat is down.
Down!
Chat is down 
33
Sequence diagram without Vivox
http://bowling-bash.blogspot.com/2010/03/vivox-integration.html
34
Sequence diagram with Vivox
Client-side
Server-side
http://bowling-bash.blogspot.com/2010/03/vivox-integration.html
35
Client-side protocol
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-server-and-protocols.html 36
Class diagram (sort of)
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html
37
Component diagram
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html
38
Communication diagram
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html
39
40