User%20Requirements%20Notation%20(URN)%20%20Application%20and%20Research%20Areas

1
User Requirements Notation (URN) Application
and Research Areas
Daniel Amyot SITE, University of
Ottawa damyot_at_site.uottawa.ca UofT, August 23,
2007
2
Modeling Puzzle Common View
Data
Can we do better to bridge this gap?
3
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

4
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

5
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

6
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

7
Basic GRL Notation
8
Basic GRL Notation

• Goal
• Quantifiable (often functional)
• Softgoal
• Qualifiable but not measurable (often
  non-functional)
• Task
• Solution which achieves goals (means-end) or
  satisfice softgoals (contribution, correlation)
• Belief
• Captures rationale
• And/Or Link
• Contribution correlation links may be typed AND
  or OR

9
Basic GRL Notation

• Contribution
• Link for tasks, softgoals, beliefs, and links
• May be qualified (see symbols ?)
• Some hesitate between Make (sufficient) and
  Help (insufficient)
• Some- hesitate between Break (sufficient) and
  Hurt (insufficient)
• Correlation
• Same as contribution but indicates side-effect
• Means-End
• Link for tasks achieving goals (always OR)
• Decomposition
• Defines what is needed for a task to be performed
  (refinement, always AND)

10
Advanced GRL Notation

• GRL graphs can be allocated to actors
• Dependencies can be defined between actors,
  together with intermediate resources.

11
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

12
GRL Abstract Metamodel (I)
13
GRL Abstract Metamodel (II)
Links
Strategies
14
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

15
Pool
UCM Example
StartPoint
Stub
AND-Fork
Slot
End Point
Responsibility
Component
a) Root UCM
Bindings for Authorize atNight ? Biometrics
(IN1,Bio), (OUT1,Yes), (OUT2,No) !atNight ?
PassWord (IN1,PW), (OUT1,Yes), (OUT2,No)
OR-Foin
16
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

17
URN (Typed) Links

• 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

18
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

19
Evaluations with GRL (strategy 1)
AND
.
.
AND
OR
20
Evaluations with GRL

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

21
Evaluations with GRL (strategy 2)
AND
.
.
AND
OR
22
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

23
Strategies in jUCMNav
A star () indicates an initial value part of a
given strategy. All the others are evaluated
through a propagation algorithm.
24
Numerical Evaluation in jUCMNav

• Evaluation between -100 and 100.
• E -100 ? Denied
• -100 lt E lt 0 ? Weakly Denied
• E 0 ? Undecided
• 0 lt E lt 100 ? Weakly Satisficed
• 100 ? Satisficed

25
Numerical Evaluation Decompositions

• Minimum for AND, maximum for OR

Or Decomposition
And Decomposition
26
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.

27
Numerical Evaluation Dependencies

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

28
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

29
Numerical Evaluation Actor Evaluation
Priority Low Criticality None
Priority None Criticality High
30
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

31
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

32
Modeling Puzzle URN
Data
UCMs link to operationalizationsand actors in
GRL models
UCMs represent visually use cases in terms of
causal responsibilities
UCMs visually associate behavior and structure at
the system level
UCMs provide a framework for making high level
and detailed design decisions
33
Key Points - URN Puzzle

• Goal-based (e.g. GRL) and scenario-based (e.g.
  UCMs) notations complement each other
• URN fills a void in UML and ITU-T languages
• UCMs offer more capabilities than UML 1.X use
  case diagrams and activity diagrams
• URN fits well into scenario-based software
  development methodologies
• GRL provides the decision making framework for
  software engineering activities
• URN supports early activities in software
  development, bringing together stakeholders with
  expertise in many different areas
• UCMs provide a good basis for design-time feature
  interaction detection and for model construction
• UCMs and GRL can be used iteratively and
  independently

34
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

35
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

36

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

37
jUCMNav Scenario Export

• Groups of scenarios can be run together
• Scenarios 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

38

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

39
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

40
Comparison
41
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.

42
Test Generation for Web Applications
Amyot, Roy and Weiss, 2005
43
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

44
Example GRL Model (Wireless Service)
45
Three Alternative Architectures
46
Two Resulting MSCs
Service in MobSC (option a)
Service and SDF in SCP (option c)
47
Quantitative Performance Engineering with UCMs

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

• Workload
• Characteristics
• Poisson, periodic
• Population size
• Open/closed

Security
E_Accountant
TaxPayer
CheckBio
Continue
Ready
Access
Rejected

• Components
• Allocated responsibilities
• Resource assignment

• Responsibilities
• Host demand
• External op. demands
• Multiplicity

• OR Forks andDynamic Stubs
• Probability

Automated translation to Core Scenario Model
(CSM) for analytical evaluations and simulations.
48
Resource Management
49
Demand and Workload Management
50
From UCM to Core Scenario Model (CSM)

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

51
LQN Generation from UCMs

