Archface : A Contract Place Where Architectural Design and Code Meet Together

1. ICSE 2010 Archface: A Contract PlaceWhere Architectural Design and Code Meet Together POSL (Principles of Software Languages) Gr. NaoyasuUbayashi (Kyushu University, Japan) Jun Nomura (Kyushu Institute of Technology, Japan) Tetsuo Tamai (University of Tokyo, Japan)

2. Overview Architecture ADL Architectural information is encapsulated in interfaces public class Subject{
private Vector observers = new Vector(); private String state = “”;
public void addObserver(Observero){ … }
public void removeObserver(Observero){ … }
public void notify(){
Iteratori = observers.iterator();
while(i.hasNext() ){
Observers o = (Observer)i.next();
o.update(this);
}
} public void setState(Strings){ state = s; } public String getState() {return state; }
} Interface Archface Program Code Bug Bidirectional Traceability ! • Architectural design plays an important role in the software development. • Robustness • Reliability • Maintainability • However, it is not easy to • implement the result of architecture modeling as a program preserving the architectural correctness; • maintain the traceability between an architecture and program code; and • deal with software evolution.

3. Outline Motivation Archface Archface for Java Discussion Conclusion

4. 1. Motivation 1. Motivation

5. Motivating example Architectural Design (Observer Pattern) Architectural constraints (Collaborative behavior) are not preserved ! public class Subject { private String state = ""; public String getState() { return state; } public void setState(Strings) { state = s; } … } Bug Code

6. Solution ? MDD + Code generation ?  Fine, but … Full code generation Detailed Model Descriptions Program Code Detailed model generation Architectural design should be abstract !

7. Problems to be tackled These problems arise because the boundary between design and implementation is vague !! • Abstraction level of architectural design • It is not clear which abstraction level is adequate for designing architecture. The gap between design and implementation becomes large if the design is too abstract. On the other hand, the difference between them becomes unclear if the abstraction level of the design is low. • Refinement from design to code • It is not easy to reflect the design decisions at the code level when UML or informal natural languages are used for design notation. • Co-evolution between design and code • It is not easy to synchronize design and code. In other words, bidirectional traceability between design and code is needed.

8. 2. Archface (= Architecture + Interface)

9. Our Approach Architecture Architectural information is encapsulated in interfaces public class Subject{
private Vector observers = new Vector(); private String state = “”;
public void addObserver(Observero){ … }
public void removeObserver(Observero){ … }
public void notify(){
Iteratori = observers.iterator();
while(i.hasNext() ){
Observers o = (Observer)i.next();
o.update(this);
}
} public void setState(Strings){ state = s; } public String getState() {return state; }
} Archface Program Code Archface: architectural interface for bridging a gap between design modeling and implementation

10. Architecture Descriptions Supported by Archface • Predicate Coordination • A component exposes [dynamic or static] program points by predicate • A trait-based connector coordinates exposed program points Signature-based Interface is insufficient. <Example: Observer Pattern> Predicate Coordination Component Component Collaboration Component-and-Connector Architecture (Structure) Collaborations among Components (Behavior)

11. Predicate Coordination Component predicate class, method, field (static program points) call, execution, cflow, etc. (dynamic program points) Connector coordination introduce [open class] (static composition) before, after, around (dynamic coordination) [Behavioral aspect of architecture] Dynamic program points & dynamic coordination [Structural aspect of architecture] Static program points & static composition Based on AspectJ’sPointcut & Advice Predicate -> Pointcut Coordination -> Advice

12. Traditional Interface vs. Archface Archface conceptually includes the notion of traditional interface mechanisms Component Connection Expose method signatures Interface Method call coordinate between calland execution program points executionprogram points Coordinate execution of program points Expose program points Archface Predicate Coordination (Pointcut) (Advice)

13. 3. Archface for Java 1. Motivation

14. Archface as ADL Observer Pattern represented by Archface [Port update] pointcut update(): execution(void update()); [Connection] connects notifyChange (port1 :cSubject.notifyObservers, port2 :cObserver.update){ around() void :port1 { port2.proceed(); } } ADL [Port notifyObservers] pointcutnotifyObservers() : cflow(execution(voidsetState(Strings))) && call(void notify());

15. Archface as Program Interface Archface (Program Interface) Program Code (Implement exposed program points) Implement Type check + formal verification + test

