Early Aspects

8/3/2019 Early Aspects

1/86

May 2004

DBO - 1 -

Early Aspects

Overview of Some Approaches

David Bar-On

April 2004


2/86

May 2004

DBO - 2 -

References for AORE / Early Aspects

y [Nuseibeh] BasharNuseibeh Crosscutting Requirements, AOSD conference 2004keynote presentation, http://aosd.net/2004/archive/AOSD-FromPromiseToReality.ppt

y [Mylopoulos ] John Mylopoulos at al Exploring Alternatives During requirements

Analysis, IEEE Software, January/February 2001, http://ieeexplore.ieee.org/

y [Sousa]Sousa, G.; Silva, I. and Castro, J. (2003) Adapting the NFR Framework toAspect-Oriented Requirements Engineering. XVII Brazilian Symposium onSoftware Engineering, Manaus, Brazil, October.(Or: Gergia Sousa, Srgio Soares, Paulo Borba and Jaelson Castro Separation of

Crosscutting Concerns from Requirements to Design: Adapting an Use Case DrivenApproach, Informatics Center Federal University of Pernambuco (UFPE)AOSD2004, http://trese.cs.utwente.nl/workshops/early-aspects-2004/Papers/SousaEtAl.pdf)

y [Rashid02] Rashid A.; Moreira, A. and Araujo, J. Early Aspects: a Model forAspect-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

y

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

y [Moreira] Moreira, A.; Araujo, J.; Brito, I.; Crosscutting Quality Attributes forRequirements Engineering, 14th International Conference on Software Engineeringand Knowledge Engineering (SKE 2002), ACM Press, Italy, July 2002,http://portal.acm.org/ (alternative http://trese.cs.utwente.nl/AOSD-

EarlyAspectsWS/Papers/Brito.pdf)

y [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

y

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

y [Grundy] John Grundy Aspect-oriented Requirements Engineering for Component-based Software Systems, Proceedings of RE99, 7-11 June, Limerick, Irland, 1999,

http://ieeexplore.ieee.org/

y [BaniassadTheme] E. Baniassad, S. Clarke Theme: An approach for aspect-orientedanalysis and design, International Conference on Software Engineering, 2004,

http://www.cs.tcd.ie/Elisa.Baniassad/theme.pdf

y [BaniassadDoc] E. Baniassad E., E. Siobhan Finding Aspects in Requirements withTheme/Doc, ??? AOSD Conference 2004 ???,

http://trese.cs.utwente.nl/workshops/early-aspects-2004/Papers/Baniassad-Clarke.pdf


3/86

May 2004

DBO - 3 -

Presentation Plan

Overview of requirements Engineering (RE)

Crosscutting (Aspectual) Requirements

Overview of works related to Early Aspects /

AORE


4/86

May 2004

DBO - 4 -

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

RE is about discovering customers needs (goals andexpectations), extending them if needed andcommunicating them to implementers

Requirements

Expression of customer needs and expectations to achieveparticular 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


5/86

May 2004

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


6/86

May 2004

DBO - 6 -

Types of requirements

Requirements 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)


7/86

May 2004

DBO - 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 becompetitive and features that differentiate it from competitors

Non-F

unctional Requirements (NF

R) Requirements that impose restrictions on the product being

developed, or development process or specify constraints [Sousa]

Properties that emerge from the combination of a systemsparts/features

NFR can be split into:

Qualities: characteristics that the customer cares about and thereforeaffect 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)


8/86

May 2004

DBO - 8 -

Requirements Terminology to Avoid [Young]

Source or Customer Requirements

Specify the individual source of the requirements

Nonnegotiable VersusNegotiable Requirements

Use minimum requirements

Key Requirements

More details are needed: benefit-to-cost ratio, risk, estimated time andeffort 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.)


9/86

May 2004

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


10/86

May 2004

DBO - 1 0 -

AORE Related works Identified

CombinedAND/OR diagrams ofGoaland Softgoal- encourages separation the

analysis of Softgoals (NFR) concern [Mylopoulos]

