Architectural Reasoning
This presentation is the property of its rightful owner.
Sponsored Links
1 / 48

Architectural Reasoning in ArchJava Jonathan Aldrich Craig Chambers David Notkin University of Washington ECOOP ‘02, 13 June 2002 PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Software architecture

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


Architecture and implementation

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


Architecture and implementation1

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


Archjava

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


A parser component

A Parser Component

public component class Parser {

Component class

  • Defines architectural object

  • Must obey architectural constraints

Jonathan Aldrich - ECOOP '02 - ArchJava


A parser component1

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


A parser component2

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


A parser component3

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


Hierarchical composition

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


Hierarchical composition1

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


Evaluation questions

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

Control Communication Integrity

  • Architecture allows

    • Calls between connected components

Jonathan Aldrich - ECOOP '02 - ArchJava


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

Control Communication Integrity

  • Architecture allows

    • Calls between connected components

    • Calls from a parent to its immediate subcomponents

Jonathan Aldrich - ECOOP '02 - ArchJava


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

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


Why not use modules

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


Why not use modules1

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


Why not use modules2

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


Why not use modules3

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


Why not use modules4

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


Action example in archjava

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


Enforcing communication integrity

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


Enforcing communication integrity1

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


Other integrity issues

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


Archfj a formal framework

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


Evaluation questions1

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


Evaluation questions2

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


Architectural reasoning in archjava jonathan aldrich craig chambers david notkin university of washington ecoop 02

Jonathan Aldrich - ECOOP '02 - ArchJava


Architectural comparison

Architectural Comparison

Jonathan Aldrich - ECOOP '02 - ArchJava


Archjava architecture

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


Evaluation questions3

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


Evaluation questions4

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


Coupling in taprats

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


Taprats in archjava

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


Taprats in archjava1

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


Taprats in archjava2

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


Case study summary

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


Case study summary1

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


More in paper

More in paper

  • Formalization of language & properties

  • Architectural design principles

  • Architectural refactoring patterns

  • Comparison to earlier case study

Jonathan Aldrich - ECOOP '02 - ArchJava


Current and future work

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


Conclusion

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


Limitations of archjava

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


  • Login