Early Aspects at ICSE:Workshop in AspectOriented Requirements Engineering and Architecture Design 21

1
Early Aspects at ICSE Workshop in
Aspect-Oriented Requirements Engineering and
Architecture Design21 May 2006Aspects,
Architecture, and NFR Group
2
Members

• Christina Chavez, Federal University of Bahia
• Jaelson Castro, UFPE / IRST
• John Hosking, University of Auckland
• Harvey Siy, University of Nebraska at Omaha
• Mikio Aoyama, Nanzan University
• Atsuko Higashi, Nanzan University
• Peter Heidl, Robert Bosch GmbH
• Alessandro Garcia, Lancaster University
• Nelis Boucke, KULeuven
• Paul Clements, Software Engineering Institute

3
Topic Statement

• How can aspects be used in the expression of the
  relationship between requirements and
  architecture?
• We decided that NFRs are not special and we
  could treat requirements in general.

4
Questions we tried to address

• Relation between concerns in requirements, and
  the architecture
• Relations between different views (and their
  representations) domain-specific languages,
  weaving, consistency, composition, wholeness

5
IEEE 1471-2000 Recommended Best Practice for

• IEEE 1471
• Prescribes documenting architecture as a set of
  views
• Starts by capturing stakeholders and their
  concerns
• Requires demonstrating consistency among views
• Are 1471s concerns the same thing as early
  aspects?
• Pre-architecture
• Certainly not unrelated, but they require
  structuring and reasoning before they can become
  aspects
• Does thinking about these as aspects help lead us
  to solutions? Good question!

6
Where do architectural aspects come from? Where
do they go?
Aspects from requirements, domain modeling
activities
Architectureactivity

Aspects come from previousphases, and are
passedthrough, or disposed of. Aspects are
created by thearchitect, and are passedout, or
disposed of.
Aspects passed downstream
7
Do we already do aspect modeling?

• We already use modeling languages
• Notations/representations to capture views (as in
  1471)
• Are modeling languages equivalent to identifying
  and modeling aspects?
• When we use such a language (e.g., to capture a
  view) we address a particular set of concerns

8
Making the models consistent

• Making the models consistent is critical
• Is this a form of aspect composition?
• Early version Kruchtens 41 view
• State of the practice Mapping between views,
  showing consistencies between views, 1471
  requires documenting any known inconsistencies

9
Making the models consistent across phases

• Mapping from phase to phase can be used
• To show model consistency
• To demonstrate traceability
• Some projects require a strong Mapping to
  requirements laid on top of architectural
  design. This is a primitive and informal form of
  model consistency.
• Satisfaction often fuzzy.
• Failure to satisfy leads to requirements
  re-negotiation.

10
How do aspects help?

• AOSD notion of composition seems a promising
  contribution.
• Model composition (as in UML) also seems
  promising to apply.
• Connections to Model-Driven Development community
  needed.