ArchJava Connecting Software Architecture to Implementation Jonathan Aldrich Craig Chambers David Notkin University of Washington ICSE ‘02, May 22, 2002.

Slides:



Advertisements
Similar presentations
A Method for Validating Software Security Constraints Filaret Ilas Matt Henry CS 527 Dr. O.J. Pilskalns.
Advertisements

© 2005 by Prentice Hall Chapter 13 Finalizing Design Specifications Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Design by Contract.
Verification and Validation
Alternate Software Development Methodologies
Introduction to Databases
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
Automated creation of verification models for C-programs Yury Yusupov Saint-Petersburg State Polytechnic University The Second Spring Young Researchers.
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
Software Engineering COMP 201
Architecture-driven Modeling and Analysis By David Garlan and Bradley Schmerl Presented by Charita Feldman.
Architectural Reasoning in ArchJava Jonathan Aldrich Craig Chambers David Notkin University of Washington ECOOP ‘02, 13 June 2002.
Alias Annotations for Program Understanding Jonathan Aldrich Valentin Kostadinov Craig Chambers University of Washington.
21-February-2003cse Architecture © 2003 University of Washington1 Architecture CSE 403, Winter 2003 Software Engineering
ArchJava A software architecture tool –components –connections –constraints on how components interact Implementation must conform to architecture.
End-to-End Design of Embedded Real-Time Systems Kang G. Shin Real-Time Computing Laboratory EECS Department The University of Michigan Ann Arbor, MI
An Introduction to Rational Rose Real-Time
Chapter 9 – Software Evolution and Maintenance
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
Impact Analysis of Database Schema Changes Andy Maule, Wolfgang Emmerich and David S. Rosenblum London Software Systems Dept. of Computer Science, University.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
XFindBugs: eXtended FindBugs for AspectJ Haihao Shen, Sai Zhang, Jianjun Zhao, Jianhong Fang, Shiyuan Yao Software Theory and Practice Group (STAP) Shanghai.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Architecture-Based Runtime Software Evolution Peyman Oreizy, Nenad Medvidovic & Richard N. Taylor.
Assessing the Suitability of UML for Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los.
High-Level Design With Sequence Diagrams COMP314 (based on original slides by Mark Hall)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements.
Reviewing Recent ICSE Proceedings For:.  Defining and Continuous Checking of Structural Program Dependencies  Automatic Inference of Structural Changes.
Compiler course 1. Introduction. Outline Scope of the course Disciplines involved in it Abstract view for a compiler Front-end and back-end tasks Modules.
Lecture 3 Software Engineering Models (Cont.)
POSL (Principles of Software Languages) Gr. Kyushu Institute of Technology, Japan Pointcut-based Architectural Interface.
Approaching a Problem Where do we start? How do we proceed?
JCMP: Linking Architecture with Component Building Guoqing Xu, Zongyuan Yang and Haitao Huang Software Engineering Lab, East China Normal University SACT-01,
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Systems Analysis and Design in a Changing World, 3rd Edition
1 OCL Tools Supervised by Prof. Daniel Amyot May Khalil Nadia Spido Submitted to Professor Daniel Amyot in partial fulfillment of the requirements for.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 1 Chapter 13 Finalizing Design Specifications.
1 An Aspect-Oriented Implementation Method Sérgio Soares CIn – UFPE Orientador: Paulo Borba.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Introduction to Compilers. Related Area Programming languages Machine architecture Language theory Algorithms Data structures Operating systems Software.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Software Prototyping Rapid software development to validate requirements.
Requirements Validation
Wrapper-Based Evolution of Legacy Information System Philippe Thiran et al Fcculties University Notre-Dame de la Paix.
Modeling Highly Dynamic Software Architectures
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Chapter 13 Finalizing Design Specifications
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
Software Engineering Lecture 8: Quality Assurance.
T Project Review MalliPerhe Iteration 3 Implementation
Architectural Mismatch: Why reuse is so hard? Garlan, Allen, Ockerbloom; 1994.
Software Design and Development Development Methodoligies Computing Science.
The Structuring of Systems Using Upcalls By David D. Clark Presented by Samuel Moffatt.
1 Process activities. 2 Software specification Software design and implementation Software validation Software evolution.
LECTURE 10 Semantic Analysis. REVIEW So far, we’ve covered the following: Compilation methods: compilation vs. interpretation. The overall compilation.
Testing Tools & Standards
Advanced Programing practices
Chapter 18 Maintaining Information Systems
Software Processes.
Logical architecture refinement
Analysis models and design models
Advanced Programing practices
Chapter 13 Finalizing Design Specifications
Chapter 8 Software Evolution.
Architectural Mismatch: Why reuse is so hard?
Presentation transcript:

