User Requirements Notation (URN) Application and Research Areas

User Requirements Notation (URN) Application and Research Areas Daniel Amyot SITE, University of Ottawa [email protected] «URN » UofT, August 23, 2007 D. Am yot uOtta wa URN: Application and Research Areas 1

Modeling Puzzle – Common View Structural Diagrams SDL, eODL, or UML class, object, component, & deployment diagrams «URN » Data Informal Requirements, Textual Use Cases MSC, UML Use Case Diagram & Activity Diagram Behavioral Diagrams MSC/SDL, or UML sequence, collabor., & statechart diagrams Can we do better to bridge this gap? Testing and Performance Languages TTCN, LQN, . D. Am yot uOtta wa URN: Application and Research Areas 2

Overview of the Presentation «URN » D. Am 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 yot uOtta wa URN: Application and Research Areas 3

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. Am yot uOtta wa URN: Application and Research Areas 4

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/ «URN » Use Case Maps (UCM) — for operational requirements and architectures — http://www.UseCaseMaps.org/ — http://www.UseCaseMaps.org/pub D. Am yot uOtta wa URN: Application and Research Areas 5

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. Am yot uOtta wa URN: Application and Research Areas 6

Basic GRL Notation Softgoal ? System Security Break Hurt Some- Unknown AND Decomposition Make Help Some Equal . Access Authorization Cost of Terminal Security of Terminal . Make Contribution Encryption Task AND Correlation (side-effect) Security of Host Authentication Identification Goal OR Belief Cardkey «URN » D. Am yot uOtta wa Password Biometrics Biometrics is no regular off-the-shelf technology URN: Application and Research Areas 7

Advanced GRL Notation GRL graphs can be allocated to actors Dependencies can be defined between actors, together with intermediate resources. Actor Resource Dependency Payment Electronic Accountant TaxPayer Forward Tax Forms System Security . Security of Terminal Access Authorization Cost of Terminal Authentication . Biometrics is no regular off-the-shelf technology Security of Host . Encryption Identification Keep Password Secret Cardkey Password Biometrics Actor Boundary «URN » D. Am yot uOtta wa URN: Application and Research Areas 10

Why GRL? «URN » 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 D. Am yot uOtta wa URN: Application and Research Areas 11

UCMs in a Nutshell «URN » 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 D. Am yot uOtta wa URN: Application and Research Areas 14

UCM Example Pool Start Point Stub AND-Fork Slot End Point Responsibility Component a) Root UCM c) PassWord Plug-in b) Biometrics Plug-In Timer «URN » D. Am yot uOtta w Bindings for Authorize: [atNight] Biometrics {(IN1,Bio), (OUT1,Yes), (OUT2,No)} [!atNight] PassWord {(IN1,PW), (OUT1,Yes), (OUT2,No)} OR-Fork OR-Foin a URN: Application and Research Areas 15

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 «URN » D. Am yot uOtta wa 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: Application and Research Areas 16

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 Actor Intentiona l Element Map Component Responsibility «URN » D. Am yot uOtta wa URN: Application and Research Areas 17

Overview of the Presentation «URN » D. Am 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 yot uOtta wa URN: Application and Research Areas 18

Evaluations with GRL (strategy 1) Satisficed System Security Weakly Satisficed AND Undecided Weakly Denied . Denied Security of Terminal Security of Host . Access Authorization Cost of Terminal Encryption AND Authentication Identification OR «URN » D. Am yot uOtta wa Cardkey Password Biometrics Biometrics is no regular off-the-shelf technology URN: Application and Research Areas 19

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 «URN » D. Am yot uOtta wa 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) URN: Application and Research Areas 20

Evaluations with GRL (strategy 2) Satisficed System Security Weakly Satisficed AND Undecided Weakly Denied . Denied Security of Terminal Security of Host . Access Authorization Cost of Terminal Encryption AND Authentication Identification OR «URN » D. Am yot uOtta wa Cardkey Password Biometrics Biometrics is no regular off-the-shelf technology URN: Application and Research Areas 21

GRL Strategies «URN » 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 D. Am yot uOtta wa URN: Application and Research Areas 22

Strategies in jUCMNav «URN » A star (*) indicates an initial value part of a given strategy. All the others are evaluated through a propagation algorithm. D. Am yot uOtta wa URN: Application and Research Areas 23

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. Am yot uOtta wa URN: Application and Research Areas 24

