«URN » D. Amyot uOttawa URN: Application and Research Areas1 User Requirements Notation (URN) Application and Research Areas Daniel Amyot SITE, University

URN: Application and Research Areas 1

«URN »

D. Amyot uOttawa

User Requirements Notation (URN)

Application and Research Areas

Daniel AmyotSITE, University of [email protected]

UofT, August 23, 2007


«URN »

D. Amyot uOttawa

MSC, UML Use

Case Diagram & Activity Diagram

Informal Requirements,

Textual Use Cases

Structural Diagrams

SDL, eODL, or UML class, object,

component, & deployment

diagrams

Testing and Performance Languages

TTCN, LQN, ...

Behavioral DiagramsMSC/SDL, or UML

sequence, collabor., & statechart diagrams

DataModeling Puzzle – Common View

Can we do better to

bridge this gap?


«URN »

D. Amyot uOttawa

Overview of the Presentation

Overview of URN• Goal-oriented Requirements Language (GRL)• Use Case Maps (UCM)

URN Analysis Techniques• GRL Strategies• UCM Scenarios

Application and Research Areas• Transformations to Message Sequence Charts and test goals• Architectural Evaluations• Performance engineering• Business process modelling and management• Requirements management and policy compliance• Pattern formalization• Reverse engineering• Aspect-oriented requirements engineering


«URN »

D. Amyot uOttawa

User Requirements Notation (URN)

• ITU-T Languages in Study Group 17

— SDL, MSC, ASN.1, TTCN-3, eODL, URN, …

— UML 2.0 profiles

• ITU-T Z.150: User Requirements Notation (URN)

— Focus on early stages of development with goals and scenarios


«URN »

D. Amyot uOttawa

URN Proposal

Combined use of two complementary notations:

• Goal-oriented Requirement Language (GRL)

— for goals and non-functional requirements

— http://www.cs.toronto.edu/km/GRL/

• Use Case Maps (UCM)

— for operational requirements and architectures

— http://www.UseCaseMaps.org/

— http://www.UseCaseMaps.org/pub


«URN »

D. Amyot uOttawa

GRL in a Nutshell

Goal-oriented Requirement Language

• graphical notation

• connects requirements to business objectives

• allows reasoning about (non-functional) requirements

• has its roots in i* and the NFR framework

GRL models the “why” aspect

• objectives, alternatives, as well as decision rationales

• little or no operational details

Supports goal and trade-off analysis and evaluations


«URN »

D. Amyot uOttawa

Basic GRL Notation

Correlation(side-effect)

Cost ofTerminal

Belief

Biometrics is noregular off-the-shelf

technology

?Break Hurt Some- Unknown

Make Help Some+ Equal

PasswordCardkey Biometrics

OR Goal

IdentificationAuthentication

AND

..

Task

Make

AccessAuthorization Encryption

Contribution

Decomposition Security ofHost

Security ofTerminal

AND

Softgoal SystemSecurity


«URN »

D. Amyot uOttawa

Advanced GRL Notation

• GRL graphs can be allocated to actors

• Dependencies can be defined between actors, together with intermediate resources.

..


Identification

Cost ofTerminal


technology

AccessAuthorization

Encryption

Authentication

Securityof HostSecurity of

Terminal

SystemSecurity

ActorBoundary

...


Identification

Cost ofTerminal


technology

AccessAuthorization

Encryption

Authentication

Securityof HostSecurity of

Terminal

SystemSecurity

ActorBoundary

.

TaxPayer

Payment

ForwardTax Forms

ResourceDependency

TaxPayer

Payment

ForwardTax Forms

ResourceDependency

ElectronicAccountant

Actor

ElectronicAccountant

Actor

Keep PasswordSecret

Keep PasswordSecret


«URN »

D. Amyot uOttawa

Why GRL?

• Goals are an important driver for requirements elaboration

• GRL expresses and clarifies tentative, ill-defined and ambiguous requirements

— Supports argumentation, negotiation, conflict detection & resolution, and decisions

— Captures decision rationale and criteria (documentation!)

• GRL identifies alternatives (requirements, architectures, means…)

• GRL provides traceability from strategic objectives to technical requirements

• GRL allows reuse of stable higher-level goals when the system evolves

• Nothing quite like this in UML…


«URN »

D. Amyot uOttawa

UCMs in a Nutshell

Use Case Maps

• graphical scenario notation

• causal relationships between responsibilities

• scenario elements may (optionally) be allocated to components

UCMs model the “what” aspects

• functional requirements as scenarios

• integration and reusability of scenarios

• guidance for architecture and detailed behaviour

Performance analysis, conflict detection, transformations


«URN »

D. Amyot uOttawa

Component

StartPoint

End Point

Responsibility

