User Requirements Notation (URN) Application and Research Areas Daniel Amyot SITE, University of Ottawa damyot@site.uottawa.ca UofT, August 23, 2007 URN: Application and Research Areas

Modeling Puzzle – Common View Data Modeling Puzzle – Common View Structural Diagrams SDL, eODL, or UML class, object, component, & deployment diagrams Informal Requirements, Textual Use Cases MSC, UML Use Case Diagram & Activity Diagram Can we do better to bridge this gap? Behavioral Diagrams MSC/SDL, or UML sequence, collabor., & statechart diagrams Testing and Performance Languages TTCN, LQN, ... GRL and UCM represent essential pieces of the OMG/SG17 language puzzle. Some of the key points are: Goal-based (e.g. GRL) and scenario-based (e.g. UCMs) notations complement each other. GRL and UCMs, as part of the User Requirements Notation (URN), propose to fill a void in methodologies based on ITU-T languages UCMs offer more capabilities than UML use case diagrams and activity diagrams for requirements-level descriptions and analysis Compared to other scenario notations, UCMs are graphical, do not require components with interactions/messages, and support dynamic behavior and structures well URN fits well into scenario-based software development methodologies GRL provides the decision making framework for software engineering activities, and supports the documentation of decisions UCMs become the focal point for 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 (TTCN tests, performance/LQN, MSC / Sequence Diagrams, LOTOS, and others). Data types in ASN.1 can be used at all steps, although no particular binding to URN exists. Why yet another notation? Sometimes we cannot commit to data types because we do not know enough about the messages that will be required Sometimes we cannot commit to messages and component behaviour because we are not sure about what entities will be involved in our system Sometimes we cannot even commit to particular functionalities because stakeholders have conflicting goals that remain unresolved This is where URN can help! URN: Application and Research Areas

Overview of the Presentation Overview of URN Goal-oriented Requirements Language (GRL) Use Case Maps (UCM) URN Analysis Techniques GRL Strategies UCM Scenarios Application and Research Areas Transformations to Message Sequence Charts and test goals Architectural Evaluations Performance engineering Business process modelling and management Requirements management and policy compliance Pattern formalization Reverse engineering Aspect-oriented requirements engineering URN: Application and Research Areas

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: Application and Research Areas

URN: Application and Research Areas URN Proposal Combined use of two complementary notations: Goal-oriented Requirement Language (GRL) for goals and non-functional requirements http://www.cs.toronto.edu/km/GRL/ Use Case Maps (UCM) for operational requirements and architectures http://www.UseCaseMaps.org/ http://www.UseCaseMaps.org/pub URN: Application and Research Areas

URN: Application and Research Areas 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 The Goal-oriented Requirement Language (GRL) addresses most of URN’s additional objectives. Goal-oriented modeling has been proposed in the requirements engineering community for a number of years and several approaches have been published. GRL is a rather new addition to this growing list of techniques but builds on the well-established NFR framework (for non-functional requirements), and the agent-oriented language i* (for the modeling, analysis, and reengineering of organisations and business processes. GRL captures business or system goals, alternative means of achieving goals (either objectively or subjectively), and the rationale for goals and alternatives. The notation may be applied to non-functional as well as functional requirements. URN: Application and Research Areas

Correlation (side-effect) regular off-the-shelf technology Basic GRL Notation Softgoal System Security ? Break Hurt Some- Unknown Make Help Some+ Equal Decomposition Security of Host Terminal AND . Task Make Access Authorization Encryption Contribution Correlation (side-effect) Cost of Terminal Goal Identification Authentication AND GRL provides constructs for expressing various types of concepts that appear during the requirement process. There are four main categories of concepts: intentional elements, links, actors, and non-intentional elements. The intentional elements in GRL are goals, tasks, softgoals, and resources. They are intentional because they are used for models that allow answering questions such as why particular behaviors, informational and structural aspects were chosen to be included in the system requirement, what alternatives were considered, what criteria were used to deliberate among alternative options, and what the reasons were for choosing one alternative over the other. This kind of modeling is different from the detailed specification of what is to be done. Here the modeler is primarily concerned with exposing "why" certain choices for behavior and/or structure were made or constraints introduced. The modeler is not yet interested in the "operational" details of processes or system requirements (or component interactions). Omitting these kinds of details during early phases of analysis (and design) allows taking a higher-level (sometimes called a strategic stance) towards modeling the current or the future software system and its embedding environment. Modeling, documenting, and answering "why" questions leads us to consider the opportunities stakeholders seek out and/or vulnerabilities they try to avoid within their environment by utilizing capabilities of the software system and/or other stakeholders, by trying to rely upon and/or assign capabilities and by introducing constraints on how those capabilities ought to be performed. Password Cardkey Biometrics OR Belief Biometrics is no regular off-the-shelf technology URN: Application and Research Areas

URN: Application and Research Areas 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 URN: Application and Research Areas

URN: Application and Research Areas Basic GRL Notation Break Hurt Some- Unknown Make Help Some+ Equal 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) URN: Application and Research Areas