Numerical Evaluation: Decompositions Minimum for AND, maximum for OR «URN » And Decomposition Or Decomposition D. Am yot uOtta wa URN: Application and Research Areas 25

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 «URN » D. Am yot uOtta w Contributions are additive, but are normalized. a URN: Application and Research Areas 26

Numerical Evaluation: Dependencies Intentional element evaluation is set to the minimal value in the set of dependees evaluation or it current evaluation «URN » D. Am yot uOtta wa URN: Application and Research Areas 27

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. Am yot uOtta wa URN: Application and Research Areas 28

Numerical Evaluation: Actor Evaluation «URN » D. Am yot uOtta wa Priority Low Criticality None Priority None Criticality High URN: Application and Research Areas 29

UCM Scenario Definitions and Path Traversal (Highlight) «URN » D. Am yot uOtta wa 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: Application and Research Areas 30

GRL - UCM Relationship «URN » D. Am yot uOtta wa 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: Application and Research Areas 31

Modeling Puzzle — URN Structural Diagrams SDL, eODL, or UML class, object, component, & deployment diagrams «URN » UCMs visually associate behavior and structure at the system level Data Informal Requirements, Textual Use Cases URN-GRL ? ? Goals, non-functional requirements, alternatives, rationales UCMs link to operationalizations and actors in GRL models URN-UCM MSC, UML Use Superimpose Case Diagram visually & system level behavior Activity Diagram onto structures of abstract components. Can replace UML use case / deployment diagrams. UCMs represent visually use cases in terms of causal responsibilities Behavioral Diagrams MSC/SDL, or UML sequence, collabor., & statechart diagrams UCMs provide a framework for making high level and detailed design decisions Testing and Performance Languages TTCN, LQN, . D. Am yot uOtta wa URN: Application and Research Areas 32

Overview of the Presentation «URN » D. Am 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 yot uOtta wa URN: Application and Research Areas 34

Several Known URN Application Domains «URN » 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 D. Am yot uOtta wa URN: Application and Research Areas 35

«URN » D. Am yot uOtta wa jUCMNav supports -Scenario definition (with data types, pre/post conditions, start/end points, and scenario inclusion) -Problems View -Scenario highlight URN: Application and Research Areas 36

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 «URN » D. Am yot uOtta wa URN: Application and Research Areas 37

jUCMNav supports -MSC viewer -Reordering of instances -MSC export to images «URN » D. Am yot uOtta wa URN: Application and Research Areas 38

UCM-Based Testing «URN » D. Am yot uOtta wa 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: Application and Research Areas 39

Comparison Testing Patterns Scenario Definitions Automatic Transformations Automation Unfeasible scenarios Communication Exhaustiveness Coverage Scalability Model Evolution Usability Transformations «URN » D. Am yot uOtta w Maturity Tool Support a URN: Application and Research Areas 40

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! «URN » There are however some partial results available Use of UCMNav, scenario definitions, and Fitnesse to generate executable test cases for a typical Web application. D. Am yot uOtta wa URN: Application and Research Areas 41

Test Generation for Web Applications Config. File XML Files (scenarios) UCM2FIT Fixtures Test Pages FitNesse UCM File ( scen. defs) UCMNAV «URN » User-selected values Web Application (widget.com) Test Results [Amyot, Roy and Weiss, 2005] D. Am yot uOtta wa URN: Application and Research Areas 42

Overview of the Presentation «URN » D. Am 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 yot uOtta wa URN: Application and Research Areas 43

Three Alternative Architectures (a) Service in MobSC «URN » D. Am yot (b) Service in MobSC, SDF in SN uOtta w (c) Service and SDF in SCP a URN: Application and Research Areas 45

Two Resulting MSCs Service in MobSC (option a) «URN » Service and SDF in SCP (option c) D. Am yot uOtta wa URN: Application and Research Areas 46

Quantitative Performance Engineering with UCMs Workload Characteristics Poisson, periodic Population size Open/closed Resource Characteristics Passive/active, external operations Disks, processors, Operation time Multiplicity TaxPayer Access Security CheckBio Continue E Accountant Ready Rejected Components Allocated responsibilities Resource assignment «URN » D. Am yot uOtta wa OR Forks and Dynamic Stubs Probability Responsibilities Host demand External op. demands Multiplicity Automated translation to Core Scenario Model (CSM) for analytical evaluations and simulations. URN: Application and Research Areas 47