Stub

AND-Fork

Pool

a) Root UCM

Slot

b) Biometrics Plug-In c) PassWord Plug-in

Timer

OR-Fork

UCMExample

OR-Foin

Bindings for Authorize:[atNight] Biometrics {(IN1,Bio), (OUT1,Yes), (OUT2,No)}[!atNight] PassWord {(IN1,PW), (OUT1,Yes), (OUT2,No)}


«URN »

D. Amyot uOttawa

Why Use Case Maps?

• Help bridge the modeling gap between use cases, requirements, and design

— Link behavior and structure in an explicit and visual way— Provide a behavioral framework for making (evaluating)

architectural decisions at a high level of design— Characterize the behavior at the architecture level once the

architecture is decided• Enable reasoning about many integrated scenarios (FIs)• Can model dynamic systems where scenarios and structures

may change at run-time• May be transformed into more detailed representations• Effective learning tool for people unfamiliar with the

domain


«URN »

D. Amyot uOttawa

• Most frequently, URN links are used to trace …

—Actors in GRL models to components in UCM models

—Tasks in GRL models to maps or responsibilities in UCM models

• jUCMNav also allows other intentional elements to be linked to responsibilities or maps

• Other links are currently restricted in the tool even though the URN metamodel allows links from any URN modeling element to another

URN (Typed) Links

Actor Intentional

Element

Component

Map

Responsibility


«URN »

D. Amyot uOttawa






«URN »

D. Amyot uOttawa

Cost ofTerminal


technologyPasswordCardkey Biometrics

OR


AND

..Access

Authorization Encryption

Security ofHost

Security ofTerminal

AND

SystemSecurity

Evaluations with GRL (strategy 1)

Satisficed

Weakly Satisficed

Undecided

Weakly Denied

Denied


«URN »

D. Amyot uOttawa

• Evaluations of GRL graphs show the impact of qualitative decisions on high level softgoals

• Propagation is usually bottom-up• Fuzzy evaluation of satisfaction level• Takes into consideration four parameters:

— Degrees of satisfaction of children (satisficed, denied, …)— Composition operators (AND, OR)— Contributions and correlations (+/-, sufficient or not)— Dependencies

• More complete than simple pros/cons tables or criteria evaluation matrices

• One could use numerical values and functions instead of qualitative values (see jUCMNav tool)

Evaluations with GRL


«URN »

D. Amyot uOttawa

Cost ofTerminal


technologyPasswordCardkey Biometrics

OR


AND

..Access

Authorization Encryption

Security ofHost

Security ofTerminal

AND

SystemSecurity

Satisficed

Weakly Satisficed

Undecided

Weakly Denied

Denied

Evaluations with GRL (strategy 2)


«URN »

D. Amyot uOttawa

GRL Strategies

• User defined sets of initial evaluations• Propagated to the rest of the model• Numerical interpretation of satisfaction levels• Implemented using the strategies view• Visual coloured feedback• Cycles permitted• Evaluation of the impact of strategies on the

operational and architectural aspects, using URN links


«URN »

D. Amyot uOttawa

Strategies in jUCMNav

A star (*) indicates an initial value part of

a given strategy. All the others are evaluated through a propagation

algorithm.


«URN »

D. Amyot uOttawa

Numerical Evaluation in jUCMNav

Evaluation between -100 and 100.

E = -100 Denied

-100 < E < 0 Weakly Denied

E = 0 Undecided

0 < E < 100 Weakly Satisficed

100 Satisficed


«URN »

D. Amyot uOttawa

Numerical Evaluation: Decompositions

Minimum for AND, maximum for OR

And Decomposition Or Decomposition


«URN »

D. Amyot uOttawa

Numerical Evaluation: Contributions

For each contribution, convert the contribution level to the corresponding weight factor

Make = 1

Help = 0.5

Some Positive = 0.25

Unknown = 0

Some Negative = -0.25

Hurt = -0.5

Break = -1

Contributions are additive, but are normalized.


«URN »

D. Amyot uOttawa

Numerical Evaluation: Dependencies

Intentional element evaluation is set to the minimal value in the set of dependees evaluation or it current evaluation


«URN »

D. Amyot uOttawa

Actor Evaluation

• Evaluations deal with negotiations between stakeholders

• Actor evaluations help analyzing and comparing the satisfaction levels of each actor based on the selected strategy

• Computed from priority and criticality attributes of intentional element references bound to actors


«URN »

D. Amyot uOttawa

Numerical Evaluation: Actor Evaluation

Priority = LowCriticality = None

Priority = NoneCriticality = High


«URN »

D. Amyot uOttawa

UCM Scenario Definitions and Path Traversal (Highlight)

• Extraction of individual scenarios based on a traversal algorithm