URN: Application and Research Areas Advanced GRL Notation GRL graphs can be allocated to actors Dependencies can be defined between actors, together with intermediate resources. URN: Application and Research Areas

URN: Application and Research Areas Why GRL? Goals are an important driver for requirements elaboration GRL expresses and clarifies tentative, ill-defined and ambiguous requirements Supports argumentation, negotiation, conflict detection & resolution, and decisions Captures decision rationale and criteria (documentation!) GRL identifies alternatives (requirements, architectures, means…) GRL provides traceability from strategic objectives to technical requirements GRL allows reuse of stable higher-level goals when the system evolves Nothing quite like this in UML… URN: Application and Research Areas

GRL: Abstract Metamodel (I) URN: Application and Research Areas

GRL: Abstract Metamodel (II) Links Strategies URN: Application and Research Areas

URN: Application and Research Areas 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 Use Case Maps (UCMs) are a scenario-based software engineering technique that have a history of application to the description of object-oriented systems and reactive systems in various areas, including wireless, mobile, and agent domains. UCMs are used as a visual notation for describing causal relationships between responsibilities of one or more use cases, optionally allocated to a structure of abstract components. UCMs are most useful at the early stages of software development and are applicable to use case capturing and elicitation, use case validation, as well as high-level architectural design and test case generation. The combined, gray-box, view of behavior and structure and the flexible allocation of responsibilities to architectural structures bridge the gap between requirements and design. UCMs provide a behavioral framework for evaluating and making architectural decisions at a high level of design, optionally based on performance analysis of UCMs. Moreover, UCMs provide its users with dynamic (run-time) refinement capabilities for variations of scenarios and structure and allow incremental development and integration of complex scenarios. URN: Application and Research Areas

URN: Application and Research Areas Pool UCM Example Start Point Stub AND-Fork Slot End Point Responsibility Component a) Root UCM b) Biometrics Plug-In c) PassWord Plug-in Timer OR-Fork UCMs have four basic concepts: start points capture preconditions and triggering events, end points represent resulting events and post-conditions, responsibilities are locations where computation or actions are necessary, and components capture abstract entities and roles (software, hardware, human, etc.). Paths connect start points to end points and can link responsibilities in a causal way. Responsibilities may be bound to components where they can be performed. Alternative and concurrent paths that span an entire system may easily be captured. Stubs and plug-ins enable the structuring and reuse of complex maps. Dynamic stubs may contain many plug-ins, whose selection is done at run time according to a selection policy. Dynamic responsibilities (on UCM paths) and dynamic components capture object and role dynamics in a static way and UCM. This capability is useful to describe dynamic systems (e.g. based on agents) while avoiding to have a series of snapshots exposing the system structure at different points in time. Bindings for Authorize: [atNight]  Biometrics {(IN1,Bio), (OUT1,Yes), (OUT2,No)} [!atNight]  PassWord {(IN1,PW), (OUT1,Yes), (OUT2,No)} OR-Foin URN: Application and Research Areas

