Presentation is loading. Please wait.

Presentation is loading. Please wait.

Technion Israel Early Aspects Based on lectures by Awais Rashid, Alessandro Garcia Lectures at AOSD Summer School, Brussels, July 2006 © A. Rashid, A.

Similar presentations


Presentation on theme: "Technion Israel Early Aspects Based on lectures by Awais Rashid, Alessandro Garcia Lectures at AOSD Summer School, Brussels, July 2006 © A. Rashid, A."— Presentation transcript:

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


Download ppt "Technion Israel Early Aspects Based on lectures by Awais Rashid, Alessandro Garcia Lectures at AOSD Summer School, Brussels, July 2006 © A. Rashid, A."

Similar presentations


Ads by Google