• Conditions attached to selection/start/end points

• Initialization of global variables, and selection of start points and expected end points

• Data types: Boolean, integer, enumerations

• Used for validation and transformations


«URN »

D. Amyot uOttawa

GRL - UCM Relationship

Goal-based approach

• Focuses on answering “why” questions

• Functional and non-functional requirements

Scenario-based approach

• Focuses on answering “what” questions

Goals are operationalized into tasks and tasks are elaborated in (mapped to) UCM scenarios

• Focus on answering “how” questions

Enables completeness and consistency analysis

User-defined links for requirements management

• Any GRL element can be linked to any UCM element


«URN »

D. Amyot uOttawa

?

?MSC, UML Use

Case Diagram & Activity Diagram

Informal Requirements,

Textual Use Cases

UCMs link to operationalizationsand actors in GRL

models

Structural Diagrams

SDL, eODL, or UML class, object,

component, & deployment

diagrams

Testing and Performance Languages

TTCN, LQN, ...

Behavioral DiagramsMSC/SDL, or UML

sequence, collabor., & statechart diagrams

UCMs represent visually use cases in terms of causal

responsibilities

UCMs provide a framework for

making high level and detailed

design decisions

UCMs visually associate

behavior and structure at the

system level

URN-UCMSuperimpose visually system level behavior onto structures of abstract components. Can

replace UML use case / deployment diagrams.

URN-GRLGoals, non-functional requirements, alterna-

tives, rationales

DataModeling Puzzle — URN


«URN »

D. Amyot uOttawa






«URN »

D. Amyot uOttawa

Several Known URN Application Domains

• Telecommunication/telephony services

• Wireless systems

• Object-oriented software

• Multi-agent systems

• Web applications and Web services

• Railway control systems

• Embedded systems

• User interfaces

• Access control procedures• Network protocols• e-Business applications• Supply chain management • e-Health applications• Software product lines• Operating systems• Information retrieval

systems• Vehicle communication

systems• …


«URN »

D. Amyot uOttawa

jUCMNav supports-Scenario definition (with data types, pre/post conditions, start/end points, and scenario inclusion)-Problems View-Scenario highlight


«URN »

D. Amyot uOttawa

jUCMNav Scenario Export

Groups of scenarios can be run togetherScenarios can be exported to:

• UCM model where all scenarios are linearized— Stubs flattened and choices resolved

(but documented with special waiting places) • UCM model where all scenarios are linearized and well-formed

— From graph to “tree” (especially for AND-joins)— Some concurrency may be lost along the way

• MSC model with one diagram per scenario• Can be visualized with embedded MSC viewer


«URN »

D. Amyot uOttawa

jUCMNav supports-MSC viewer-Reordering of instances-MSC export to images


«URN »

D. Amyot uOttawa

UCM-Based Testing

Based on UCM Testing Patterns• Grey-box test selection strategies, applied to

requirements scenarios • Manual

Based on UCM Scenario Definitions• UCM + simple data model, definitions, and path

traversal algorithms• Semi-automated

Based on UCM Transformations• Exhaustive traversal• Mapping to formal language (e.g., LOTOS, ASM)• Automated


«URN »

D. Amyot uOttawa

Comparison

Maturity

Automation

Usability

Transformations

Coverage

Tool Support

Model Evolution

Scalability

Exhaustiveness

Communication

Unfeasible scenarios

AutomaticTransformations

Scenario Definitions

Testing Patterns

Maturity

Automation

Usability

Transformations

Coverage

Tool Support

Model Evolution

Scalability

Exhaustiveness

Communication

Unfeasible scenarios

AutomaticTransformations

Scenario Definitions

Testing Patterns


«URN »

D. Amyot uOttawa

Towards Test Case Generation

Communication and calls

• Messages, parameters, interfaces, protocols...

Data

• Must endure that the scenario is feasible

Temporal information

• UCM timers currently have no quantitative time

Implementation, sequencing, execution, clean-up

Many other challenges!

There are however some partial results available…

• Use of UCMNav, scenario definitions, and Fitnesse to generate executable test cases for a typical Web application.


«URN »

D. Amyot uOttawa

Test Generation for Web Applications

Config. FileConfig. File

UCMNAVUCMNAV

UCM File (+ scen. defs)

UCM File (+ scen. defs)

XML Files(scenarios) XML Files(scenarios)

TestPagesTest

PagesUCM2FIT FitNesse

User-sel-ected values

User-sel-ected values

FixturesFixtures

Test ResultsTest Results

Web Application(widget.com)

[Amyot, Roy and Weiss, 2005]


«URN »

D. Amyot uOttawa






«URN »

D. Amyot uOttawa

(a) Service in MobSC

