May 2004DBO - 1 -

Early AspectsOverview of Some Approaches

David Bar-On

April 2004

May 2004DBO - 2 -

References for AORE / Early Aspects [Nuseibeh] Bashar Nuseibeh “Crosscutting Requirements”, AOSD conference 2004

keynote presentation, http://aosd.net/2004/archive/AOSD-FromPromiseToReality.ppt [Mylopoulos ] John Mylopoulos at al “Exploring Alternatives During requirements

Analysis”, IEEE Software, January/February 2001, http://ieeexplore.ieee.org/ [Sousa]Sousa, G.; Silva, I. and Castro, J. (2003) “Adapting the NFR Framework to

Aspect-Oriented Requirements Engineering”. XVII Brazilian Symposium on Software Engineering, Manaus, Brazil, October. (Or: Geףrgia Sousa, Sיrgio Soares, Paulo Borba and Jaelson Castro “Separation of Crosscutting Concerns from Requirements to Design: Adapting an Use Case Driven Approach”, Informatics Center – Federal University of Pernambuco (UFPE) AOSD2004, http://trese.cs.utwente.nl/workshops/early-aspects-2004/Papers/SousaEtAl.pdf)

[Rashid02] Rashid A.; Moreira, A. and Araujo, J. “Early Aspects: a Model for Aspect-Oriented requirements Engineering”, IEEE Joint Conference on Requirements Engineering, Essen, Germany, September 2002, http://www.comp.lancs.ac.uk/computing/aose/papers/AORE_RE2002.pdf

[Rashid03] Rashid A.; Moreira, A. and Araujo, J. “Modularization and Composition of Aspectual Requirements”, 2nd international conference on AOSD, ACM, pp. 11-20, 2003, http://www.comp.lancs.ac.uk/computing/aose/papers/AORE-AOSD2003.pdf

[Moreira] Moreira, A.; Araujo, J.; Brito, I.; “Crosscutting Quality Attributes for Requirements Engineering”, 14 th International Conference on Software Engineering and Knowledge Engineering (SKE 2002), ACM Press, Italy, July 2002, http://portal.acm.org/ (alternative http://trese.cs.utwente.nl/AOSD-EarlyAspectsWS/Papers/Brito.pdf)

[Brito] Isabel Brito, Ana Moreira “Towards a Composition Process for Aspect-Oriented requirements”, workshop on Early Aspects: AORE and Architecture Design, March 17 – Boston, USA, 2003, http://www.cs.bilkent.edu.tr/AOSD-EarlyAspects/Papers/BritoMoreira.pdf

[Bergmans] Bergmans, L.; Aksit, M. “Composing Crosscutting Concerns using Composition Filters”, Communications of the ACM, Vol. 44, No. 10, October 2001, http://portal.acm.org/

[Grundy] John Grundy “Aspect-oriented Requirements Engineering for Component-based Software Systems”, Proceedings of RE’99, 7-11 June, Limerick, Irland, 1999, http://ieeexplore.ieee.org/

[BaniassadTheme] E. Baniassad, S. Clarke “Theme: An approach for aspect-oriented analysis and design”, International Conference on Software Engineering, 2004, http://www.cs.tcd.ie/Elisa.Baniassad/theme.pdf

[BaniassadDoc] E. Baniassad E., E. Siobhan “Finding Aspects in Requirements with Theme/Doc”, ??? AOSD Conference 2004 ???, http://trese.cs.utwente.nl/workshops/early-aspects-2004/Papers/Baniassad-Clarke.pdf

May 2004DBO - 3 -

Presentation Plan

• Overview of requirements Engineering (RE)• Crosscutting (Aspectual) Requirements• Overview of works related to Early Aspects /

AORE

May 2004DBO - 4 -

Requirements Engineering (RE)[Young], [Nuseibeh]

• RE is about discovering customers’ needs (goals and expectations), extending them if needed and communicating them to implementers

• Requirements– Expression of customer needs and expectations to achieve particular

goals– Defined in the Problem Domain, not the Solution Domain– Typically not formal and textual in many cases– Use Cases / Scenarios are major source of customer needs

• Customer needs and expectations:– Business requirements User requirements– Product requirements– Environmental requirements– Unknowable requirements

May 2004DBO - 5 -

SMART Requirements [Mannion and Keepence, 1995]

• Specific: no ambiguity, consistent terminology• Measurable: verifiable• Attainable: technically feasible• Realizable: realistic, given the resources• Traceable: linked from its conception to

implementation and test

May 2004DBO - 6 -

Types of requirementsRequirements Analyst (RA) view [Young]

• High Level / System Level requirements

• Functional requirements

• Non-Functional (or nonbehavioral) requirements– System properties (e.g. safety)

– The “ilities/specialty engineering requirements” (Designability, Efficiency, Portability, reliability, testability, Maintainability, etc.)

• Derived requirements and design constraints

• Performance requirements

• Interface requirements (relations between system components)

May 2004DBO - 7 -

FR and NFR [MalanFR], [MalanNFR]

• Functional Requirements (FR)– Capture the intended behavior of the system– Can be expressed as services, tasks or functions the system is required to

perform– Includes baseline functionality needed by the system to be competitive

and features that differentiate it from competitors

• Non-Functional Requirements (NFR)– Requirements that impose restrictions on the product being developed, or

development process or specify constraints [Sousa]– Properties that emerge from the combination of a system’s parts/features– NFR can be split into:

• Qualities: characteristics that the customer cares about and therefore affect satisfaction. May be negotiable (e.g. Reliability, Availability, Usability, Performance, Security, Robustness, Quality, Persistence, Configurability, Supportability, Performance, Safety, Scalability)

• Constraints: Non-negotiable system properties and characteristics (e.g. “Super-System” characteristics, Operating System, HW, Legacy)

May 2004DBO - 8 -

Requirements Terminology to Avoid [Young]

• Source or Customer Requirements– Specify the individual source of the requirements

• Nonnegotiable Versus Negotiable Requirements– Use “minimum requirements”

• Key Requirements– More details are needed: benefit-to-cost ratio, risk, estimated time and

effort to implement, etc.

• Originating requirements– Avoid referring to the requirements initially established, as it is not clear

• Other guidelines:– Avoid using vague terminology (usually, flexible, etc.)– Avoid putting more the one req in a req (helps traceability and testability)– Avoid clauses like “if that should be necessary”– Avoid wishful thinking (running on all platforms, 100% reliability, etc.)

May 2004DBO - 9 -

Crosscutting/Aspectual Requirements

• Crosscutting Requirements (Req Aspects) [Nuseibeh]– Aspect = Crosscutting Concern– Aspectual Requirement = Crosscutting Requirement– Concern: property of interest to a stakeholder– Crosscutting: interacting, interdependent, overlapping

• Quality Attributes (QA) [Moreira]– Quality Attribute is a synonym to crosscut-NFR– QA: properties that affect the system as a whole

(QA is similar to [Young] “ilities”)– QAs are handled together with the FRs

May 2004DBO - 10 -

AORE Related works Identified• Combined AND/OR diagrams of Goal and Softgoal - encourages separation the

analysis of Softgoals (NFR) concern [Mylopoulos]• Modularization and Composition of Aspectual Requirements using an AORE

process model (Concerns/SR matrix, set weight/priority to contributions between aspects, identify aspect Influence and Mapping dimensions. Suggest concrete model with Viewpoints and XML (ARCaDe) [Rashid02, Rashid03]

• Adaptation of the NFR-Framework to AORE – enhancements using NFR operationalizations instead of abstract NFR (uses parts defined in [Mylopoulos], [Rashidx]) [Sousa]

• Crosscutting Quality Attributes – NFR from the point of view of the FR [Moreira]• Towards a Composition Process for AOR [Brito] (TBD: combine with [Moreira]) • Composition Filters [Bergmans]• AORE for Component Based Software Systems [Grundy]• Theme and Theme/Doc - Finding Aspects in Requirements

[BaniassadTheme, BaniassadDoc]• ??? UML extensions for AOSD/AORE ???? Theme/UML ?? []• ???? Viewpoints ??? [Nuseibeh]

May 2004DBO - 11 -

Goal Oriented Requirements Analysis

[Mylopoulos]

May 2004DBO - 12 -

Goal Oriented Requirements Analysis (1)[Mylopoulos]

• RE should explore alternatives and evaluate their feasibility & desirability in addition to understanding & modeling functions, data, interfaces

• Exploring alternatives allows to refine the meaning of terms and define the basic functions the system will support

• Goal Oriented requirements analysis main steps (input is a set of functional goals):

1. Goal analysis - explore goals alternatives (using decomposition of each functional goal into AND/OR)

2. Softgoal analysis - analysis of NFRs/QAs (decomposing each given quality into softgoal hierarchy)

3. Softgoal correlation analysis (identify correlations between softgoals)4. Goal correlation analysis (identify correlation between goals and

softgoals)5. Evaluation of alternatives (select a set of goals and softgoals)

May 2004DBO - 13 -

• AND/OR decomposition diagrams allow exploring goals alternatives– Systemize the exploration of alternatives within a space that can be very large– A simple algorithm (details TBD) is used to evaluate whether the root goal was achieved or not

Goal Analysis using AND/OR Decomposition (2)

Notation: Goal; Root Goals supported by checked leaf goals; Softgoal; AND; OR

Example: AND/OR decomposition of alternatives for achieving the meeting-scheduling goal

May 2004DBO - 14 -

Softgoal Analysis (3,1)

(the softgoal notion is presented in detail in the book “Non-Functional Requirements in Software Engineering”, by L. Chang et al, Kluwer Publishing, the Netherlands, 2000)

• Softgoal: usually NFR/QA, represent ill-defined goals and their interdependencies

• Softgoal is satisfied when there is sufficient positive evidence in favor of it and little negative evidence against it

• Softgoal hierarchies can be built by asking what can be done to satisfy (or support) a particular softgoal

May 2004DBO - 15 -

Softgoal Analysis Example (3,2)

• Softgoal Analysis use extended AND/OR diagrams with dependency/hierarchies relationships Example for

“High Usable System” Softgoal - only this softgoal is expanded

Dependencies/relationships labeled with “+” when one softgoal supports (positively influences) another

May 2004DBO - 16 -

Softgoal Analysis (3,3)

• Relevant knowledge for identifying softgoal decompositions and dependencies might be generic and related to the softgoal being analyzed

• Number of generic decompositions to finer-grain quality factors are available for general software system qualities (QAs)– Example: Speed Performance softgoal can be AND-decomposed

into three softgoals:• Minimize User-Interface• Use Efficient Algorithms• Ensure Adequate CPU Power

• Project/task specific decomposition methods can still be used after agreement among project’s stakeholders

May 2004DBO - 17 -

Softgoal Correlation Analysis (4)

• Quality Goals frequently conflict with each other

• Correlation analysis helps discover positive or negative relations between softgoals

May 2004DBO - 18 -

Goal Correlation Analysis (5)• Goal Correlation Analysis correlates goals with the

softgoals identified, to compare and evaluate the goals• Combined Goal and Softgoal AND/OR diagrams encourages separation the analysis of the softgoals (NFR) concerns• Distinguishing between goals and softgoals encourage separating the analysis of a quality sort from the object to which it is applied

Subgoals analysis: Quality-of-Schedule Minimal-Effort Effort

Checked leaf goals that collectively satisfy all given goals (see next slide)

Schedule-meeting goals refinement analysis

May 2004DBO - 19 -

Goal-Oriented Analysis final step -Evaluation of Alternatives (6)

• Evaluation of alternative functional goals decompositions in terms of the softgoals hierarchies

• Evaluate alternatives by selecting a set of leaf goals that collectively satisfy all given goals (see checked goals in previous slide)

• Satisfying goals might be impossible because of conflicts– Search of alternatives might involve finding a set of leaf softgoals

that maximize their positive support while minimizing negative support

• Softgoal analysis leads to additional design decisions, such as using password or allowing settings changes

May 2004DBO - 20 -

Modularization and Composition ofAspectual Requirements

[Rashid02, Rashid03]

May 2004DBO - 21 -

Modularization and Composition ofAspectual Requirements (1) [Rashid02, Rashid03]

• Major issue with RE approaches,such as viewpoints, use-cases, goals, is that mainly no support is available to ensure consistency of partial specs with global requirements and constraints [TBD - including claim that in [Grundy],AORE for Components,identification of aspects and constraints is largely unsupported]

• Method focus on modularization and composition of requirements level concerns that cut across other requirements

– e.g. compatibility, availability, security and other reqs that cannot be encapsulated by single viewpoint or use-case (TBD - all these are NFRs, although claim handling of FRs)

– Improve support for separation of crosscutting FR and NFR properties, offering better means to identify and manage conflicts

– Identify the mapping and influence of requirements level aspects on artifacts at later development phases, establishing critical tradeoffs before the architecture is derived

• Supported by the Aspectual Requirements Composition and Decision tool (ARCaDe, XML based) [not covered farther here – may be TBD - example given in the paper is the “Portuguese toll collection system”](defining of “concerns” is according to the PREView viewpoints concerns definition in the book “Requirements Engineering - A Good Practice Guide” by I. Sommervile and P. Sawyer, John Wiley and Sons, 1997)

May 2004DBO - 22 -

Modularization and Composition of AR (2)AORE Model

May 2004DBO - 23 -

Modularization and Composition of AR (3)Identify and Specify Stakeholders’ Requirements• Start by identifying and specifying both concerns and stakeholders requirements:

May 2004DBO - 24 -

Modularization and Composition of AR (4,1)Specify Concerns

Specify concerns (example)

Concern: Response-Time

External Requirements:

1. A toll gate has to react in-time in order to:

1.1 read the gizmo identifier;

1.2 turn on the light (to green or yellow) before the driver leaves the toll gate area;

1.3 display the amount to be paid before the driver leaves the toll gate area;

1.4 photograph the unauthorized vehicle’s plate number from the rear.

2. The system needs to react in-time when:

2.1 The user activates the gizmo using an ATM.

Concern: Compatibility

External Requirements:

1. Users will activate the gizmo using an ATM.

2. The police will deal with vehicles using the system without a gizmo.

May 2004DBO - 25 -

Modularization and Composition of AR (4,2) Identify and Specify Concerns

May 2004DBO - 26 -

Modularization and Composition of AR (5)Identify Candidate Aspects (1)

• Relating concerns to requirements through matrix allows to see which concerns crosscut stakeholders requirements (SR) to qualify as candidate aspects

May 2004DBO - 27 -

Modularization and Composition of AR (5)Identify Candidate Aspects (2)

May 2004DBO - 28 -

Modularization and Composition of AR (6,1) Discover requirements and relate to concerns

Discover requirements and relate to concerns (example)

Viewpoint: Exit Toll

Concerns: Response Time, Correctness, Legal Issues

Requirements:

1. The driver will see a yellow light if s/he did not use an entry toll.

2. The amount being debited depends upon the entry point.

Viewpoint: ATM.

Concerns: Security, Compatibility, Response time

Requirements:

1. The ATM will send the customer’s card number, account number and gizmo identifier to the system for activation.

2. The ATM will send the account number to the system to obtain the gizmo identifiers associated with the account.

3. The ATM will send the account number, new card number and the gizmo identifier to the system to update the card number and reactivate the gizmo.

May 2004DBO - 29 -

Modularization and Composition of AR (6,2)Define Composition Rules

• Detailed composition rules allow specifying how an aspectual req influences or constrains the behavior of non-aspectual reqs

• Composition rules define the relationships between actual reqs and viewpoint reqs at a fine granularity - using XML in ARCaDe)

– Coherent set of composition rules is encapsulated in Composition tag

– Each Requirement tag has at least two attributes: aspect or viewpoint

– Constraint tag defines an action and operator defining how the viewpoint reqs are to be constrained by the specific aspectual requirement

– Outcome tag defines the result of constraining the viewpoint reqs with aspectual reqs.Action attribute value describes whether another viewpoint req or a set of viewpoint reqs must be satisfied or merely the constraint specified has to be fulfilled

May 2004DBO - 30 -

Modularization and Composition of AR (7)Conflicts between Candidate Aspects (1)

• Identification and resolution of conflicts between candidate aspects done by:

– Building contribution matrix where each aspect may contribute negatively (-) or positively (+) to the other aspects

May 2004DBO - 31 -

Modularization and Composition of AR (7)Conflicts between Candidate Aspects (2)

• Identification and resolution of conflicts (continued):– Attributing weights (range [0..1] – represent priority) to those aspects

that contribute negatively to each other– Solving conflicts with the stakeholders, using above prioritization

(weight) approach to help communication

May 2004DBO - 32 -

Modularization and Composition of AR (8)Dimensions of an Aspect

• Aspect’s dimensions makes it possible to determine its influence on later development stages and identify its mapping onto a function, decision or aspect

• Identification of the dimensions of an aspect:– Mapping: aspect may map onto feature/function, decision, design aspect (this is why

initially it is candidate aspect)– Influence (e.g. availability influences system architecture while response time

influences both architecture and detailed design)

May 2004DBO - 33 -

Adapting the NFR-Framework to AORE

[Sousa]

May 2004DBO - 34 -

Adapting the NFR-Framework to AORE [Sousa] Overview (1,1)

(The paper includes quite overview of AORE work done so far. Not used here)

• Claim to improve over [Rashid02, Rashi03, Moreira, Brito]:– They use abstract attributes which makes it difficult to compose

and to map crosscutting-concerns onto later development stages– Abstract attributes cannot be objectively verified– They do not take into account the real modeling of aspects later

• Improve mapping of crosscutting NFR requirements onto artifacts at later development stages by adopting the NFR-Framework

• Separation of Concerns (SOC) allows to concentrate on each issue of a problem individually, to decrease complexity of SW development and support division of effort & separation of responsibilities

May 2004DBO - 35 -

Adapting the NFR-Framework to AORE [Sousa] Overview (1,2)

• Advocate that dealing with NFR operationalizations (see next slide) instead of abstract NFR is more adequate for mapping to crosscutting requirements at later development phases– To “operationalize” a req means providing more concrete and

precise mechanisms (operations, processes, data representations, constraints) to solve a problem

• Defines cocepts used in AOSD:– Concern, Crosscutting-Concern, Aspect, Match-Point– Composition-Rule: sequential order in which each aspect must be

composed with other(s) component(s)• Overlap (Before of After)• Override ()• Wrap (Around)

May 2004DBO - 36 -

NFR-Framework Overview (2,1)

• Softgoal:– NFR Softgoal (NFRs): high-level, non-operationalized, NFR

• Softgoal can rarely be completely satisfied, hence goal is regarded satisfied (or satisfice [Chung]) with acceptable limits

– Operationalizing Softgoal: possible solutions or design alternatives which help achieving the NFRs

– Claim Softgoal: justify the rationale and explain the context for a softgoal or interdependency link (type is always Claim and.

– Softgoal consist of:• NFR Type (e.g. Security; Authentication; Claim for claim softgoal)• One or more topic to indicate meaning and information item (e.g.

[CardData]; [Account]; Statement for claim softgoal).

May 2004DBO - 37 -

NFR-Framework Overview (2,2)

• Interdependencies: refinement of softgoals and the contributions of offspring softgoals towards towards the achievement of its parent

• Softgoal Interdependency Graph (SIG): graph where softgoals and their interdependencies are represented

• Catalogues: group an organized body of design knowledge about NFRs [Chang]

May 2004DBO - 38 -

NFR-Framework Overview (2,3)

(HELP)(MAKE)(HURT)(BREAK)

Priority Order!, !!

May 2004DBO - 39 -

NFR-Framework Overview (2,4)

• NFR-Framework process (see next slide) starts with identification of FRs and high-level NFRs that the system should meet (NFRs are represented as Softgoals on to of the SIG)

• NFR Softgoals iteratively refined until it is possible to operationalize them– Contributions and possible conflicts are established during the process, including

defining softgoals impact on each other and priorities

• Chosen operationalizations are linked to Design Spec. of target system and then to the description of FRs

• Specific solutions for the system are then selected– Design decisions should be supported by well-justified arguments by means of

Claim Softgoals

May 2004DBO - 40 -

NFR-Framework Overview (2,5)

May 2004DBO - 41 -

Adaptation of NFR-Framework to AORE (3,1)

• Improve composition and mapping of crosscutting NFRs onto artifacts at later development stages

• Proposed approach is based on AORE generic models ([Rashid02], [Rashid03]) with following differences (see also next slide):– Explicitly deal with NFR operationalizations in the mapping and

composition activities instead of abstract declarations of NFRs– Consider each NFRS Softgoal as Concern (concerns are limited here to

NFRs), therefore there is no need to the step of Identifying Crosscut-Concerns, as all NFRs are CC

– Recommend that Aspects Composition activity to be performed after Analyze the Mapping activity (different from previous approaches), because aspects are identified only after the activity Specifying the Mapping & Influence (Specify Aspects Dimensions)

– Advocate that NFR operationalizations should be mapped wither onto architectural decision or onto an aspect (and not onto function or procedure)

– Not necessary to include an activity responsible for handling conflicts because the NFR Framework has already dealt with that in the decission evaluation procedure (by means of interdependencies, correlations and priorities)

May 2004DBO - 42 -

Adaptation of NFR-Framework to AORE (3,2)

May 2004DBO - 43 -

Adaptation of NFR-Framework to AORE (3,3)

May 2004DBO - 44 -

Adaptation of NFR-Framework ExampleSteps 1, 2 (4,1)

• Example is based on internet banking system

• Step 1: Identifying Requirements - NFRs and FRs

• Step 2: Decompose the NFRs– May use NFR catalogues (Chung] and domain information. E.g.

Security concern usually be decomposed into: Confidentiality, Integrity and Availability

May 2004DBO - 45 -

Adaptation of NFR-Framework Example - Steps 3,4

Identify and Select Possible Operationalizations (4,2)

RejectedOper.-Softgoal

AcceptedOper.-Softgoal

Softgoal

May 2004DBO - 46 -

Adaptation of NFR-Framework Example - Step 5 (4,3)

Analyzing the Mapping of NFR Operationalizetions

• In previous AORE works, mapping is done from abstract NFRs, instead of NFR Operationalizations

• Mapping from Operationalizations is richer better reflects how the aspects will be treated at later development stages

May 2004DBO - 47 -

Adaptation of NFR-Framework ExampleStep 6 - Compose Identified Aspects with FRs (4,4)

FR / Component

AcceptedOper.-Sofgoal(NFR-Aspect)

Design Spec /Match-POINT +Composition Rule

Operator(Overlap, Override,Wrap)

May 2004DBO - 48 -

Crosscutting Quality Attributes forRequirements Engineering

[Moreira]

May 2004DBO - 49 -

Crosscutting Quality Attributes forRequirements Engineering (1) [Moreira]

• Propose a model to identify and specify quality attributes that crosscut requirements, at the requirements analysis stage

• Quality Attributes (QA)– Non-functional concerns, such as response time, accuracy, security,

reliability.

– The same as NFR, but from the point of view of the FR

– Motivation is to improve separation of crosscutting requirements during analysis, giving better means to identify and manage conflicts

• QA allows to handle the NFR aspect of the FR together with the FR, instead of separately

• Case study used is a toll collection system implemented in the Portuguese highways network (this system is used as case study most or all of their papers, which mainly covers only NFRs)

May 2004DBO - 50 -

Crosscutting Quality Attributes (2)Requirements Model

May 2004DBO - 51 -

Crosscutting Quality Attributes (3)Template for Quality Attributes (1)

May 2004DBO - 52 -

Crosscutting Quality Attributes (3)Template for Quality Attributes (2)

May 2004DBO - 53 -

Crosscutting Quality Attributes (4) - Process

• Adopts the concept of Overlapping, Overriding and Wrapping concerns

• Use-Cases and Sequence Diagrams scenarios are use to specify the FRs and QAs.

• QA-Templates are then used to specify QAs• If a QA affects more then one use case according

to “where”, it is crosscutting• Use-Cases are used to integrate (“weave”) FRs and

QAs

May 2004DBO - 54 -

Crosscutting Quality Attributes (5)Integrating (“weaving”) FRs and QAs (1)

May 2004DBO - 55 -

Crosscutting Quality Attributes (5)Integrating (“weaving”) FRs and QAs (2)

May 2004DBO - 56 -

Crosscutting Quality Attributes (5)Integrating (“weaving”) FRs and QAs (3)

May 2004DBO - 57 -

Towards Composition Process for AOR

[Brito]

May 2004DBO - 58 -

Towards Composition Process for AOR (1) [Brito]

• Process to compose crosscutting concerns with the functional (non-crosscutting) concerns (FR, Class, etc.)) they cut across

• Composed of three main activities:– Identify concerns– Specify concerns and discover which of them are crosscutting– Compose the crosscutting concerns with other concerns

• Main concepts behind the process that is used to identify and resolve conflicting crosscutting concerns:– Match Point: where one or more crosscutting concerns are applied to a

given functional concern (FR). Abstraction of the join-point concept– Conflicting Aspect: used to identify dominant crosscutting concerns to

resolve conflicts– Composition Rule: sequential list of simpler compositions of crosscutting

concerns, some operators and the model element

• Mainly handle Non-Functional Concerns (NFC, NFR)

May 2004DBO - 59 -

Towards Composition Process for AOR (2)Specify Concerns and Identify which are Crosscutting

• “Where” = interaction. [WORK IDEA: Allows to not deal with the crosscutting concerns in the FR definition, but only in the crosscut-[WORK IDEA: Allows to not deal with the crosscutting concerns in the FR definition, but only in the crosscut-concern definition. May be used to automatically integrate crosscut requirements into FRs]concern definition. May be used to automatically integrate crosscut requirements into FRs]

• “Contribution” = conflicts

May 2004DBO - 60 -

Towards Composition Process for AOR (3)Compose Candidate-Aspects with Concerns

• Goal is to integrate the candidate aspects with the concerns it cuts to obtain the whole system. Main steps guiding the composition are:

1. Identify how each candidate aspect affects the concerns it cuts across (using Overlap, Override, Wrap)

2. Identify match points based on the “Where”3. Identify conflicts between candidate aspects based on

“Contribution”4. Identify the dominant aspect based on “Priority”5. Identify composition rule based on the above

May 2004DBO - 61 -

Towards Composition Process for AOR (3)Match-Points Identification

• MEi: Model Element under study and the stakeholders of the system

• CAi: Candidate Aspect that affect each Model Element

• MPi: Match Point

In the table bellow, each filled cell represents a match-point:

May 2004DBO - 62 -

Towards Composition Process for AOR (4)Steps Needed to Handle Composition

May 2004DBO - 63 -

Theme and Theme/DocFinding Aspects in Requirements

[BanissadTheme, BanissadDoc]

May 2004DBO - 64 -

Theme and Theme/Doc - Finding Aspects in Requirements(1) [BanissadTheme, BanissadDoc]

• Theme: approach and tools to identify and handle aspects from requirements to implementation– Theme represent a feature of the system

– Theme/Doc tool: allows to refine views of (textual) requirements to reveal which functionality in the system is crosscutting;Assumes that if two behaviors are described in the same requirement then they are related (coincidently, hierarchically or crosscutting)

– Theme/UML method: design and modeling (using standard UML editors)

• Allows to identify aspects from interrelated behaviors of FRs, not just aspects from NFR as most of other methods identify

• Themes are divided into bases-themes (non-crosscutting) and crosscutting-themes

• Actions are good starting point for finding themes (only major enough actions are modeled separately as themes)

May 2004DBO - 65 -

Theme and Theme/Doc (2)

• Major steps in using Theme/Doc and transfer to Theme/UML– Define Actions used in the requirements (done manually)– Creation of Action View that shows actions usage by the

requirements (by lexical analysis of the requirements by the tool)– Identify crosscutting (aspectual) actions and entities being used

(removing non-crosscutting actions)– Create Clipped Action View that shows the crosscutting

hierarchy– Create Theme Views for the crosscutting actions to model the

themes identified in the previous steps– Use Theme/UML to incorporate the crosscutting actions and

identified entities into the design as classed, methods, etc.– Augmentation of the Theme Views to help in verifying that the

design choices made align with the requirements

May 2004DBO - 66 -

Theme (3) –Requirements Example

2.1. Course Management System (CMS)

• The CMS is a very small system, with nine requirements. Identifiedactions are in bold, entities in italics (Actions are taken from a listpre-defined by the developers) :

• R1. Students can register for courses.

• R2. Students can unregister for courses.

• R3. When a student registers then it must be logged in their record.

• R4. When a student unregisters it must also be logged.

• R5. Professors can unregister students.

• R6. When a professor unregisters a student it must be logged.

• R7 When a professor unregisters a student it must be flagged as special.

• R8. Professors can give marks for courses.

• R9. When a professor gives a mark this must be logged in the record.

May 2004DBO - 67 -

Theme (4) – Theme/Doc Action View

Expanded Requirement R3

Requirements

“logged” is primary behavior of R3 “logged”

identified as Crosscutting

“register” identified as Base

“flagged” identified as “professor” theme behavior (could be crosscutting)

May 2004DBO - 68 -

Theme (5) – Clipped Action View

Crosscutting hierarchy

Base Actions

Crosscutting Action

Requirements snipped from Base Actions and left with Crosscutting only

May 2004DBO - 69 -

Theme (6) – Theme View and Theme/UML (1)

Action translated to Method

Entity translated to Class

Read from top to bottom

May 2004DBO - 70 -

Theme (6) – Theme View and Theme/UML (2)

“gray”: Crosscutting actions/entities (common to other actions)

Non Crosscutting. Unique to logged

Entity translated to Database

Template Method (handle method for base behaviors)

May 2004DBO - 71 -

Theme (7) – Bind feature of Theme/UML

bind feature of Theme/UML is used here to bind the _log() method from logged theme to other CMS themes and classes

May 2004DBO - 72 -

Theme (8) – Augmented View

Augmented Associations

Augmented Method

Theme/Doc Augmentation:Align a theme with thedesign decisions to verifythat design choices arealigned with requirements

May 2004DBO - 73 -

AORE for Component-based SW Systems

[Grundy]

May 2004DBO - 74 -

AORE for Component-based SW Systems (1) [Grundy]

• AOCRE (Aspect Oriented Component Requirements Engineering)– Focus on identifying and specifying the FRs and NFRs relating to key aspects of a

system each component provides or requires

– Analyze and characterize components based on different aspects of the overall application a component addresses

– Aspect of a system for which components provide required services are user-interface, persistency, user configuration, collaborative work, etc.

– AOCRE covers Requirements through Implementation phases (here, only Requirements-related is covered)

• Component based systems build applications from discrete, inter-related software components, with a key aim to allow components to be interchangeable

• Existing components development tools (e.g. Agetm, Rational-Rose, etc.) focus on design and implementation; Component characterizations such as JavaBeans, COM are too low level for describing requirements

May 2004DBO - 75 -

AOCRE (2) – Component’s Aspects

• Some general use categories for components aspects were developed (see below)

• Domain-specific aspects can be specified for specialized components

May 2004DBO - 76 -

AOCRE (3) – AOCRE Process

Figure 3. Basic AOCRE process.

May 2004DBO - 77 -

AOCRE (4) – example of component and their aspects

(Not clear what and if is the main difference between the components aspects and OO-Method, except that Methods is part of design and these aspects are for Requirements)

May 2004DBO - 78 -

AOCRE (5) – Detailed AOCRE Specs

• Aspectual requirements specs using some formally defined parameters[may be the approach for specifying AOR, to allow creation of (semi) [may be the approach for specifying AOR, to allow creation of (semi) automatic mechanism to handle aspectual requirements]automatic mechanism to handle aspectual requirements]

II. Collaborative Work Aspects : COLLABORATION

II. 1) +data fetch/store functions : DATA_MANIPULATION