Modularization and Composition of Aspectual Requirements using an AOREprocess model (Concerns/SR matrix, set weight/priority to contributionsbetween aspects, identify aspect Influence and Mapping dimensions. Suggestconcrete model with Viewpoints and XML (ARCaDe) [Rashid02, Rashid03]

Adaptation of theNFR-Frameworkto AORE enhancements using NFR

operationalizations instead of abstractNFR(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]


11/86

May 2004

DBO - 1 1 -

Goal Oriented Requirements Analysis

[Mylopoulos]


12/86

May 2004

DBO - 1 2 -

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 anddefine the basic functions the system will support

Goal Oriented requirements analysis main steps (input is a set offunctional goals):

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

2. Softgoal analysis - analysis ofNFRs/QAs (decomposing each givenquality 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)


13/86

May 2004

DBO - 1 3 -

AND/ORdecomposition 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 wasachieved or not

Goal Analysis using AND/OR Decomposition (2)

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

Example: AND/ORdecomposition of

alternatives for

achieving the

meeting-scheduling

goal


14/86

May 2004

DBO - 1 4 -

Softgoal Analysis (3,1)

(the softgoal notion is presented in detail in the book Non-FunctionalRequirements in Software Engineering, by L. Chang et al, KluwerPublishing, the Netherlands, 2000)

Softgoal: usuallyNFR/QA, represent ill-defined

goals and their interdependencies Softgoal is satisfied when there is sufficient

positive evidence in favor of it and little negativeevidence against it

Softgoal hierarchies can be built by asking whatcan be done to satisfy (or support) a particularsoftgoal


15/86

May 2004

DBO - 1 5 -

Softgoal Analysis Example (3,2)

Softgoal Analysis use extended AND/OR diagrams with

dependency/hierarchies relationships Example forHigh Usable SystemSoftgoal - only thissoftgoal is expanded

Dependencies/relationships

labeled with + when one

softgoal supports (positively

influences) another


16/86

May 2004

DBO - 1 6 -

Softgoal Analysis (3,3)

Relevant knowledge for identifying softgoaldecompositions and dependencies might be generic andrelated to the softgoal being analyzed

Number ofgeneric decompositions to finer-grain quality

factors are available for general software system qualities(QAs)

Example: Speed Performance softgoal can be AND-decomposedinto three softgoals:

Minimize User-Interface

Use Efficient Algorithms

Ensure Adequate CPU Power

Project/taskspecific decomposition methods can still beused after agreement among projects stakeholders


17/86

May 2004

DBO - 1 7 -

Softgoal Correlation Analysis (4)

Quality Goals frequently conflict with each other Correlation analysis helps discoverpositive or

negative relationsbetween softgoals


18/86

May 2004DBO - 1 8 -

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


19/86

May 2004DBO - 1 9 -

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


20/86

May 2004DBO - 2 0 -

Modularization and Composition of

Aspectual Requirements

[Rashid02, Rashid03]


21/86

May 2004DBO - 2 1 -

Modularization and Composition of

Aspectual 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 withglobal requirements and constraints [TBD - including claim that in [Grundy],AORE forComponents,identification of aspects and constraints is largely unsupported]

Method focus on modularization and composition of requirements levelconcerns that cut across other requirements

e.g. compatibility, availability, security and other reqs that cannot be

encapsulated by single viewpoint oruse-case (TBD - all these areNFRs,although claim handling of FRs)

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

Identify the mapping and influence of requirements level aspects onartifacts 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 givenin the paper is the Portuguese toll collection system](defining of concerns is according to the PREView viewpoints concerns definition in the bookRequirements Engineering - A Good Practice Guide by I. Sommervile and P. Sawyer, John Wiley and Sons,1997)


22/86

May 2004DBO - 2 2 -

Modularization and Composition of AR (2)

AORE Model


23/86

May 2004DBO - 2 3 -


Identify and Specify Stakeholders Requirements

Start by identifying and specifying both concerns andstakeholdersrequirements:


24/86

May 2004DBO - 2 4 -

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 vehicles 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.


25/86

May 2004DBO - 2 5 -


Identify and Specify Concerns


26/86

May 2004DBO - 2 6 -


Identify Candidate Aspects (1)

Relating concerns to requirements through matrix allows to

see which concerns crosscutstakeholders requirements

(SR) to qualify as candidate aspects


27/86

May 2004DBO - 2 7 -


Identify Candidate Aspects (2)


28/86

May 2004DBO - 2 8 -


Discover requirements and relate to concerns

Discover requirements and relate to concerns (example)

Viewpoint: Exit TollConcerns: 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 customers 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.


29/86

May 2004DBO - 2 9 -


Define Composition Rules

Detailed composition rules allow specifying

how an aspectual req influences or constrainsthe behavior of non-aspectual reqs

Composition r ules define the relationshipsbetween actual reqs and viewpoint reqs at afine granularity - using XML in ARCaDe)

Coherent set of composition rules isencapsulated in Composition tag

EachRequirement taghas at least twoattributes: aspectorviewpoint