(b) Service in MobSC, SDF in SN (c) Service and SDF in SCP

Three Alternative Architectures


«URN »

D. Amyot uOttawa

Two Resulting MSCs

Service in MobSC (option a) Service and SDF in SCP (option c)


«URN »

D. Amyot uOttawa

Security E_Accountant

ReadyContinueCheckBio

TaxPayer

Access

Resource Characteristics• Passive/active, external operations • Disks, processors, …• Operation time• Multiplicity

Rejected

WorkloadCharacteristics• Poisson, periodic…• Population size• Open/closed

Responsibilities• Host demand• External op. demands• Multiplicity

OR Forks andDynamic Stubs• Probability

Components• Allocated responsibilities• Resource assignment

Automated translation to Core Scenario Model (CSM) for analytical evaluations and simulations.

Quantitative Performance Engineering with UCMs


«URN »

D. Amyot uOttawa

Resource Management


«URN »

D. Amyot uOttawa

Demand and Workload Management


«URN »

D. Amyot uOttawa

From UCM to Core Scenario Model (CSM)

• Export CSM (XML) from URN model • Translation of CSM file to LQN, QN, stochastic Petri Nets…


«URN »

D. Amyot uOttawa

Typical Performance Analysis Results…

• Ex: Via conversion to Layered Queueing Networks

• General statistics: elapsed time, system time…

• Measured quantities: service demands, number of blocking and non-blocking calls, call delays, synchronization delays.

• Service times: for every entry and activity, with confidence intervals and variances (where relevant)

• Throughputs and utilizations for every entry and activity, with confidence intervals

• Utilizations and waiting times for devices (by entry)


«URN »

D. Amyot uOttawa






«URN »

D. Amyot uOttawa

BPM and the W5 Questions

UCM models describe:• what the activities related to a business goal are (responsibilities

and scenarios)

• who is involved in these activities (actors and components)

• where they are performed (allocation to components)

• when they should be performed (via common workflow constructs for expressing sequence, choice, concurrency, synchronization).

GRL models describe:• why activities, participants and processes are structured the way

they are (goal graphs and URN links)


«URN »

D. Amyot uOttawa

Agent: actor

Team: role theactor plays

Simple Supply Chain Management BPM


«URN »

D. Amyot uOttawa

Alternative Process Architectures (1/2)

Warehouse

InventoryManagement

Warehouse

InventoryManagement:W

Retailer

OrderProcessing

Retailer

OrderProcessing:R

Manufacturer

ProductionWarehouse:M

Manufacturer

Production:MWarehouse:M

ConsumerConsumer

a) CURRENT: Sell to stock via warehouse and retailer (R)

b) Sell to stock via warehouse (W)

ConsumerConsumer Warehouse


Warehouse


Manufacturer

OrderProcessing:W

Production:M

Warehouse:MWarehouse:M


«URN »

D. Amyot uOttawa

Alternative Process Architectures (2/2)

Consumer

InventoryManagement:MWarehouse:M

OrderProcessing:M

Production:M

Manufacturer

InventoryManagement:MWarehouse:M

OrderProcessing:M

Production:M

d) Sell direct to consumer with internal warehouse (M)

ConsumerConsumer Warehouse


Warehouse


Manufacturer

OrderProcessing:M

Production:M

c) Sell direct to consumer with external warehouse (MW)

Warehouse:M


«URN »

D. Amyot uOttawa

When to Evolve our Process Architecture?

LowRisk


«URN »

D. Amyot uOttawa

UCM Maps for Business Process (M)


«URN »

D. Amyot uOttawa

Business Process Analysis and Monitoring

• How can we model and monitor business processes and determine how well they meet their business goals and performance requirements?

• Can monitoring information be used to better align business processes and goals?

Business Processes

Business Goals

UCM

GRL

KPI Model ?

Key Performance Indicator (KPI) Model


«URN »

D. Amyot uOttawa

BP Analysis and Monitoring(e.g. with KPI, using Cognos 8)


«URN »

D. Amyot uOttawa

GRL with KPI Extensions for BAM


«URN »

D. Amyot uOttawa

KPI: Fed from Outside & Impact on GRL


«URN »

D. Amyot uOttawa

URN Model Export to DOORS (DXL Library)Enables- Requirements management- Traceability to/from other external requirements or models- Impact analysis, etc.


«URN »

D. Amyot uOttawa

• Internal GRL and UCM links created automatically• Manual links between UCM model and higher/lower level

requirements• Link auto-completion uses some manual links and internal

links to infer and generate other links automatically

Autolinking URN Models

UserLevel

References

References

Traced By

Refines

UCMs(Resp.)

UCMs(Comp.)

UCMs(Scenarios)

Scenario.Resp

UserRequirements