URN: Application and Research Areas 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 “UML includes several implicit links between these two sets of diagrams (e.g., sequence and collaboration diagrams can use the entities defined in class diagrams). However, UML does not emphasize any first-class and compact way of describing large-scale units of behavior that emerge from the collective efforts of many system components (e.g., transactions spanning a network).” [Am99-2] “There exists a large conceptual gap between use cases and their realization in terms of behavioral diagrams where the system’s internals are refined with sub-components. Reasoning about this gap and the big picture using the current UML diagrams is often puzzling since much mental effort is required to integrate many details from many diagrams of different styles.” [Am99-2] URN: Application and Research Areas

URN: Application and Research Areas 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 Intentional Element Map Component Responsibility URN: Application and Research Areas

Overview of the Presentation Overview of URN Goal-oriented Requirements Language (GRL) Use Case Maps (UCM) URN Analysis Techniques GRL Strategies UCM Scenarios Application and Research Areas Transformations to Message Sequence Charts and test goals Architectural Evaluations Performance engineering Business process modelling and management Requirements management and policy compliance Pattern formalization Reverse engineering Aspect-oriented requirements engineering URN: Application and Research Areas

Evaluations with GRL (strategy 1) Satisficed Weakly Satisficed Undecided Weakly Denied Denied System Security AND Security of Host Security of Terminal . . Cost of Terminal Access Authorization Encryption AND The previous slide illustrated how GRL can help visualising static relations that exist between identified goals, different alternatives that contribute to these goals, side-effects, and rationales. GRL also supports an evaluation mechanism used to measure the impact of qualitative decisions on the level of satisfaction of high-level goals. Such mechanism requires one to assign a qualitative degree of satisfaction or availability to tasks and goals at the bottom of the graph, and then to use a propagation algorithm to compute how well higher-level goals are satisfied. For instance, if biometrics systems are available, then the authentication will be satisfied as well. If the identification is not possible, then one can be undecided about whether the access authorization is satisfied or not. Note also that selecting biometrics will have a negative impact on the cost of the terminal (because biometrics is an expensive authentication means). Additional notation elements for associating goal trees to agents and for expressing dependencies between agents are not shown here but are defined in the draft Z.151. Authentication Identification OR Biometrics is no regular off-the-shelf technology Cardkey Password Biometrics URN: Application and Research Areas

URN: Application and Research Areas 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) URN: Application and Research Areas

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

URN: Application and Research Areas 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 - Advantage is that user could compare different strategies and their impact on the model URN: Application and Research Areas

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

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 Requested by users URN: Application and Research Areas

Numerical Evaluation: Decompositions Minimum for AND, maximum for OR And Decomposition Or Decomposition URN: Application and Research Areas

Numerical Evaluation: Contributions For each contribution, convert the contribution level to the corresponding weight factor Make = 1 Help = 0.5 Some Positive = 0.25 Unknown = 0 Some Negative = -0.25 Hurt = -0.5 Break = -1 Contributions are additive, but are normalized. URN: Application and Research Areas

Numerical Evaluation: Dependencies Intentional element evaluation is set to the minimal value in the set of dependees evaluation or it current evaluation How evaluation and URN links are related URN: Application and Research Areas

URN: Application and Research Areas 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 Criticality and priority is high, medium or low URN: Application and Research Areas

Numerical Evaluation: Actor Evaluation Priority = Low Criticality = None Priority = None Criticality = High URN: Application and Research Areas

UCM Scenario Definitions and Path Traversal (Highlight) Extraction of individual scenarios based on a traversal algorithm Conditions attached to selection/start/end points Initialization of global variables, and selection of start points and expected end points Data types: Boolean, integer, enumerations Used for validation and transformations URN: Application and Research Areas

