ArchJava

1. ArchJava • A software architecture tool • components • connections • constraints on how components interact • Implementation must conform to architecture

2. References • ECOOP 2002 paper • ICSE 2002 paper • website on ArchJava • ArchJava reference manual

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

4. public component class Parser { public port in { provides void setInfo(Token symbol, SymTabEntry e); requires Token nextToken() throws ScanException; } public port out { provides SymTabEntry getInfo(Token t); requires void compile (AST ast);} void parse (String file) { Token tok = in.nextToken(); AST ast = parseFile(tok); out.compile(ast); } AST parseFile(Token lookahead) { … } void setInfo(Token t, SymTabEntry e) {… } SymTabEntry getInfo(Token t) { … } … } strange that parse does not belong to a port; parse is provided.

5. collaboration Parser { public participant in { provides void setInfo(Token symbol, SymTabEntry e); requires Token nextToken() throws ScanException; } public participant out { provides SymTabEntry getInfo(Token t); requires void compile (AST ast); void parse (String file) { Token tok = in.nextToken(); AST ast = parseFile(tok); out.compile(ast); } AST parseFile(Token lookahead) { … } void setInfo(Token t, SymTabEntry e) {… } SymTabEntry getInfo(Token t) { … } … } can we do the same with an aspectual collaboration?

6. public component class Compiler { private final Scanner scanner = … ; private final Parser parser = … ; private final CodeGen 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); … }

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

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

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

10. public component class WebServer { 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 requestWorkers() { final Worker newWorker = new Worker(); r.workers connection = connect(r.workers, newWorker.serve); return connection; } } }

11. public component class Router {

12. Limitations of ArchJava • 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

13. Example: Aphyds • Developed by EE professor with PhD in CS

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

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

16. Hypotheses • Expressing software in ArchJava 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.

17. 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 ArchJava encourages local communication and helps to reduce coupling between components.

18. Architectural Refactoring during Translation • ArchJava’s

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

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

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

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

23. Topic Switch

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