Jan's Review

Summary

---

Requirements documents contain information about the concerns (here: “themes”) of a software system. By analyzing these documents, the authors claim they can derive a list of potential concerns and group them into base- and crosscutting concerns. The approach thus provides the basis for an aspect-oriented modeling of the system. It further ties the requirements to the respective concerns, allowing for traceability between the two.

Contributions

---

• The paper does present a relatively straight-forward approach for modeling aspect-oriented systems based on their requirements documentations. For small systems, the approach seems to aid the developer in determining concerns and separating them into base- and crosscutting concerns.
• The Augmented Views are a nice and intuitively transparent way to illustrate crosscutting concerns of limited scope.
• Similarly, the (clipped) Action Views are nice illustrations of the system’s concerns and their relationships.
• A major contribution of this paper is the “traceability”: tying requirements to the system design. While it seems to work better for backwards references than for forward ones, this should be very useful.

Weaknesses

---

• A fundamental problem with the paper is that when discussing their goal “effectiveness of support for aspect identification”, no indication of the effort required to identify aspects/CCCs is provided. Does it take an amount of time comparable to what a “standard” approach would take?
• Similarly, their discussion of this topic (3.3.1) is not too convincing: only one extra CCC (out of 8) has been identified using the tool (as opposed to a naïve reading/analysis of the requirements). The point that their approach helps determining binding order is potentially good, but not substantiated.
• The difference/relationship between “themes” and concerns is unclear.
• To better gauge their analysis of requirements it would be helpful to have an example of a more complex requirement. The CMS requirements seem artificially simple: each one only uses 1-2 verbs and exactly 2 nouns (except req. 9, which has 3), resulting in a rather sparse Action View.
• Scalability is another problem: despite the author’s claims that they “identified functionality that would enhance the scalability” (see 6.), the approach appears to be limited to small software systems. Hinting that “more degrees of zooming” would “likely be useful” (3.3.4) is not concrete enough.
• The process described for clipping (2.2) seems rather subjective. How can the tool help here in suggesting what to clip? In general, at this point the advantage of having tool support is unclear.

Questions

---

• My understanding is that the chosen decomposition determines which concerns are crosscutting and which are not. In the presented examples it appears that only one decomposition makes sense. Is that realistic?
• How much of the aspect modeling information can really be derived from the requirements documentation alone? In several parts of the paper the authors seem to adjust the requirements to fit the tool (i.e., 4.3)
• In figure 8: why does student have a “has” relationship with the register theme? Intuitively, I’d assume “has” only applies between classes.
• Scattered requirements (4.2): this may be a good point. Can this approach help to identify non-explicit requirements?
• Requirements evolution (4.4): Can the tool point out discrepancies between two versions? The next logical step would be to suggest refactorings to adapt to the changed requirements. Also: do the developers have to go through the same steps as before, or can they save time and effort (e.g., do they need to re-discover ambiguities, synonyms, scattered requirements, etc.?)
• Ignoring problems like ambiguities (section 4.3), can’t the approach be simplified? For example, it seems that all verbs in the requirements map to actions (which are candidates for concerns, crosscutting or base), while all nouns seem to map to classes – this should alleviate the developer from identifying the key actions “by looking at the requirements document”. Further, can concerns/themes be automatically classified based on the kinds/number of relationships they have? For example, if a theme is related to few other themes it is likely a base concern, while otherwise it is likely crosscutting (Compare logging in example 1; prompt, accumulate, track energy etc. in example 2). This might be a better starting point for a classification that “intuition and […] cursory analysis of the view”. While the approach can not be fully automated, it seems that it could be better aided by the tool.

Terry's Review

Summary

---

This paper addresses the problem of analyzing requirements to identify aspects. It is a hard process to identify aspects, and later on associate requirements satisfied for each aspect (traceability). The authors introduce the Theme approach as the solution. It uses the term "theme" as a collection of structures and behaviours that represent one feature. The two segemnts of the Theme approach (Theme/Doc and Theme/UML) provide support in the requirements/analysis phase and the design phase respectively.

The action view in Theme/Doc tool performs lexical analysis on the original requirements document and identify all the actions. The view shows each sentence and how it relates to the actions. Aspects are identified by examing shared requirements. The action view can be further organized by performing "clipping".

The theme view provides a link between requirements and design by showing actions and key entities needed for each theme's design. Colours are used to distinguish between crosscutting and non-crosscutting elements in the view. Theme/UML are used to produce each theme's design from Theme/Doc views. There is also an augmented theme view for verifying that the design satisfies the requirements.

A case study is performed by the authors on a medium-size software.

Contributions

---

• an interesting approach to identification of aspects
• innovative views for displaying requirements/design
• provide traceability between aspects and requirements

Weaknesses

---

• case study users are the authors themselves, hence usability is not really tested
• I'm not sure that the steps needed to design a theme is so easy even in the medium-size software presented in the case study. The use of "we examined... then determined..." seems to glaze over the difficulties of actually coming up with the decision.
• I'm still not convince that these views would scale. Even figure 10 and 11 seem pretty daunting to go through.

Questions

---

• Would the use of synonyms (4.1) increases complexity of what the user has to go through? It seems like each word has so many synonyms that automating this step may not be that simple, leaving the user with more work than before.
• the augmented view seems very confusing to me. There are many different kinds of arrows that are supposed to mean different things. Are they trying to convey too much in one view?

Lyndon's Review

Summary

---

Aspects are used to encapsulate the crosscutting behaviour in a system. Being able to identify and model all the aspects of a system from the requirements is a difficult task. Some can be found by looking for common aspects, like logging. But other aspects may be subtle and require more effort to find. The Theme approach is presented to identify and analyze the relationships between behaviours from the requirements document.

Contributions

---

• A model that helps developers identify aspects and where they crosscut in the system
• An approach that maintains traceability between the requirements and design
• Case study of the Theme approach

Weaknesses

---

• (2.2) Identifying a list of key action verbs is quite cumbersome.
• (2.2) The clipping functionality that finds the aspects, is mainly performed by the developer, not the tool. Also, there are no details on how the decision between base and crosscutting classification is made.
• (Section 2) Too many figures showing different views made the paper hard to follow.
• (3.3.3) Traceability from theme view sentences to the requirements is done by scanning the original text for the matching sentence. This functionality would be more helpful with tool support.
• (4.1 & 4.3) Relying on lexical text analysis and a synonym dictionary still leaves problems with linguistic ambiguities, which are fixed by manually checking the views. This doesn't scale to larger systems, where it become more difficult to spot these errors.

Questions

---

• What is the significance of determining the binding order of crosscutting themes? How is this information used with aspects? (3.2.2)
• Would an aspect developer benefit from using this tool, given the amount of interaction needed from a developer?