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

Slides:



Advertisements
Similar presentations
Requirements Engineering Process
Advertisements

© Gerald Kotonya and Ian Sommerville Viewpoint-Oriented Requirements Methods.
Awais Rashid, Steffen Zschaler
INTRODUCTION TO MODELING
The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development.
Computing Department On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study Phil Greenwood 1 Co-authors:
Software Testing and Quality Assurance
SWE Introduction to Software Engineering
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 71 System models l Abstract descriptions of systems whose requirements are being analysed.
Requirements Analysis Concepts & Principles
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Viewpoint-oriented requirements methods. Objectives To explain the notion of viewpoints in RE To explain the notion of viewpoints in structured analysis.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Overview of Software Requirements
Software Architecture in Practice
Systems Engineering Foundations of Software Systems Integration Peter Denno, Allison Barnard Feeney Manufacturing Engineering Laboratory National Institute.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Deriving AO Software Architectures using the AO-ADL Tool Suite Luis Fernández, Lidia Fuentes, Mónica Pinto, Juan A. Valenzuela Universidad de Málaga
The design process z Software engineering and the design process for interactive systems z Standards and guidelines as design rules z Usability engineering.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
An Introduction to Software Architecture
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Requirements Engineering
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
HCI in Software Process Material from Authors of Human Computer Interaction Alan Dix, et al.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development 1.
Chapter 7 System models.
Lecture 7: Requirements Engineering
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
1 Introduction to Software Engineering Lecture 1.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Aspect-Oriented Requirements Engineering David Schaefer, Joao Araujo, Isabel Brito, Awais Rashid, Claudia Mesquita.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training Copyright © 2009, David Emery & D&S Consultants,
Systems Development Life Cycle
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Requirements Engineering Process
SWE 513: Software Engineering
1 Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Requirements Analysis
From Aspectual Requirements to Proof Obligations for Aspect- Oriented Systems Shmuel Katz and Awais Rashid The Technion Lancaster University Haifa, Israel.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
Aspect-Oriented Software Development (AOSD)
Metadata Driven Aspect Specification Ricardo Ferreira, Ricardo Raminhos Uninova, Portugal Ana Moreira Universidade Nova de Lisboa, Portugal 7th International.
Requirements Engineering Processes, York EngD Programme, 2009Slide 1 Requirements engineering processes Prof Ian Sommerville.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
1 Requirements Elicitation – 2 Lecture # Requirements Engineering Process Requirements Elicitation Requirements Analysis and Negotiation Requirements.
Requirements Engineering Process
Abstract descriptions of systems whose requirements are being analysed
HCI in the software process
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
HCI in the software process
CS310 Software Engineering Lecturer Dr.Doaa Sami
HCI in the software process
Presentation transcript:

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)

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)

Technion Israel Are Aspects Only at the Implementation Level? software development Architecture Design Detailed Design Implementation Testing Requirements Analysis

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?

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

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!

Technion Israel Expectation vs Delivery

Technion Israel

Technion Israel

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

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 –………

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

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

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

Technion Israel Composition specification Requirements-level Aspects Requirements-level aspects Requirements partitioned using viewpoints, use cases, themes, etc.

Technion Israel Early Aspects for Earlier Aspects first manifest themselves in requirements –Reflect stakeholders’ real concerns Separation of concerns should begin with stakeholders’ concerns

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

Technion Israel Further Reading Early Aspects Portal: 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:

Technion Israel Aspect-Oriented Requirements Engineering (AORE)

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

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

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

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

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?

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

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

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

Technion Israel Toll Collection System: Authorised Vehicle Toll Gate Euro 20

Technion Israel Toll Collection System: Unauthorised Vehicle Toll Gate

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

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

Technion Israel Vehicle Viewpoint Subviewpoint

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

Technion Israel Aspects Security Response Time Multi-Access Compatibility Legal Issues Correctness Availability

Technion Israel Response Time Concern Subrequirements

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

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

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

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

Technion Israel Composition Rule for Response Time Requirements - - …

Technion Israel Discussion Point What is a join point at the requirements level?

Technion Israel Composition Semantics: Constraint Actions

Technion Israel Composition Semantics: Constraint Operators

Technion Israel Composition Semantics: Outcome Actions

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

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

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)

Technion Israel Identify contributions between aspects Aspects

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

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]

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

Technion Israel Conflict Resolution Easy!              Need help! React in time vs display correct amount Viewpoints

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

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,..)

Technion Israel From Aspectual Requirements to Architecture

Technion Israel Architectural Choices Response Time Availability Security.... ConcernsArchitecture Choices … … …....

Technion Israel Where Does the Final Architecture Reside? Multi-access Availability Security Correctness Architecture

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: 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: