Presentation is loading. Please wait.

Presentation is loading. Please wait.

Architectural Point Mapping for Design Traceability Naoyasu Ubayashi and Yasutaka Kamei Kyushu University, Japan March 26, 2012 FOAL 2012 (AOSD Workshop)

Similar presentations


Presentation on theme: "Architectural Point Mapping for Design Traceability Naoyasu Ubayashi and Yasutaka Kamei Kyushu University, Japan March 26, 2012 FOAL 2012 (AOSD Workshop)"— Presentation transcript:

1 Architectural Point Mapping for Design Traceability Naoyasu Ubayashi and Yasutaka Kamei Kyushu University, Japan March 26, 2012 FOAL 2012 (AOSD Workshop)

2 Overview 22 Bidirectional traceability between design and code (preserving appropriate abstraction level) 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 Code Architecture Traceability 1.Abstraction mechanism based on Archpoints (Pointcut-based architectural representation) 2.Traceability link based on Archmapping (Automatic verification using an SMT solver)

3 Outline  Introduction  Architectural points and mapping  SMT-based traceability checking  Conclusions and Future work 3

4 Introduction 4

5 Software architecture  Definition (Bass, L. et. al)  The software architecture of a program or computing system is the structure or structures of the system, which comprise of software elements, the externally visible properties of those elements, and relationships among them.  Architecture plays an important role in software development.  System characteristics such as robustness and maintainability depend on the architecture. 5 Bass, L., et al.: Software Architecture in Practice, Addison-Wesley, 2003.

6 Open issues  Precious design description  Synchronization between design and code 6 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 Code Architecture Important research issue Adequate support for fluidly moving between design and coding tasks Taylor, R. N. and Hoek, A.: Software Design and Architecture -- The once and future focus of software engineering, In Proceedings of 2007 Future of Software Engineering (FOSE 2007), pp.226-243, 2007.

7 Example: Observer Pattern 7 Architectural constraints Class diagramSequence diagram

8 Does this code conform to its architectural design ? 8 It behehaves correctly ! It corresponds to its class diagram ! However It does not conform to its design ! There is a code clone. Correct implementation

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; } } Solution ? – Detailed design descriptions Detailed Model Descriptions Complete code generation However, architectural design should be appropriate abstract ! Program Code 9 Traditional MDD approach

10 Problems to be tackled  It is not easy to reflect the design decisions at the code level.  It is not easy to synchronize design and code with preserving adequate abstraction level.  A mechanism for checking the design traceability is needed. 10

11 Our approach: Archface 11 public class Subject{ private Vector observers = new Vector(); private String state = “”; … } Code Architectural design Archface (Exposure of shared design points) Design Implementation Modification of Architectural design Naoyasu Ubayashi, Jun Nomura, and Tetsuo Tamai: Archface: A Contract Place Where Architectural Design and Code Meet Together. 32rd ACM/IEEE International Conference on Software Engineering (ICSE 2010), ACM PRESS, pp.75-84 (2010). Contract between design and code A set of architectural points A set of program points However, a verification mechanism for design traceability is not provided !

12 Our proposal : A verification mechanism for design traceability  Basic concept  Archpoint: Architectural point  Points for representing the essence of architectural design.  Architecture represented by inter-component structure and message interaction among components can be designed.  ArchMapping: Archpoint mapping  A mechanism for design traceability  An archpoint such as message send in design is mapped to a program point such as method call in code.  Traceability can be verified by checking whether archpoints are consistently mapped to program points while preserving order.  For this checking, an SMT (Satisfiability Modulo Theories) solver is used. 12

13 Architectural points and mapping 13

14 Archpoint and ArchMapping 14 Bidirectional traceability while preserving appropriate abstraction level SMT solver In this talk, Archmapping is introduced from behavioral aspects

15 Bisimulation-based synchronization  There is a bisimulation relation between design and code. We cannot distinguish code from its associated design in terms of archpoints.  Moreover, a sequence of archpoints (behavioral archpoints such as message send) can be regarded as a process if we regard the sequence as a trace of an LTS (Labelled Transition System). 15

16 Bisimulation-based synchronization 16 Abstraction = Bisimulation in terms of archpoints

17 Translation from Archface into logical formula 17 cSubject Component interface cObserver Component interface cObserverPattern Connector interface Architectural design Logical formula AspectJ pointcut

18 Design description 18 Architecture is defined as a set of archpoints and a set of constraints among them. [List 3] Observer_Pattern := sequence(; [predicate] cSubject_setState_message_receive,; archpoint cSubject_notify_message_send,; archpoint cSubject_notify_message_receive,; archpoint iteration(; [predicate] cSubject_update_message_send,; archpoint cObserver_update_message_receive,; archpoint cObserver_getState_message_send,; archpoint cSubject_getState_message_receive)); archpoint

19 Program description 19 A program can be represented as a set of program points and a set of constraints among them. [List 4] Program_List1 := sequence(; [predicate] cSubject_setState_execution,; program point iteration(; [predicate] cSubject_size_call,; program point Vector_size_execution,; program point cSubject_get_call,; program point Vector_get_execution,; program point cSubject_update_call,; program point cObserver_update_execution,; program point cObserver_getState_call,; program point cSubject_getState_execution,; program point cObserver_println_call,; program point System_out_println_execution)); program point

20 Traceability check based on ArchMapping 20 ArchMapping: refine Traceability check Not satisfied ! Code does not conform to it design !

21 SMT-based traceability checking 21

22 SMT (Satisfiability Modulo Theories)  SMT generalizes SAT (Satisfiability).  Theories  Uninterpreted function symbols with equality  Linear real and integer arithmetic  Tuples  Records  Extensional arrays  Yices, one of SMT solvers, decides the satisfiability of logical formulas. 22 Yices: http://yices.csl.sri.com/

23 Yices eccoding 23 A sequence of archpoints Is encoded by an array. Order preservation

24 Example of verification -- Model checking 24 Verification of temporal behavior of architectural design Yices encoding Bounded model checking LTL

25 Conclusions and Future work 25

26 Summary  The essence of our approach is a fruitful integration of  a design abstraction mechanism based on archpoints,  bidirectional mapping between archpoints and program points, and  SMT-based verification. 26

27 Future work  In this paper, we considered only one-to-one mapping between archpoints in design and program points in code.  We think there is a case in which one-to- multiple mapping and multiple-to-one mapping are needed. 27

28 28 Thank you for your attention.


Download ppt "Architectural Point Mapping for Design Traceability Naoyasu Ubayashi and Yasutaka Kamei Kyushu University, Japan March 26, 2012 FOAL 2012 (AOSD Workshop)"

Similar presentations


Ads by Google