Aspect-Oriented Requirements Engineering

1
Aspect-Oriented Requirements Engineering

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

2
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?

3
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.

4
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

5
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

6
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

7
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 gt greater
  flexibility
• - Difficult to integrate with other techniques
• - Higher maintenance costs
• Int Complex structure might make it difficult to
  identify an aspect

8
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

9
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 tool
• Int 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

10
Validation (1)

• Solution 1 Prototyping
• Intensive participation of stakeholders at an
  early stage
• - Things can be missed
• Solution 2 Formal methods
• Precision
• - Doesnt mean it is correct
• - Hard to obtain input from stakeholders
• - Can be complicated an expensive

11
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 design
• Int Decision on architecture may be too early

12
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