may 2004 dbo - 1 - early aspects overview of some approaches david bar-on april 2004
Post on 22-Dec-2015
219 views
TRANSCRIPT
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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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