1 / 10

Members

Early Aspects at ICSE: Workshop in Aspect-Oriented Requirements Engineering and Architecture Design 21 May 2006 Aspects, Architecture, and NFR Group. Members. Christina Chavez, Federal University of Bahia Jaelson Castro, UFPE / IRST John Hosking, University of Auckland

hachi
Télécharger la présentation

Members

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 1471’s “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: Kruchten’s “4+1” 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.

More Related