QUERY=true; UPDATE=true

II 2) +event broadcasting/actions functions : EVENT_MANAGEMENT

DETECT=true; ACTION=true

II 3) + event annotation functions : AWARENESS

HIGHLIGHT=colour; ANNOTATE=text

II 4) - remote data/event synchronisation : LOCKING

SYNCHRONOUS=true OR false; SEMI_SYNCHRONOUS=true OR false; NETWORK_SPEED=any; STORE=true

II 5) - data/event versioning : VERSIONING

DATA=true; EVENT=true; INTERFACE=extensible affordances; CHECKIN=true; CHECKOUT=true

Figure 5. Detailed aspect-oriented component requirements specifications.

May 2004DBO - 79 -

AOCRE (6) – Aspects Reasoning and Aggregation

• After component’s provided and required aspects are identified, related components and aspects can be reasoned about (i.e. making sure component provide required aspects)

• Aggregate aspects can be identified for interrelated components, allowing reasoning about AO requirements for these components or even whole application

• Global application requirements can be specified using aspects and then migrate down to related components [similar to AspectJ mechanism for [similar to AspectJ mechanism for code – can this be done code – can this be done automatically for requirements?]automatically for requirements?]

May 2004DBO - 80 -

Composition Filters

[Bergmans]

May 2004DBO - 81 -