URN: Application and Research Areas 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 GRL supports the reasoning about scenarios by establishing correspondences between intentional GRL elements and non-intentional elements in scenario models of UCMs (hence describing the “how”). Modeling both goals and scenarios is complementary and may aid in identifying further goals and additional scenarios (and scenario steps) important to stakeholders, thus contributing to the completeness and accuracy of requirements. In a development process, one would likely start with high-level goals that would be refined in terms of sub-goals and preliminary scenarios. As scenarios are refined, they can too impact the goal model. This would suggest an incremental and iterative process. URN: Application and Research Areas

? Modeling Puzzle — URN Data URN-GRL URN-UCM Structural Diagrams SDL, eODL, or UML class, object, component, & deployment diagrams Informal Requirements, Textual Use Cases ? MSC, UML Use Case Diagram & Activity Diagram URN-GRL Goals, non-functional requirements, alterna-tives, rationales UCMs link to operationalizations and actors in GRL models URN-UCM Superimpose visually system level behavior 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 Testing and Performance Languages TTCN, LQN, ... GRL and UCM represent essential pieces of the OMG/SG17 language puzzle. Some of the key points are: Goal-based (e.g. GRL) and scenario-based (e.g. UCMs) notations complement each other. GRL and UCMs, as part of the User Requirements Notation (URN), propose to fill a void in methodologies based on ITU-T languages UCMs offer more capabilities than UML use case diagrams and activity diagrams for requirements-level descriptions and analysis Compared to other scenario notations, UCMs are graphical, do not require components with interactions/messages, and support dynamic behavior and structures well URN fits well into scenario-based software development methodologies GRL provides the decision making framework for software engineering activities, and supports the documentation of decisions UCMs become the focal point for 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 (TTCN tests, performance/LQN, MSC / Sequence Diagrams, LOTOS, and others). Data types in ASN.1 can be used at all steps, although no particular binding to URN exists. Why yet another notation? Sometimes we cannot commit to data types because we do not know enough about the messages that will be required Sometimes we cannot commit to messages and component behaviour because we are not sure about what entities will be involved in our system Sometimes we cannot even commit to particular functionalities because stakeholders have conflicting goals that remain unresolved This is where URN can help! UCMs visually associate behavior and structure at the system level UCMs provide a framework for making high level and detailed design decisions URN: Application and Research Areas

URN: Application and Research Areas 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 URN: Application and Research Areas

Overview of the Presentation Overview of URN Goal-oriented Requirements Language (GRL) Use Case Maps (UCM) URN Analysis Techniques GRL Strategies UCM Scenarios Application and Research Areas Transformations to Message Sequence Charts and test goals Architectural Evaluations Performance engineering Business process modelling and management Requirements management and policy compliance Pattern formalization Reverse engineering Aspect-oriented requirements engineering URN: Application and Research Areas

Several Known URN Application Domains Telecommunication/telephony services Wireless systems Object-oriented software Multi-agent systems Web applications and Web services Railway control systems Embedded systems User interfaces Access control procedures Network protocols e-Business applications Supply chain management e-Health applications Software product lines Operating systems Information retrieval systems Vehicle communication systems … URN: Application and Research Areas

URN: Application and Research Areas 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

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: Application and Research Areas

URN: Application and Research Areas jUCMNav supports MSC viewer Reordering of instances MSC export to images URN: Application and Research Areas

URN: Application and Research Areas UCM-Based Testing Based on UCM Testing Patterns Grey-box test selection strategies, applied to requirements scenarios Manual Based on UCM Scenario Definitions UCM + simple data model, definitions, and path traversal algorithms Semi-automated Based on UCM Transformations Exhaustive traversal Mapping to formal language (e.g., LOTOS, ASM) Automated URN: Application and Research Areas

URN: Application and Research Areas Comparison URN: Application and Research Areas

