1 / 86

Early Aspects Overview of Some Approaches

Early Aspects Overview of Some Approaches. David Bar-On April 2004. Presentation Plan. Overview of requirements Engineering (RE) Crosscutting (Aspectual) Requirements Overview of works related to Early Aspects / AORE. Requirements Engineering (RE) [Young], [Nuseibeh].

rumor
Télécharger la présentation

Early Aspects Overview of Some Approaches

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Early AspectsOverview of Some Approaches David Bar-On April 2004 - 1 -

  2. - 2 -

  3. Presentation Plan • Overview of requirements Engineering (RE) • Crosscutting (Aspectual) Requirements • Overview of works related to Early Aspects / AORE - 3 -

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

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

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

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

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

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

  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] - 10 -

  11. Goal Oriented Requirements Analysis [Mylopoulos] - 11 -

  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): • Goal analysis - explore goals alternatives (using decomposition of each functional goal into AND/OR) • Softgoal analysis - analysis of NFRs/QAs (decomposing each given quality into softgoal hierarchy) • Softgoal correlation analysis (identify correlations between softgoals) • Goal correlation analysis (identify correlation between goals and softgoals) • Evaluation of alternatives (select a set of goals and softgoals) - 12 -

  13. Notation:Goal; Root Goals supported by checked leaf goals;Softgoal; AND; OR Goal Analysis using AND/OR Decomposition (2) • AND/OR decompositiondiagrams 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 Example: AND/OR decomposition of alternatives for achieving the meeting-scheduling goal - 13 -

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

  15. Softgoal Analysis Example (3,2) Example for“High Usable System” Softgoal - only this softgoal is expanded • Softgoal Analysis use extended AND/OR diagrams with dependency/hierarchies relationships Dependencies/relationships labeled with “+” when one softgoal supports (positively influences) another - 15 -

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

  17. Softgoal Correlation Analysis (4) • Quality Goals frequently conflict with each other • Correlation analysis helps discover positive or negative relations between softgoals - 17 -

  18. Effort Goal Correlation Analysis (5) • Goal Correlation Analysis correlates goals with thesoftgoals 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 Schedule-meeting goals refinement analysis Checked leaf goals that collectively satisfy all given goals (see next slide) - 18 -

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

  20. Modularization and Composition ofAspectual Requirements [Rashid02, Rashid03] - 20 -

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

  22. Modularization and Composition of AR (2)AORE Model - 22 -

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

  24. Modularization and Composition of AR (4,1)Specify Concerns Specify concerns (example) 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. 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. - 24 -

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

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

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

  28. Modularization and Composition of AR (6,1) Discover requirements and relate to concerns Discover requirements and relate to concerns (example) 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. 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. - 28 -

  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 Compositiontag • 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 valuedescribeswhether another viewpoint req or a set of viewpoint reqs must be satisfied or merely the constraint specified has to be fulfilled - 29 -

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

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

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

  33. Adapting the NFR-Framework to AORE [Sousa] - 33 -

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

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

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

  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] - 37 -

  38. (HELP) (MAKE) (HURT) (BREAK) NFR-Framework Overview (2,3) Priority Order !, !! - 38 -

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

  40. NFR-Framework Overview (2,5) - 40 -

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

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

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

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

  45. Adaptation of NFR-Framework Example - Steps 3,4Identify and Select Possible Operationalizations (4,2) Softgoal AcceptedOper.-Softgoal RejectedOper.-Softgoal - 45 -

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

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

  48. Crosscutting Quality Attributes forRequirements Engineering [Moreira] - 48 -

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

  50. Crosscutting Quality Attributes (2)Requirements Model - 50 -

More Related