(Use Cases)

SystemRequirements

UCMs (Maps)

Bou

nd

To

Bound To

Ref

ines

Map

* Map.Stub

* Map.Resp

* Map.Comp

manual & generated links

generated links

manual links


«URN »

D. Amyot uOttawa

From Traceability to Compliance: 3 Wishes

Framework that can model organizational policies, procedures and legislative documents in the same notation

Support for useful links:

• within views of a model (goals and processes)

• between two models (organization and legislation)

• between models and legislation and other documents

A way to manage the evolution of any part (legislation, business processes, etc.) in order to assess the global impact and ensure compliance in the new context


«URN »

D. Amyot uOttawa

Compliance Management Framework

• Provides a set of links to connect the policy and procedure documents of an organization to legislation documents

• Other links/models provide little return on investment

GRL- Softgoals, Goals, Tasks and Actors

UCM- Business Processes

Law and Legislation Documents

Policies and Procedure Documents

GRL- Softgoals, Goals, Tasks and Actors

1- Traceability Link2- C

ompliance Link

3- Responsibility

Link

Legislation Model

Sou

rce

Link Source Link Source Link

Responsibility Link

Organization Model


«URN »

D. Amyot uOttawa

Framework Metamodel (DOORS View)Organization Metamodel

Law Metamodel

Organization Model

IntentionalElement

IntentionalElementRef

GRLdiagram

Responsibility

Actor

ActorRef RespRef

Component

ComponentRef

UCMmap

Stub

ref

refines

resp

ref ref ref

boundToboundTo

refinesrefines

resp

resp

1..* 1..*

0..* 0..*

0..*0..*

0..* 0..*

Association

0..*

0..*

0..*

0..*

0..*

0..*

refines

refines

0..*

0..*

PoliciyProcedureDocument1..*

sou

rce

0..1

0..10..*0..*

Legislation Model

IntentionalElement

IntentionalElementRef

GRLdiagram

Actor

ActorRef

ref ref

boundTo

refines

1..*

0..*

0..*

Association

refines

refines

0..*

0..*

Clause Definition

LawDocument

1..*

0..*

1..* 1..*

source

0..*

source0..*

0..1

traces

complies resp

Link legendManual-jUCMNavManual-DOORSAutomated-jUCMNavManual andautomated-DOORS


«URN »

D. Amyot uOttawa

Case Study – PHIPA Compliance at Ontario Hospital

GRL Model of PHIPA

Satisfy PrivacyRegulations

ProtectConfidentiality

Prevent Unautho-rized Disclosure

Ask for ComplianceAgreement

Check Research

Plan

Check Adequate

Safeguards

Check Ethical Issues

HIC

And

And

Ask for REB

Approval

REB Committee

Limit Disclosureof Data









Check Research

Plan

Check Research

Plan

Check Adequate

Safeguards

Check Adequate

Safeguards



HIC

And

And

Ask for REB

Approval

Ask for REB

Approval

REB Committee



GRL Model of Hospital

Protect Privacy andConfidentiality of

Hospital Data

Protect Privacy andConfidentiality of

Hospital Data

PreventUnauthorized Use

and Disclosure

PreventUnauthorized Use

and Disclosure

EnsureAccountabilityof Data User

EnsureAccountabilityof Data User



Get to An Agreement

with Data User

Get to An Agreement

with Data User

Check Request

Form

Check Request

Form

Check with Privacy and Confidentiality

Legislations

Check with Privacy and Confidentiality

Legislations

Check Users

Safeguards

Check Users

Safeguards

DW Administrator

REB

Privacy Officer

Hospital Document HIC Policy Document

- All requests for data from data warehouse will be evaluated based on technical feasibility, data availability, resource availability and REB approval for research.

-Policy 2…

PHIPA Document

PHIPA Document-HIC: Person or organization who has custody of PHI.- A HIC may disclose PHI to a researcher if he/she,

(a) submits:(i) an application,(ii) a research plan, (iii) a copy of REB approval

(b) enters into the agreement…

sour

ce

sour

ce

sour

ce

resp

resp

traces

complies

UCM Model of Hospital

X

X

X

X V

[GiveUp]

Reject

requestForPHI

Accept getToAnAgreement

reviewRequest

getRejectionamendDocuments

[NewRequest]

Researcher Hospitalresp

resp

Discrepancies could be detected during modelling…


«URN »

D. Amyot uOttawa






«URN »

D. Amyot uOttawa

URN for Pattern Formalization

Many pattern descriptions tend to focus on the solution to a problem, and not so much on how the various (and often conflicting) forces involved are balanced.

Use URN to formalize patterns:

• Enables rigorous trade-off analysis (GRL)

• Maintains the genericity and abstract nature of the solution description (UCM)