Towards Test Case Generation Communication and calls Messages, parameters, interfaces, protocols... Data Must endure that the scenario is feasible Temporal information UCM timers currently have no quantitative time Implementation, sequencing, execution, clean-up Many other challenges! There are however some partial results available… Use of UCMNav, scenario definitions, and Fitnesse to generate executable test cases for a typical Web application. URN: Application and Research Areas

Test Generation for Web Applications [Amyot, Roy and Weiss, 2005] URN: Application and Research Areas

Overview of the Presentation Overview of URN Goal-oriented Requirements Language (GRL) Use Case Maps (UCM) URN Analysis Techniques GRL Strategies UCM Scenarios Application and Research Areas Transformations to Message Sequence Charts and test goals Architectural Evaluations Performance engineering Business process modelling and management Requirements management and policy compliance Pattern formalization Reverse engineering Aspect-oriented requirements engineering URN: Application and Research Areas

Example GRL Model (Wireless Service) High Evolveability High Performance Throughput Maximum Hardware Utilisation Minimum Changes to Infrastructure Low Cost Less need for new hardware Minimum MobSC Load Minimum Message Exchange Service in SCP Service in MobSC SDF in SCP SDF in SN Determine SDF Location Impact is vendor-specific URN: Application and Research Areas

URN: Application and Research Areas Three Alternative Architectures (a) Service in MobSC (b) Service in MobSC, SDF in SN (c) Service and SDF in SCP URN: Application and Research Areas

Service in MobSC (option a) Service and SDF in SCP (option c) Two Resulting MSCs Service in MobSC (option a) Service and SDF in SCP (option c) URN: Application and Research Areas

Quantitative Performance Engineering with UCMs Resource Characteristics Passive/active, external operations Disks, processors, … Operation time Multiplicity Workload Characteristics Poisson, periodic… Population size Open/closed TaxPayer Security E_Accountant CheckBio Continue Access Ready Rejected Components Allocated responsibilities Resource assignment 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

URN: Application and Research Areas Resource Management URN: Application and Research Areas

Demand and Workload Management URN: Application and Research Areas

From UCM to Core Scenario Model (CSM) Export CSM (XML) from URN model Translation of CSM file to LQN, QN, stochastic Petri Nets… URN: Application and Research Areas

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! URN: Application and Research Areas

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: Application and Research Areas

Overview of the Presentation Overview of URN Goal-oriented Requirements Language (GRL) Use Case Maps (UCM) URN Analysis Techniques GRL Strategies UCM Scenarios Application and Research Areas Transformations to Message Sequence Charts and test goals Architectural Evaluations Performance engineering Business process modelling and management Requirements management and policy compliance Pattern formalization Reverse engineering Aspect-oriented requirements engineering URN: Application and Research Areas

URN: Application and Research Areas 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: Application and Research Areas

Simple Supply Chain Management BPM Agent: actor Team: role the actor plays URN: Application and Research Areas

Alternative Process Architectures (1/2) Warehouse InventoryManagement InventoryManagement:W Retailer OrderProcessing OrderProcessing:R Manufacturer Production Warehouse:M Production:M Consumer a) CURRENT: Sell to stock via warehouse and retailer (R) Consumer Warehouse InventoryManagement:W Manufacturer OrderProcessing:W Production:M Warehouse:M b) Sell to stock via warehouse (W) URN: Application and Research Areas

Alternative Process Architectures (2/2) Consumer Warehouse InventoryManagement:W Manufacturer OrderProcessing:M Production:M c) Sell direct to consumer with external warehouse (MW) Warehouse:M Consumer Manufacturer OrderProcessing:M OrderProcessing:M InventoryManagement:M InventoryManagement:M Warehouse:M Warehouse:M Production:M Production:M d) Sell direct to consumer with internal warehouse (M) URN: Application and Research Areas

When to Evolve our Process Architecture? Low Risk URN: Application and Research Areas

