Transcript Document 384891

Aspect-Oriented Requirements
Engineering
Awais Rashid
Computing Department
© A. Rashid (2009)
Acknowledgements
• I have worked with a number of people over the years on
the topic of these lectures. They have all contributed to
this work and a number of the slides. A special
acknowledgement is due to the following persons:
– Americo Sampaio, Ruzanna Chitchyan, Vander Alves, Paul
Rayson, Alessandro Garcia, Nathan Weston and Peter Sawyer
(Lancaster University, UK)
– Ana Moreira and Joao Araujo (New University of Lisbon,
Portugal)
– Elisa Baniassad (Chinese University of Hong Kong, China)
– Shmuel Katz (Technion-Israel Institute of Technology, Israel)
– Monica Pinto and Lidia Fuentes (University of Malaga, Spain)
Computing Department
Identifying Concerns in Requirements
Computing Department
10.And a river went out of Eden to water the garden; and
from thence it was parted, and became into four heads.
11.The name of the first is Pison: that is it which compasseth
the whole land of Havilah, where there is gold;
12.And the gold of that land is good: there is bdellium and
the onyx stone.
13.And the name of the second river is Gihon: the same is it
that compasseth the whole land of Ethiopia.
14.And the name of the third river is Hiddekel: that is it
which goeth toward the east of Assyria. And the fourth
river is Euphrates.
Genesis 2:10-14
Computing Department
Where was the Garden of Eden?
•
•
•
•
•
•
•
•
In Taurus Mountains in Anatolia, Turkey?
Near Tabriz in North West Iran?
Ethiopia?
Java?
Seychelles?
Jackson County, Missouri?
Bristol, Florida?
…
Computing Department
What is a Concern?
Computing Department
Dijkstra’s View
“It is what I sometimes have called "the separation of
concerns", which, even if not perfectly possible, is yet
the only available technique for effective ordering of
one's thoughts, that I know of. This is what I mean by
"focussing one's attention upon some aspect": it
does not mean ignoring the other aspects, it is just doing
justice to the fact that from this aspect’s point of view,
the other is irrelevant. It is being one- and multiple-track
minded simultaneously.
E. W. Dijkstra, EWD 447, 1974
Computing Department
Parnas’ View
“Every module in the … decomposition is
characterized by its knowledge of a design
decision which it hides from all others. Its
interface or definition was chosen to reveal as
little as possible about its inner workings.”
D. L. Parnas, CACM 15(12), 1972
Computing Department
Not One and the Same Thing
• Separation of concerns is …
… a principle to order one’s thoughts. Does not say
what is a concern.
• Modularity and information hidhing is …
… about abstraction. Still need to find the suitable
abstractions.
Computing Department
A Concern is …
“A concern is an interest which pertains to the
system’s development, its operation or any other
matters that are critical or otherwise important to
one or more stakeholders.”
AOSD Ontology from AOSD-Europe
Available from: http://www.aosd-europe.net
Computing Department
When do Concerns Manifest?
Stakeholders
Computing Department
Designers/Developers
Expectation vs. Delivery
Computing Department
Computing Department
Computing Department
“When a wise man, established well in virtue,
Develops consciousness and understanding,
Then as a bhikku ardent and sagacious,
He succeeds in disentangling this tangle.”
Buddhaghosha (Visuddhimagga)
Computing Department
Concerns in Requirements
• Concerns first manifest themselves in
requirements
– Reflect stakeholders’ real concerns
• Separation of concerns should begin with
stakeholders’ concerns
• But too many, often conflicting and
overlapping, perspectives on the system
Computing Department
Repeating Patterns of Concerns
• Mostly same concerns appear in different
concrete forms time and again in systems
• Non-functional ones:
– Security, Distribution, Persistence, Real-time, …
• Functional ones:
– Billing, Registration, Ordering, Booking, Business
Rules, …
Computing Department
Identifying Concerns
Meta Concern
Space
Requirements
Computing Department
System
Space
Use Case based Requirements
Engineering
• In a toll gate system, we must ensure that the vehicle gizmo is read
between the moment the vehicle is detected by the system (when it
is within ten meters of the toll gate) and enters the toll gate
• Several use cases: read gizmo, enter motorway, exit motorway.
Read gizmo
Vehicle-gizmo
Enter
motorway
Computing Department
Exit
motorway
Use Case based Requirements
Engineering
• A Shuttle Transport System
Accountancy
<<include>>
Disrupt Track
Passenger
Make Trip
Monitor
Broadcast Order
<<include>>
<<constrain>>
Pay for Trip
<<include>>
Pay for Services
|Move to Intermediate
Station
Shuttle
Pay Shuttle
Get Maintenance
<<include>>
Accountancy
Shuttle
Register
Initialize Parameters
Bid for Contract
<<include>>
Computing Department
Initialize Capital
Repair Shop
Is a Use Case a Concern?
• A step-by-step usage path through a system
– Such a path may run through multiple concerns
• Use cases may overlap
• No means to capture non-functional concerns
Computing Department
Viewpoint-oriented Requirements
Engineering
• In a toll gate system, we must ensure that the vehicle gizmo is read
between the moment the vehicle is detected by the system (when it
is within ten meters of the toll gate) and enters the toll gate
• Involves several user and system viewpoints: gizmo, vehicle, toll
gate.
Name
Focus
Concerns
Toll gate
…
response time, securiy
…
Sources
Name
RequirementsFocus
Concerns
History
Vehicle
…
response time
Name
Sources
Focus
Requirements
Concerns
History
Computing Department
Sources
Requirements
History
…Gizmo
…
response time
…
Is a Viewpoint a Concern?
• A viewpoint represents the perspective of a
stakeholder (user or system) on the system
under development
• Viewpoints naturally overlap
• A viewpoint carries a slice of each concern
relevant to the particular stakeholder
– Not all concerns are relevant or as important for all
stakeholders
• Mostly focusing on functional concerns
Computing Department
Goal-Oriented Requirements
Engineering
• In a toll gate system, we must ensure that the vehicle gizmo is read
between the moment the vehicle is detected by the system (when it
is within ten meters of the toll gate) and enters the toll gate
• Distinguish between goal and soft goal
Gizmo
Vehicle
Respons
e Time
PlateNr
Gizmo
is-part-of
DetectVehicle
ReadGizmo
is-part-of
Tollgate
Computing Department
Respons
e Time
Is a Goal a Concern?
• Typically focused on broadly-scoped nonfunctional properties
– Which are non-functional concerns
• Catalogues of non-functional concerns
Computing Department
The Problem of Crosscutting
Concerns
• The dominant decomposition
– Slice requirements on the lines of viewpoints, use
cases and goals
• A number of concerns do not naturally fit these
dominant decomposition boundaries
Computing Department
Scattering and Tangling
• Scattering
– The specification of one
property is not encapsulated
in a single requirements unit,
e.g., a viewpoint, a use case.
• Tangling
– Each requirements unit contains
descriptions of several properties
or different functionalities
Computing Department
Aspect-Oriented Requirements
Engineering
• Improved support for separation of crosscutting
functional and non-functional properties during
requirements engineering
– A better means to identify and manage conflicts arising due to
tangled representations
•
Improved understanding of the
Identify
the mapping
andability
influence of
problem
and
torequirements-level
reason
aspects on artefacts at later development stages
aboutcritical
it trade-offs even before the architecture is
– Establish
derived
• Trace aspectual requirements and their trade-offs to
architecture and subsequently all the way to
implementation
Computing Department
AORE in the Broader RE
Context
Elicitation
Concern
Identification
Concern
Composition
Validation
Concern
Representation
Trade-Off
resolution
Concern
Mapping
Legend:
Activity in the process
Flow of activities
Overlapping of activities
AORE contribution
Computing Department
Architecture
Design
Managing Crosscutting Concerns
in Requirements
• To find crosscutting in requirements, look for
behavioural terms or concepts that are
mentioned in more than one location
• 1. Pay interest of a certain percent on each account
making sure that the transaction is fully completed
and an audit history is kept.
• 2. Allow customers to withdraw from their accounts,
making sure that the transaction is fully completed
and an audit history is kept.
Computing Department
Managing Crosscutting Concerns
in Requirements
• Separate each of those concepts into a section of their
own
1. Pay interest of a
certain percent on
each account
2. Allow customers to
withdraw from their
accounts
Computing Department
3. To fully complete a transaction...
4. To maintain an audit history...
Managing Crosscutting Concerns
in Requirements
• Composition specifies the crosscutting
relationship, showing how crosscutting concerns
affect base concerns
1. Pay interest of a
certain percent
on each account
2. Allow customers
to withdraw from
their accounts
Fully complete pay interest and withdraw
3. To fully complete a transaction...
Audit pay interest and withdraw
4. To maintain an audit history...
Computing Department
Tyranny of Dominant
Decomposition … again
• Aspects capture crosscutting concerns
• Analysed with reference to a base
decomposition
• What about concerns that do not fit the aspect
boundaries?
• Can we really capture all concerns effectively
using such a base-aspect dichotomy?
Computing Department
What Does the Tyranny mean in
RE Terms?
Broadly-scoped requirements,
e.g., goals, aspects, etc.
Analysis conducted using
Base decomposition:
Functional Requirements
(Viewpoints, use cases, etc.)
Main drivers for architectural quality analyses
But why not these?
Computing Department
Multi-Dimensional Nature of
Concerns
Computing Department
Concern Identification: The Scale
of the Problem
Computing Department
Concern Identification: A
Solution?
Computing Department
Computing Department
Requirements Sources
• Requirements documents tend to be
unstructured
• Requirements can take a variety of forms
–
–
–
–
–
–
Natural Language
Interviews
Sketches
Standardisation documents
Organisational procedures
………
Computing Department
Concern Identification Challenges
• Time consuming and error prone activities
– Requirements elicitation and analysis
• How to identify the concerns (or aspects, base abstractions, etc.)?
• How the concepts are related?
• How to structure them into a model?
• Why?
– Replication of requirements (crosscutting) and unrelated responsibilities
(tangling) are difficult to find and separate
– Documents can be of varied structure and nature (e.g., user manuals,
legacy specifications, e-mails, etc.)
– Size matters (e.g., 5,000 words document takes 20 minutes just to read)
• Therefore
– Tool support is vital for identifying concerns and structuring them into a
suitable model for requirements analysis
Computing Department
Thinking Multi-Disciplinary
• Software is no longer an isolated entity
• Part of a larger socio-technical system
• Ethnography
– To understand the processes by which concerns are
identified and structured
• Natural Language Analysis
– To understand how concerns are expressed in natural
language descriptions
Computing Department
The EA-Miner Tool
•
Provides automation support for concern
identification
Uses Natural Language Processing (NLP) to
reason about the properties and semantics of
requirements expressed in natural language
Can identify concerns in both asymmetric AORE
models (e.g., viewpoint-based) or multidimensional models
Reduce the complexity (effort) of concern
identification
•
•
•
–
Not aimed at automating 100% of the tasks
Computing Department
How EA-Miner Works?
…All potential users of the system must first enroll with
the system; once enrolled they have to log on to the
system for each session. … (Requirement Document)
WMATRIX
NLP Processor
EA-Miner
<s>
<w pos="DB" svo="" lemma="all" sem="N5.1+">All</w>
• Identification of Concepts (e.g.,
<w pos="JJ" svo="" lemma="potential" sem="DMOD">
viewpoints, early aspects,
relationships)
potential</w>
• Filtering of candidates
<w pos="NN2" svo=“s" lemma="user"
• Generation of concern model
sem="A1.5.1/S2mf">users</w>
Computing
Department
</s>
Plural noun
EA-Miner high level architecture
View Generator
Eclipse GUI
Viewpoint
View
WMATRIX
Controller
Other Model
View
Specification Generator
Viewpoint
RDL in XML
In Word File
file
Requirements to internal
model parser
Viewpoint
parser
Other Model
parser
Computing Department
Internal model
Viewpoint
Other
Viewpoint-based AORE
• Viewpoint groups requirements from the
perspective of a stakeholder or other system
(e.g., Driver, ATM, Toll Gate on a toll System)
• Viewpoints are base elements
• Aspects are broadly scoped requirements that
crosscut the viewpoints (e.g., security, real-time)
Computing Department
How EA-Miner Identifies
Viewpoints and Aspects?
• Based on Heuristics and NLP properties
– For the Viewpoint-based AORE model, EA-miner identifies:
• Viewpoints (based on POS tag): Nouns are the
Viewpoint candidates
• Non-functional Aspects: (Based on lexicon of
NFRs and semantic tags): candidates are words
found in the lexicon whose semantic tag is of
interest
• Functional Aspects: candidates are action verbs
who are referenced in the requirements of several
viewpoints.
Computing Department
The NFRs lexicon
• Used for the identification of non-functional aspects
• Semantic tags are important for analysing the context
– Performance:
• Meaning1: How well a football player performed
• Meaning2: A distributed system property
• The lexicon was initially built re-using existing knowledge
(NFR catalogues, domain experts)
– Lexicon entries:
<word content="authorise" sem="S7.4+" nfr="security"> </word>
<word content=“performance" sem=“K4" nfr=“performance"> </word>
– Tool will suggest automatic updates in the future
WMATRIX SEM class that groups words related to permission
Computing Department
Requirements Description
Language (RDL)
• A multi-dimensional model – no base-aspect
distinction
• Makes natural language requirement semantics
more explicit and bases composition on these
semantics.
• How?
– Use grammatical information
– Use semantic grouping from linguistics
– Use natural language processing to help automation
Computing Department
How EA-Miner Identifies Concerns
for an RDL-based Analysis?
• Based on Heuristics and NLP properties
• NOUN-Based concerns (based on POS tag):
Represent general entities and actors of the
system.
• Functional-based Concerns (Based on POS tag):
Represent functionalities, operations.
• NFR-based Concerns (Based on lexicon of NFRs
and semantic tags): Represent broadly-scoped
NFRs of the system.
Computing Department
Sort by Frequency
Sort by Name
Assign Requirement Uniquely
Filter
Add Concern
Add Requirement
Delete
Merge Concerns
Move Requirements
Save AORE model
Computing Department
Generate specification in Word
Delete All Empty Concerns
Generate specification in RDL
format (XML)
How Do We Know it Works?
• 1st Case Study: Comparison of 3 different
systems between manual versus EA-Miner
based approach
– Research question: How well does EA-Miner perform
when compared with a manual approach
– Comparison Dimensions: Effort (Time Spent) and
Quality of output: based on the judgment of a third
senior engineer
– Findings:
• Improvements for the tool were found
• Tool can provide valuable information and save time
Computing Department
Comparative Results
Number of Viewpoints Identified
12
11
10
9
8
8
8
7
Senior Requirements Engineer
6
6
Manual
Tool-based
4
4
4
4
2
0
Auction System
Computing Department
Light Control System
Library System
Comparative Results
Number of Early Aspects Identified
9
8
8
7
7
7
6
6
6
5
Senior Requirements Engineer
4
4
3
3
3
2
2
1
0
Auction System
Computing Department
Light Control System
Library System
Manual
Tool-based
In an industrial Setting
• 2nd Case Study: INDUSTRIAL (Siemens)
Case Study: toll system
– Research question: How well does EA-Miner
perform when used in a real industrial case
study?
– Findings:
• The tool can help to spot important
concerns missed by the developers as well
as the requirements describing them in the
source documentation
Computing Department
Summary
• Concerns first manifest themselves in
requirements
– This is where we must start to treat them
• Concern identification is a non-trivial task
– Requires us to go beyond our traditional software
engineering boundaries
• Tool support is essential to aid the requirements
engineers in building concern models
Computing Department
Selected Further Reading: AspectOriented Requirements Engineering
• Early Aspects Portal: http://www.early-aspects.net.
• Report synthesising state-of-the-art in aspect-oriented requirements
engineering, architecture and design, Chitchyan et al., Available
from: http://www.aosd-europe.net.
• Modularisation and Composition of Aspectual Requirements,
Rashid, Araujo, Moreira, Proc. AOSD Conference 2003, ACM.
• Discovering Early Aspects, Baniassad, Clements, Araujo, Moreira,
Rashid, Tekinerdogan, IEEE Software 23(1), Jan/Feb 2006.
• Aspect-Oriented Requirements Engineering: an Introduction,
Rashid, International Conference on Requirements Engineering
(RE), 2008, IEEE CS.
Computing Department
Selected Further Reading: MultiDimensional Models
• N Degrees of Separation: Multi-Dimensional
Separation of Concerns, Tarr, Ossher, Harrison,
Sutton, Proc. International Conference on
Software Engineering 1999, ACM.
• Multi-dimensional Separation of Concerns in
Requirements Engineering, Moreira, Rashid,
Araujo, Proc. Requirements Engineering Conf.,
2005, IEEE CS Press.
Computing Department
Selected Further Reading: EAMiner
• Towards Automation in Aspect-Oriented Requirements
Engineering, Sampaio, Rashid, Chitchyan, Rayson, To
Appear in Transactions on Aspect-Oriented Software
Development Special Issue on Early Aspects.
• A Comparative Study of Aspect-Oriented Requirements
Engineering Approaches, Sampaio, Greenwood, Garcia,
Rashid, International Conference on Empirical Software
Engineering and Metrics, 2007. IEEE CS
• EA-Miner: A Tool for Automating Aspect-Oriented
Requirements Identification, Sampaio, Chitchyan,
Rashid, Rayson, Proc. International Conference on
Automated Software Engineering 2005, ACM.
Computing Department
Download and Play with EAMiner:
http://www.aosd-europe.net/deliverables/D73EAMinerDistribution.zip
• Includes:
–
–
–
–
Installation Guide
User manual
Sample files
Eclipse plug-in (.JAR)
• WMatrix is accessible at:
http://www.comp.lancs.ac.uk/ucrel/wmatrix/
Computing Department
Concern Dependencies and
Interactions
Computing Department
“The first step towards the management of disease
was replacement of demon theories and humours
theories by the germ theory. That very step, the
beginning of hope, in itself dashed all hopes of
magical solutions. It told workers that progress
would be made stepwise, at great effort, and that a
persistent, unremitting care would have to be paid
to a discipline of cleanliness. So it is with software
engineering today.”
Fred Brookes, No Silver Bullet
Computing Department
Why do We Wish to Separate
Concerns?
• Modular Reasoning
– Keep concerns separated regardless of how they
affect or influence various other concerns in the
system, so that we can reason about each concern in
isolation
• Compositional Reasoning
– Understand the dependencies and interactions
amongst concerns to reason about the global or
emergent properties of the system
Computing Department
Two Types of Dependencies
• At the requirements-level
– How concerns influence or affect each other?
– Which concerns reinforce each other and which ones conflict?
– What are the trade-offs amongst concerns?
• Beyond requirements analysis
– How do concerns refine and map to architecture, design and
implementation?
– How changes in requirements affect the solutions we devise?
– Does the resultant design and implementation meet
stakeholders’ concerns?
Computing Department
Requirements Dependencies and
Interactions
Computing Department
Alice through the Looking Glass
Security
Concern
Computing Department
Other Concerns
Trade-off Analysis
• Basic questions
– Are the solutions that are being suggested as good as
possible?
– How much must I give up to get a little more of what I
want most?
• How can we define a good / better outcome?
– Reduced time of response
– Improved security access
– Increase number of clients being served
simultaneously
Computing Department
Decision Support
• Finding the combination that better satisfies the
stakeholder goals
• What can actually be done given reality and
resource constraints?
– Use sophisticated techniques such as MCDM, fuzzy
logic, etc.
– Use some simple way to achieve a ranking between
conflicting concerns (with the stakeholders help)
Computing Department
Externalised Dependency
Discovery
• Discovering dependencies during the software
development process
–
–
–
–
–
During release planning
Change management
Reuse
Use cases
…
Computing Department
Discovering Intentional
Dependencies
• Study the semantics of requirements
– Look at how and what stakeholders expressed
– Inherently intentional dependencies
• May not be obvious
– Concerns may interact in subtle ways
• A requirement may indirectly utilise data modified
by another requirement
• Improved connectivity would improve mobility
Computing Department
Back to Multi-Disciplinarity
• Linguistic models
– Links between meaning of words and their
grammatical representation
• Example:
– Archaic English verb gally
– “Sailors gallied the whales”
– “Whales gally easily”
Computing Department
to see
to frighten
Grammatical Semantics to
Understand Dependencies
Concern Security
R1: Users must enrol with the system
Subject Degree Relationship
Computing Department
Object
Subject-Object Dependencies
• Direct dependencies
– Understand links between requirements
– An object in one requirement may form the subject of
another requirement
• Indirect dependencies
– Discover data- and control-flow dependencies early
on
Computing Department
Dependencies through Synonyms
• Users can be referred to in many ways in other
requirements
–
–
–
–
Customers
Sellers
Buyers
…
Computing Department
Dependencies and lemmatisation
• Different terms may be variants of the same
base form
– enrols, enrolling and enrolment can be reduced to
enrol
• Simple syntactic or lexical match cannot reveal
this dependency
Computing Department
Semantic Dependencies
• Different concerns may belong to the same
semantic category
– Authorisation, access control, etc. can be grouped
into the same semantic category of Security.
– May have reinforcement, dependent inclusion or
mutual exclusion semantics
• Or vice versa
– May not belong to the same semantic category
– Performance of the system vs. performance of the
actor
Computing Department
Relationship Semantics
• Verbs express relationships between subjects
and objects
• Hence most fundamental to discovering
dependencies
• Dixon’s classification of verbs
– Varying grammatical behaviour of verbs is due to
differences in their meaning
Computing Department
Dixon’s Verb Classification
Relationship Types
Relating
Affect
Touch
Happening
Competition
Stretch
Giving
Wrap
Stab
Weather
Rub
Rest
Comparing
Sit
Stay
Motion
Arrive
Take
Drop
Using
Open
Put
Throw
Carry
Follow
Computing Department
Thinking
Think
Social Contract
Assume
Hold
Contain
Forgive
Shout
Order
Report
Tell
Inform
Acting
Obeying
Speaking
Talk
Liking
Hit
Run
Annoying
Build
Attention
See
Show
Watch
Look
Recognise
Witness
Discover
Ponder
Believe
Solve
Conclude
Know
Remember
Deciding
Resolve
Believe
Patterns of Participating Roles
• Giving type verbs require Donor, Gift and
Recipient roles
– Alan gave the keys to Peter.
Donor
Gift
Recipient
• Attention verbs require Perceiver and
Impression roles
– The instructor witnessed the accident.
Perceiver
Computing Department
Impression
Condensing the Verb Categories
• Positive and Negative sense of each verb category
– Use: Utilise vs. Waste
– Change: Increase vs. Decrease
• Some categories are too fine-grained
– Touch and Hit only differ in the intensity of the contact action
– Look and Watch only differ in the duration of observation
•
Some categories could be amalgamated
– Giving and Taking are opposites
Computing Department
Condensing the Verb Categories
Relationship Types
Comparing
Happening
Relating
Annoying
Competition
Liking
Affect
Build
Touch
Hit
Talk
Tell
Giving
Thinking
Rest
Hold
Motion
Stay
Open
Sit
Run
Drop
Arrive
Throw
Believe
Know
Social Contract
Put
Think
Contain
Assume
Attention
Computing Department
Show
Look
Recognise
Witness
Carry
Take
Discover
Solve
Conclude
Ponder
See
Watch
Follow
Report
Acting
Using
Rub
Wrap
Inform
Shout
Forgive
Obeying
Stretch
Order
Discuss
Weather
Stab
Speaking
Remember
Deciding
Resolve
Believe
Condensed Verb Categorisation
Relationship Types
General
Actions
Affect
Damaging &
Destroying
Create &
Transform
Avoid
Compete
Obey
Modify/Change
Corporeal
Use
Touch
Rest
Hold
Move
Set in
Motion
Group
Maintain
Put
Commute
Transfer
Possession
Compare
Constrain
Mental
Actions
Communicate
Order
Talk
Discover
Like/
Dislike
Show
Discuss
Think
Inform
Decide
See
Solve
Computing Department
How was it Condensed?
• Some major groups remain
– Affect, Move, Rest
• Others amalgamated or repositioned
– Attention and Thinking into Mental Action
– Speaking and Show into Communicate
• General Actions as a convenience group for
action verbs
• Still retain the patterns of participating roles
Computing Department
Reasoning about Influences
relat
e
Relationship Types
General Actions
affect
Compete
Affect
enable
compete
break
Avoid
Obey
Damaging &
Destroying
Create &
Transform
avoid
comply
Corporeal
Use
Touch
Modify/Change
use
feel
Constrain
apply
keep
modify
Compare
Rest
enforce
evaluate
Hold
Maintain
consider
includ
e
move
Mental Actions
satisfy
Put
Move
aggravate
retain
Like/ Dislike
Discover
Set in Motion
Commute
observe
Decide
correspond
begin/end
deliver
Group
Solve
Talk
Transfer Possession
Computing Department
provide
group
Think
decide
Communicate
reflect
Order
talk
conclude
See
make
Show
discuss
Discuss
demonstrate
witness
Inform
inform
Relative Degrees of Importance
and Influence
Degree
Modals
Maximizers
Boosters
Approximators
Diminishers
Compromisers
Computing Department
Exclusivizre/
Paticulazers
Minimizers
Dependencies Across the Lifecycle
Computing Department
“Enter and ask”.
An inscription in the Alhambra in Granada.
Computing Department
Issues on Mapping and
Traceability
• Is a requirements concern always a design and
implementation module?
• How do requirements concerns map onto later
development stages?
• How can we ensure forward and backward traceability
between requirements concerns and corresponding
architecture, design and implementation?
• How do we know that the requirements concern tradeoffs are preserved and respected by the design and
implementation?
Computing Department
Mapping Compatibility Concern to
Architecture
Compatibility
Concern
may conflict with other concerns
Response Time
Concern
Option 1: Mapping to an
Architectural Element
Option 2: Mapping to an
Implementation Decision
Adapter
Use of Compatible
Technologies
implies a new architectural decision
Option 1.2
Option 1.1
ATM
PS
DS
Adapter
Computing Department
Toll Gate System
ATM
PS
DS
Adapter
Adapter
Adapter
Toll Gate System
How do Requirements Concerns Map
onto Later Development Stages?
• A concern in requirements may be resolved as non-software
solution (e.g. for some business hiring a security guard to satisfy a
Security concern → no mapping to software architecture)
• Architectural Decision (e.g., the architectural topology for
Compatibility concern)
• Architectural Module or an element of a module which has localised
influence in architecture (e.g., a method checking correctness or
some processing within a component)
• Aspectual Architectural Modules which influence a number of other
architectural components (e.g., a module providing encryption and
decryption functionality)
Computing Department
Concern Traceability
• As always need Tool Support for Traceability, but
– Dedicated modules for concerns at various levels help with direct
mapping where appropriate
– Composition specifications at various levels help in tracing influences:
• Examples of composition specifications in Architecture are bindings
in ADL supported in connectors or dedicated composition
languages as part of traceability templates
– Correspondence between meta-models of requirements and
architecture (etc.) elements helps with mapping and traceability
guidelines.
• Mapping patterns of concern compositions in requirements to
patterns of component or aspect compositions in architecture,
design and implementation
Computing Department
Concerns Driving Architectural
Choices
Concerns
Architecture Choices
Response
Time
…
Availability
…
.
.
Security
Computing Department
.
.
…
Where Does the Final Architecture
Reside?
Computing Department
Architecture
Availability
Performance
Security
Multi-access
Are Trade-offs Preserved and
Respected?
• Need to connect concerns to their concrete realisations
in design and implementation
– Need to know that trade-offs established at requirements level
are preserved in the implementation
• Needs precise semantics for requirements
• Proof obligations may be used for:
– Formal verification of the resultant system (e.g., via model
checking)
– Deriving test cases
Computing Department
Concern Proof Obligations
• Temporal logic formulas about concern
• Group individual formulas to those treating each
concern
• Must treat potential conflicts among concerns
(as identified in requirements)
Computing Department
Temporal Logic Formulas
•
•
•
•
•
Gp: from now on, p is true
Fp: eventually, p will be true
pUq: p is true until q becomes true
Can be input for formal methods tools
G((veh-ent-sys((Fveh-ent-toll)/\
((¬veh-ent-toll)Uread-gizmo)))/\(readgizmogizmo-effects) /\ (time(veh-ent-toll) –
time(veh-ent-sys) < N))
Computing Department
Conflict Analysis
• Multiple concerns with contradictory requirements
– Availability (backup system) vs Response Time
• Often requires preferring one over the other or
weakening for real conflicts
• Solution: weakened properties for conflict resolution
– Weak Resp. Time:… time(E2) – time (E1)<N+Extra
Computing Department
The Resulting Proof Obligations
• Collection of temporal formulas from the
requirements with predicates instantiated
• Possibly weakened versions for conflicts
• Assertion of non-interference among concerns
• Assertion that desirable properties of the system
are still true as new concerns are augmented
during incremental development
Computing Department
Summary
• Dependencies and interactions are not a problem
– They are inherent and essential to the systems we are trying to
analyse and design
– Understanding them is essential for effective compositional
reasoning
• Semantics of the natural language capture such
dependencies and interactions
– Can be used to expose and study them
• Clearer mapping of concerns to architecture and beyond
• Early trade-off analysis and resolution
• Improved traceability of stakeholders’ concerns to the
solution and its implementation
Computing Department
Selected Further Reading: Verb
Classification
• A Semantic Approach to English Grammar, 2
ed., Dixon, Oxford University Press, 2005.
• English Verb Classes and Alternations: A
Preliminary Investigation, Levin, University of
Chicago Press, 1993.
Computing Department
Selected Further Reading: Concern
Dependency Semantics
• Semantics-based Composition for AspectOriented Requirements Engineering, Chitchyan,
Rashid, Rayson, Waters, International
Conference on Aspect-Oriented Software
Development (AOSD), 2007, ACM.
• Tracing Requirements Interdependency
Semantics, Chitchyan, Rashid, Early Aspects
2006: Traceability of Aspects in the Early Life
Cycle Workshop at AOSD 2006.
Computing Department
Selected Further Reading: Concern
Mappings
• COMPASS: Composition-Centric Mapping of Aspectual
Requirements to Architecture, Chitchyan, Pinto, Rashid,
Fuentes, Transactions on Aspect-Oriented Software
Development: Special Issue on Early Aspects, Accepted
to Appear.
• From Aspectual Requirements to Proof Obligations for
Aspect-Oriented Systems, Katz, Rashid. International
Conference on Requirements Engineering (RE), 2004,
IEEE Computer Society.
Computing Department
Semantics-based Composition of
Concerns
Computing Department
“Oh! thou great Lycurgus, that com’st to my beautiful dwelling,
Dear to Jove, and to all who sit in the halls of Olympus,
Whether to hail thee a god I know not, or only a mortal,
But my hope is strong that a god thou wilt prove, Lycurgus.”
Pythoness of Delphi to Lycurgus of Sparta
(Herodotus: The Histories)
Computing Department
Recap
• What have we Looked at so Far?
– Concerns in requirements represent real concerns of the
stakeholders
– Natural language semantics can give clues about:
• Nature of concerns
• Their relationships and interdependencies
• Next:
– We look at how to exploit these semantics for composition and
analysis
– Using the Requirements Description Language (RDL)
Computing Department
How does it all Fit Together?
Concern
Identification
Concern
Elicitation
Concern
Representation
Requirement
Refinement
Requirement
Mapping
Computing Department
RDL
Link RE &
Architecture
EA-Miner
Requirement
Composition
Trade-Off
Resolution
Problems of Syntactic Matching
• Composition specified in terms of structure (so must
map content to structure);
Concern Bidding
Rn: Buyers are bidding for goods.
Concern Security
R1: Users must enrol with the system
Composition Secure Bidding
concern= Security id= R1
concern= Bidding id= Rn …
Computing Department
Problems of Syntactic Matching
• Infer the semantics of the relationships back
from structure to reason
Composition Secure Bidding
concern= Security id= R1
concern= Bidding id= Rn …
Computing Department
Problems of Syntactic Matching
• Must define each joinpoint/composition point
manually:
– give id/name to each relevant point
– must know ahead these points, or
– constantly refactor
• Fragile compositions: e.g., add new requirement to
violate all id references.
Concern Security
A secure
protocol
mustthe
besystem;
used. a
RR11:: Users
must
enrol with
secure
protocol
used.
R : Users
must must
enrol be
with
the system.
2
Composition Secure Bidding
concern= Security id= R1
concern=
Bidding id= Rn …
Computing
Department
Syntactic Matching in AOSDbased Use Cases
Use Case: Reserve Room
(a)
Link 4
Basic Flow
The use case begins when a customer wants to
reserve a room(s).
1.
The customer selects to reserve a room
2.
The system displays the A types of rooms
the hotel has and their A rates.
3.
The customer Check Room Cost.
4.
The customer makes the reservation for the
chosen rooms.
5.
The System deducts from the database the
number of A rooms of the specified type
available for reservation.
Link 1
6. …
Link 2.1
Link 2.2
Alternative Flows
Use Case: <Perform Transaction>
(d)
Basic
Flow
Basic Flow
…
The use case begins when the actor instance performs a
transaction to view the values of an entity instance
Extension Flows
1.The system prompts the actor instance to identify the
EF1. Queue for Room
desired entity instance.
This extension flow UpdatingRoomAvailability
2.
The actor enters the values and submits his request
occurs at the extension point Update Room
3.The system retrieves the entity instance from data
Availability in the Reserve Room use case when
store and displays its values
there are no Rooms of the selected type available.
Link 7
4.The use case Terminates.
1. The system creates a pending reservation with a
Alternative Flows …
unique identifier for the selected Room type.
Link 6
…
Extension Point
Link 3
Extension Pointcuts
D E1: Access Frequently used Data
extension pointcut UpdatingRoomAvailability =
This extension occurs at step 3 of the Basic Flow when
Reserve Room. Update Room Availability
Frequently Used Data is accessed.
Use Case: Handle Waiting List
(b)
…
B Special Requirements
(c)
Frequently Assessed Data: Room rates, Room Types
Extension Points
<extend>
Handle
Link 5
E1. Update Room Availability
<Perform Transaction>
The Update Room Availability extension point occurs
at step 5 of the Basic Flow.
C E2. Access Frequently Used Data
D
The Access Frequently Used Data occurs at step 2
and step 5 of the Basic flow
Computing Department
<extend> Authorization
<extend>
Audit
Transactions
Provide Cache
Access
(e)
Use Case: Provide Cache Access
Extension Flows:
Link 8
EF1. Look Up Cache
This AccessingData extension occurs when Frequently
Used Data in Reserve Room use case is accessed.
1.
The system looks up the local cache to see if the
requested data is available …
Extension Pointcuts
Link 9
extension pointcut: AccessingData=PerformTransaction.
Access Frequently used Data
Syntactic Matching in Viewpoint-based AORE
<Viewpoint name=“Customer”>
<Requirement id=“1”>The customer selects the room type to view room
facilities. </Requirement>
<Requirement id=“2”> The customer makes a reservation for the chosen
room type with the given room price. </Requirement> …
</Viewpoint>
(a)
<aspect name=“CacheAccess”>
<Requirement id=“1”>The system looks up cache when :
<Requirement id=“1.1”> room type data is accessed; </Requirement>
<Requirement id=“1.2”> room pricing data is accessed; </Requirement>
</Requirement>
</aspect>
(b)
<Composition>
<Requirement aspect=“CacheAccess" id=“1.1">
Computing
Department
<Constraint
action=“provide" operator=“for">
<Requirement viewpoint=“Customer" id=“1" /> …
(c)
Three key problems
• Map developer’s intentionality onto a syntax
governed structural model
• Infer semantic influences and interferences from
syntactic compositions
• Composition fragility
Computing Department
Semantics-based Composition
with the RDL
• Make natural language requirement semantics
more explicit and base composition on these
semantics.
• How?
–
–
–
–
Use grammatical information
Use semantic grouping from linguistics
Use natural language processing to help automation
Basically what we have been talking about in the last
lecture! 
Computing Department
Requirements Description
Language Elements
Requirement
Subject
Object
Relationship
Degree
Computing Department
Concern
RDL Concern Example
Concern Security
R1: Users must enrol with the system
Subject Degree Relationship
Object
<Concern name=“Security”>
<Requirement id=“1”>
<Subject> Users </Subject>
<Degree type=“Modal” semantics=“Modal” level=“high”> must </Degree>
<Relationship type=“Move” semantics=“Group”>enrol </Relationship>
with the
<Object> system </Object>
</Requirement>
Computing
</Concern> Department
Requirements Description Language
Composition Elements
Advise
Base
Constraint
Concern B
Concern A
Req. 1
Req. 2
Outcome
Req. 1
Req. 2
Req. k
Req. x
Req. z
Req. n
Req. y
Computing Department
Semantic Queries
Query:
Select the requirements where user enrols or a
system is enrolled to.
RDL Query
all requirements where
( Subject=“users” and
Relationship=“enrol”
) or (
Relationship=“enrol”
)
Computing Department
Object=“system”
and
Also used in Queries for matching:
Synonyms: register, sign up, join…
Lemmas: enrol, enrolled, enrolling..
RDL Composition Example
Composition:
Apply the requirements where user enrols to a system
before any buyer bids.
<Composition name=“SecureBidding”>
<Constraint operator=“apply”> subject= “user” and relationship=
“enrol” and object=“system” </Constraint>
<Base operator=“before”> subject=“buyer” and relationship=“bid”
</Base>
<Outcome operator=”satisfied”/>
</Composition>
Computing Department
Composition Sequencing Operators
Computing Department
Verb Type-based Query
Composition:
Apply the requirements where user enrols to a system
before all types of activities where goods are exchanged.
<Composition name=“CompAccessCache”>
<Constraint operator=“apply”> subject= “user” and
relationship= “enrol” and object=“system” </Constraint>
<Base operator=“before”> relationship.semantics=
“Transfer_Posession” object=“goods”</Base>
</Concern>
Computing Department
Degree Type Based Query
Composition:
Constraint requirement “Include requirements into 1st
release” should be applied for
all requirements which have Modal verbs of high importance.
<Composition name=“CompFirstRelase”>
<Constraint operator=“include”> “Include requirements into
1st release” </Constraint>
<Base operator=“if”> degree.semantics=“Modal” and
degree.level=“high”</Base>
</Concern>
Computing Department
Automation Support: Wmatrix
• Wmatrix Natural Language Processor
– Semantic Category Annotation
– Part of Speech (POS) Annotation
– Using the POS tags form rules for Subject, Relationship,
and Object identification (continuously improving)
– Map RDL verb classes onto Wmatrix native classification
(continuously improving)
• Used as the backend of EA-Miner, which generates
the annotated files for analysis tools
Computing Department
Composition Challenges
• Multidimensional modularity implies high
complexity and low scalability
• Reducing compositional combinations (and
hence semantic graphs)
– Critical for reasonable response to change / limited
resources with larger specifications
– Compositional intersection
• i.e., orphan semantic links are not included
– Elimination of some potential combinations
Computing Department
Trade-off Analysis using
Compositional Intersection
• Need to observe trade-offs with respect to some base!
– Too many possible combinations when projecting every possible
set of concerns on every other possible set
• Let C1, C2, C3, …, Cn be the concrete concerns in our
requirements spec.
• Let Sc1, Sc2, Sc3, …, Scn be the sets of concerns that
each of them cuts across
• C1  C2 = Ca iff both C1 and C2 semantically
influence/constrain the same or overlapping set of
requirements in Ca
Computing Department
Cumulative Effect of Concern
Contributions
Availability
Information
Retrieval
Mobility
...
Computing Department
Architectural Choices
Concerns
Architecture Choices
Inf. Ret.
…
Availability
…
.
.
Mobility
Computing Department
.
.
…
Where Does the Final Architecture
Reside?
Computing Department
Architecture
Availability
Information
Retrieval
Cost
Mobility
How to Map to Architecture?
Computing Department
SRO Mapping
Computing Department
Summary
• How RDL Addresses Problems of Syntactic
Composition?
–
–
–
–
Composition specified in terms of intentional semantics
No need for manual joinpoint definition
Clear semantics of concern relationships from compositions
Composition fragility ameliorated: will either match or not
depending on the semantics
• Tool support from WMatrix and EA-Miner helps with
identification, representation, composition and analysis
of semantic dependencies
• Map patterns of concern compositions in requirements to
patterns of architecture composition
Computing Department
Selected Further Reading: RDL
• Semantics-based Composition for Aspect-Oriented
Requirements Engineering, Chitchyan, Rashid, Rayson,
Waters, International Conference on Aspect-Oriented
Software Development (AOSD), 2007, ACM.
• A Formal Approach to Semantic Composition of AspectOriented Requirements, Weston, Chitchyan, Rashid,
International Conference on Requirements Engineering
(RE), 2008, IEEE CS.
Computing Department
Selected Further Reading: Mapping
• COMPASS: Composition-Centric Mapping of
Aspectual Requirements to Architecture,
Chitchyan, Pinto, Rashid, Fuentes, Transactions
on Aspect-Oriented Software Development:
Special Issue on Early Aspects, Accepted to
Appear.
Computing Department
Further Information
[email protected]
http://www.comp.lancs.ac.uk/computing/aose
http://www.aosd-europe.net
Computing Department