Download presentation
Presentation is loading. Please wait.
1
Technion Israel Early Aspects Based on lectures by Awais Rashid, Alessandro Garcia Lectures at AOSD Summer School, Brussels, July 2006 © A. Rashid, A. Garcia (2006)
2
Technion Israel Acknowledgements We have worked with a number of people over the years on this topic. We feel that a special acknowledgement is due to the following people: –Ruzanna Chitchyan, Americo Sampaio, Nelio Cacho, Safoora Shakil Khan, Paul Rayson, Peter Sawyer (Lancaster University) –Ana Moreira, Joao Araújo (Universidade Nova de Lisboa) –Christina Chavez, Thais Batista, Claudio Sant'Anna, Uira Kulesza, Eduardo Figueiredo, Carlos Lucena, Arndt von Staa (PUC-Rio, UFBA, UFRN – Brazil)
3
Technion Israel Are Aspects Only at the Implementation Level? software development Architecture Design Detailed Design Implementation Testing Requirements Analysis
4
Technion Israel AOSD: Myth vs Reality Myth: Aspects only exist during implementation Reality: Aspects have got to come from somewhere for us to design and implement them! How can we implement without modelling and analysing the problem and modelling and analysing the solution?
5
Technion Israel AOSD: Myth vs Reality Myth: Aspects are there for us to better align our design and implementation with broadly-scoped requirements Reality: Aspects can be of benefit to better structure requirements specifications and architectures as well as reason about them
6
Technion Israel More than Just AOP AOSD is more than just addressing scattering and tangling in your programs A different way to approach the problem you are trying to address –Reasoning about aspects of the problem is not the same as reasoning about the program!
7
Technion Israel Expectation vs Delivery
8
Technion Israel
9
Technion Israel
10
Technion Israel Problem space Problem Space Solution space Solution Space Analysis and Design Aspects Aspect-Oriented Requirements Engineering Aspect-Oriented Architectures and Designs Identify aspects Model and analyse the problem Insights into trade-offs and solution rationale Refine aspects/Identify new ones Model and analyse the solution Guidelines for implementation
11
Technion Israel More than Mere Homogeneity If we have aspects at requirements- and architecture-level, we have a nice homogeneous AO separation throughout But there is much more to early aspects than homogeneity –Identifying aspects –Modelling of requirements and architectures –Composability and evolvability –Trade-off analysis –………
12
Technion Israel Dangers with Late Aspect Identification Architecture Design Detailed Design Implementation Testing Requirements Analysis Miss early aspects Difficult to model aspects Misalignment between the problem domain representation and the corresponding solution domain –Causing difficulties for tracing, maintenance, evolution
13
Technion Israel Advantages of Early Aspect Identification Architecture Design Detailed Design Implementation Testing Requirements Analysis All relevant aspects can be identified Modelling aspects from domain knowledge Alignment between the problem domain concepts and the corresponding solution domain artefacts –Improving traceability, maintenance, evolution
14
Technion Israel What is an Early Aspect? A concern that crosscuts an artefact’s dominant decomposition, in the early stages of the software life cycle. or: A broadly scoped property: one that has an affect on multiple early-lifecycle artefacts with potential consequences to later development stages
15
Technion Israel Composition specification Requirements-level Aspects Requirements-level aspects Requirements partitioned using viewpoints, use cases, themes, etc.
16
Technion Israel Early Aspects for Earlier Aspects first manifest themselves in requirements –Reflect stakeholders’ real concerns Separation of concerns should begin with stakeholders’ concerns
17
Technion Israel Early Aspects for Later Aspects in requirements can become aspects in architecture; Aspects in architecture can become aspects in design; Aspects in design are aspects in code Early Aspects provide: –Broader Vision: improved localised description of stakeholder needs, by addressing the crosscutting concerns, as gathered by domain experts –Improved Traceability: allowing developers to know how aspects arose –Improved Trade-off Handling: providing insight into the true scope and influence of a concern
18
Technion Israel Further Reading Early Aspects Portal: http://www.early-aspects.net Discovering Early Aspects, Baniassad, Clements, Araujo, Moreira, Rashid, Tekinerdogan, IEEE Software 23(1), Jan/Feb 2006 Special Issue on Early Aspects, IEE proceedings - Software Engineering - Volume 151, Issue 04, August 2004, (Rashid, Moreira, Tekinerdogan (eds)) Report synthesising state-of-the-art in aspect- oriented requirements engineering, architecture and design, Chitchyan et al., Available from: http://www.aosd-europe.net
19
Technion Israel Aspect-Oriented Requirements Engineering (AORE)
20
Technion Israel Aspect-Oriented Requirements Engineering Improved support for separation of crosscutting functional and non-functional properties during requirements engineering –A better means to identify and manage conflicts arising due to tangled representations Identify the mapping and influence of requirements-level aspects on artefacts at later development stages –Establish critical trade-offs even before the architecture is derived Trace aspectual requirements and their trade-offs to architecture and subsequently all the way to implementation Improved understanding of the problem and ability to reason about it
21
Technion Israel Identifying Aspects A challenging problem Requirements documents tend to be unstructured Requirements can take a variety of forms –Natural Language –Interviews –Sketches –Standardisation documents –Organisational procedures –……… Think multi-disciplinary when developing techniques for aspect identification –Natural language processing –Ethnography techniques
22
Technion Israel Join Point Models Thinking beyond programming language models Concerns are more abstract –Join point models serve a very different purpose –Facilitating specification of constraints, semantic influences or dependencies
23
Technion Israel Weaving/Composition What does it mean to weave or compose aspectual requirements? Projecting the constraints and influences of aspectual requirements on other system requirements A synthesis of the various projections that provides a deeper understanding of the system that we want to develop –Critical needs of the stakeholders –Identification of the key properties of a system –Various trade-offs affecting the system
24
Technion Israel Mapping and Traceability How do Early Aspects map onto later development stages? Is an Early Aspect always a design and implementation aspect? How can we ensure forward and backward traceability between early aspects and corresponding design and implementation? How do we know that the early aspect trade-offs are preserved and respected by the design and implementation?
25
Technion Israel A Viewpoint-based Model for AORE Viewpoints specify stakeholder requirements Aspects crosscut the viewpoints Composition information separated from aspects Fine-grained composition relationships –Observe the influence of an aspectual requirement on individual viewpoint requirements Explicit support for establishing aspectual trade-offs and subsequent negotiations
26
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
27
Technion Israel Requirements Representation and Tool Support XML –Extensible language for specification of viewpoints, aspects and their composition EA-Miner: NLP-based tool for identifying aspects in requirements ARCaDe: Aspectual Requirements Composition and Decision Support Tool –DOM, SAX and eXist Native XML database
28
Technion Israel Toll Collection System: Authorised Vehicle Toll Gate Euro 20
29
Technion Israel Toll Collection System: Unauthorised Vehicle Toll Gate
30
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
31
Technion Israel Viewpoints ATM Vehicle –Unauthorised Vehicle Gizmo Toll Gate –Entry Toll –Paying Toll Single Toll Exit Toll Police Debiting System System Administrator Vehicle Owner –Registration –Billing –Activation
32
Technion Israel Vehicle Viewpoint Subviewpoint
33
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
34
Technion Israel Aspects Security Response Time Multi-Access Compatibility Legal Issues Correctness Availability
35
Technion Israel Response Time Concern Subrequirements
36
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
37
Technion Israel Aspect/Viewpoint Relationships Legend: Pol: Police; Gz: Gizmo; DS: Debiting System; ATM: ATM; TG: Toll Gate; Vh: Vehicle; UV: Unauthorised Vehicle; VO:Vehicle Owner; Adm: Administrator. VP
38
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
39
Technion Israel Composition Rule for Response Time Requirements - - … Action and operator specifying how the viewpoint requirements are constrained by the specific aspectual requirements Describes whether another (or a set of) viewpoint requirement must be satisfied or merely the constraint specified fulfilled Subrequirements must be explicitly excluded or included
40
Technion Israel Composition Rule for Response Time Requirements - - …
41
Technion Israel Discussion Point What is a join point at the requirements level?
42
Technion Israel Composition Semantics: Constraint Actions
43
Technion Israel Composition Semantics: Constraint Operators
44
Technion Israel Composition Semantics: Outcome Actions
45
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
46
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
47
Technion Israel Ye Old Interaction Problem Composition reveals aspects that interact with reference to the same or overlapping set of requirements Interactions are not always bad! –Interacting aspects may reinforce each other (positive contributions) –Interacting aspects may hinder each other (negative contributions)
48
Technion Israel Identify contributions between aspects + + + + + Aspects
49
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
50
Technion Israel Attribute Weights to Conflicting Aspects (1) Attributing weights to those aspects that contribute negatively to each other –Priority of an aspect in relation to a set of stakeholders’ requirements –Extent to which an aspect may constrain another concern Very important takes values in the interval [0,8.. 1,0] Important takes values in the interval [0,5.. 0,8] Average takes values in the interval [0,3.. 0,5] Not so important takes values in the interval [0,1.. 0,3] Do not care much takes values in the interval [0.. 0,1]
51
Technion Israel Identify & specify viewpoints Identify & specify aspects Identify coarse-grained aspects/viewpoints relationships Define composition rules Compose aspects & viewpoints Build contribution table Attribute weights to conflicting aspects Resolve conflicts Handle conflicts Revise req.specification Specify aspect dimensions Compose Identify & Specify
52
Technion Israel Conflict Resolution Easy! Need help! React in time vs display correct amount Viewpoints
53
Technion Israel An Alternative Specifications based on typical scenarios/ Use Cases Aspectual use case: cuts into other scenarios Instead of having the same special option/exception in a lot of use cases Once aspect scenarios are identified, can be used in similar ways to viewpoint-based ones
54
Technion Israel Aspect Scenarios: ATM example Regular scenarios: –Make a withdrawal –Get a record of recent activity –Deposit a check Aspect scenarios: –Communication failure: abort scenario until now, return card, announce failure –Debit account for some activities (over 7 records of recent activity in a month, each transfer,..)
55
Technion Israel From Aspectual Requirements to Architecture
56
Technion Israel Architectural Choices Response Time Availability Security.... ConcernsArchitecture Choices … … …....
57
Technion Israel Where Does the Final Architecture Reside? Multi-access Availability Security Correctness Architecture
58
Technion Israel Further Reading EA-Miner: A Tool for Automating Aspect-Oriented Requirements Identification, Sampaio, Chitchyan, Rayson, Rashid, Proc. Automated Software Engineering Conf. 2005, ACM. Modularisation and Composition of Aspectual Requirements, Rashid, Araujo, Moreira, Proc. AOSD Conference 2003, ACM. Multi-dimensional Separation of Concerns in Requirements Engineering, Moreira, Rashid, Araujo, Proc. Requirements Engineering Conf., 2005, IEEE CS Press. Early Aspects Portal: http://www.early-aspects.net Discovering Early Aspects, Baniassad, Clements, Araujo, Moreira, Rashid, Tekinerdogan, IEEE Software 23(1), Jan/Feb 2006 Report synthesising state-of-the-art in aspect-oriented requirements engineering, architecture and design, Chitchyan et al., Available from: http://www.aosd-europe.net
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.