UCM Maps for Business Process (M) URN: Application and Research Areas

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 ? URN: Application and Research Areas

BP Analysis and Monitoring (e.g. with KPI, using Cognos 8) URN: Application and Research Areas

GRL with KPI Extensions for BAM URN: Application and Research Areas

KPI: Fed from Outside & Impact on GRL URN: Application and Research Areas

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

URN: Application and Research Areas 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 URN: Application and Research Areas

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 To solve these issues, it is required to have an integrated framework to help model both organizational and legislative documents, and establish necessary links between the elements of models and documents. These links must be complete enough to help managing changes and ensuring compliance in the new contexts. URN: Application and Research Areas

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 Our requirements management framework lets organizations model their goals, procedures and legislative documents in the same modelling language. We also allow for the introduction of links that can be used to connect these models and documents to each other in order to help in documenting and managing compliance. This framework is composed of two models and several sets of links. The model of the organization includes the policy and procedure documents, a GRL model which models the goals and tasks of the organization and a UCM model which models the business processes. The GRL and UCM models are part of the user requirement notation which connects goals and business processes together. Legislation documents are modeled with GRL but not UCM. This is because of the nature of legislation which is not procedural. Between grl and ucm of the organization there are responsibility links which connect elements of the GRL to the UCM models. These models are also connected to the original document via source links. The legislation grl model is also connected to the source document through source links. Between the organization and legislation models 3 different links are created. Traceability links are created manually between elements of both GRL models. Compliance links connect the organization’s grl model and the original law and legislation documents. Finally, responsibility links relate the UCM model of the organization to the GRL model of the legislation. URN: Application and Research Areas

Framework Metamodel (DOORS View) Organization Metamodel Law Metamodel For example, in the legislation model, the law document is divided into two objects, clauses and definitions. Clauses are linked to the intentional elements of the legislation and organization GRL model via source and compliance links respectively. In addition, we can identify that some links can be inferred by transitivity. These are compliance and responsibility links between two models. URN: Application and Research Areas

Case Study – PHIPA Compliance at Ontario 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 … Hospital Document HIC Policy Document - All requests for data from data warehouse will be evaluated based on technical feasibility, data availability, resource availability and REB approval for research. Policy 2 … source resp traces complies source GRL Model of Hospital Protect Privacy and Confidentiality of Hospital Data Prevent Unauthorized Use and Disclosure Ensure Accountability of Data User Check Ethical Issues Get to An Agreement with Data User Request Form Check with Privacy and Confidentiality Legislations Users Safeguards DW Administrator REB Privacy Officer GRL Model of PHIPA Satisfy Privacy Regulations Protect Confidentiality Prevent Unautho - rized Disclosure Ask for Compliance Agreement Check Research Plan Adequate Safeguards Ethical Issues HIC And REB Approval REB Committee Limit Disclosure of Data UCM Model of Hospital X V [GiveUp] Reject requestForPHI Accept getToAnAgreement reviewRequest getRejection amendDocuments [NewRequest] Researcher Hospital resp Discrepancies could be detected during modelling… URN: Application and Research Areas

Overview of the Presentation Overview of URN Goal-oriented Requirements Language (GRL) Use Case Maps (UCM) URN Analysis Techniques GRL Strategies UCM Scenarios Application and Research Areas Transformations to Message Sequence Charts and test goals Architectural Evaluations Performance engineering Business process modelling and management Requirements management and policy compliance Pattern formalization Reverse engineering Aspect-oriented requirements engineering URN: Application and Research Areas

Integrating UCEd and jUCMNav URN: Application and Research Areas

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 ExtensionPoint==> 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 URN: Application and Research Areas

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: Application and Research Areas

Modelling Forces and Resolutions URN: Application and Research Areas

Considering Alternative Combinations [Mussbacher, Amyot and Weiss, 2007] URN: Application and Research Areas

Reverse-Engineering UCM Models from 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] URN: Application and Research Areas