Constraint tagdefines an action and operatordefining how the viewpoint reqs are to beconstrained by the specific aspectualrequirement

Outcome tagdefines the result of constrainingthe viewpoint reqs with aspectual reqs.Action attribute value describes whetheranother viewpoint req or a set of viewpointreqs must besatisfiedor merely the constraintspecified has to befulfilled


30/86

May 2004DBO - 3 0 -


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


31/86

May 2004DBO - 3 1 -


Conflicts between Candidate Aspects (2) Identification and resolution of conflicts (continued):

Attributing weights (range [0..1] represent priority) to those aspectsthat contribute negatively to each other

Solving conflicts with the stakeholders, using above prioritization(weight) approach to help communication


32/86

May 2004DBO - 3 2 -


Dimensions of an Aspect Aspects dimensions makes it possible to determine its influence on later

development stages and identify its mapping onto afunction, decision oraspect

Identification of the dimensions of an aspect:

Mapping: aspect may map onto feature/function, decision, design aspect (this is whyinitially it is candidate aspect)

Influence (e.g. availability influences system architecture while response timeinfluences both architecture and detailed design)


33/86

May 2004DBO - 3 3 -

Adapting the NFR-Framework to AORE

[Sousa]


34/86

May 2004DBO - 3 4 -

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 composeand 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 crosscuttingNFR requirements ontoartifacts at later development stages by adopting the NFR-Framework

Separation of Concerns (SOC) allows to concentrate oneach issue of a problem individually, to decreasecomplexity of SW development and support division ofeffort & separation of responsibilities


35/86

May 2004DBO - 3 5 -

Adapting the NFR-Framework to AORE [Sousa]

Overview (1,2)

Advocate that dealing with NFRoperationalizations (seenext slide) instead of abstractNFR is more adequate formapping 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)


36/86

May 2004DBO - 3 6 -

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 (orsatisfice [Chung]) with acceptable limits

Operationalizing Softgoal: possible solutions or design alternativeswhich help achieving the NFRs

Claim Softgoal:justify the rationale and explain the context for asoftgoal 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).


37/86

May 2004DBO - 3 7 -


Interdependencies: refinement of softgoals and thecontributions of offspring softgoals towards towards theachievement of its parent

Softgoal Interdependency Graph (SIG): graph where

softgoals and their interdependencies are represented Catalogues: group an organized body of design knowledge

aboutNFRs [Chang]


38/86

May 2004DBO - 3 8 -


(HELP)

(MAKE)(HURT)

(BREAK)

Priority Order

!, !!


39/86

May 2004DBO - 3 9 -


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

NFR Softgoals iteratively refined until it is possible to operationalizethem

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 systemand then to the description of FRs

Specific solutions for the system are then selected

Design decisions should be supported by well-justified arguments bymeans ofClaim Softgoals


40/86

May 2004DBO - 4 0 -



41/86

May 2004DBO - 4 1 -

Adaptation ofNFR-Framework to AORE (3,1)

Improve composition and mapping of crosscutting NFRs onto artifactsat later development stages

Proposed approach is based on AORE generic models ([Rashid02],[Rashid03]) with following differences (see also next slide):

Explicitly deal with NFRoperationalizations in the mapping andcomposition activities instead of abstract declarations ofNFRs

Consider each NFRS Softgoal as Concern (concerns are limited here toNFRs), 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 afterAnalyze the Mappingactivity (different from previous approaches), becauseaspects are identified only after the activity Specifying the Mapping &Influence (Specify Aspects Dimensions)

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

Not necessary to include an activity responsible for handling conflictsbecause theNFR Framework has already dealt with that in the decissionevaluation procedure (by means of interdependencies, correlations andpriorities)


42/86

May 2004DBO - 4 2 -



43/86

May 2004DBO - 4 3 -



44/86

May 2004DBO - 4 4 -

Adaptation ofNFR-Framework Example

Steps 1, 2 (4,1)

Example is based on internet banking system

Step 1: Identifying Requirements - NFRs and FRs

Step 2: Decompose the NFRs

May useNFR catalogues (Chung] and domain information. E.g.

Security concern usually be decomposed into: Confidentiality,

Integrity and Availability


45/86

May 2004DBO - 4 5 -

Adaptation ofNFR-Framework Example - Steps 3,4

Identify and Select Possible Operationalizations (4,2)

Rejected

Oper.-Softgoal

Accepted

Oper.-Softgoal

Softgoal


46/86

May 2004DBO - 4 6 -

Adaptation ofNFR-Framework Example - Step 5 (4,3)

Analyzing the Mapping ofNFR Operationalizetions