16. Software Process with Archface UML Model element Pointcut Class diagram class definition class method definition method field definition field Interaction diagram message send call message receive execution message sequence cflow • Bidirectional Traceability • Archface supports software evolution based on bidirectional traceability. • Archface can be considered as a contractdefined between architectural design and implementation.

17. Integration with AO Predicate Coordination -> Common Mechanism for integrating AO with OO Archface supports not only OO but also AO architecture. A weaving in AO can be realized by the component-and-connectormechanism. We do not have to distinguish crosscutting concerns from primary concerns at the architectural design phase.

18. Example: Figure Editor Primary Concern (Component) Crosscutting Concerns Primary Concerns cDisplay cPoint redraw change Predicate Coordination Crosscutting Concern (Component) cLine Predicate Coordination (Connector) change

19. Compiler construction (Prototype) Java code (class) Archface definitions Archfacecompiler Archfaceparser AspectJ code generator Aspect-Factory class generator AspectJ code (aspect) AspectJ weaver executable program

20. 4. Discussion 1. Motivation

21. POSA Patterns and Archface POSA Archface Component Evaluation Layer Each layer Well-fitted Pipes & Filters Data Source, Filter, Data Sink Well-fitted Blackboard Blackboard, Knowledge Source, Control Well-fitted Broker Client, Client-side Proxy, Broker, Well-fitted Server-side Proxy, Server MVC Model, View, Controller Well-fitted PAC {Top,Interm.,Bottom}-Level Agent Well-fitted Micro kernel Internal server, External server, Fair Adapter, Client, Microkernel Reflection {Base,Meta}-Level, Metaobject Protocol Fair POSA (Pattern-Oriented Software Architecture) [Buschmann, F., et al. 1996] MVC (Model-View-Controller), PAC (Presentation-Abstraction-Control)

22. Related Work Our approach is based on the interface mechanisms that not only enforce architectural constraints on the program implementation but also represent architectural abstractions. • Architecture and Implementation: • ArchJava [Aldrich, J. 2002] • Design pattern implementation in Java and AspectJ [Hannemann, J. 2002] • Co-evolution: • Co-evolution between design and implementation [D'Hondt, T. 2001] • Co-evolving the application design models after the code refactoring [Cazzola, W. 2007] • Aspect Component: • JAsCo [Suvee, D. et al. 2003]

23. How the problems are resolved Abstraction level of architectural design Refinement from design to code Co-evolution between design and code

24. How the problems are resolved • Co-evolution between design and code • resolved by the co-evolution between design and code. Model elements can be synchronized with program point shadows via Archface. • Refinement from design to code • avoided by implementing the code conforming to Archface. The Archface compiler detects an error if the code does not implement the Archface correctly. • Abstraction level of architectural design • resolved by describing architecture in Archface because the essence of architectural design can be described at an adequately abstract level without considering implementation.

25. Open Issues • What kinds of contextual pointcuts are really needed for effective architectural descriptions ? • Currently, we consider control flow only… • Which class of architecture descriptions can be statically verified ? • Which description should be tested ?

26. 5. Conclusion 1. Motivation

27. Summary Archface is not only an ADL but also a programming-level interface mechanism. Archface provides a contract place where design and code meet. Our main idea, predicate coordination, is very simple and we believe that the idea reveals a new research direction for discussing what is design and what is implementation.

28. Thank you for your attention. 1. Motivation

29. Architectural Verification PROMELA (Observer Pattern) 01: #define SYNCH 0 02: mtype = {setState, getState, notify, update, getSubjectState} 03: chantoSubject = [SYNCH] of {mtype}; 04: chantoObserver = [SYNCH] of {mtype}; 05: 06: proctypecSubject(){ 07: do 08: :: to_Subject?setState -> to_Subject!notify 09: od 10: } 11: proctypecObserver(){ 12: do 13: :: to_Observer?update -> to_Observer!getSubjectState 14: od 15: } 16: proctypenotifyChange(){ 17: do 18: :: toSubject?notify -> toObserver!update 19: od 20: } 21: proctypeObtainNewState(){ 22: do 23: :: toObserver?getSubjectState -> toSubject!getState 24: od 25: } Model Checking Archface Mapping Component -> Process In-port -> receive (?) Out-port -> send (!) Control flow -> simplest case