Modeling Traceability of Concerns In Architectural Views

1. Modeling Traceability of Concerns In Architectural Views Bedir Tekinerdogan, Christian Hofmann, Mehmet Aksit Department of Computer Science, University of TwenteThe Netherlands

2. Overview • Architectural Views • Requirements for Concern Traceability in Architectural Views • The Concern Traceability Metamodel • Extending CTM to Trace Concerns in Architectural Views • Instantiating the Metamodel and Tracing Concerns • Discussion

3. View: a representation of a system from the perspective of one or more concerns which are held by one or more stakeholders. Architecture described by identifies Stakeholder ArchitecturalDescription 1..* important to 1..* organized by has 1..* 1..* participates in View Model Concern consists of 1..* Architectural Views Important Concepts from IEEE-Std-1471

4. Module View Component and Connector View Deployment View Architectural Views – ExampleClimate Control System

5. Temperature Control Models can represent different views on the same concern Actuator ReferenceModel TemperatureSensor Controller Actuator Controller Sensor GUI Concerns within and across architectural Views • The elements in every model addresses some concern

6. Traceability • What is it? • Identify dependencies between (crosscutting) concerns and model elements • Relate elements from different models to each other • What is our goal in this paper? • Dealing with Complexity, Understandability • Impact of concerns

7. Requirements for Tracing Concerns • Explicit modeling of concerns • Explicit modeling of dependency relations • Support for Automated Tracing

8. Requirements for Tracing Concerns • Intra-view traceability of concerns • Inter-view traceability of concerns

9. One possible specialization of CTM is the Architectural Concern Traceability Metamodel Concern Traceability Metamodel • Desribed in Detail in another Workshop Paper • (See: Early Aspects Workshop tomorrow)

10. Application of CTM • Instantiating CTM • Modeling concerns and architecture model for case • Defining trace links (mappings) of concerns to architectural elements in the views • Tracing of concerns

11. CTM – Modeling Concerns • Concern • „matters of interest in a software system“ • „design intentions of corresponding stakeholders“ • How to model matter of interest? • Model needs to be very very simple • Entities and Relationships • Can Model nearly everything • See: DBMS

12. 1 ..* 0 ..* Trace source Concern Model Stakeholder ConcernGroup Concern 1 ..* 0 ..* target TraceableElement 1 ..* 1 ..* 1 ..* Concern CTM – Modeling Concerns • Entities • Relationships

13. 1 ..* 0 ..* Trace source 1 ..* 0 ..* target IntensionalTrace - sourceQuery <<meta>> Concern - targetQuery TraceableElement ExtensionalTrace <<instance-of>> ConcernTypeA Concern subconcern phase Concern ConcernTypeB Extending CTM • Giving Additional Semantics Possible • Extension of the Meta-Model • Instances can add new attributes and relations

14. Extension Points Stakeholder ConcernGroup Concern 1 ..* 1 ..* IntensionalTrace 1 ..* 0 ..* Concern Model TraceableElement 1 ..* - sourceQuery source - targetQuery 1 ..* 0 ..* Trace target children ExtensionalTrace 1 ..* 1 ..* Unit UnitModel 1 ..* 1 ..* - reference - name TraceModel ArchitectureModel ArchitectureView ArchitecturalElement 1 ..* 1 ..* advices Variable Part children Architectural Entity Relation Aspect Traceability of Concerns in Architectural Views

15. TraceableElement Traceability of Concerns in Architectural Views • Architectural Models are Artefacts • Units - Artefacts of the Software Development Lifecycle children 1 ..* Unit UnitModel 1 ..* - reference - name ArchitectureModel ArchitectureView ArchitecturalElement 1 ..* 1 ..* advices children Architectural Entity Relation Aspect

16. Implementation in XML <?xml version="1.0" encoding="ISO-8859-1" ?> <!-- definition for view --> <!ELEMENT view ((view)* ,(entity | relation | arch-aspect)*)> <!ATTLIST view id CDATA #REQUIRED phase CDATA #IMPLIED reference CDATA #IMPLIED name CDATA #REQUIRED type CDATA #REQUIRED> <!ELEMENT entity (entity | relation)*> <!ATTLIST entity id CDATA #REQUIRED phase CDATA #IMPLIED reference CDATA #IMPLIED name CDATA #REQUIRED type CDATA #REQUIRED> <!-- A typical element type hierarchy is for example: (super->subclass) (arch-element (allocated-to connector uses extend)) --> <!ELEMENT relation ((from)+, (to)+)> <!ATTLIST relation id CDATA #REQUIRED phase CDATA #IMPLIED reference CDATA #IMPLIED name CDATA #REQUIRED type CDATA #REQUIRED> <!ELEMENT from (entity)+> <!ELEMENT to (entity)+> <!ELEMENT arch-aspect (arch-advice)> <!ATTLIST arch-aspect id CDATA #REQUIRED phase CDATA #IMPLIED reference CDATA #IMPLIED name CDATA #REQUIRED type CDATA #REQUIRED> <!ELEMENT arch-advice (entity | relation)+> <exist:result xmlns:exist="http://exist.sourceforge.net/NS/exist" hitCount="2"> <name>CCS CC</name> <name>CCS DV</name> </exist:result> Qery Execution let $elements := f:getElementFromViewWithName(("cc1", "dv1"),"","Sensor") let $views := f:viewForElement( $elements ) for $view in $views return <name>{ string( $view/@name ) }</name> XPATH Query

17. Conclusion • Concerns can be identified in and across architectural views • Metamodel for traceability of concerns • enhancement of metamodel for tracing concerns in architectural views • Metamodel implementation using XML models and query mechanism through XQuery

18. Conclusion • Use of querying language to select model elements • Makes establishing trace links a lot easier • Arbitrary m:n relationships – crosscutting concerns • Same language for tracing and establishing trace links • Operates directly on the models • Future work • Use model transformation to generate representation from existing models

19. Modeling Aspects • Aspects are Artifacts • Conceptual counterpart: crosscutting concerns

20. Modeling Aspects • Piece of advice is an artifacts • Pointcut language dependent pointcut model relates aspect and advice