In previous AORE works, mapping is done from abstract NFRs,

instead ofNFR Operationalizations

Mapping from Operationalizations is richer better reflects how the

aspects will be treated at later development stages


47/86

May 2004DBO - 4 7 -

Adaptation ofNFR-Framework Example

Step 6 - Compose Identified Aspects with FRs (4,4)

FR / Component

Accepted

Oper.-Sofgoal

(NFR-Aspect)

Design Spec /

Match-POINT +

Composition Rule

Operator

(Overlap, Override,

Wrap)


48/86

May 2004DBO - 4 8 -

Crosscutting Quality Attributes for

Requirements Engineering

[Moreira]


49/86

May 2004DBO - 4 9 -

Crosscutting Quality Attributes for

Requirements 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 thePortuguese highways network (this system is used as case study most or

all of their papers, which mainly covers only NFRs)


50/86

May 2004DBO - 5 0 -

Crosscutting Quality Attributes (2)

Requirements Model


51/86

May 2004DBO - 5 1 -


Template for Quality Attributes (1)


52/86

May 2004DBO - 5 2 -


Template for Quality Attributes (2)


53/86

May 2004DBO - 5 3 -

Crosscutting Quality Attributes (4) - Process

Adopts the concept ofOverlapping, Overriding

and Wrappingconcerns

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


54/86

May 2004DBO - 5 4 -


Integrating (weaving) FRs and QAs (1)


55/86

May 2004DBO - 5 5 -




56/86

May 2004DBO - 5 6 -




57/86

May 2004DBO - 5 7 -

Towards Composition Process for AOR

[Brito]


58/86

May 2004DBO - 5 8 -

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 agiven functional concern (FR). Abstraction of thejoin-point concept

Conflicting Aspect: used to identify dominantcrosscutting concerns to

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

concerns, some operators and the model element

Mainly handleNon-Functional Concerns (NFC,NFR)


59/86

May 2004DBO - 5 9 -

Towards Composition Process for AOR (2)

Specify Concerns and Identify which are Crosscutting

Where = interaction. [WORK IDEA: Allows to not deal with the crosscutting[WORK IDEA: Allows to not deal with the crosscuttingconcerns in the FR definition, but only in the crosscutconcerns in the FR definition, but only in the crosscut--concern definition. Mayconcern definition. Maybe used to automatically integrate crosscut requirements into FRs]be used to automatically integrate crosscut requirements into FRs]

Contribution = conflicts


60/86

May 2004DBO - 6 0 -


Compose Candidate-Aspects with Concerns

Goal is to integrate the candidate aspects with theconcerns it cuts to obtain the whole system. Mainsteps 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 conflictsbetween candidate aspects based onContribution

4. Identify the dominant aspectbased on Priority

5. Identify composition rulebased on the above


61/86

May 2004DBO - 6 1 -


Match-Points Identification

MEi:Model Elementunder study and the stakeholders of the system

CAi: Candidate Aspectthat affect each Model Element

MPi:Match Point

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


62/86

May 2004DBO - 6 2 -


Steps Needed to Handle Composition


63/86

May 2004DBO - 6 3 -

Theme and Theme/Doc

Finding Aspects in Requirements

[BanissadTheme, BanissadDoc]


64/86

May 2004DBO - 6 4 -

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 thenthey 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, notjust

aspects fromNFR as most of other methods identify

Themes are divided into bases-themes (non-crosscutting) andcrosscutting-themes

Actions are good starting point for finding themes (only major enough

actions are modeled separately as themes)


65/86

May 2004DBO - 6 5 -

Theme and Theme/Doc (2)

Major steps in using Theme/Doc and transfer toTheme/UML

DefineActions used in the requirements (done manually)

