Session 15 Modeling Traceability of Concerns in Architectural Views

1. Session 15Modeling Traceability of Concerns in Architectural Views Mark Stobbe October 29, 2007

2. Outline • Traceability • What? / Why? / How? • Introducing aspects • ‘Early’ aspects vs. ‘Late’ aspects • Traceability of aspects • Comments on the paper • Relation to AOP • Comparison

3. Traceability What? Why? How? Matrices Keywords Information Retrieval methods Scenario based Event based Process centered Design Pattern based • Validation • Change impact • Design decisions • Document! • Forward and backward

4. Answering question Question What is meant by "artifacts" in section 3.1? (Martijn) Answer Artifact (also artefact, in Dutch bijproduct): an artificial product or effect observed in a natural system, especially one introduced by the technology used in scientific investigation or by experimental error. In the paper, use cases, class diagrams, test suites, design documents, etc. Pretty much anything that you want to trace and can be linked.

5. Introducing aspects • Localized • Functional vs. non-Functional • Special compiler Requirements Early Aspect Design Implementation Late Aspect

6. non-Aspect Example interface Shape { public moveBy(int dx ,int dy); } class Point { publicint x, y; publicint getX() { return x; } publicint getY() { return y; } publicvoid setX(int x) { this.x = x; Display.update(); } publicvoid setY(int y) { this.y = y; Display.update(); } publicvoid moveBy(int dx, int dy) { x += dx; y += dy; Display.update(); } } class Line { public void moveBy(int dx, int dy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; Display.update(); } }

7. Aspect Example interface Shape { public moveBy(int dx ,int dy); } class Point { publicint x, y; publicint getX() { return x; } publicint getY() { return y; } publicvoid setX(int x) { this.x = x; } publicvoid setY(int y) { this.y = y; } publicvoid moveBy(int dx, int dy) { x += dx; y += dy; } } class Line { public void moveBy(int dx, int dy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; } } aspect Update { pointcut change(): execution(void Point.setX(int)) || execution(void Point.setY(int)) || execution(void Shape+.moveBy(int, int)); after() returning: change() { Display.update(); } }

8. Change scenario • Change public fields in Point to private • Interface changes, visible in Line • Aspect needs change, cflowbelow • Gregor Kiczales and Mira Mezini argue the need for ‘aspect-awareness’

9. Comments on the paper • Extension of Jethro Bakker’s thesis • Missing aspect application to CTM • No M-Trace tool

10. Answering question Question In order to explicitly reason about traceability of the concerns in architectural views it is necessary that the corresponding concerns are explicitly modeled as first-class abstractions. Could you explain this? What do they mean? (3.1 Explicit Modeling of Concerns) (Robin) Answer A first-class object is an object which do not have restrictions. In Haskell, functions are first-class citizens, meaning you can pass them to other functions (so-called, higher order functions).

11. Answering question Question The paper talks about symmetric and asymmetric approaches. Could you give a small explanation of this? (3.1 Explicit Modeling of Concerns) (Robin) Answer In general it means that two things are either the same or different, ie. symmetric. In this paper, they compare ‘concerns’ with ‘artifacts’ and if they are symmetric or assymmetric.

12. Relation to AOP

13. Answering question Question In the paper the authors mention that it is not always possible to trace the concerns by providing specific names. They say that you need domain specific knowledge to characterize the concerns. Could you describe how domain specific knowledge can be applied?(Alesya) Answer The proposed model is a “general-purpose meta-model”. It can be applied to all domains, whereas you sometimes want specific domain knowledge, like special artifacts. One way to obtain this would be to extend this model with a specific instance, another possibility is to add extra meta-data. Actually, one could also think of the proposed meta-model as an instantiation with relation to aspect-oriented development.

14. Answering question Question In the paper they talk about how they do the modeling but only in the conclusion they talk a little bit about how it's applied and what problems they encountered there ("for some concerns it appeared that sufficient domain knowledge was necessary to define the appropriate queries"). Are there some more details published about that perhaps? (Christiaan) Answer No. They give an extensive example of how this meta-model should be applied. (also see Alesya’s question)

15. Meta Aspect for Traceability • Early Aspect Model • Controller Model • Rule Model

16. Answering question Question I don't really understand the proposed Meta-model. Could you explain this? (Robin) Answer A model for defining the relationships between requirements, tests, design and code. So, this is on top of the existing software development lifecycle.

17. Answering question Question Could you imagine some other problems you could run into? (Christiaan) Answer There is still a lot to be done in this field. Especially tool support seems to be essential. In practice, the traceability matrices are most common, because there is tool support for this. Also, the discipline to document everything and link everything together is often time consuming. The CTM framework does not support consistency or completeness, which was the main reason for the authors of the MAT framework.