• Layered Queueing Networks
• Capture the workload within activities
  (operations connected in sequence or in parallel)
  which belong to an entry of a task (e.g. method
  of an operating system process) running on a host
  device (usually a processor).
• http//www.layeredqueues.org/
• Solving LQN models
• Analytic solver (LQNS) or simulator (LQSim)
• Both developed at Carleton University
• Solver is faster but more limited than simulator
• Useful for various types of analyses
• Sensitivity (importance or impact of parameters)
• Scalability (what if more users/requests?)
• Concurrency (what if more/fewer threads?)
• Deployment and configuration (different HW
  allocation)
• Quantitative architecture evaluations!

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

53
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

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

55
Simple Supply Chain Management BPM
Agent actor
Team role theactor plays
56
Alternative Process Architectures (1/2)
b) Sell to stock via warehouse (W)
57
Alternative Process Architectures (2/2)
Consumer
Manufacturer
OrderProcessingM
OrderProcessingM
InventoryManagementM
InventoryManagementM
WarehouseM
WarehouseM
ProductionM
ProductionM
d) Sell direct to consumer with internal
warehouse (M)
58
When to Evolve our Process Architecture?
59
UCM Maps for Business Process (M)
60
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?

Key Performance Indicator (KPI) Model
?
61
BP Analysis and Monitoring(e.g. with KPI, using
Cognos 8)
62
GRL with KPI Extensions for BAM
63
KPI Fed from Outside Impact on GRL
64
URN Model Export to DOORS (DXL Library)

• Enables
• Requirements management
• Traceability to/from other external
  requirements or models
• Impact analysis, etc.

65
Autolinking URN Models

• 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

66
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

67
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

68
Framework Metamodel (DOORS View)
Organization Metamodel
Law Metamodel
69
Case Study PHIPA Compliance at Ontario Hospital
Discrepancies could be detected during modelling
70
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

71
Integrating UCEd and jUCMNav
72
Integrating UCEd and jUCMNav

• Title PaperSubmission1. Author writes a
  paper2. Conference receives submission3.
  INCLUDE PaperReview4. Conference
  ProgramCommittee informs
• author of outcome5. Author forwards response
  to supervisorExtensionPointgt response
  receptionTitle PaperReview1. Conference
  Reviewer receives paper2. Conference Reviewer
  reviews the paper3. Conference Reviewer sends in
  evaluation1. a. Conference Reviewer is too
  busy1. a. 1. Conference Reviewer delegates
  work1. a. 2. Conference Reviewer confirms
  review1. a. 3. GOTO 3
• Title PaperReceptionPART 1. At Extension Point
  response
• reception1. Author updates
  publication list

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

74
Modelling Forces and Resolutions
75
Considering Alternative Combinations
Mussbacher, Amyot and Weiss, 2007
76
Reverse-Engineering UCM Models from Code
Code

• 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

Instrument and execute
Execution traces
Filter out utilities
Abstraction
UCM model generation
UCM model
Validation
OK?
no
yes
77
Correspondence of UCM Elements (Example)
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
78
Example of Trace Viewed as UCM (TConfig)
79
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

Not limitedto only OO
Scattering designelements to supportR1 in
many placesof the OO design
Tanglingsingle 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
80
Background on Aspects The Solution

• Aspects address the problem of one unit
  crosscutting other units in the system or model

aspect
(new unit of encapsulation)
R1 elements
F.R1
intertypedeclaration(structural)
R1 elements
Triggered behavior (code)
advice(behavioral)
R1 elements
Predicate
pointcut
R1 elements
(identifies joinpointswhere advice is executed)
R1 elements
Terminology based on AspectJ www.eclipse.org/aspe
ctj
81
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

82
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

83
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

84
Prototype Support for Concerns
85
Towards AoURN
Goal graphs can become very complex (due to
number of concerns)!
Reporter Goal Graph
Webmaster Goal Graph
Reporter
Web-master


AND
Scattering and Tangling Pollution!
86
Example AoGRL
Webmaster Goal Graph
Reporter Goal Graph
Reporter
Web-master
AND
Security Aspect Pointcut Graph 2
Security Aspect Pointcut Graph 1
Web-master
Reporter


Priority high
Priority medium
87
Example AoGRL
Security Aspect Advice Graph

.
Security of Host
Security of Terminal
Cost ofTerminal
.
_
.
AccessAuthorization

Encryption
Authentication
AND
?100
OR
Identification
88
Summary

• URN
• 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 informally
• GRL
• 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

89
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!

90
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), 6390, 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 (SAM06), 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. CSMR05,
  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. QSIC03, 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 2005
• Performance 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. ltltUMLgtgt 2000.
  LNCS 1939, 16-31, 2000.

91

• 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 (WER07), 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 (WER07),
  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 (WER07), 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)

92
(No Transcript)
93
(No Transcript)