URN: Application and Research Areas 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) Condition Condition (between square brackets) [cond] {2} … … IN1 OUT1 … URN: Application and Research Areas

URN: Application and Research Areas Example of Trace Viewed as UCM (TConfig) Start End URN: Application and Research Areas

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 R1 elements ClassB ClassC ClassG ClassD ClassF R2 elements R3 elements RN elements ClassE “Scattering: design elements to support R1 in many places of the OO design” Requirement Unit1 (R1) Requirement Unit2 (R2) Requirement Unit3 (R3) Requirement UnitN (RN) … “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 URN: Application and Research Areas

Background on Aspects: The Solution Aspects address the problem of one unit crosscutting other units in the system or model aspect ClassA R1 elements ClassC ClassG ClassF R2 elements R3 elements RN elements ClassB (new unit of encapsulation) R1 R1 elements intertype declaration (structural) F.R1 Triggered behavior (code) R1 elements advice (behavioral) R1 elements Predicate pointcut R1 elements (identifies joinpoints where advice is executed) R1 elements joinpoint Terminology based on AspectJ: www.eclipse.org/aspectj URN: Application and Research Areas

Aspect-oriented URN (AoURN) By Ph.D. student Gunter Mussbacher URN extended to support aspects-oriented modelling Demonstrated that UCM (with their dynamic stubs) can be a more expressive concern composition language for requirements than most AO languages Same language (UCM) used for base models, advices, and pointcuts URN metamodel additions (very few), composition algorithm, and examples are available Extended to support AoGRL Metrics defined to measure effectiveness of AoURN URN: Application and Research Areas

AoUCM: Advice and Pointcut Maps Base Model StartPoint EndPoint A B R1 R0 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 Advice Map start endSuccess [success] Advice.after_success Advice.before Advice.after_fail endFail [fail] C Pointcut P * Pointcut Map URN: Application and Research Areas

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

Prototype Support for Concerns URN: Application and Research Areas

Provide Online Content Security of Terminal [R] Towards AoURN Goal graphs can become very complex (due to number of concerns)! Reporter Goal Graph Webmaster Goal Graph Reporter Web- master Win Pulitzer Prize Provide Online Content AND + + Security of Terminal [R] System Security [W] Research Story Write Story Publish Story Scattering and Tangling – Pollution! URN: Application and Research Areas

Provide Online Content Provide Online Content Example: AoGRL Reporter Goal Graph Webmaster Goal Graph Reporter Web- master Win Pulitzer Prize Provide Online Content AND Research Story Write Story Publish Story Security Aspect: Pointcut Graph 1 Security Aspect: Pointcut Graph 2 Reporter Web- master Win Pulitzer Prize Provide Online Content + + Fingerprint 100 * Cardkey 100 * Security of Terminal System Security Encryption 100 * Encryption 100 * Priority: medium Priority: high URN: Application and Research Areas

URN: Application and Research Areas Example: AoGRL Security Aspect: Advice Graph System Security + + . Security of Terminal Security of Host Cost of Terminal _ . + . + Access Authorization + Encryption Authentication AND 100 * OR Identification Cardkey Password Fingerprint URN: Application and Research Areas

URN: Application and Research Areas 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 URN: Application and Research Areas

URN: Application and Research Areas Outlook Still many aspects under development In jUCMNav Support for improved workflow semantics for UCM Transformations to UML, test cases Aspect-oriented Use Case Maps Report generation URN-based aspect-oriented modeling Link definition and exploitation between GRL and UCM Formal semantics of URN models (LOTOS, ASM, SDL, …) Integration with UML (profiles and tools) Improved round-trip requirements and performance engineering Many more topics! URN: Application and Research Areas

