User%20Requirements%20Notation%20(URN)%20%20Application%20and%20Research%20Areas - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

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

Description:

URN: Application and Research Areas. 2 'URN ' D. Amyot. uOttawa ... Application and Research Areas. Transformations to Message Sequence Charts and test goals ... – PowerPoint PPT presentation

Number of Views:99
Avg rating:3.0/5.0
Slides: 85
Provided by: daniel103
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
Start Point
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 operationalizations and 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 and Dynamic 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 the actor 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 PaperSubmission 1. Author writes a
    paper 2. Conference receives submission 3.
    INCLUDE PaperReview 4. Conference
    ProgramCommittee informs
  • author of outcome 5. Author forwards response
    to supervisor ExtensionPointgt response
    reception Title PaperReview 1. Conference
    Reviewer receives paper 2. Conference Reviewer
    reviews the paper 3. Conference Reviewer sends in
    evaluation 1. a. Conference Reviewer is too
    busy 1. a. 1. Conference Reviewer delegates
    work 1. a. 2. Conference Reviewer confirms
    review 1. a. 3. GOTO 3
  • Title PaperReception PART 1. At Extension Point
    response
  • reception 1. 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 limited to only OO
Scattering design elements to support R1 in
many places of the OO design
Tangling single OO design unit has
elements for 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
intertype declaration (structural)
R1 elements
Triggered behavior (code)
advice (behavioral)
R1 elements
Predicate
pointcut
R1 elements
(identifies joinpoints where 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 it is a standard
    UCM)
  • A pointcut stub contains one (zero) or more
    pointcut maps (other than that it is a standard
    stub)
  • A pointcut map visually describes a pointcut
    expression (other than that it is 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 of Terminal
.
_
.
Access Authorization

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)
About PowerShow.com