Creation ofAction View that shows actions usage by therequirements (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 thethemes 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


66/86

May 2004DBO - 6 6 -

Theme (3) Requirements Example

2.1. Course Management System (CMS)

The CMS is a very small system, with nine requirements. Identified

actions are in bold, entities in italics (Actions are taken from a list

pre-defined by the developers) :

R1. Students can register forcourses.

R2. Students can unregister forcourses.

R3. When astudentregisters then it must be logged in theirrecord.

R4. When astudentunregisters it must also be logged.

R5.Professors can unregisterstudents.

R6. When aprofessorunregisters astudentit must be logged.

R7 When aprofessorunregisters astudentit must be flagged as special.

R8.Professors can give marks forcourses.

R9. When a professorgives a markthis must be logged in the record.


67/86

May 2004DBO - 6 7 -

Theme (4) Theme/Doc Action View

Expanded

RequirementR3

Requirements

logged is

primary behaviorof R3 logged

identified as

Crosscutting

register

identified asBase

flagged identified as

professor theme

behavior (could be

crosscutting)


68/86

May 2004DBO - 6 8 -

Theme (5) Clipped Action View

Crosscutting

hierarchy

Base Actions

Crosscutting

Action

Requirements snipped from

Base Actions and left with

Crosscutting only


69/86

May 2004

DBO - 6 9 -

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

Action translated

to Method

Entity translated

to Class

Read from

top to bottom



70/86

May 2004

DBO - 7 0 -


gray: Crosscutting

actions/entities (common

to other actions)

Non Crosscutting.

Unique to logged

Entity translated

to Database

Template Method

(handle method for

base behaviors)


71/86

May 2004

DBO - 7 1 -

Theme (7) Bind feature of Theme/UML

bindfeature of Theme/UML is used here to bind

the_log() method from loggedtheme to otherCMS themes and classes

Theme (8) Augmented View


72/86

May 2004

DBO - 7 2 -

( ) g

Augmented

Associations

Augmented

Method

Theme/Doc Augmentation:

Align a theme with thedesign decisions to verify

that design choices are

aligned with requirements


73/86

May 2004

DBO - 7 3 -

AORE for Component-based SW Systems

[Grundy]


74/86

May 2004

DBO - 7 4 -

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

( )


75/86

May 2004

DBO - 7 5 -

AOCRE (2) Components Aspects

Some general use categories for components aspects were developed

(see below) Domain-specific aspects can be specified for specialized components

AOCRE (3) AOCRE P


76/86

May 2004

DBO - 7 6 -

AOCRE (3) AOCRE Process

Figure 3. Basic AOCRE process.

AOCRE (4) l f t d th i t


77/86

May 2004

DBO - 7 7 -

AOCRE (4) example of component and their aspects

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

AOCRE (5) D t il d AOCRE S


78/86

May 2004

DBO - 7 8 -

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_MANAGEMENTDETECT=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.

AOCRE (6) A t R i d A ti


79/86

May 2004

DBO - 7 9 -

AOCRE (6) Aspects Reasoning and Aggregation

After components providedand required aspects areidentified, related componentsand aspects can be reasonedabout (i.e. making surecomponent provide requiredaspects)

Aggregate aspects can be

identified for interrelatedcomponents, allowingreasoning about AOrequirements for thesecomponents or even wholeapplication

Global application

requirements can be specifiedusing aspects and then migratedown to related components[similar to AspectJ mechanism for[similar to AspectJ mechanism forcodecode can this be donecan this be done

automatically for requirements?]automatically for requirements?]


80/86

May 2004

DBO - 8 0 -

Composition Filters

[Bergmans]

Composition Filters (1) [B ]


81/86

May 2004

DBO - 8 1 -

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 anddelegation, synchronization, real-time constraints, inter-object protocols

Filters in the Composition Filters (CF) model can express crosscuttingconcerns by modular and orthogonal enhancements to objects

Modularmeans that filters have well defined interfaces and areconceptually independent of the implementation (language) of the object

Orthogonalmeans that filters specs do not refer to (the spec of) otherfilters

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. AdaptiveProgramming and AspectJ which adopt dedicated declarative specs toexpress crosscut and a general-purpose language to express concerns

Composition Filters (2)


82/86

May 2004

DBO - 8 2 -

p ( )

UML-based representation of CF Class

A CF class aggregates

zero of more internalclasses and composestheir behaviorusingone or more filters

When message arrivesit is matched witheach of the filters

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

Filters are matched inorder of appearance

Exception raised if nofilter match

In case of match,message is dispatchedto object of first filtermatched

CFImplementation

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



83/86

May 2004

DBO - 8 3 -


Filter Types

Composition Filters (4) Error Filter


84/86

May 2004

DBO - 8 4 -

Composition Filters (4) - Error Filter

Evaluated first.

Received messages

setApprovedClaim or

seClaimAmountmatch filter

ifFinancialResp is True

Evaluated second, ifno

match in first

Evaluated if othersFalse.

All messages match, exceptthe 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

Composition Filters (5) Superimposition


85/86

May 2004

DBO - 8 5 -

Composition Filters (5) - SuperimpositionCF model provides thesuperimposition mechanism to impose filter interfaces onto

one or more objects

{NoActiveThreads=>*} =

if no condition

NoActiveThreads is true, all

messages can pass this filter

allTasks


86/86

UML Extensions for AOSD ????

[????]

Documents

Early Aspects