Argo: A Tool for Evolving Software Architectures

1. Argo: A Tool for Evolving Software Architectures Jason E. RobbinsDavid M. HilbertDavid F. Redmiles Information and Computer Science Dept. University of California at Irvine

2. Overview • Quick Tour of Argo • Motivation • Underlying Theories • Demo of Argo Features and Why They are Useful • Argo’s Architecture • Related Work • Conclusions • Availability

3. Quick Tour of Argo • Direct manipulation editor for C2 style software architectures • Critics continuously analyze architecture • To Do List presents feedback without interrupting the architect • Simple process model used as a resource • Perspectives divide complexity of design

4. Motivation • Design is a cognitively challenging task • Design knowledge is diverse, heuristic, tacit • Design decisions are interdependent, and made over extended periods of time • Software systems are difficult to understand and communicate to others • Software architecture as the “Big Picture”

5. Underlying Theories of Designers’ Cognitive Needs • We have tried to identify what makes design challenging for people • Design feedback: Reflection-in-Action [Schoen] • Design process support: Opportunistic Design [Guindon] • Design perspectives: Comprehension and Problem Solving [Kintsch] • We have specialized and applied these theories to software architecture

6. Design Feedback — Reflection-in-Acton • Observation: Designers work through the design • Designers rarely produce a design fully formed • Incrementally frame a partial design; evaluate it; revise • Suggested requirements on design environments • Support the designer in framing a partial solution • Support the designer in evaluating it • Integrate manipulation and analysis • Support in Argo: Editors, Critics, To Do List

7. Design Process Support - Opportunistic Design • Observation: Designers deviate from prespecified processes • Emerging issues change the design process • Cognitive costs explain some task reorderings • Suggested requirements on design environments • Provide process models as resources • Use process models to keep design feedback timely • Support in Argo: First-class process model, To Do List

8. Design Perspectives — Comprehension and Problem Solving • Observation: Designers use multiple mental models • Work through successive levels of refinement • Restructure their thinking to address different issues • Suggested requirements on design environments • Present multiple perspectives to match mental models • Help maintain mappings between mental models • Support in Argo: Multiple coordinated design perspectives, customizable visualizations

9. Argo’s Own Architecture

10. Related Work • Software architecture tools • Aesop, DaTE • Design environments • Janus, Framer, VDDE • Process models • Endeavors, OZ, IDEF-0 • Visualization with multiple perspectives • OBPE, Explainer, 4+1 Views

11. Conclusions • Design tools should support designer’s cognitive needs • We have examined three theories of cognitive needs and prototyped features that support them • We have implemented a domain-independent design environment infrastructure that can be applied to multiple domains

12. Availability • Informal demo’s at the UCI booth at ICSE • Argo + ArchShell: Direct Manipulation Dynamic Architecture • http://www.ics.uci.edu/pub/arch • On-line demo of Argo • Java source code and documentation • GEF, Argo’s visualization framework