1 / 48

Architectural Reasoning in ArchJava Jonathan Aldrich Craig Chambers David Notkin University of Washington ECOOP ‘02, 13

Architectural Reasoning in ArchJava Jonathan Aldrich Craig Chambers David Notkin University of Washington ECOOP ‘02, 13 June 2002. Software Architecture. High-level system structure [GS93,PW92] Components and connections Automated analysis Support program evolution Source of defect

naida
Télécharger la présentation

Architectural Reasoning in ArchJava Jonathan Aldrich Craig Chambers David Notkin University of Washington ECOOP ‘02, 13

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architectural Reasoningin ArchJavaJonathan AldrichCraig ChambersDavid NotkinUniversity of WashingtonECOOP ‘02, 13 June 2002

  2. Software Architecture • High-level system structure [GS93,PW92] • Components and connections • Automated analysis • Support program evolution • Source of defect • Effect of change • Invariants to preserve Jonathan Aldrich - ECOOP '02 - ArchJava

  3. Architecture and Implementation • Inconsistency caused by evolution • Architecture documentation becomes obsolete • Problems • Suprises • Misunderstandings lead to defects • Untrusted architecture won’t be used Jonathan Aldrich - ECOOP '02 - ArchJava

  4. 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  5. ArchJava • Specifies architecture within Java code • Verifies control flow architecture • Statically checked (except for casts, as in Java) • Code and architecture evolve together • Is flexible • Supports dynamically changing architectures • Allows common implementation techniques • Case study on a 12,000-line program • Evaluates expressiveness, benefits, limitations Jonathan Aldrich - ECOOP '02 - ArchJava

  6. A Parser Component public component class Parser { Component class • Defines architectural object • Must obey architectural constraints Jonathan Aldrich - ECOOP '02 - ArchJava

  7. 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  8. A Parser Component public component class Parser { public port in { requiresToken nextToken(); } public port out { providesAST parse(); } Ordinary (non-component) objects • Passed between components • Sharing is permitted • Can use just as in Java Jonathan Aldrich - ECOOP '02 - ArchJava

  9. 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  10. 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  11. 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  12. Evaluation Questions • Does ArchJava guarantee communication integrity? • Is ArchJava expressive enough for real systems? • What are the benefits and limitations of ArchJava? Jonathan Aldrich - ECOOP '02 - ArchJava

  13. Communication Integrity 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  14. Communication Integrity 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  15. Communication Integrity 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  16. Control Communication Integrity • Architecture allows • Calls between connected components Jonathan Aldrich - ECOOP '02 - ArchJava

  17. Control Communication Integrity • Architecture allows • Calls between connected components • Calls from a parent to its immediate subcomponents Jonathan Aldrich - ECOOP '02 - ArchJava

  18. Control Communication Integrity • Architecture allows • Calls between connected components • Calls from a parent to its immediate subcomponents • Architecture forbids • External calls to subcomponents Jonathan Aldrich - ECOOP '02 - ArchJava

  19. Control Communication Integrity • Architecture allows • Calls between connected components • Calls from a parent to its immediate subcomponents • Architecture forbids • External calls to subcomponents • Calls between unconnected subcomponents Jonathan Aldrich - ECOOP '02 - ArchJava

  20. Control Communication Integrity • Architecture allows • Calls between connected components • Calls from a parent to its immediate subcomponents • Architecture forbids • External calls to subcomponents • Calls between unconnected subcomponents • Calls violating architectural hierarchy • Benefit: local reasoning about control flow Jonathan Aldrich - ECOOP '02 - ArchJava

  21. Control Communication Integrity • Architecture allows • Calls between connected components • Calls from a parent to its immediate subcomponents • Architecture forbids • External calls to subcomponents • Calls between unconnected subcomponents • Calls violating architectural hierarchy • Benefit: local reasoning about control flow Jonathan Aldrich - ECOOP '02 - ArchJava

  22. Why Not Use Modules? • Implicit Invocation Example • Jiazzi [MFH01] : strong encapsulation, module linking • Action object is passed down pipeline • Invocations through action violate architecture • Other issues • First-class functions • Dynamic architectures • Instance encapsulation Jonathan Aldrich - ECOOP '02 - ArchJava

  23. Why Not Use Modules? • Implicit Invocation Example • Jiazzi [MFH01] : strong encapsulation, module linking • Action object is passed down pipeline • Invocations through action violate architecture • Other issues • First-class functions • Dynamic architectures • Instance encapsulation Jonathan Aldrich - ECOOP '02 - ArchJava

  24. Why Not Use Modules? • Implicit Invocation Example • Jiazzi [MFH01] : strong encapsulation, module linking • Action object is passed down pipeline • Invocations through action violate architecture • Other issues • First-class functions • Dynamic architectures • Instance encapsulation Jonathan Aldrich - ECOOP '02 - ArchJava

  25. Why Not Use Modules? • Implicit Invocation Example • Jiazzi [MFH01] : strong encapsulation, module linking • Action object is passed down pipeline • Invocations through action violate architecture • Other issues • First-class functions • Dynamic architectures • Instance encapsulation Jonathan Aldrich - ECOOP '02 - ArchJava

  26. Why Not Use Modules? • Implicit Invocation Example • Jiazzi [MFH01] : strong encapsulation, module linking • Action object is passed down pipeline • Invocations through action violate architecture • Other issues • First-class functions (like Actions) • Instance encapsulation (2 compiler example) • Dynamically changing architectures Jonathan Aldrich - ECOOP '02 - ArchJava

  27. Action Example in ArchJava X • Classes can’t refer to components • Action can’t store reference to scanner component • Components can share Action • Allows communication through side effects • current work: specify & enforce this • Type system prevents control flow through Action Jonathan Aldrich - ECOOP '02 - ArchJava

  28. Enforcing Communication Integrity • Communication integrity for direct method calls • Can only call self or subcomponents • Invariant • All component-typed references in a component (and called objects) are to self or subcomponents • Key lemma in integrity proof • Enforcement • No component types in port interfaces • No fields of component type in objects Jonathan Aldrich - ECOOP '02 - ArchJava

  29. Enforcing Communication Integrity • What about casts? • Store components in data structures • But, data structures can be shared • Downcasts could violate communication integrity • Solution: additional dynamic check • Components store parent • Casted object or its parent must be this Jonathan Aldrich - ECOOP '02 - ArchJava

  30. Other Integrity Issues • Dynamically changing architectures • Patterns specify permissible connections • Dependent types • Relate a connection to a component instance • Restrictions on inheritance, inner classes • e.g., components may not implement interfaces • Reasonable in component libraries • Relax to use existing Java libraries • Investigating ways to relax restrictions safely Jonathan Aldrich - ECOOP '02 - ArchJava

  31. ArchFJ : A Formal Framework • Based on Featherweight Java [OOPSLA 99] • Includes components, ports, connections • Benefits • Precise semantics • Shows how integrity is enforced • Proven: • Type safety • Control communication integrity Jonathan Aldrich - ECOOP '02 - ArchJava

  32. Evaluation Questions • Does ArchJava guarantee control communication integrity? • Yes, using the type system • Is ArchJava expressive enough for real systems? • What are the benefits and limitations of ArchJava? • Two case studies • 12,000 lines of Java code each • Asked developer to draw architecture • Tried to specify architecture in ArchJava Jonathan Aldrich - ECOOP '02 - ArchJava

  33. Evaluation Questions • Does ArchJava guarantee control communication integrity? • Yes, using the type system • Is ArchJava expressive enough for real systems? • What are the benefits and limitations of ArchJava? • Case study: Taprats • 12,000 lines of Java code • Two challenges • Drawn by original developer • Dynamic changes Jonathan Aldrich - ECOOP '02 - ArchJava

  34. Jonathan Aldrich - ECOOP '02 - ArchJava

  35. Architectural Comparison Jonathan Aldrich - ECOOP '02 - ArchJava

  36. ArchJava Architecture • Architecture shows design characteristics • Pipeline of components • Dynamically created • Largely independent • Architecture matches intuition • But ArchJava guarantees correctness! • Architecture evolves with implementation Jonathan Aldrich - ECOOP '02 - ArchJava

  37. 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 Jonathan Aldrich - ECOOP '02 - ArchJava

  38. Evaluation Questions • Does ArchJava guarantee control communication integrity? • Yes • Is ArchJava expressive enough for real systems? • Yes (validated by 2 other case studies) • What are the benefits and limitations of ArchJava? Jonathan Aldrich - ECOOP '02 - ArchJava

  39. RenderView PreviewPanel Coupling in Taprats RenderPanel render.getView().setTheta(t); • PreviewPanel coupled to RenderPanel • Depends on View representation of RenderPanel • Programs are fragile, change is difficult • Law of Demeter [Lieberherr et al.] • Design guideline • “Only talk with your neighbors” Jonathan Aldrich - ECOOP '02 - ArchJava

  40. PreviewPanel Taprats in ArchJava RenderPanel RenderView render.getView().setTheta(t); • Control communication integrity • Components only talk with connected components • Compile-time error in ArchJava • PreviewPanel can only reference local connections • Call through architecture, reducing coupling Hypothesis: Enforcing communication integrity helps to reduce system coupling Jonathan Aldrich - ECOOP '02 - ArchJava

  41. PreviewPanel Taprats in ArchJava RenderPanel RenderView render.getView().setTheta(t); • Control communication integrity • Components only talk with connected components • Compile-time error in ArchJava • PreviewPanel can only reference local connections • Call through architecture, reducing coupling Hypothesis: Enforcing communication integrity helps to reduce system coupling Jonathan Aldrich - ECOOP '02 - ArchJava

  42. PreviewPanel Taprats in ArchJava RenderPanel RenderView render.getView().setTheta(t); • Control communication integrity • Components only talk with connected components • Compile-time error in ArchJava • PreviewPanel can only reference local connections • Call through architecture, reducing coupling Hypothesis: Enforcing communication integrity helps to reduce system coupling Jonathan Aldrich - ECOOP '02 - ArchJava

  43. Case Study Summary • Successful overall • Expressed dynamic architecture • Made design explicit • Reduced coupling • Low cost (5 hours, 500 lines of additional code) • Lessons Learned • Some unnecessary casts • Creation slightly awkward Jonathan Aldrich - ECOOP '02 - ArchJava

  44. Case Study Summary • Successful overall • Expressed dynamic architecture • Made design explicit • Reduced coupling • Low cost (5 hours, 500 lines of additional code) • Directions for improvement • Some unnecessary casts • Creation slightly awkward Jonathan Aldrich - ECOOP '02 - ArchJava

  45. More in paper • Formalization of language & properties • Architectural design principles • Architectural refactoring patterns • Comparison to earlier case study Jonathan Aldrich - ECOOP '02 - ArchJava

  46. Current and Future Work • ICSE ’02 • ArchJava language design • Case study with static architecture • ECOOP: communication integrity & dynamic architecture • OOPSLA ’02 • Specification of data sharing • ownership type system [Clarke et al.] • Extend ML-style modules to enforce architecture • Refine language design • Distributed systems, flexible connectors Jonathan Aldrich - ECOOP '02 - ArchJava

  47. Conclusion • ArchJava integrates architecture with Java code • Control communication integrity • Keeps architecture and code synchronized • Initial experience • ArchJava expresses dynamically changing architectures • ArchJava may improve program structure • Download the ArchJava compiler and tools http://www.archjava.org/ Jonathan Aldrich - ECOOP '02 - ArchJava

  48. Limitations of ArchJava • Some idioms are awkward • Implicit invocation architectures • Dynamic component creation and connection • Some extra casts • Architecture is very concrete • Connections must be method calls • Can’t express all architectural properties • Data sharing (partial solution: OOPSLA ‘02) • Others (temporal protocols, styles, etc.) Jonathan Aldrich - ECOOP '02 - ArchJava

More Related