ArchJava Connecting Software Architecture to Implementation Jonathan Aldrich Craig Chambers David Notkin University of Washington ICSE ‘02, May 22, 2002

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava2 Software Architecture High-level system structure –Components and connections Automated analysis Support program evolution –Source of defect –Effect of change –Invariants to preserve

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava3 Architecture and Implementation Inconsistency caused by evolution –Architecture documentation becomes obsolete Problems –Suprises –Misunderstandings lead to defects –Untrusted architecture won’t be used

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava4 Architecture and Implementation Does code conform to architecture? Communication integrity [LV95,MQR95] –All communication is documented Interfaces and connectivity –Enables effective architectural reasoning Quickly learn how components fit together Local information is sufficient

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava5 Architectural Approaches: Checking vs. Flexibility Partial Dynamic Static General PurposeRestricted Language Communication Integrity None Flexibility Note: only two dimensions of the design space

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava6 Architectural Approaches: Checking vs. Flexibility Partial Dynamic Static Knit, A COEL, ML, Rose RealTime General PurposeRestricted Language Rapide Communication Integrity None SDL Wright, SADL Flexibility

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava7 Architectural Approaches: Checking vs. Flexibility Partial Dynamic Static Knit, A COEL, ML, Rose RealTime General PurposeRestricted Language Rapide Communication Integrity None SDL Wright, SADL Flexibility ArchJava

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava8 ArchJava Approach: add architecture to language –Control-flow communication integrity Enforced by type system –Architecture updated as code evolves –Flexible Dynamically changing architectures Common implementation techniques Case study: is it practical and useful?

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava9 A Parser Component public component class Parser { Component class Defines architectural object Must obey architectural constraints

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava10 A Parser Component public component class Parser { public port in { requires Token nextToken(); } public port out { provides AST parse(); } Components communicate through Ports A two-way interface Define provided and required methods

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava11 A Parser Component public component class Parser { public port in { requires Token nextToken(); } public port out { provides AST parse(); } Ordinary (non-component) objects Passed between components Sharing is permitted Can use just as in Java

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava12 A Parser Component public component class Parser { public port in { requires Token nextToken(); } public port out { provides AST parse(); } AST parse() { Token tok=in.nextToken(); return parseExpr(tok); } AST parseExpr(Token tok) {... }... } Can fill in architecture with ordinary Java code

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava13 Hierarchical Composition public component class Compiler { private final Scanner scanner = new Scanner(); private final Parser parser = new Parser(); private final CodeGen codegen = new CodeGen(); Subcomponents –Component instances inside another component –Communicate through connected ports

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava14 Hierarchical Composition public component class Compiler { private final Scanner scanner = new Scanner(); private final Parser parser = new Parser(); private final CodeGen codegen = new CodeGen(); connect scanner.out, parser.in; connect parser.out, codegen.in; Connections –Bind required methods to provided methods

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava15 Evaluation Questions Does ArchJava guarantee communication integrity? Is ArchJava expressive enough for real systems? Can ArchJava aid software evolution tasks?

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava16 A component may only communicate with the components it is connected to in the architecture ArchJava enforces integrity for control flow No method calls permitted from one component to another except –From a parent to its nested subcomponents –Through connections in the architecture Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava17 A component may only communicate with the components it is connected to in the architecture ArchJava enforces integrity for control flow No method calls permitted from one component to another except –From a parent to its immediate subcomponents –Through connections in the architecture Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava18 A component may only communicate with the components it is connected to in the architecture ArchJava enforces integrity for control flow Other communication paths –Shared data (current work) –Run-time system Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava19 Architecture allows –Calls between connected components Control Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava20 Architecture allows –Calls between connected components –Calls from a parent to its immediate subcomponents Control Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava21 Architecture allows –Calls between connected components –Calls from a parent to its immediate subcomponents –Calls to shared objects Control Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava22 Architecture allows –Calls between connected components –Calls from a parent to its immediate subcomponents –Calls to shared objects Architecture forbids –External calls to subcomponents Control Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava23 Architecture allows –Calls between connected components –Calls from a parent to its immediate subcomponents –Calls to shared objects Architecture forbids –External calls to subcomponents –Calls between unconnected subcomponents Control Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava24 Architecture allows –Calls between connected components –Calls from a parent to its immediate subcomponents –Calls to shared objects Architecture forbids –External calls to subcomponents –Calls between unconnected subcomponents –Calls through shared objects Control Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava25 Architecture allows –Calls between connected components –Calls from a parent to its immediate subcomponents –Calls to shared objects Architecture forbids –External calls to subcomponents –Calls between unconnected subcomponents –Calls through shared objects Benefit: local reasoning about control flow Control Communication Integrity

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava26 Enforcing Control-flow Integrity Type system invariant –Components can only get a typed reference to subcomponents and connected components –Prohibits illegal calls Informal description in ICSE paper –Formalization and proof to appear in ECOOP ‘02

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava27 Evaluation Questions Does ArchJava guarantee control communication integrity? –Yes, using the type system Is ArchJava expressive enough for real systems? Can ArchJava aid software evolution tasks? Two case studies –12,000 lines of Java code each –Asked developer to draw architecture –Tried to specify architecture in ArchJava

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava28 Evaluation Questions Does ArchJava guarantee control communication integrity? –Yes, using the type system Is ArchJava expressive enough for real systems? Can ArchJava aid software evolution tasks? Case study: Aphyds –12,000 lines of Java code –Tried to specify architecture in ArchJava Original developer drew architecture

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava29 Aphyds Architecture UI above –Main window –3 secondary windows Circuit DB below –Central DB –5 comp. Modules Arrows –Data & control flow

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava30 Aphyds Architecture Informal drawing –Common in practice Leaves out details –What’s inside the components, connections? –CircuitViewer has internal structure Some surprises –Missing paths –Component lifetimes Hypothesis: Developers have a conceptual model of their architecture that is mostly accurate, but this model may be a simplification of reality, and it is often not explicit in the code.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava31 Aphyds Architecture Informal drawing –Common in practice Leaves out details –What’s inside the components, connections? –CircuitViewer has internal structure Some surprises –Missing paths –Component lifetimes Hypothesis: Developers have a conceptual model of their architecture that is mostly accurate, but this model may be a simplification of reality, and it is often not explicit in the code.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava32 Architectural Comparison Automatically Generated Architectural Visualization

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava33 Advantages of ArchJava Complete –Can “zoom in” on details Consistency checking –Original architecture had minor flaws Evolves with program Low cost –30 hours, or 2.5 hours/KLOC –Includes substantial refactoring –12.1 KLOC => 12.6 KLOC Hypothesis: Applications can be translated into ArchJava with a reasonable amount of effort, and without excessive code bloat.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava34 Advantages of ArchJava Complete –Can “zoom in” on details Consistency checking –Original architecture had minor flaws Evolves with program Low cost –30 hours, or 2.5 hours/KLOC –Includes substantial refactoring –12.1 KLOC => 12.6 KLOC Hypothesis: Applications can be translated into ArchJava without excessive effort or code bloat.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava35 Evaluation Questions Does ArchJava guarantee control communication integrity? –Yes Is ArchJava expressive enough for real systems? –Yes (validated by 2 other case studies) Three experiments –Understanding Aphyds communication –Refactoring Aphdys –Reparing a defect

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava36 Evaluation Questions Does ArchJava guarantee control communication integrity? –Yes Is ArchJava expressive enough for real systems? –Yes (validated by 2 other case studies) Can ArchJava aid software evolution tasks? Three experiments –Understanding Aphyds communication –Reengineering Aphyds’ architecture –Repairing a defect

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava37 Program Understanding Communication between the main structures is awkward, especially the change propagation messages – Aphyds developer, initial interview Communication analysis aided by ArchJava –Ports group related methods provided and required interfaces –Connections show relationships Discovered refactoring opportunities Hypothesis: Expressing software architecture in ArchJava highlights refactoring opportunities by making communication protocols explicit.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava38 Program Understanding Communication between the main structures is awkward, especially the change propagation messages – Aphyds developer, initial interview Communication analysis aided by ArchJava –Ports group related methods provided and required interfaces –Connections show relationships Discovered refactoring opportunities Hypothesis: Expressing software architecture in ArchJava highlights refactoring opportunities by making communication protocols explicit.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava39 Reengineering Aphyds getDisplayer().getViewer().ChannelRouterMenuItem.setEnabled(b); Highly coupled code –Depends on every link in chain –Programs are fragile, change is difficult Law of Demeter [Lieberherr et al.] –Design guideline –“Only talk with your neighbors” RouterDialogCircuitDisplayerCircuitViewerMenuItem

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava40 Reengineering Aphyds getDisplayer().getViewer().ChannelRouterMenuItem.setEnabled(b); Control communication integrity –Components only talk with connected components Compile-time error in ArchJava –RouterDialog can only reference local connections –Instead, call a method through a new port Hypothesis: Enforcing communication integrity helps to reduce system coupling CircuitViewer MenuItem RouterDialog CircuitDisplayer

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava41 Reengineering Aphyds getDisplayer().getViewer().ChannelRouterMenuItem.setEnabled(b); Control communication integrity –Components only talk with connected components Compile-time error in ArchJava –RouterDialog can only reference local connections –Call through architecture, reducing coupling Hypothesis: Enforcing communication integrity helps to reduce system coupling CircuitViewer MenuItem RouterDialog CircuitDisplayer

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava42 Reengineering Aphyds getDisplayer().getViewer().ChannelRouterMenuItem.setEnabled(b); Control communication integrity –Components only talk with connected components Compile-time error in ArchJava –RouterDialog can only reference local connections –Call through architecture, reducing dependencies Hypothesis: Enforcing communication integrity helps to reduce system coupling CircuitViewer MenuItem RouterDialog CircuitDisplayer

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava43 Reengineering Aphyds getDisplayer().getViewer().ChannelRouterMenuItem.setEnabled(b); Control communication integrity –Components only talk with connected components Compile-time error in ArchJava –RouterDialog can only reference local connections –Call through architecture, reducing coupling Hypothesis: Enforcing communication integrity helps to reduce system coupling CircuitViewer MenuItem RouterDialog CircuitDisplayer

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava44 Defect Repair Fix same Aphyds bug –First in ArchJava, then Java ArchJava version required more coding –Had to add new ports & connections Java took longer –Difficult to find object involved in fix –Even though I’d already fixed the bug in ArchJava! getDisplayer().placeroutedialog1.placeRouteDisplayer1.getCircuitGlobalRouter().doGlobalRouting(); Hypothesis: An explicit software architecture makes it easier to identify and evolve the components involved in a change.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava45 Defect Repair Fix same Aphyds bug –First in ArchJava, then Java ArchJava version required more coding –Had to add new ports & connections Java version took longer –Difficult to find object involved in fix Had to traverse a sequence of hard-to-find field links –Even though we had already fixed the bug in ArchJava Hypothesis: An explicit software architecture makes it easier to identify and evolve the components involved in a change.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava46 Defect Repair Fix same Aphyds bug –First in ArchJava, then Java ArchJava version required more coding –Had to add new ports & connections Java version took longer –Difficult to find object involved in fix Had to traverse a sequence of hard-to-find field links –Even though we had already fixed the bug in ArchJava Hypothesis: An explicit software architecture makes it easier to identify and evolve the components involved in a change.

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava47 Evaluation Questions Does ArchJava guarantee control communication integrity? –Yes Is ArchJava expressive enough for real systems? –Yes Can ArchJava aid software evolution tasks? –Preliminary experience suggests: ArchJava highlights refactoring opportunities ArchJava encourages loose coupling ArchJava may aid defect repair

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava48 Current & Future Work ECOOP ’02 –Formalization of language & properties –Case study : dynamically changing architecture OOPSLA ’02 –Specification of data sharing ownership type system [Clarke et al.] Further evaluate and refine language –More design and evolution experience –Distributed architectures –Flexible connections

May 22, 2002Jonathan Aldrich - ICSE '02 - ArchJava49 Conclusion ArchJava integrates architecture with Java code Control communication integrity –Keeps architecture and code synchronized Initial experience –ArchJava can express real program architectures –ArchJava may aid in software evolution tasks Download the ArchJava compiler and tools