Presentation is loading. Please wait.

Presentation is loading. Please wait.

Visualizing Architectures INF 123 – Software architecture 1.

Similar presentations


Presentation on theme: "Visualizing Architectures INF 123 – Software architecture 1."— Presentation transcript:

1 Visualizing Architectures INF 123 – Software architecture tdebeauv@uci.edu 1

2 Outline Some theory The tools Examples – Socket networking in the Linux kernel – Vivox: VOIP for Second Life 2

3 SOME THEORY 3

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 4

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 5

6 Architectural Model 6 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 7

8 Example: level of detail (few details) 8

9 More details 9

10 Inconsistent models Models contradicting each other 10

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 11

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 12

13 TOOLS 13

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 14

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 … 15

16 XML 16 <types:archStructure xsi:type=”types:ArchStructure” types:id=”ClientArch”> Client Architecture <types:component xsi:type=”types:Component” types:id=”WebBrowser”> Web Browser <types:interface xsi:type=”types:Interface” types:id=”WebBrowserInterface”> Web Browser Interface inout <types:archStructure xsi:type=”types:ArchStructure” types:id=”ClientArch”> Client Architecture <types:component xsi:type=”types:Component” types:id=”WebBrowser”> Web Browser <types:interface xsi:type=”types:Interface” types:id=”WebBrowserInterface”> Web Browser Interface inout

17 JSON 17 xArch{ 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 18 Static, 1pt Slow, 70pts Fast, 12pts

19 Box and Arrow The most appropriate most of the time UML Other standard diagrams 19 Logic State Display

20 UML Structure – Class diagram – Component diagram Interaction – Communication diagram – Sequence diagram Behavior – State machine – Flowchart/Activity diagram 20

21 Other standard diagrams Control flow graph Data flow diagram Swimming lane diagram 21

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 22 Client 1Client 2 Send position Has a 2-way connection server

23 Tools for diagrams Dia https://wiki.gnome.org/Apps/Diahttps://wiki.gnome.org/Apps/Dia – Not just UML ArgoUML http://argouml.tigris.org/http://argouml.tigris.org/ Eclipse UML plugins Visio, PowerPoint Gliffy, Lucidchart, online tools Paint (please don’t …) 23

24 EXAMPLE: SOCKET NETWORKING IN THE LINUX KERNEL 24

25 Swimming lane diagram 25 http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html

26 26 http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html

27 Flowchart 27 http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html

28 Data flow diagram 28 http://wiki.openwrt.org/doc/networking/praxis

29 29

30 30

31 VIVOX: VOIP FOR SECOND LIFE 31

32 High-level diagram 32 Why is Vivox a separate server process?

33 Separation of concerns! 33 Down! Still working. But chat is down. Still working Chat is down 

34 Sequence diagram without Vivox 34 http://bowling-bash.blogspot.com/2010/03/vivox-integration.html

35 Sequence diagram with Vivox 35 Client-side Server-side http://bowling-bash.blogspot.com/2010/03/vivox-integration.html

36 Client-side protocol 36 http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-server-and-protocols.html

37 Class diagram (sort of) 37 http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html

38 Component diagram 38 http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html

39 Communication diagram 39 http://bowling-bash.blogspot.com/2010/03/vivox-in-sl-client-side-components.html

40 40


Download ppt "Visualizing Architectures INF 123 – Software architecture 1."

Similar presentations


Ads by Google