Resource Management «URN » D. Am yot uOtta wa URN: Application and Research Areas 48

Demand and Workload Management «URN » D. Am yot uOtta wa URN: Application and Research Areas 49

From UCM to Core Scenario Model (CSM) «URN » Export CSM (XML) from URN model uOtta w a Translation of CSM file to LQN, QN, stochastic Petri Nets D. Am yot URN: Application and Research Areas 50

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. Am yot uOtta wa URN: Application and Research Areas 52

Overview of the Presentation «URN » D. Am 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 yot uOtta wa URN: Application and Research Areas 53

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. Am yot uOtta wa URN: Application and Research Areas 54

Simple Supply Chain Management BPM Agent: actor Team: role the actor plays «URN » D. Am yot uOtta wa URN: Application and Research Areas 55

Alternative Process Architectures (1/2) Consumer Retailer Warehouse OrderProcessing OrderProcessing:R Manufacturer InventoryManagement:W InventoryManagement Production:M Production Warehouse:M a) CURRENT: Sell to stock via warehouse and retailer (R) Consumer Warehouse Manufacturer InventoryManagement:W Production:M Warehouse:M OrderProcessing:W «URN » D. Am b) Sell to stock via warehouse (W) yot uOtta wa URN: Application and Research Areas 56

Alternative Process Architectures (2/2) Consumer Manufacturer Warehouse OrderProcessing:M InventoryManagement:W Production:M Warehouse:M c) Sell direct to consumer with external warehouse (MW) Consumer Manufacturer OrderProcessing:M OrderProcessing:M InventoryManagement:M InventoryManagement:M Warehouse:M Production:M Production:M «URN » D. Am yot uOtta wa d) Sell direct to consumer with internal warehouse (M) URN: Application and Research Areas 57

When to Evolve our Process Architecture? Low Risk «URN » D. Am yot uOtta wa URN: Application and Research Areas 58

UCM Maps for Business Process (M) «URN » D. Am yot uOtta wa URN: Application and Research Areas 59

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 Goals GRL ? KPI Model «URN » UCM Key Performance Indicator (KPI) Model Business Processes D. Am yot uOtta wa URN: Application and Research Areas 60

BP Analysis and Monitoring (e.g. with KPI, using Cognos 8) «URN » D. Am yot uOtta wa URN: Application and Research Areas 61

GRL with KPI Extensions for BAM «URN » D. Am yot uOtta wa URN: Application and Research Areas 62

KPI: Fed from Outside & Impact on GRL «URN » D. Am yot uOtta wa URN: Application and Research Areas 63

URN Model Export to DOORS (DXL Library) Enables - Requirements management - Traceability to/from other external requirements or models - Impact analysis, etc. «URN » D. Am yot uOtta wa URN: Application and Research Areas 64

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 Map * Map.Stub * Map.Resp Bound To User Requirements (Use Cases) Refines manual links UCMs (Resp.) D. Am yot uOtta wa generated links Refines UCMs (Scenarios) References Bound To Traced By Scenario. Resp * Map.Comp References «URN » manual & generated links UCMs (Maps) UCMs (Comp.) System Requirements User Level URN: Application and Research Areas 65

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 «URN » D. Am 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 yot uOtta wa URN: Application and Research Areas 66

Compliance Management Framework Source Link 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 Organization Model Legislation Model Policies and Procedure Documents Law and Legislation Documents Source Link GRL- Softgoals, Goals, Tasks and Actors Responsibility Link «URN » D. Am yot uOtta wa UCM- Business Processes c an i l mp o -C in eL k 2 1- Traceability Link i nk L ility b i s on p es R 3- Source Link GRL- Softgoals, Goals, Tasks and Actors URN: Application and Research Areas 67

