May%202004%20DBO

1
Early AspectsOverview of Some Approaches

• David Bar-On
• April 2004

2
(No Transcript)
3
Presentation Plan

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

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

5
SMART Requirements Mannion and Keepence, 1995

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

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

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

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

9
Crosscutting/Aspectual Requirements

• Crosscutting Requirements (Req Aspects)
  Nuseibeh
• Aspect Crosscutting Concern
• Aspectual Requirement Crosscutting Requirement
• Concern property of interest to a stakeholder
• Crosscutting interacting, interdependent,
  overlapping
• Quality Attributes (QA) Moreira
• Quality Attribute is a synonym to crosscut-NFR
• QA properties that affect the system as a
  whole(QA is similar to Young ilities)
• QAs are handled together with the FRs

10
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
  RequirementsBaniassadTheme, BaniassadDoc
• ??? UML extensions for AOSD/AORE ???? Theme/UML
  ??
• ???? Viewpoints ??? Nuseibeh

11
Goal Oriented Requirements Analysis

• Mylopoulos

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)

13
Goal Analysis using AND/OR Decomposition (2)

• 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

Example AND/OR decomposition of alternatives for
achieving the meeting-scheduling goal
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

15
Softgoal Analysis Example (3,2)

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

Example forHigh Usable System Softgoal - only
this softgoal is expanded
Dependencies/relationships labeled with when
one softgoal supports (positively influences)
another
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 projects
  stakeholders

17
Softgoal Correlation Analysis (4)

• Quality Goals frequently conflict with each other
• Correlation analysis helps discover positive or
  negative relations between softgoals

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

20
Modularization and Composition ofAspectual
Requirements

• Rashid02, Rashid03

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)

22
Modularization and Composition of AR (2)AORE
Model
23
Modularization and Composition of AR (3)Identify
and Specify Stakeholders Requirements

• Start by identifying and specifying both
  concerns and stakeholders requirements

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 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.
25
Modularization and Composition of AR (4,2)
Identify and Specify Concerns
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

27
Modularization and Composition of AR (5)Identify
Candidate Aspects (2)
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 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.
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.
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

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

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

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

33
Adapting the NFR-Framework to AORE

• Sousa

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

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)

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

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

38
NFR-Framework Overview (2,3)
Priority Order !, !!
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

40
NFR-Framework Overview (2,5)
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)

42
Adaptation of NFR-Framework to AORE (3,2)
43
Adaptation of NFR-Framework to AORE (3,3)
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

45
Adaptation of NFR-Framework Example - Steps
3,4Identify and Select Possible
Operationalizations (4,2)
Softgoal
AcceptedOper.-Softgoal
RejectedOper.-Softgoal
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

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)
48
Crosscutting Quality Attributes forRequirements
Engineering

• Moreira

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)

50
Crosscutting Quality Attributes (2)Requirements
Model
51
Crosscutting Quality Attributes (3)Template for
Quality Attributes (1)
52
Crosscutting Quality Attributes (3)Template for
Quality Attributes (2)
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

54
Crosscutting Quality Attributes (5)Integrating
(weaving) FRs and QAs (1)
55
Crosscutting Quality Attributes (5)Integrating
(weaving) FRs and QAs (2)
56
Crosscutting Quality Attributes (5)Integrating
(weaving) FRs and QAs (3)
57
Towards Composition Process for AOR

• Brito

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)

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-concern
  definition. May be used to automatically
  integrate crosscut requirements into FRs
• Contribution conflicts

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
• Identify how each candidate aspect affects the
  concerns it cuts across (using Overlap, Override,
  Wrap)
• Identify match points based on the Where
• Identify conflicts between candidate aspects
  based on Contribution
• Identify the dominant aspect based on Priority
• Identify composition rule based on the above

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

62
Towards Composition Process for AOR (4)Steps
Needed to Handle Composition
63
Theme and Theme/DocFinding Aspects in
Requirements

• BanissadTheme, BanissadDoc

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

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

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.

67
Theme (4) Theme/Doc Action View
Requirements
flagged identified as professor theme
behavior (could be crosscutting)
logged is primary behavior of R3
logged identified as Crosscutting
Expanded Requirement R3
register identified as Base
68
Theme (5) Clipped Action View
Requirements snipped from Base Actions and left
with Crosscutting only
Crosscutting Action
Crosscutting hierarchy
Base Actions
69
Theme (6) Theme View and Theme/UML (1)
Read from top to bottom
Entity translated to Class
Action translated to Method
70
Theme (6) Theme View and Theme/UML (2)
gray Crosscutting actions/entities (common to
other actions)
Non Crosscutting. Unique to logged
Template Method (handle method for base behaviors)
Entity translated to Database
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
72
Theme (8) Augmented View
Augmented Method
Augmented Associations
Theme/Doc AugmentationAlign a theme with
thedesign decisions to verifythat design
choices arealigned with requirements
73
AORE for Component-based SW Systems

• Grundy

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

75
AOCRE (2) Components Aspects

• Some general use categories for components
  aspects were developed (see below)
• Domain-specific aspects can be specified for
  specialized components

76
AOCRE (3) AOCRE Process
Figure 3. Basic AOCRE process.
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)

78
AOCRE (5) Detailed AOCRE Specs

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

II. Collaborative Work Aspects
COLLABORATION II. 1) data fetch/store functions
DATA_MANIPULATION QUERYtrue
UPDATEtrue II 2) event broadcasting/actions
functions EVENT_MANAGEMENT DETECTtrue
ACTIONtrue II 3) event annotation functions
AWARENESS HIGHLIGHTcolour ANNOTATEtext II
4) - remote data/event synchronisation LOCKING
SYNCHRONOUStrue OR false SEMI_SYNCHRONOUStru
e OR false NETWORK_SPEEDany STOREtrue II 5) -
data/event versioning VERSIONING DATAtrue
EVENTtrue INTERFACEextensible affordances
CHECKINtrue CHECKOUTtrue Figure 5. Detailed
aspect-oriented component requirements
specifications.
79
AOCRE (6) Aspects Reasoning and Aggregation

• After components 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 code
  can this be done automatically for
  requirements?

80
Composition Filters

• Bergmans

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

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 Expression1) Target inner
Selector 2) Target doc Selector

CF Representation of a Class
Implementation of non-crosscutting concerns of a
Class
83
Composition Filters (3)Filter Types
84
Composition Filters (4) - Error Filter
Enforce required multiple views on the
documentClass PortClaimDocument declares two
conditions FinancialResp and MedicalResp which
evaluate to true if the responsibility of the
sender is financial or medical
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 (gt exclution
operatorif True all messages match except the
ones in the list)
85
Composition Filters (5) - Superimposition
CF model provides the superimposition mechanism
to impose filter interfaces onto one or more
objects
NoActiveThreadsgt if no condition
NoActiveThreads is true, all messages can pass
this filter
allTaskslt-MulExSync filter interface
MutExSync to be superimposed upon all all
instances defined by selector allTasks of the
same class
86
UML Extensions for AOSD ????

• ????