URN: Application and Research Areas For More Information Virtual Library http://www.UseCaseMaps.org/pub/ Introduction to URN Weiss, M. and Amyot, D., Business Process Modeling with URN. International Journal of E-Business Research, 1(3), 63–90, July-September 2005. Amyot, D., Introduction to the User Requirements Notation: Learning by Example. Computer Networks, Volume 42, Issue 3, pp. 285-301, June 2003. JUCMNav Roy, J.-F. Kealey, and Amyot, D. (2006) Towards Integrated Tool Support for the User Requirements Notation. Fifth Workshop on System Analysis and Modelling (SAM’06), Kaiserslautern, Germany, May. Test Amyot, D., Roy, J.-F., and Weiss. M., UCM-Driven Testing of Web Applications. 12th SDL Forum (SDL'05), Grimstad, Norway, June 2005. LNCS 3530, Springer, 247-264. Reverse-engineering Hamou-Lhadj, A., Braun, E., Amyot, D., and Lethbridge, T., Recovering Behavioral Design Models from Execution Traces. CSMR’05, Manchester, UK, March 2005. IEEE Computer Society, 112-121. Scenario generation Amyot, D., Cho, D.Y., He, X., and He, Y., Generating Scenarios from Use Case Map Specifications. QSIC’03, Dallas, November 2003. IEEE Computer Society, 108-115. UCMNav/jUCMNav and DOORS Jiang, B. Combining Graphical Scenarios with a Requirements Management System. MSc. thesis, uOttawa, June 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

URN: Application and Research Areas Aspect-oriented URN G. Mussbacher, D. Amyot, and M. Weiss (2007) Visualizing Early Aspects with Use Case Maps, LNCS Journal on Transactions on Aspect-Oriented Software Development, to appear Mussbacher, G., Amyot, D., Whittle, J., and Weiss, M. (2007) Flexible and Expressive Composition Rules with Aspect-oriented Use Case Maps (AoUCM). 10th International Workshop On Early Aspects, Vancouver, Canada, March. G. Mussbacher, D. Amyot, and M. Weiss (2007) Aspect-Oriented User Requirements Notation (AoURN): Modeling Goals and Scenarios of Crosscutting Concerns in a Unified Way. MoDELS (submitted) URN, Compliance and DOORS Ghanavati, S., Amyot, D., and Peyton, L. (2007) Towards a Framework for Tracking Legal Compliance in Healthcare. 19th Int. Conf. on Advanced Information Systems Engineering (CAiSE'07), Trondheim, Norway, June. Ghanavati, S., Amyot, D., and Peyton, L. (2007) A Requirements Management Framework for Privacy Compliance. 10th Workshop on Requirements Engineering (WER’07), Toronto, Canada, May. Peyton, L., Ghanavati, S., and Amyot, D. (2007) Designing for Privacy Compliance and Performance Management in Health Care. Design Journal (submitted) URN, Patterns, and Business Process Modelling Mussbacher, G. (2007) Evolving Use Case Maps as a Scenario and Workflow Description Language, 10th Workshop on Requirements Engineering (WER’07), Toronto, Canada, May. Pourshahid, A., Chen, P., Amyot, D., Forster, A.J., and Weiss, M. (2007) Business Process Monitoring and Alignment: An Approach Based on the User Requirements Notation and Business Intelligence Tool. 10th Workshop on Requirements Engineering (WER’07), Toronto, Canada, May. Roy, J-F (2007) Requirement Engineering with URN: Integrating Goals and Scenarios, M.Sc. thesis, uOttawa, March Weiss, M. and Amyot, D. (2006) Chapter VIII: Business Process Modeling with the User Requirements Notation. I. Lee (Ed.), Advances in E-Business Research: E-Business Innovation and Process Management, Vol. 1, IGI Global, December, 162-193. Mussbacher, G., Amyot, D., and Weiss, M. (2007) Formalizing Patterns with the User Requirements Notation. T. Taibi (Ed.), Design Pattern Formalization Techniques, IGI Global, March, 304-325. Weiss, M. and Amyot, D., Business Model Design and Evolution. Management of Technology, World Scientific (submitted) URN: Application and Research Areas

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

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