Framework Metamodel (DOORS View) 1.* 1.* GRLdiagram resp 0.* 0.* 0.1 boundTo 0.* ref refines 0.* Intentional 0.* ElementRef refines 0.* Association Actor refines 0.* refines UCMmap refines ActorRef PoliciyProcedureDocument source 1.* Organization Model 0.* 0.* RespRef 0.* 0.* ref boundTo 0.1 ref Intentional 0.* Element Stub 0.* ref Responsibility 0.* resp 0.* ComponentRef Organization Metamodel Component 0.* resp traces resp Law Metamodel 0.* 0.* Actor ref 0.* ActorRef source refines Intentional source Element 0.* Association 0.* refines 0.* 0.1 boundTo complies ref 1.* Definition 1.* Intentional ElementRef Link legend 0.* refines GRLdiagram LawDocument 1.* «URN » Clause 1.* Legislation Model Manual-jUCMNav Manual-DOORS Automated-jUCMNav Manual and automated-DOORS D. Am yot uOtta wa URN: Application and Research Areas 68

Case Study – PHIPA Compliance at Ontario Hospital - 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 Protect Privacy and Confidentiality of Hospital Data Ensure Accountability of Data User Check Request Form Get to An Agreement with Data User Privacy Officer resp Check Users Safeguards requestForPHI Accept uOtta w a X Reject yot reviewRequest getToAnAgreement X amendDocuments [NewRequest] X [GiveUp] sp Hospital re getRejection X GRL Model of PHIPA Limit Disclosure of Data And HIC Ask for Compliance Agreement p res Researcher D. Am tra ce s PHIPA Document Protect Confidentiality Prevent Unauthorized Disclosure Ask for REB Approval Check Research Plan And re sp Check Ethical Issues Check with Privacy and Confidentiality Legislations «URN » Satisfy Privacy Regulations DW Administrator Prevent Unauthorized Use REB and Disclosure UCM Model of Hospital complies source source GRL Model of Hospital 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 HIC Policy Document source Hospital Document REB Committee Check Adequate Safeguards Check Ethical Issues V Discrepancies could be detected during modelling URN: Application and Research Areas 69

Overview of the Presentation «URN » D. Am 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 yot uOtta wa URN: Application and Research Areas 70

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. Am yot uOtta wa URN: Application and Research Areas 73

Modelling Forces and Resolutions «URN » D. Am yot uOtta wa URN: Application and Research Areas 74

Considering Alternative Combinations «URN » D. Am yot uOtta wa [Mussbacher, Amyot and Weiss, 2007] URN: Application and Research Areas 75

Reverse-Engineering UCM Models from Code Code Instrument and execute Execution traces But they are usually huge and impossible to understand Filter out “utilities” — Sometimes millions of events! Abstraction UCM model generation UCM model D. Am yot uOtta wa OK? Need abstraction and visualisation UCMs provide and abstract view of scenarios Validation «URN » Execution traces can help us understand functionalities and other dynamic aspects in an existing program [no] [A. Hamou-Lhadj et al., 2005] [yes] URN: Application and Research Areas 76

Correspondence of UCM Elements (Example) Trace element UCM element 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) Repeated sequence Loop (with loop count between curly brackets) Symbol IN1 {2} OUT1 {2} «URN » DCondition . Am y ot uOtta wa Condition (between square brackets) [cond] {2} URN: Application and Research Areas 77

Example of Trace Viewed as UCM (TConfig) Base Document Parameter enterNamedMode Start addValue {2x} {4x} End generateOutput isNullParmSet {2x} Parameter generateConfigurations Recursive RecursiveGenerator generateConfigurations LatinSquares OrthogonalArray OrthogonalArray Field generate generate generate [roundNum 0] orthogonalArray adjustValues «URN » D. Am yot uOtta wa URN: Application and Research Areas 78

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 ClassA Requirement Unit1 (R1) “Scattering: design elements to support R1 in many places of the OO design” Requirement Unit2 (R2) R1 elements ClassB ClassC ClassG R1 elements R1 elements R1 elements ClassF “Tangling: single OO design unit has elements for many requirements units” Requirement Unit3 (R3) Requirement UnitN (RN) «URN » ClassD ClassE R1 elements R2 elements R3 elements RN elements D. Am yot uOtta Clarke,wS.aand Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison-Wesley, 2005, www.thethemeapproach.com URN: Application and Research Areas 79

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) intertype declaration (structural) advice (behavioral) ClassA R1 R1 elements F.R1 ClassG Triggered behavior (code) R1 elements ClassC R1 elements Predicate ClassB pointcut (identifies joinpoints where advice is executed) «URN » D. Am joinpoint yot R1 elements ClassF R1 elements R2 elements R3 elements RN elements uOtta wa based on AspectJ: www.eclipse.org/aspectj Terminology URN: Application and Research Areas 80

