Embed Size (px)
Citation preview
2
Outline
• Some theory• The tools• Examples– Socket networking in the Linux kernel– Vivox: VOIP for Second Life
3
SOME THEORY
4
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
5
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
6
Architectural Model
Architecture A visualization of the model “protect an entrance”
7
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
8
Example: level of detail (few details)
9
More details
10
Inconsistent models
• Models contradicting each other
11
Reasons for inconsistencies
• Architects with different opinions• Level of detail– High-level view has components absent in a lower-level
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
12
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
13
TOOLS
14
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
15
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 …
16
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>
<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>
17
JSONxArch{ archStructure{ id = “ClientArch” description = “Client Architecture” component{ id = “WebBrowser” description = “Web Browser” interface{ id = “WebBrowserInterface” description = “Web Browser Interface” direction = “inout” } } }}
xArch{ archStructure{ id = “ClientArch” description = “Client Architecture” component{ id = “WebBrowser” description = “Web Browser” interface{ id = “WebBrowserInterface” description = “Web Browser Interface” direction = “inout” } } }}
18
Screenshots
Static, 1pt
Slow, 70pts
Fast, 12pts
19
Box and Arrow
• The most appropriate most of the time
• UML• Other standard diagrams
Logic
State
Display
20
UML
• Structure– Class diagram– Component diagram
• Interaction– Communication diagram– Sequence diagram
• Behavior– State machine– Flowchart/Activity
diagram
21
Other standard diagrams
• Control flow graph• Data flow diagram• Swimming lane diagram
22
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
23
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 …)
24
EXAMPLE: SOCKET NETWORKING IN THE LINUX KERNEL
25
Swimming lane diagram
http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html
26http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html
27
Flowchart
http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html
28
Data flow diagram
http://wiki.openwrt.org/doc/networking/praxis
29
30
31
VIVOX: VOIP FOR SECOND LIFE
32
High-level diagram
Why is Vivox a separate server process?
33
Separation of concerns!
Down!
Still working.But chat is down.Still working
Chat is down
34
Sequence diagram without Vivox
http://bowling-bash.blogspot.com/2010/03/vivox-integration.html
35
Sequence diagram with Vivox
Client-side Server-side
http://bowling-bash.blogspot.com/2010/03/vivox-integration.html
36
Client-side protocol
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-server-and-protocols.html
37
Class diagram (sort of)
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html
38
Component diagram
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html
39
Communication diagram
http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html
40
