Analysis and Design Lab

1
Analysis and Design Lab

• Requirements Ruzanna Chitchyan, Awais Rashid,
  Pete Sawyer
• Architecture Jethro Bakker, Mónica Pinto
  Alarcon, Awais Rashid, Alessandro Garcia, Bedir
  Tekinerdogan
• Design Siobhán Clarke, Andrew Jackson

2
Analysis and Deign Lab

• Aims
• Bring together Requirements Engineering,
  Architecture Design and Design work of the
  AOSD-Europe partners in order to
• build a deeper understanding of Early Aspects
• build an integrated AD approach for AO
• reduce duplicated effort
• facilitate collaboration among partners working
  on Early Aspects
• facilitate adoption of Early Aspects
• Partners
• University of Lancaster, UK
• Trinity College Dublin, Ireland
• University of Malaga, Spain
• University of Twente, The Netherlands
• INRIA (Institut National de Recherche en
  Informatique et en Automatique), France
• Technion Israel Institute of Technology, Israel
• IBM United Kingdom Limited, UK

3
Purpose of Survey

• To identify the additional contributions that AO
  has to offer.
• Investigate what are the lessons that AO can
  learn from other techniques.
• Use this comparison to derive a set of key
  challenges for AO.

4
Requirements Engineering

• - Identification handling of functional and NF
  crosscutting concerns
• - Composability
• - Trade-off analysis and decision support
• Traceability
• Support for mapping
• Evolvability
• Scalability

We surveyed 18 AO and non AO approaches
RE Approach
Process
Comparison
Artefacts
Method
What are the artefacts use and produced by this
approach
What steps need to be followed in order to apply
this approach
What the approach sets off to achieve
5
AORE Main Contributions

• Recognition of the need for equal treatment of
  functional and non-functional concerns.
• Recognition that both functional and
  non-functional requirements can have a broad
  crosscutting influence on other requirements.
• Notion and mechanism for requirement
  composability.
• Trade-off identification though composition the
  need for trade-off resolution and decision
  support the importance of its systematic and
  traceable treatment
• Mapping and influence detection support

6
Emerging AORE Process
Concern Identification
Concern Elicitation
Requirement Composition
Concern Representation
Requirement Refinement
Trade-Off Resolution
Requirement Mapping
Legend
Step in the process Flow of activities Overlapping
of activities
Architecture/ Design
7
AO Architecture Design
Goal Explicit identification and representation
of architectural aspects State of the Art More
research is needed. Just compare the low number
of AO architecture approaches in the survey with
those in requirements and design
We surveyed 5 AO and 17 non AO approaches
AO Architecture Approach
Evaluation
Modelling
Design
Modelling architectures visually or textually
Analysis of architecture with respect to required
quality criteria
Explicit processes and heuristic rules for
designing architectures
8
AO Architecture - Comparison

• Traceability
• Composability
• Evolvability
• Scalability

• Lack of support to trace changes in architecture
  artefacts
• Limited support for traceability between
  lifecycle artefacts

• Composition of components, concerns and
  connectors in ADLs
• Composition of models in architecture design
  processes

• Some support for evolvability is provided by
  current proposals

• Different levels of tool support generation of
  code, analysis and validation of properties and
  constraints

9
Contributions of AO Architecture

• Feasibility of using an aspect-oriented ADL (e.g.
  DAOP-ADL)
• Runtime manipulation of AO architecture
  descriptions, hence providing support for
  traceability (e.g. DAOP-ADL)
• Provision of additional support for evaluating
  software architectures (e.g. The Perspectival
  concern space framework)
• Identification of aspects in the domain model
  (e.g. AOGA)
• Mapping of aspects in the domain model to
  architecture artefacts (e.g. AOGA)

10
Emerging Architecture Design Process
11
AOD Lessons learned
We surveyed 22 AOD approaches
Many different levels of design
abstraction High-middle-low
Different levels of concern separation are
supported
AOD Approach
AOD Languages
AOD Processes
There is scope for language integration the
better language features can be composed into a
new AOD language
Heuristics for AOD are not typically well
defined, if at all
12
AOD Lessons learned (Cont)
UML is a basis for many AOD languages and
processes
UML
Extension needed to support crosscutting
Approaches place emphasis on particular views
Behavioral structural views
Meta model
Crosscutting must be described in all views
Crosscutting and non-crosscutting concern design
Concern model design
Composition specification
Many approaches are prog-language dependant
needs to be more generic
Typically not well defined
Composition semantics
13
Emerging Design Process
14
Challenges Way Forward

• Challenges
• Viability Challenge
• Composition Challenge
• Usability Challenge
• Multidimensionality Challenge
• Way Forward
• Integration
• Demonstration of Value
• Adoption