Visualizing Software Architectures PDF

Visualizing Software Architectures Software Architecture Lecture 11 Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Architecture: Foundations, Theory, an...

Visualizing Software Architectures Software Architecture Lecture 11 Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Architecture: Foundations, Theory, and Practice Objectives  Concepts  What is visualization?  Differences between modeling and visualization  What kinds of visualizations do we use?  Visualizations and views  How can we characterize and evaluate visualizations?  Examples  Concrete examples of a diverse array of visualizations  Constructing visualizations  Guidelines for constructing new visualizations  Pitfalls to avoid when constructing new visualizations  Coordinating visualizations 2 Software Architecture: Foundations, Theory, and Practice Objectives  Concepts  What is visualization?  Differences between modeling and visualization  What kinds of visualizations do we use?  Visualizations and views  How can we characterize and evaluate visualizations?  Examples  Concrete examples of a diverse array of visualizations  Constructing visualizations  Guidelines for constructing new visualizations  Pitfalls to avoid when constructing new visualizations  Coordinating visualizations 3 Software Architecture: Foundations, Theory, and Practice What is Architectural Visualization?  Recall that we have characterized architecture as the set of principal design decisions made about a system  Recall also that models are artifacts that capture some or all of the design decisions that comprise an architecture  An architectural visualization defines how architectural models are depicted, and how stakeholders interact with those depictions  Two key aspects here:  Depiction is a picture or other visual representation of design decisions  Interaction mechanisms allow stakeholders to interact with design decisions in terms of the depiction 4 Software Architecture: Foundations, Theory, and Practice Models vs. Visualizations  It is easy to confuse models and visualizations because they are very closely related  In the previous lectures, we have not drawn out this distinction, but now we make it explicit  A model is just abstract information – a set of design decisions  Visualizations give those design decisions form: they let us depict those design decisions and interact with them in different ways  Because of the interaction aspect, visualizations are often active – they are both pictures AND tools 5  Software Architecture: Foundations, Theory, and Practice Models vs. Visualizations XML-based visualization DD DD C1 Model DD DD C2 DD Box-and-arrow Our first decision is visualization that the system will have two components, C1 and C2... Natural language visualization 6 Software Architecture: Foundations, Theory, and Practice Canonical Visualizations  Each modeling notation is associated with one or more canonical visualizations  This makes it easy to think of a notation and a visualization as the same thing, even though they are not  Some notations are canonically textual  Natural language, XML-based ADLs  …or graphical  PowerPoint-style  …or a little of both  UML  …or have multiple canonical visualizations  Darwin 7 Software Architecture: Foundations, Theory, and Practice Another Way to Think About It  We may ask “isn’t the canonical visualization the same as the notation since that is how the information is fundamentally organized?”  Perhaps, but consider a piece of software that edits an architectural model decision is Our first that the system will C1 Our first decision is that the system will have two components, C1 and C2... C2 8 Software Architecture: Foundations, Theory, and Practice Different Relationships Viz Model One (canonical) visualization (common) Viz Model Model Viz Viz Viz Model Model Many visualizations for one One visualization bringing together model (common) many models (uncommon) 9 Software Architecture: Foundations, Theory, and Practice Kinds of Visualizations: 1. Textual Visualizations  Depict architectures through ordinary text files  Generally conform to some syntactic format, like programs conform to a language  May be natural language, in which case the format is defined by the spelling and grammar rules of the language  Decorative options  Fonts, colors, bold/italics  Tables, bulleted lists/outlines 10 Software Architecture: Foundations, Theory, and Practice … Textual Visualizations Client Architecture Web Browser Web Browser Interface inout 11 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice … Textual Visualizations XML visualization Client Architecture Web Browser archStructure{ Web Browser Interface id = “ClientArch” description = “Client Architecture” component{ inout id = “WebBrowser” description = “Web Browser” interface{ id = “WebBrowserInterface” description = “Web Browser Interface” direction = “inout” } } Compact visualization } } 12 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice … Textual Visualizations (Interaction)  Generally through an ordinary text editor or word processor  Some advanced mechanisms available  Syntax highlighting: one strategy to improve the readability and context of the text; especially for code that spans several pages.  Static checking: the bug is found automatically before the program even runs.  Autocomplete: a feature in which an application predicts the rest of a word a user is typing.  Structural folding: the network property of a cohesive group whose membership overlaps with that of another cohesive group 13 Software Architecture: Foundations, Theory, and Practice … Textual Visualizations  Advantages  Depict entire architecture in a single file  Good for linear or hierarchical structures  Hundreds of available editors  Substantial tool support if syntax is rigorous (e.g., defined in something like BNF)  Disadvantages  Can be overwhelming  Bad for graphlike organizations of information  Difficult to reorganize information meaningfully  Learning curve for syntax/semantics 14 Software Architecture: Foundations, Theory, and Practice Kinds of Visualizations: 2. Graphical Visualizations  Depict architectures (primarily) as graphical symbols  Boxes, shapes, pictures, clip-art  Lines, arrows, other connectors  Photographic images  Regions, shading  2D or 3D  Generally conform to a symbolic syntax  But may also be ‘free-form’ and stylistic 15 Software Architecture: Foundations, Theory, and Practice … Graphical Visualizations Abstract, stylized visualization 16 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice … Graphical Visualizations Abstract, stylized visualization More rigorous deployment visualization 17 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice … Graphical Visualizations (Interaction)  Generally graphical editors with point-and-click interfaces  Employ metaphors like scrolling, zooming, ‘drill-down’  Editors have varying levels of awareness for different target notations  For example, you can develop UML models in PowerPoint (or Photoshop), but the tools won’t help much  More exotic editors and interaction mechanisms exist in research  3D editors  “Sketching-based” editors 18 Software Architecture: Foundations, Theory, and Practice … Graphical Visualizations  Advantages  Symbols, colors, and visual decorations more easily parsed by humans than structured text  Handle non-hierarchical relationships well  Diverse spatial interaction metaphors (scrolling, zooming) allow intuitive navigation  Disadvantages  Cost of building and maintaining tool support  Difficult to incorporate new semantics into existing tools  Do not scale as well as text to very large models 19 Software Architecture: Foundations, Theory, and Practice 3. Hybrid Visualizations  Many visualizations are text-only  Few graphical notations are purely symbolic  Text labels, at a minimum  Annotations are generally textual as well  Some notations incorporate substantial parts that are mostly graphical alongside substantial parts that are mostly or wholly textual 20 Software Architecture: Foundations, Theory, and Practice … Hybrid Visualizations context UserInterface inv: new_burn_rate >= 0 Primarily graphical Architectural constraints UML class diagram expressed in OCL 21 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Views, Viewpoints, & Visualizations  Recall that a view is a subset of the design decisions in an architecture  And a viewpoint is the perspective from which a view is taken (i.e., the filter that selects the subset)  Visualizations are associated with viewpoints 22 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Effect Visualizations  Not all visualizations used in architecture-centric development depict design decisions directly  Some depict the results or effects of design decisions  We call these ‘effect visualizations’  May be textual, graphical, hybrid, etc. 23 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Evaluating Visualizations  Scope and Purpose  What is the visualization for? What can it visualize?  Basic Type  Textual? Graphical? Hybrid? Effect?  Depiction  What depiction mechanisms and metaphors are primarily employed by the visualization?  Interaction  What interaction mechanisms and metaphors are primarily employed by the visualization? 24 Software Architecture: Foundations, Theory, and Practice … Evaluating Visualizations  Fidelity  How well/completely does the visualization reflect the information in the underlying model?  Consistency should be a minimum requirement, but details are often left out  Consistency  How well does the visualization use similar representations for similar concepts?  Comprehensibility  How easy is it for stakeholders to understand and use a visualization  Note: this is a function of both the visualization and the stakeholders 25 Software Architecture: Foundations, Theory, and Practice … Evaluating Visualizations  Dynamism  How well does the visualization support models that change over time (dynamic models)?  View Coordination  How well the visualization is connected to and kept consistent with other visualizations  Aesthetics  How pleasing is the visualization (look and feel) to its users?  A very subjective judgment  Extensibility  How easy is it to add new capabilities to a visualization? 26 Software Architecture: Foundations, Theory, and Practice Objectives  Concepts  What is visualization?  Differences between modeling and visualization  What kinds of visualizations do we use?  Visualizations and views  How can we characterize and evaluate visualizations?  Examples  Concrete examples of a diverse array of visualizations  Constructing visualizations  Guidelines for constructing new visualizations  Pitfalls to avoid when constructing new visualizations  Coordinating visualizations 27 Software Architecture: Foundations, Theory, and Practice Text Visualizations  Text visualizations are generally provided through text editors  Examples:  Simple: Windows Notepad, SimpleText, pico, joe  For experts: vi, emacs  With underlying language support: Eclipse, UltraEdit, many HTML editors  Free-form text documents: Microsoft Word, other word processors 28 Software Architecture: Foundations, Theory, and Practice … Text Visualizations  Advantages  Provide a uniform way of working with many different underlying notations  Wide range of editors available to suit any need  Many incorporate advanced ‘content assist’ capabilities  Many text editors can be extended to handle new languages or integrate new tools easily  Disadvantages  Increasing complexity as models get bigger  Do not handle graph structures and complex interrlationships well 29 Software Architecture: Foundations, Theory, and Practice Advanced Interaction Mechanisms 30 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Text Visualizations: Evaluation  Scope/Purpose  Consistency  Visualizing design decisions  Generally good; depends on or effects as (structured) underlying notation text  Comprehensibility  Basic Type  Drops with increasing  Textual complexity  Depiction  Dynamism  Ordered lines of characters  Rare, but depends on editor possibly grouped into tokens  View coordination  Interaction  Depends on editor  Basic: insert, delete, copy,  Aesthetics paste  Varies; can be overwhelming or  Advanced: coloring, code elegant and structured folding, etc.  Extensibility  Fidelity  Many extensible editors  Generally canonical 31 Software Architecture: Foundations, Theory, and Practice General Graphical Visualizations  E.g., PowerPoint, OmniGraffle, etc.  Provide point-and-click manipulation of graphical symbols, interconnections, and text blocks  Advantages  Friendly UI can create nice-looking depictions  Nothing hidden; no information difference between model and depiction  Disadvantages  No underlying semantics; difficult to add them  Visio is a partial exception  This means that interaction mechanisms can offer minimal support  Difficult to connect to other visualizations 32 Software Architecture: Foundations, Theory, and Practice General Graphical Example 33 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice General Graphical: Evaluation  Scope/Purpose  Consistency  Visualizing design decisions  Manual as symbolic pictures  Comprehensibility  Basic Type  Depends on skill of the  Graphical modeler and use of  Depiction consistent symbols/patterns  (Possibly) interconnected  Dynamism symbols on a finite canvas  Some animation capabilities  Interaction  View coordination  Point and click, drag-and-  Difficult at best drop direct interactions with  Aesthetics symbols, augmented by  Modeler’s responsibility menus and dialogs  Extensibility  Fidelity  Adding new symbols is easy,  Generally canonical adding semantics is harder34 Software Architecture: Foundations, Theory, and Practice Objectives  Concepts  What is visualization?  Differences between modeling and visualization  What kinds of visualizations do we use?  Visualizations and views  How can we characterize and evaluate visualizations?  Examples  Concrete examples of a diverse array of visualizations  Constructing visualizations  Guidelines for constructing new visualizations  Pitfalls to avoid when constructing new visualizations  Coordinating visualizations 35 Software Architecture: Foundations, Theory, and Practice UML Visualizations  Canonical graphical depictions + tool-specific interactions  XMI: Textual depiction in XML + text-editor interactions  Advantages  Canonical graphical depiction common across tools  Graphical visualizations have similar UI metaphors to PowerPoint-style editors, but with UML semantics  XMI projection provides textual alternative  Disadvantages  No standard for interaction as there is for depiction  In some tools hard to tell where UML model ends and auxiliary models begin  Most UML visualizations are restricted to (slight variants) of the canonical UML depiction 36 Software Architecture: Foundations, Theory, and Practice UML Visualization 37 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice 38... Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice UML Visualizations: Evaluation  Scope/Purpose  Consistency  Visualization of UML models  Generally good across  Basic Type diagrams; small exceptions  Graphical (diagrams), textual  Comprehensibility (XMI)  Ubiquity assists interpretations  Depiction  Dynamism  Diagrams in UML symbolic  Rare vocabulary/XML-formatted  View coordination text  Some editors better than  Interaction others  Depends on the editor;  Aesthetics generally point-and-click for  Simple symbols reduce diagrams; text editor for XMI complexity; uniform diagrams  Fidelity  Extensibility  Diagrams are canonical, XMI  Profile support OK; major elides layout info language extensions hard 39 Software Architecture: Foundations, Theory, and Practice Rapidé  Rapidé models are generally written with a canonical textual visualization  Some graphical builders available as well  Focus: Interesting effect visualization of simulation results  Advantages  Provides an intuitive way to visualize the causal relationships between events  Automatically generated from Rapide specifications  Disadvantages  Complex applications generate complex graphs  Difficult to identify why particular causal relationships exist  Simulation is not interactive 40 Software Architecture: Foundations, Theory, and Practice Rapidé Examples type DataStore is interface action in SetValues(); out NotifyNewValues(); behavior begin SetValues => NotifyNewValues();; end DataStore; type Calculation is interface action in SetBurnRate(); out DoSetValues(); behavior action CalcNewState(); begin SetBurnRate => CalcNewState(); DoSetValues();; end Calculation; type Player is interface action out DoSetBurnRate(); in NotifyNewValues(); behavior TurnsRemaining : var integer := 1; action UpdateStatusDisplay(); action Done(); 41 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Rapidé Effect Visualization: Evaluation Comprehensibility   Easy to see causal  Scope/Purpose relationships but difficult to  Graphical event traces understand why they’re there  Basic Type  Dynamism  Graphical  No support  Depiction  View coordination  Directed acyclic graph of  Event traces are generated events automatically from  Interaction architectural models  Aesthetics  No substantial interaction with generated event traces  Simple unadorned directed  Fidelity acyclic graph of nodes and edges  Each trace is an instance;  Extensibility different simulation runs may produce different traces in a  Tool set is effectively a ‘black non-deterministic system box”  Consistency  Tiny symbol vocabulary ensures consistency 42 Software Architecture: Foundations, Theory, and Practice Labeled Transition State Analyzer (LTSA)  A tool for analyzing and simultaneously visualizing concurrent systems’ behavior using a modeling language called FSP  Advantages  Provides multiple concurrent visualizations of concurrent behavior  Integrates both model and effect visualizations, textual and graphical depictions  Can develop domain-specific visualizations to understand abstract models  Disadvantages  Behavior specification language has somewhat steep learning curve  Developing domain-specific graphical visualizations can be expensive 43 Software Architecture: Foundations, Theory, and Practice LTSA Examples 44 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice LTSA Examples 45 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice LTSA: Evaluation  Scope/Purpose  Comprehensibility  Multiple coordinated  FSP has some learning curve; visualizations of concurrent domain-specific effect systems’ behavior visualizations are innovative  Basic Type  Dynamism  Textual, Graphical, Effect  Animation on state-transition  Depiction diagrams and domain-specific  Text & state machines for visualizations models, various effect viz.  View coordination  Interaction  Views are coordinated automatically  FSP can be edited textually or graphically  Aesthetics  Fidelity  State transition diagrams are traditional; domain-specific  Graphical visualizations may visualizations can enhance elide some information aesthetics  Consistency  Extensibility  Limited vocabulary helps  New domain-specific effect ensure consistency visualizations as plug-ins 46 Software Architecture: Foundations, Theory, and Practice xADL Visualizations  Coordinated set of textual, graphical, and effect visualizations for an extensible ADL  Advantages  Provides an example of how to construct a wide variety of (often) coordinated or interrelated visualizations  Lets users move fluidly from one visualization to another  Guidance available for extending visualizations or adding new ones  Disadvantages  Some learning curve to extend graphical editors  Adding or extending visualizations has to be done carefully so they play well with existing ones 47 Software Architecture: Foundations, Theory, and Practice xADL Visualization Examples MyComponent Interface1 inout 48 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice xADL Visualization Examples MyComponent component{ id = "myComp"; interface{ Interface1 id = "iface1"; description = "Interface1"; direction = "inout"; inout } } 49 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice xADL Visualization Examples MyComponent component{ id = "myComp"; interface{ Interface1 id = "iface1"; description = "Interface1"; direction = "inout"; inout } } 50 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice xADL Visualization Examples MyComponent component{ id = "myComp"; interface{ Interface1 id = "iface1"; description = "Interface1"; direction = "inout"; inout } } 51 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice xADL Visualization Examples MyComponent component{ id = "myComp"; interface{ Interface1 id = "iface1"; description = "Interface1"; direction = "inout"; inout } } 52 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice xADL Visualizations: Evaluation  Scope/Purpose  Comprehensibility  Multiple coordinated  Varies; some easier than visualizations of xADL others models  Dynamism  Basic Type  Animation on state-transition  Textual, Graphical, Effect diagrams and domain-specific  Depiction visualizations  XML, abbreviated XML,  View coordination symbol graphs, hybrid effect  Many views coordinated ‘live,’ (MTAT) MTAT leverages some  Interaction animation  Visualizations emulate  Aesthetics various editing paradigms  Varies; Archipelago promotes  Fidelity aesthetic improvements by allowing fine customization  Textual & ArchEdit complete;  Extensibility graphical leave detail out  Consistency  Many extensibility mechanisms at different levels  Effort to follow conventions 53 Software Architecture: Foundations, Theory, and Practice Objectives  Concepts  What is visualization?  Differences between modeling and visualization  What kinds of visualizations do we use?  Visualizations and views  How can we characterize and evaluate visualizations?  Examples  Concrete examples of a diverse array of visualizations  Constructing visualizations  Guidelines for constructing new visualizations  Pitfalls to avoid when constructing new visualizations  Coordinating visualizations 54 Software Architecture: Foundations, Theory, and Practice Constructing New Visualizations  Developing a new visualization can be expensive both in initial development and maintenance  Must answer many questions in advance  Can I achieve my goals by extending an existing visualization?  Can I translate into another notation and use a visualization already available there?  How will my visualization augment the existing set of visualizations for this notation?  How will my visualization coordinate with other visualizations?  (Plus all the evaluation categories we’ve been exploring) 55 Software Architecture: Foundations, Theory, and Practice New Visualizations: Guidelines  Borrow elements from similar visualizations  Leverages existing stakeholder knowledge  Improves comprehensibility  Be consistent among visualizations  Don’t conflict with existing visualizations without a good reason (e.g., developing a domain-specific visualization where the concepts and metaphors are completely different)  Give meaning to each visual aspect of elements  Parsimony is more important than aesthetics  Corollary: avoid having non-explicit meaning encoded in visualizations 56 Software Architecture: Foundations, Theory, and Practice New Visualizations: Guidelines (cont’d)  Document the meaning of visualizations  Visualizations are rarely self-explanatory  Focus on mapping between model and visualization  Balance traditional and innovative interfaces  Stakeholders bring a lot of interaction experience to the table  But just because a mechanism is popular doesn’t mean it’s ideal 57 Software Architecture: Foundations, Theory, and Practice New Visualizations: Anti- Guidelines  Same Symbol, Different Meaning 58 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice New Visualizations: Anti- Guidelines (cont’d)  Differences without meaning 59 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice New Visualizations: Anti- Guidelines (cont’d)  Decorations without meaning 60 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice New Visualizations: Anti- Guidelines (cont’d)  Borrowed symbol, different meaning 61 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Coordinating Multiple Visualizations  How do we keep multiple simultaneous visualizations of the same (part of the) architectural model consistent with each other and the model?  This is NOT the same as maintaining architectural consistency  If something is wrong with the model, this error would be reflected in the visualizations  Can be made much easier by making simplifying assumptions, e.g.:  Only one visualization may operate at a time  Only one tool can operate on the model at a time  But what if we can’t simplify like this? 62 Software Architecture: Foundations, Theory, and Practice Strategy: Peer-to-Peer Coordination  Each visualization communicates with each other visualization for updates  Has scaling problems  Works best for visualizations known a priori 63 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Strategy: Master-Slave  One visualization is the master and others coordinate through it  Works best when visualizations are subordinate  E.g., a “thumbnail” or “overview” next to a main, zoomed-in visualization 64 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Strategy: Pull-based  Visualizations repeatedly poll a model repository for changes  Potential consistency/staleness problems  May be necessary if model repository is entirely passive  May save computing power 65 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Strategy: Push-based  Visualizations actively notified and update themselves whenever model changes for any reason  Best for multiple simultaneous visualizations  Hard to debug, must avoid infinite loops and subtle concurrency conditions 66 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission. Software Architecture: Foundations, Theory, and Practice Caveats  Like the modeling lectures, this optimized for breadth rather than depth  You are encouraged to explore these in depth, as well as visualizations you encounter in your own experiences  Although we can attempt to conceptually separate modeling notations and visualizations, they are never truly distinct  Each influences the other in direct and indirect ways 67