Archface: A Contract PlaceWhere Architectural Design and Code Meet
Together
ICSE 2010
POSL (Principles of Software Languages) Gr.
Naoyasu Ubayashi (Kyushu University, Japan)Jun Nomura (Kyushu Institute of Technology,
Japan)Tetsuo Tamai (University of Tokyo, Japan)
POSL
2
Overview 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.
public class Subject{ private Vector observers = new Vector(); private String state = “”; public void addObserver(Observer o){ … } public void removeObserver(Observer o){ … } public void notify(){ Iterator i = observers.iterator(); while(i.hasNext() ){ Observers o = (Observer)i.next(); o.update( this ); } } public void setState(String s){ state = s; } public String getState() {return state; }}
Program
Cod
e
Bidirectional Traceability !
Archite
cture
Bug
ArchfaceArchitectural information
is encapsulated in interfaces
ADL
Interface
POSL
3
Outline Motivation Archface Archface for Java Discussion Conclusion
POSL
4
1. MOTIVATION1. Motivation
POSL
5
Motivating example
public class Subject { private String state = ""; public String getState() { return state; } public void setState(String s) { state = s; } … }
Architectural Design(Observer Pattern)
Code
Bug
Architectural constraints(Collaborative behavior)are not preserved !
POSL
6
Solution ?MDD + Code generation ? Fine, but …
Architectural design should be abstract !
Detaile
d
Model
Descrip
tions Program
Code
Full codegeneration
Detailed modelgeneration
POSL
7
Problems to be tackled 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.
These problems arise because the boundary between design and implementation is vague !!
POSL
8
2. Archface
(= Architecture + Interface)
POSL
9
public class Subject{ private Vector observers = new Vector(); private String state = “”; public void addObserver(Observer o){ … } public void removeObserver(Observer o){ … } public void notify(){ Iterator i = observers.iterator(); while(i.hasNext() ){ Observers o = (Observer)i.next(); o.update( this ); } } public void setState(String s){ state = s; } public String getState() {return state; }}
Our Approach
Archite
cture
Program
Cod
e
Archface: architectural interface for bridging a gap between design modeling and implementationArchitectural information
is encapsulated in interfaces
Archface
POSL
10
Architecture Descriptions Supported by Archface
Component-and-Connector Architecture (Structure)
Collaborations among Components (Behavior)
<Example: Observer Pattern>
Component Component
Collaboration
Signature-based Interface is insufficient.
Predicate Coordination
Predicate Coordination
• A component exposes [dynamic or static] program points by predicate
• A trait-based connector coordinates exposed program points
POSL
11
Predicate Coordination
Component predicateclass, method, field (static program points)call, execution, cflow, etc. (dynamic
program points)
Connector coordinationintroduce [open class] (static composition)before, after, around (dynamic
coordination)Based on AspectJ’s Pointcut & AdvicePredicate -> PointcutCoordination -> Advice
[Behavioral aspect of architecture] Dynamic program points & dynamic coordination
[Structural aspect of architecture] Static program points & static composition
POSL
12
Traditional Interface vs. Archface
Interface Expose methodsignatures
ArchfacePredicate
Coordination
Expose program points
Method call
Coordinateexecution ofprogram points
(Pointcut) (Advice)
ConnectionComponent
execution program points
coordinate between call and execution program points
Archface conceptually includes the notion oftraditional interface mechanisms
POSL
13
1. MOTIVATION3. Archface for Java
POSL
14
Archface as ADL
Observer Pattern represented by
Archface
ADL[Port notifyObservers]pointcut notifyObservers() : cflow(execution(void setState(String s))) && call(void notify());
[Port update]pointcut update():execution(void update());
[Connection]connects notifyChange (port1 :cSubject.notifyObservers, port2 :cObserver.update){ around() void :port1 { port2.proceed(); }}
POSL
15
Archface as Program InterfaceArchface
(Program Interface)
Implement
Program Code(Implement exposed program points)
Type check+ formal verification+ test
POSL
16
Software Process with Archface
UML Model elementPointcut
Class diagram class definition classmethod definitionmethodfield definition field
Interaction diagram message sendcall
message receive executionmessage sequence cflow
Bidirectional Traceability Archface supports software
evolution based on bidirectional traceability.
Archface can be considered as a contract defined between architectural design and implementation.
POSL
17
Integration with AO Archface supports not only OO but also
AO architecture. A weaving in AO can be realized by the
component-and-connector mechanism. We do not have to distinguish crosscutting
concerns from primary concerns at the architectural design phase.
Predicate Coordination -> Common Mechanism for integrating AO with OO
POSL
18
Example: Figure Editor
cDisplay cPoint
cLine
change
change
redraw
PrimaryConcerns
CrosscuttingConcerns
PredicateCoordination
PrimaryConcern
(Component)
CrosscuttingConcern
(Component)
PredicateCoordination(Connector)
POSL
19
Compiler construction (Prototype)
Archface definitions
Archface parserAspectJ code
generatorAspect-Factoryclass generator
AspectJweaver
executable program
Archface compiler
AspectJ code (aspect)
Java code (class)
POSL
20
1. MOTIVATION4. Discussion
POSL
POSA Patterns and Archface
21
POSA Archface ComponentEvaluation
Layer Each layer Well-fittedPipes & Filters Data Source, Filter, Data Sink
Well-fittedBlackboard Blackboard, Knowledge Source, Control Well-fittedBroker Client, Client-side Proxy, Broker,
Well-fittedServer-side Proxy, Server
MVC Model, View, Controller Well-fittedPAC {Top,Interm.,Bottom}-Level Agent Well-fitted
Micro kernel Internal server, External server, FairAdapter, 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)
POSL
22
Related Work 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]
Our approach is based on the interface mechanisms that not only enforce architectural constraints on the program implementation but also represent architectural abstractions.
POSL
23
How the problems are resolved Abstraction level of architectural
design Refinement from design to code Co-evolution between design and
code
POSL
24
How the problems are resolved 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.
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.
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.
POSL
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 ?
POSL
26
1. MOTIVATION5. Conclusion
POSL
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.
POSL
28
1. MOTIVATION
Thank you for your attention.
POSL
29
Architectural Verification
Archface
01: #define SYNCH 002: mtype = {setState, getState, notify, update, getSubjectState}03: chan toSubject = [SYNCH] of {mtype};04: chan toObserver = [SYNCH] of {mtype};05:06: proctype cSubject(){07: do08: :: to_Subject?setState -> to_Subject!notify09: od10: }11: proctype cObserver(){12: do13: :: to_Observer?update -> to_Observer!getSubjectState14: od15: }16: proctype notifyChange(){17: do18: :: toSubject?notify -> toObserver!update19: od20: }21: proctype ObtainNewState(){22: do23: :: toObserver?getSubjectState -> toSubject!getState24: od25: }
PROMELA (Observer Pattern)
ModelChecking
Component -> ProcessIn-port -> receive (?)Out-port -> send (!)Control flow -> simplest case
Mapping