Aspect-oriented URN (AoURN) «URN » 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 D. Am yot uOtta wa URN: Application and Research Areas 81

AoUCM: Advice and Pointcut Maps Base Model A StartPoint EndPoint R0 B EndPoint R1 Advice Map C Pointcut start P Advice.before endSuccess [success] Advice.after success [fail] Advice.after fail endFail Pointcut Map «URN » D. Am yot uOtta wa * 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 URN: Application and Research Areas 82

Composition of AoUCM with Aspect Stubs Base Model Composed System A A StartPoint EndPoint StartPoint R0 Aspect Aspect A A R0 B EndPoint B EndPoint Aspect R1 EndPoint A R1 Advice Map C C Pointcut start P Advice.before endSuccess Advice.after success [fail] s3 Advice.before Advice.after success endFail endFail Pointcut Map «URN » yot uOtta wa endSuccess s2 Advice.after fail Advice.after fail D. Am e1 start [success] * Composition is achieved by inserting aspect stubs at the joinpoints in the base model identified by the mapped pointcut expression URN: Application and Research Areas 83

Prototype Support for Concerns «URN » D. Am yot uOtta wa URN: Application and Research Areas 84

Towards AoURN Goal graphs can become very complex (due to number of concerns)! Reporter Goal Graph Webmaster Goal Graph Webmaster Reporter Win Pulitzer Prize AND Research Story Write Story Provide Online Content Security of Terminal [R] System Security [W] Publish Story «URN » D. Am yot uOtta w Scattering and Tangling – Pollution! a URN: Application and Research Areas 85

Example: AoGRL Webmaster Goal Graph Reporter Goal Graph Webmaster Reporter Win Pulitzer Prize Provide Online Content AND Write Story Research Story Reporter Security Aspect: Pointcut Graph 1 Win Pulitzer Prize Fingerprint D. Am Encryption 100 * Webmaster Security Aspect: Pointcut Graph 2 Provide Online Content Cardkey Security of Terminal 100 * «URN » Publish Story System Security 100 * Priority: medium Encryption 100 * Priority: high yot uOtta wa URN: Application and Research Areas 86

Example: AoGRL Security Aspect: Advice Graph System Security . Security of Host Security of Terminal Cost of Terminal . . Access Authorization Authentication Encryption AND OR 100 * Identification Cardkey Password Fingerprint «URN » D. Am yot uOtta wa URN: Application and Research Areas 87

Summary «URN » 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 D. Am yot uOtta wa URN: Application and Research Areas 88

Outlook Still many aspects under development In jUCMNav — — — — «URN » 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! D. Am yot uOtta wa URN: Application and Research Areas 89

For More Information Virtual Library http://www.UseCaseMaps.org/pub/ «URN » D. Am yot uOtta wa 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 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. UML 2000. LNCS 1939, 16-31, 2000. URN: Application and Research Areas 90

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 «UR N» (submitted) D. Am yot uOtta wa URN: Application and Research Areas 91

Softgoal Actor Satisficed Weakly Satisficed Belief Undecided Actor Boundary AND Weakly Denied Goal Denied Task Conflict Resource OR (a) GRL Elements (b) GRL Satisfaction Levels Contribution Correlation (c) Link Composition ? Break Hurt Some- Unknown Means-end Dependency Decomposition «URN » (d) GRL Links Make Help Some Equal (e) GRL Contributions Types D. Am yot uOtta wa URN: Application and Research Areas 92

Start Point Path OR-Fork & Guarding [C1] Conditions End Point Responsibility Direction Arrow Timestamp Point Failure Point Shared Responsibility [C3] AND-Fork (a) UCM Path Elements «URN » D. Am yot uOtta wa Continuation Trigger Path Path (asynchronous) Waiting Path OR-Join AND-Join (b) UCM Forks and Joins (c) UCM (Generic) Component Waiting Path Waiting Place [C2] Timeout Path Timer Continuation Path IN1 OUT1 IN1 OUT1 S{IN1} Static Stub & Segments ID Dynamic Stub Plug-in Map E{OUT1} (d) UCM Stubs and Plug-ins Timer Release (synchronous) (e) UCM Waiting Places and Timers URN: Application and Research Areas 93