View
216
Download
0
Category
Preview:
Citation preview
8/3/2019 Early Aspects
1/86
May 2004
DBO - 1 -
Early Aspects
Overview of Some Approaches
David Bar-On
April 2004
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
3/86
May 2004
DBO - 3 -
Presentation Plan
Overview of requirements Engineering (RE)
Crosscutting (Aspectual) Requirements
Overview of works related to Early Aspects /
AORE
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
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/3/2019 Early Aspects
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.)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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]
8/3/2019 Early Aspects
11/86
May 2004
DBO - 1 1 -
Goal Oriented Requirements Analysis
[Mylopoulos]
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
20/86
May 2004DBO - 2 0 -
Modularization and Composition of
Aspectual Requirements
[Rashid02, Rashid03]
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
22/86
May 2004DBO - 2 2 -
Modularization and Composition of AR (2)
AORE Model
8/3/2019 Early Aspects
23/86
May 2004DBO - 2 3 -
Modularization and Composition of AR (3)
Identify and Specify Stakeholders Requirements
Start by identifying and specifying both concerns andstakeholdersrequirements:
8/3/2019 Early Aspects
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.
8/3/2019 Early Aspects
25/86
May 2004DBO - 2 5 -
Modularization and Composition of AR (4,2)
Identify and Specify Concerns
8/3/2019 Early Aspects
26/86
May 2004DBO - 2 6 -
Modularization and Composition of AR (5)
Identify Candidate Aspects (1)
Relating concerns to requirements through matrix allows to
see which concerns crosscutstakeholders requirements
(SR) to qualify as candidate aspects
8/3/2019 Early Aspects
27/86
May 2004DBO - 2 7 -
Modularization and Composition of AR (5)
Identify Candidate Aspects (2)
8/3/2019 Early Aspects
28/86
May 2004DBO - 2 8 -
Modularization and Composition of AR (6,1)
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.
8/3/2019 Early Aspects
29/86
May 2004DBO - 2 9 -
Modularization and Composition of AR (6,2)
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
8/3/2019 Early Aspects
30/86
May 2004DBO - 3 0 -
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
8/3/2019 Early Aspects
31/86
May 2004DBO - 3 1 -
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 aspectsthat contribute negatively to each other
Solving conflicts with the stakeholders, using above prioritization(weight) approach to help communication
8/3/2019 Early Aspects
32/86
May 2004DBO - 3 2 -
Modularization and Composition of AR (8)
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)
8/3/2019 Early Aspects
33/86
May 2004DBO - 3 3 -
Adapting the NFR-Framework to AORE
[Sousa]
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
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).
8/3/2019 Early Aspects
37/86
May 2004DBO - 3 7 -
NFR-Framework Overview (2,2)
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]
8/3/2019 Early Aspects
38/86
May 2004DBO - 3 8 -
NFR-Framework Overview (2,3)
(HELP)
(MAKE)(HURT)
(BREAK)
Priority Order
!, !!
8/3/2019 Early Aspects
39/86
May 2004DBO - 3 9 -
NFR-Framework Overview (2,4)
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
8/3/2019 Early Aspects
40/86
May 2004DBO - 4 0 -
NFR-Framework Overview (2,5)
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
42/86
May 2004DBO - 4 2 -
Adaptation ofNFR-Framework to AORE (3,2)
8/3/2019 Early Aspects
43/86
May 2004DBO - 4 3 -
Adaptation ofNFR-Framework to AORE (3,3)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
48/86
May 2004DBO - 4 8 -
Crosscutting Quality Attributes for
Requirements Engineering
[Moreira]
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
50/86
May 2004DBO - 5 0 -
Crosscutting Quality Attributes (2)
Requirements Model
8/3/2019 Early Aspects
51/86
May 2004DBO - 5 1 -
Crosscutting Quality Attributes (3)
Template for Quality Attributes (1)
8/3/2019 Early Aspects
52/86
May 2004DBO - 5 2 -
Crosscutting Quality Attributes (3)
Template for Quality Attributes (2)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
54/86
May 2004DBO - 5 4 -
Crosscutting Quality Attributes (5)
Integrating (weaving) FRs and QAs (1)
8/3/2019 Early Aspects
55/86
May 2004DBO - 5 5 -
Crosscutting Quality Attributes (5)
Integrating (weaving) FRs and QAs (2)
8/3/2019 Early Aspects
56/86
May 2004DBO - 5 6 -
Crosscutting Quality Attributes (5)
Integrating (weaving) FRs and QAs (3)
8/3/2019 Early Aspects
57/86
May 2004DBO - 5 7 -
Towards Composition Process for AOR
[Brito]
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
60/86
May 2004DBO - 6 0 -
Towards Composition Process for AOR (3)
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
8/3/2019 Early Aspects
61/86
May 2004DBO - 6 1 -
Towards Composition Process for AOR (3)
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:
8/3/2019 Early Aspects
62/86
May 2004DBO - 6 2 -
Towards Composition Process for AOR (4)
Steps Needed to Handle Composition
8/3/2019 Early Aspects
63/86
May 2004DBO - 6 3 -
Theme and Theme/Doc
Finding Aspects in Requirements
[BanissadTheme, BanissadDoc]
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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.
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
Theme (6) Theme View and Theme/UML (2)
8/3/2019 Early Aspects
70/86
May 2004
DBO - 7 0 -
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)
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
73/86
May 2004
DBO - 7 3 -
AORE for Component-based SW Systems
[Grundy]
8/3/2019 Early Aspects
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
( )
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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?]
8/3/2019 Early Aspects
80/86
May 2004
DBO - 8 0 -
Composition Filters
[Bergmans]
Composition Filters (1) [B ]
8/3/2019 Early Aspects
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)
8/3/2019 Early Aspects
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
Composition Filters (3)
8/3/2019 Early Aspects
83/86
May 2004
DBO - 8 3 -
Composition Filters (3)
Filter Types
Composition Filters (4) Error Filter
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
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
8/3/2019 Early Aspects
86/86
UML Extensions for AOSD ????
[????]
Recommended