Aspect-Oriented Requirements Engineering

David Schaefer, Joao Araujo, Isabel Brito, Awais Rashid, Claudia

Mesquita

Problems

• How to identify aspects at the requirements level?– What is the relationship between aspects and non-

functional requirements, constraints and concerns?

• How to model aspects at the requirements level?• How to trace requirements level aspects through

later development stages and during re-engineering?

• How to validate aspects identified at the requirements level?

Identifying Aspects (1)

• Solution 1: Model using viewpoints/use cases/scenarios/stakeholder concerns and then identify crosscutting requirements.+ Exploit the power and potential of existing mechanisms- Scalability problems. Hard to observe crosscutting in the

presence of a large number of viewpoints, use cases or scenarios.

Int Easier to see the functional crosscutting against a base SOC

Int Adapt existing techniques.

Identifying Aspects (2)

• Solution 2: Brainstorming without the modelling.+ No effort required for initial structuring

- You could be absolutely list: brainstormed!

- You are bound to miss something

Int You could find aspect you might not find using other techniques

Identifying Aspects (3)

• Solution 3: Look at global properties, non-functional requirements and constraints as they are potential aspects+ Easier to spot

Int Might not necessarily be global

Modelling Aspects (1)

• Solution 1: Extension of existing modelling mechanisms e.g. OO, FSM, Concern-based+ Ride the power of existing techniques

+ Ease of integration with existing techniques, tools, etc.

+ Ease of learning

- Inherit the shortcomings of existing techniques

Modelling Aspects (2)

• Solution 2: Express them as requirements affected by multiple concerns in a concern graph. The edges of the concern graph express satisfaction of requirements by certain other entities. + No modelling restrictions => greater flexibility

- Difficult to integrate with other techniques

- Higher maintenance costs

Int Complex structure might make it difficult to identify an aspect

Traceability (1)

• Solution 1: Concern graph developed through stepwise concretisation of concerns. The leaves of the graph are the code and in between are other documents such as design. + Good traceability

- Maintenance and scalability

Int Development time is a question of evaluation in real world systems development

Traceability (2)

• Solution 2: Re-engineering: Tool to find aspects in your code. Some form of code mining and extract patterns of crosscutting.+ Tool support- Effort to develop a toolInt Accuracy

• Solution 3: Guidelines for the mapping and influence of aspects to later stages perhaps influenced by domain analysis.+ Early identification of traceability- Need really good guidelines otherwise mistakes are likely

Validation (1)

• Solution 1: Prototyping+ Intensive participation of stakeholders at an early stage

- Things can be missed

• Solution 2: Formal methods+ Precision

- Doesn’t mean it is correct

- Hard to obtain input from stakeholders

- Can be complicated an expensive

Validation (2)

• Solution 3: Domain analysis+ Domain constraints taken into account- Hard to generalise

• Solution 4: Early architecture development (in parallel with requirements modelling)+ Early exchange of information between

architecture and requirements designInt Decision on architecture may be too early

Conclusion

• Need a systematic process to identify, model and validate concerns– Exploit existing mechanisms for backward

compatibility, their existing user base and power

– Scalability and traceability are critical

– Validation is extremely important though hard to achieve

– Domain analysis and stepwise development has an important role to play