Composition Filters (1) [Bergmans]

• Filters are defined as functions which manipulate messages received and sent by objects– Capable of expressing a large category of concerns, such as inheritance and

delegation, synchronization, real-time constraints, inter-object protocols

• Filters in the Composition Filters (CF) model can express crosscutting concerns by modular and orthogonal enhancements to objects– Modular means that filters have well defined interfaces and are conceptually

independent of the implementation (language) of the object– Orthogonal means that filters specs do not refer to (the spec of) other filters

• CF implements constraints in the level of Messages between objects, instead or in addition to the level of Methods– CF are defined in the Class level– Defines to what Class and Message is applicable by generic expression (including

“*”)

• CF declaratively specify concerns using messages manipulation language (ComposeJ compiler, Sina language) vs. Adaptive Programming and AspectJ which adopt dedicated declarative specs to express crosscut and a general-purpose language to express concerns

May 2004DBO - 82 -

Composition Filters (2)UML-based representation of CF Class

• A CF class aggregates zero of more internal classes and composes their behavior using one or more filters

• When message arrives it is matched with each of the filters

• Filter: {x.y, …}: x: Object/Class y: Class Message

• Filters are matched in order of appearance• Exception raised if no filter match• In case of match, message is dispatched to

object of first filter matched

CF Implementation

of a Class

Filter Expression:1) Target = “inner” Selector = “*” 2) Target = “doc” Selector = “*”

CF Representation

of a Class

Implementation of non-

crosscutting concerns of a

Class

May 2004DBO - 83 -

Composition Filters (3)Filter Types

May 2004DBO - 84 -

Composition Filters (4) - Error Filter

Evaluated first.Received messages setApprovedClaim or seClaimAmount match filter if FinancialResp is True

Evaluated second, if no match in first

Evaluated if others False. All messages match, except the ones in the list(“~> = exclution operator:if True all messages match except the ones in the list)

Enforce required multiple views on the document:Class PortClaimDocument declares two conditions FinancialResp and MedicalResp which evaluate to true if the responsibility of the sender is financial or medical

May 2004DBO - 85 -

Composition Filters (5) - SuperimpositionCF model provides the superimposition mechanism to impose filter interfaces onto one or more objects

{NoActiveThreads=>*} =if no condition NoActiveThreads is true, all messages can pass this filter

“allTasks<-MulExSync” =filter interface MutExSync to be superimposed upon all all instances defined by selector allTasks of the same class

May 2004DBO - 86 -

UML Extensions for AOSD ????

[????]