«URN »

D. Amyot uOttawa

Modelling Forces and Resolutions


«URN »

D. Amyot uOttawa

Considering Alternative Combinations

[Mussbacher, Amyot and Weiss, 2007]


«URN »

D. Amyot uOttawa

Reverse-Engineering UCM Models from Code

Instrument and execute

OK?

Code

Execution traces

Filter out “utilities”

Abstraction

UCM model generation

Validation

UCM model

[no]

[yes]

• Execution traces can help us understand functionalities and other dynamic aspects in an existing program

• But they are usually huge and impossible to understand

— Sometimes millions of events!

• Need abstraction and visualisation

• UCMs provide and abstract view of scenarios

[A. Hamou-Lhadj et al., 2005]


«URN »

D. Amyot uOttawa

Trace element UCM element Symbol

Package Component (Agent), shown as a rectangle with thick border.

Class Component (Team), shown as a rectangle with narrow border.

Object Component (Object), shown as a rounded-corner rectangle.

Thread Component (Process), shown as a parallelogram.

Beginning / End of trace

Start point (circle) / End point (bar) (also used as connectors for linking sub-scenarios to the parent stub)

Instruction Responsibility (shown as a X on a path)

Block of 3 or more instructions in the same class/object

Stub (diamond) with the name of the first instruction that is not a constructor. This stub contains a plug-in (another sub-map) showing the sub-sequence with one responsibility per instruction.

Repeated instruction Responsibility with repetition count (number between curly brackets) {2}

Repeated sequence Loop (with loop count between curly brackets) {2}

Condition Condition (between square brackets) [cond] {2}

… …IN1 OUT1

… …

… …

Correspondence of UCM Elements (Example)


«URN »

D. Amyot uOttawa

Base

Document

enterNamedMode

Parameter

Parameter

addValue {2x}

{4x}

isNullParmSet {2x}generateOutput

generateConfigurations

Recursive

RecursiveGenerator OrthogonalArray

OrthogonalArray

orthogonalArray

generate

generate

generate

LatinSquares Field

generateConfigurations

adjustValues

[roundNum = 0]

Start

End

Example of Trace Viewed as UCM (TConfig)


«URN »

D. Amyot uOttawa

Background on Aspects: The Problem“Structurally, the units of interest in the requirements domain are fundamentally different from the units of interest in object-oriented software. Requirements units of interest generally are not, and cannot readily be, encapsulated in the software.” [ClBa05]

Requirement Unit1 (R1)



Requirement UnitN (RN)…

ClassA

R1 elements

ClassB

R1 elements

ClassC

R1 elements

ClassG

R1 elements

ClassD

ClassF

R1 elementsR2 elementsR3 elementsRN elements

ClassE

“Scattering: designelements to supportR1 in many placesof the OO design”

“Tangling:single OOdesign unit has elementsfor many requirements units”

Clarke, S. and Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison-Wesley, 2005, www.thethemeapproach.com

Not limitedto only OO


«URN »

D. Amyot uOttawa

ClassA

R1 elements

ClassC

R1 elements

ClassG

R1 elements

ClassF

R1 elementsR2 elementsR3 elementsRN elements

ClassB

R1 elements

R1

Triggered behavior

(code)

Predicate

F.R1

Background on Aspects: The SolutionAspects address the problem of one unit crosscutting other units in the system or model

Terminology based on AspectJ: www.eclipse.org/aspectj

(identifies joinpointswhere advice is executed)

R1 elements

R1 elements

R1 elements

R1 elements

R1 elements

intertypedeclaration(structural)

advice(behavioral)

pointcut

joinpoint

aspect(new unit of

encapsulation)


«URN »

D. Amyot uOttawa

Aspect-oriented URN (AoURN)

• By Ph.D. student Gunter Mussbacher

• URN extended to support aspects-oriented modelling

• Demonstrated that UCM (with their dynamic stubs) can be a more expressive concern composition language for requirements than most AO languages

• Same language (UCM) used for base models, advices, and pointcuts

• URN metamodel additions (very few), composition algorithm, and examples are available

• Extended to support AoGRL

• Metrics defined to measure effectiveness of AoURN


«URN »

D. Amyot uOttawa

AoUCM: Advice and Pointcut Maps• An aspect is a group of UCMs

(some may be advice maps)

• An advice map visually describes the advice of an aspect

• An advice map contains one (zero) or more pointcut stubs (other than that itis a standard UCM)

• A pointcut stub contains one (zero) or more pointcut maps (other than that itis a standard stub)

• A pointcut map visually describes a pointcut expression (other than that itis a standard UCM)

• A pointcut map is matched against the base model in order to identify the joinpoints that are affected by the aspect

*

Pointcut Map

