architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of...
Post on 20-Dec-2015
221 Views
Preview:
TRANSCRIPT
Architectural Reasoningin ArchJava
Jonathan AldrichCraig Chambers
David Notkin
University of Washington
ECOOP ‘02, 13 June 2002
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 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
parser codegen scanner
Compiler
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 3
parser codegen scanner
Compiler
Architecture and Implementation
• Inconsistency caused by evolution– Architecture documentation becomes obsolete
• Problems– Suprises– Misunderstandings lead to defects– Untrusted architecture won’t be used
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 4
parser codegen scanner
Compiler
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
13 June 2002 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
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 6
A Parser Component
public component class Parser {
Component class• Defines architectural object• Must obey architectural constraints
Parser
13 June 2002 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
Parser out in
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 8
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
Parser out in
13 June 2002 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
Parser out in
13 June 2002 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
parser codegen scanner
Compiler out in out in
13 June 2002 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
parser codegen scanner
Compiler out in out in
13 June 2002 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?
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 13
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
parser codegen scanner
Compiler
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 14
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
parser codegen scanner
Compiler
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 15
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
parser codegen scanner
Compiler
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 16
• Architecture allows– Calls between connected components
Control Communication Integrity
parser codegen scanner
Compiler
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 17
parser codegen scanner
Compiler
• Architecture allows– Calls between connected components
– Calls from a parent to its immediate subcomponents
Control Communication Integrity
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 18
parser codegen scanner
Compiler
• Architecture allows– Calls between connected components– Calls from a parent to its immediate subcomponents
• Architecture forbids– External calls to subcomponents
–
Control Communication Integrity
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 19
parser codegen scanner
Compiler
• Architecture allows– Calls between connected components– Calls from a parent to its immediate subcomponents
• Architecture forbids– External calls to subcomponents– Calls between unconnected subcomponents
Control Communication Integrity
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 20
parser codegen scanner
compiler2
• 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
Control Communication Integrity
parser codegen scanner
compiler1
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 21
parser codegen scanner
compiler2
• 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
Control Communication Integrity
parser codegen scanner
compiler1
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 22
Action
parser codegen scanner
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
13 June 2002 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
Action
parser codegen scanner
13 June 2002 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
Action
parser codegen scanner
13 June 2002 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
Action
parser codegen scanner
13 June 2002 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
Action
parser codegen scanner
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 27
Action
parser codegen scanner
Action Example in ArchJava
• 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
X
13 June 2002 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
13 June 2002 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
13 June 2002 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
13 June 2002 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
13 June 2002 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
13 June 2002 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
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 34
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 35
Architectural Comparison
13 June 2002 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
13 June 2002 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
13 June 2002 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?
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 39
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”
PreviewPanelRenderPanel
RenderView
Coupling in Taprats
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 40
Taprats in ArchJava
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
RenderPanel
PreviewPanelRenderView
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 41
Taprats in ArchJava
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
RenderPanel
PreviewPanelRenderView
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 42
Taprats in ArchJava
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
RenderPanel
PreviewPanelRenderView
13 June 2002 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
13 June 2002 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
13 June 2002 Jonathan Aldrich - ECOOP '02 - ArchJava 45
More in paper
• Formalization of language & properties
• Architectural design principles
• Architectural refactoring patterns
• Comparison to earlier case study
13 June 2002 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
13 June 2002 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/
13 June 2002 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.)
top related