Arch Java A software architecture tool components connections

Arch. Java • A software architecture tool – components – connections – constraints on how components interact • Implementation must conform to architecture

References • • ECOOP 2002 paper ICSE 2002 paper website on Arch. Java reference manual

Architectural Conformance • communication integrity – each component in the implemented system may only communicate directly with the components to which it is connected in the architecture.

public component class Parser { public port in { provides void set. Info(Token symbol, Sym. Tab. Entry e); requires Token next. Token() throws Scan. Exception; } public port out { provides Sym. Tab. Entry get. Info(Token t); requires void compile (AST ast); } void parse (String file) { Token tok = in. next. Token(); strange that parse does not AST ast = parse. File(tok); belong to a port; parse is out. compile(ast); provided. } AST parse. File(Token lookahead) { … } void set. Info(Token t, Sym. Tab. Entry e) {… } Sym. Tab. Entry get. Info(Token t) { … }

collaboration Parser { public participant in { provides void set. Info(Token symbol, Sym. Tab. Entry e); requires Token next. Token() throws Scan. Exception; } public participant out { provides Sym. Tab. Entry get. Info(Token t); requires void compile (AST ast); can we do the same void parse (String file) { with an aspectual Token tok = in. next. Token(); AST ast = parse. File(tok); collaboration? out. compile(ast); } AST parse. File(Token lookahead) { … } void set. Info(Token t, Sym. Tab. Entry e) {… } Sym. Tab. Entry get. Info(Token t) { … }

public component class Compiler private final Scanner scanner private final Parser parser = private final Code. Gen codegen { = … ; connect scanner. out, parser. in; connect parser. out, codegen. in public static void main(String args[]) { new Compiler(). compile(args); } public void compile(String args[]) { // for each file in args do: … parser. parse(file); … }

Composite components • sub component: component instance nested within another component. • singleton sub components: final • connections: connect primitive is symmetric – bind each required method to a provided method with same name and signature – args to connect: components own ports or those of subcomponents in final fields

Composite components • Provided methods can be implemented by forwarding invocations to sub components or to the required methods of another port. • Alternative connection semantics: write smart connectors. • Only a component’s parent can invoke its methods directly.

Dynamic architectures • create component instances with new. • typed references to sub components may not escape the scope of their parent. • Garbage collection when components are no longer reachable through references or connections.

public component class Web. Server { private final Router r = new Router(); connect r. request, create; // may be instantiated at run-time // personality analogy connect pattern Router. workers, Worker. serve; public void run() { r. listen(); } private port create { provides r. workers request. Workers() { final Worker new. Worker = new Worker(); r. workers connection = connect(r. workers, new. Worker. serve); return connection; } } }

public component class Router {

Limitations of Arch. Java • only Java • inter-component connections must be implemented through method calls (not events, for example) • focus on communication integrity • no reasoning about temporal ordering of architectural events • shared data

Example: Aphyds • Developed by EE professor with Ph. D in CS

Hypotheses • Do those hypotheses hold for aspectual collaborations? A port corresponds to a participant. • In Arch. Java: no renaming of methods in connectors

Hypotheses • Refactoring an application to expose its architecture is done most efficiently in small increments • Applications can be translated into Arch. Java with a modest amount of effort and without excessive code bloat

Hypotheses • Expressing software in Arch. Java highlights refactoring opportunities by making communication protocols explicit. • Note: the name of a port gives a clue about the purpose of the port’s methods.

Hypotheses • Using separate ports and connections to distinguish different protocols and describing protocols with separate provided and required port interfaces may ease program understanding tasks. • Communication integrity in Arch. Java encourages local communication and helps to reduce coupling between components.

Architectural Refactoring during Translation • Arch. Java’s

Ideas • Can Arch. Java constraints be simulated in Aspect. J? Simulate a component class with aspects that check the constraints? • What are the connections between ports and participants? • Law of Demeter and default architecture.

Ports and Participants • Sounds like ports are a second very useful application of the participant idea. Participants are connected in a graph; ports don’t rely on that.

Ports and Participants • • • Arch. Java has provides/requires connect: link ports no renaming no component merging • • • AC has provides/requires attach: link participants renaming of method names component merging

component class Flying { port flier { provides void fly(); requires void take. Off(); requires void land(); …}} component class Bat { port flier_infra { provides void take. Off(); provides void land(); … } } component class Flying. Bat { private final Flying f = … ; private final Bat b = … ; connect f. flier, b. flier_infra; public void fly() { f. fly(); } }

Topic Switch

Hygienic Components and Mixins class Add. Attribute<C, Attribute> extends C{ // mixin class that adds a field of type // Attribute to any class C private Attribute _a; void set. Attribute(Attribute a) {_a = a; } Attribute get. Attribute() {return _a; } } class Point { … }