architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of...

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



Compiler

Architecture and Implementation

• Inconsistency caused by evolution– Architecture documentation becomes obsolete

• Problems– Suprises– Misunderstandings lead to defects– Untrusted architecture won’t be used



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


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


A Parser Component

public component class Parser {

Component class• Defines architectural object• Must obey architectural constraints

Parser


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


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


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


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


Compiler out in out in


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


Compiler out in out in


Evaluation Questions

• Does ArchJava guarantee communication integrity?• Is ArchJava expressive enough for real systems?• What are the benefits and limitations of ArchJava?


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


Compiler



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



Compiler



ArchJava enforces integrity for control flow

Other communication paths– Shared data (current work)– Run-time system



Compiler


• Architecture allows– Calls between connected components

Control Communication Integrity


Compiler



Compiler

• Architecture allows– Calls between connected components

– Calls from a parent to its immediate subcomponents




Compiler

• Architecture allows– Calls between connected components– Calls from a parent to its immediate subcomponents

• Architecture forbids– External calls to subcomponents

–




Compiler


• Architecture forbids– External calls to subcomponents– Calls between unconnected subcomponents




compiler2


• Architecture forbids– External calls to subcomponents– Calls between unconnected subcomponents– Calls violating architectural hierarchy

• Benefit: local reasoning about control flow



compiler1


Action


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





• Other issues– First-class functions (like Actions)– Instance encapsulation (2 compiler example)– Dynamically changing architectures

Action



Action


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


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


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


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


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



• 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



• 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


Architectural Comparison


ArchJava Architecture

• Architecture shows design characteristics– Pipeline of components– Dynamically created– Largely independent

• Architecture matches intuition– But ArchJava guarantees correctness!

• Architecture evolves with implementation



• 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



• 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?


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


Taprats in ArchJava


• 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


Taprats in ArchJava





RenderPanel



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


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


More in paper

• Formalization of language & properties

• Architectural design principles

• Architectural refactoring patterns

• Comparison to earlier case study


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


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/


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.)

architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of...

Documents

jonathan aldrich ecoop

public port

java slide

private final scanner

sufficient slide

archjava3 architecture

archjava4 architecture

ordinary java code slide