Base Model

StartPoint EndPoint

A

B

EndPoint

R1

R0

Advice Map

start endSuccess[success]

Advice.after_successAdvice.before

Advice.after_fail

endFail

[fail]

C

Pointcut

P


«URN »

D. Amyot uOttawa

Composition of AoUCM with Aspect Stubs

Composition is achieved by inserting aspect stubs at the joinpoints in the base model identified by the mapped pointcut expression

*

Pointcut Map

Base Model

StartPoint EndPoint

A

B

EndPoint

R1

R0

Advice Map

start endSuccess[success]

Advice.after_successAdvice.before

Advice.after_fail

endFail

[fail]

C

Composed System

StartPoint EndPoint

A

B

EndPointR1

R0

endSuccess

Advice.after_success

s2

Advice.after_fail

endFail

s3

Aspect

A

Aspect

AAspect

A

start

Advice.before

e1

C

Pointcut

P


«URN »

D. Amyot uOttawa

Prototype Support for Concerns


«URN »

D. Amyot uOttawa

Towards AoURN

Reporter

AND

Write Story

Win PulitzerPrize

Research Story

+

Web-master

Publish Story

Provide OnlineContent

+

Reporter Goal Graph Webmaster Goal Graph

Goal graphs can become very complex (due to number of concerns)!

Scattering and Tangling – Pollution!

Security ofTerminal [R]

SystemSecurity [W]


«URN »

D. Amyot uOttawa

Example: AoGRL

Reporter

Win PulitzerPrize

+

Web-master


+

Reporter

AND

Write Story

Win PulitzerPrize

Research Story

Web-master

Publish Story


Priority: medium Priority: high

Securityof Terminal

SystemSecurityFingerprint

100 *

Encryption100 *

Cardkey100 *

Encryption100 *

Reporter Goal Graph Webmaster Goal Graph

Security Aspect: Pointcut Graph 1

Security Aspect: Pointcut Graph 2


«URN »

D. Amyot uOttawa

Example: AoGRL

100 *

PasswordCardkey Fingerprint

Cost ofTerminal

Identification

Encryption

Security of Host

Security of Terminal

System Security

AND

OR

+

.+

+.

.+

_

+

Authentication

AccessAuthorization

Security Aspect: Advice Graph


«URN »

D. Amyot uOttawa

SummaryURN

• Allows engineers to specify or discover requirements for proposed and evolving systems, and review such requirements for correctness and completeness.

• Combines goals and scenarios• Helps bridging the gap between informal and formal concepts, and

between requirements models and design models• Big benefits for little modeling investment, even when used

informallyGRL

• For incomplete, tentative, (non-functional) requirements• Capture goals, objectives, alternatives and rationales

UCM• For operational requirements and architectures• Enables analysis and transformations• Architectural alternatives and dynamic systems


«URN »

D. Amyot uOttawa

Outlook

Still many aspects under development

• In jUCMNav — Support for improved workflow semantics for UCM

— Transformations to UML, test cases

— Aspect-oriented Use Case Maps

— Report generation

• URN-based aspect-oriented modeling

• Link definition and exploitation between GRL and UCM

• Formal semantics of URN models (LOTOS, ASM, SDL, …)

• Integration with UML (profiles and tools)

• Improved round-trip requirements and performance engineering

• Many more topics!


«URN »

D. Amyot uOttawa

For More Information

Virtual Library• http://www.UseCaseMaps.org/pub/

Introduction to URN• Weiss, M. and Amyot, D., Business Process Modeling with URN. International Journal of E-Business Research, 1(3),

63–90, July-September 2005.• Amyot, D., Introduction to the User Requirements Notation: Learning by Example. Computer Networks, Volume 42,

Issue 3, pp. 285-301, June 2003.JUCMNav

• Roy, J.-F. Kealey, and Amyot, D. (2006) Towards Integrated Tool Support for the User Requirements Notation. Fifth Workshop on System Analysis and Modelling (SAM’06), Kaiserslautern, Germany, May.

Test• Amyot, D., Roy, J.-F., and Weiss. M., UCM-Driven Testing of Web Applications. 12th SDL Forum (SDL'05),

Grimstad, Norway, June 2005. LNCS 3530, Springer, 247-264.Reverse-engineering

• Hamou-Lhadj, A., Braun, E., Amyot, D., and Lethbridge, T., Recovering Behavioral Design Models from Execution Traces. CSMR’05, Manchester, UK, March 2005. IEEE Computer Society, 112-121.

Scenario generation• Amyot, D., Cho, D.Y., He, X., and He, Y., Generating Scenarios from Use Case Map Specifications. QSIC’03, Dallas,

November 2003. IEEE Computer Society, 108-115.UCMNav/jUCMNav and DOORS

• Jiang, B. Combining Graphical Scenarios with a Requirements Management System. MSc. thesis, uOttawa, June 2005Performance analysis

• Petriu, D.B., Amyot, D., and Woodside, M., Scenario-Based Performance Engineering with UCMNav. 11th SDL Forum (SDL'03), Stuttgart, Germany, July 2003. LNCS 2708, 18-35.

URN and UML• Amyot, D. and Mussbacher, G., On the Extension of UML with Use Case Maps Concepts. <<UML>> 2000. LNCS

1939, 16-31, 2000.


«URN »

D. Amyot uOttawa

Aspect-oriented URN• G. Mussbacher, D. Amyot, and M. Weiss (2007) Visualizing Early Aspects with Use Case Maps, LNCS Journal on

Transactions on Aspect-Oriented Software Development, to appear• Mussbacher, G., Amyot, D., Whittle, J., and Weiss, M. (2007) Flexible and Expressive Composition Rules with

Aspect-oriented Use Case Maps (AoUCM). 10th International Workshop On Early Aspects, Vancouver, Canada, March.

• G. Mussbacher, D. Amyot, and M. Weiss (2007) Aspect-Oriented User Requirements Notation (AoURN): Modeling Goals and Scenarios of Crosscutting Concerns in a Unified Way. MoDELS (submitted)

URN, Compliance and DOORS• Ghanavati, S., Amyot, D., and Peyton, L. (2007) Towards a Framework for Tracking Legal Compliance in Healthcare.

19th Int. Conf. on Advanced Information Systems Engineering (CAiSE'07), Trondheim, Norway, June. • Ghanavati, S., Amyot, D., and Peyton, L. (2007) A Requirements Management Framework for Privacy Compliance.

10th Workshop on Requirements Engineering (WER’07), Toronto, Canada, May. • Peyton, L., Ghanavati, S., and Amyot, D. (2007) Designing for Privacy Compliance and Performance Management in

Health Care. Design Journal (submitted)URN, Patterns, and Business Process Modelling

• Mussbacher, G. (2007) Evolving Use Case Maps as a Scenario and Workflow Description Language, 10th Workshop on Requirements Engineering (WER’07), Toronto, Canada, May.

• Pourshahid, A., Chen, P., Amyot, D., Forster, A.J., and Weiss, M. (2007) Business Process Monitoring and Alignment: An Approach Based on the User Requirements Notation and Business Intelligence Tool. 10th Workshop on Requirements Engineering (WER’07), Toronto, Canada, May.

• Roy, J-F (2007) Requirement Engineering with URN: Integrating Goals and Scenarios, M.Sc. thesis, uOttawa, March• Weiss, M. and Amyot, D. (2006) Chapter VIII: Business Process Modeling with the User Requirements Notation. I.

Lee (Ed.), Advances in E-Business Research: E-Business Innovation and Process Management, Vol. 1, IGI Global, December, 162-193.

• Mussbacher, G., Amyot, D., and Weiss, M. (2007) Formalizing Patterns with the User Requirements Notation. T. Taibi (Ed.), Design Pattern Formalization Techniques, IGI Global, March, 304-325.

• Weiss, M. and Amyot, D., Business Model Design and Evolution. Management of Technology, World Scientific (submitted)


«URN »

D. Amyot uOttawa

Satisficed

Weakly Satisficed

Undecided

Weakly Denied

Denied

Conflict

(b) GRL Satisfaction Levels

Dependency

Contribution

Correlation

Means-end

Decomposition

(d) GRL Links

?Break Hurt Some- Unknown

Make Help Some+ Equal

(e) GRL Contributions Types

OR

AND

(c) Link Composition

Goal

Softgoal

Belief

Actor

ActorBoundary

Resource

(a) GRL Elements

Task


«URN »

D. Amyot uOttawa

…

…

…

…[C1]

[C2]

[C3]

OR-Fork& GuardingConditions

…

…

…

…OR-Join

……

…… …

…

……

AND-JoinAND-Fork

(b) UCM Forks and Joins

StartPoint

EndPoint

Path

… …… … Responsibility

Direction Arrow

… … Timestamp Point

Failure Point… …

Shared Responsibility… …(a) UCM Path Elements

(c) UCM (Generic) Component

Waiting Place

Trigger

Path

(asynchronous)

Waiting

Path

Continuation

Path

Timer

Timer

Release

(synchronous)

Waiting

Path

Continuation

Path

Timeout

Path

(e) UCM Waiting Places and Timers

… …IN1 OUT1 Static Stub & Segments ID

Dynamic StubIN1 OUT1… …

S{IN1} E{OUT1}

(d) UCM Stubs and Plug-ins

Plug-in Map