S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA, C ANADA Daniel Amyot Q18/17 (URN) Rapporteur Time and Performance in the User Requirements Notation (URN )

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Objectives n Overview of URN support for performance and time –In the Goal-oriented Requirements Language –In Use Case Maps n Discuss relationships to proposed timed extensions for SDL (D.21/GEN) n Towards a marriage between URN and other languages

Time and Performance in the User Requirements Notation, Geneva, March 1 st, URN support for performance and time

Time and Performance in the User Requirements Notation, Geneva, March 1 st, URN - Relevant Objectives n Capture user requirements when little design detail is available n No messages, components, or component states required n Early performance analysis n Express, analyse and deal with non- functional requirements (NFRs) n Connect to other ITU-T languages (and to UML)

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Current Proposal for URN n Draft documents for Z.150, Z.151, Z.152 – n Combined use of two complementary notations: –Goal-oriented Requirement Language (GRL) for NFRs ( –Use Case Maps (UCM) for Functional Requirements ( n Create ITU-T standard by end of 2003 (Z )

Time and Performance in the User Requirements Notation, Geneva, March 1 st, URN and Real-Time Systems n URN can handle a variety of requirements for reactive and distributed systems n Does it support real-time systems well (e.g. multimedia applications, hard time constraints)? n What do we need at the URN level? –Specification language, not implementation n Trying to connect URN to other languages down the development cycle will raise interesting and challenging issues

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Time and Performance in GRL n Focus on business goals and NFRs n No formal definition or support of time n Performance is not different from other non-functional requirements –Any attribute can be attached to non- intentional elements –Textual, traceable, but no specific semantics

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Examples of GRL attributes

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Contributions in a GRL Model

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Time and Performance in UCMs n Focus on scenarios and causal relationships between responsibilities n Time found in several attributes, but no formal semantics n Numerous performance attributes –Makes performance requirements visible and analyzable up front. If not spelled out, nobody can agree or disagree with them… –See sections 8.2, 8.13, 8.15 and 12.1 of Draft Recommendation Z.152 n Target the conversion to models suitable for performance analysis (e.g. Layered Queuing Networks – LQNs)

Time and Performance in the User Requirements Notation, Geneva, March 1 st, UCM Performance Attributes n Resources and system characteristics –Device characteristics (for processors, disks, …) –Response-time requirements for path segments (delay value and percentage of responses which must complete within that delay) –Arrival characteristics for start points –Device demand parameters for responsibilities (amount of service required from devices) and data access modes for responsibilities –Relative weights for OR-forks to select branches –Allocation of components to processors

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Response Time Requirement From T1 to T2 Name Response time Percentage Agent:AAgent:BUser:B ring vrfy upd chk User:A req T1 Timestamp T2 UCM Performance Annotations Device Characteristics Processors, disks, DSP, external services… Speed factors denied Arrival Characteristics Exponential, or Deterministic, or Uniform, or Erlang, or Other Population size Responsibilities Data access modes Device demand parameters Mean CPU load (time) Mean operations on other devices OR Forks Relative weights (probability) Components Allocated responsibilities Processor assignment

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Early Performance Evaluation – PERFECT (C. Scratchley) n Specify behaviour and concurrency architecture by annotating UCMs with performance information n PERFormance Evaluation by Construction Tool n Automatically translates annotated UCMs into representation of simulation tool (PARASOL) –Uses a simulated virtual implementation of the specification and heuristics for scheduling to evaluate the feasibility of software concurrency architectures –Considers time constraints linking pairs of responsibilities –Reports the percentage of deadlines achieved, resource utilizations, and overhead costs

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Early Performance Evaluation – LQN (D. Petriu, G. Franks) n Automatically translates annotated UCMs into LQN representation –UCM2LQN tool n Layered Queuing Network (LQN) –Provides a client-server performance view of systems –Uses LQN Solver (LQNS) to solve LQN models –Typical results are throughputs, response time, and utilization –Used to determine and eliminate bottlenecks and for capacity planning

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Early Performance Aware Development: E-PAD n UCM specification of the system using UCMNav n Add workload parameters –based on workloads from similar systems –based on known parameters from existing components –possibly use a budgeting approach n Completions for missing detail –re-use from a library n Generate LQN model using UCM2LQN n LQN-level completions n Solve LQN model using existing solvers –LQNS analytic solver –ParaSRVN simulator

Time and Performance in the User Requirements Notation, Geneva, March 1 st, … E-PAD n Reason about performance impacts of the scenario and the architecture: –exploit concurrency and parallelism –identify potential performance bottleneck –choose from alternative arch., behaviours, components –evaluate scalability

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Relationships to proposed timed extensions for SDL

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Use Case Maps / URN Do Not Have… n Standard time semantics –Provided by conversion to other models n Time-guarded behaviour n Local time n Urgency n Time-driven scenarios per say –but start points supports various distributions of arrivals, with percentiles n Support for multiple queues, priorities, and scheduling

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Use Case Maps / URN Have… n A timer construct (clock symbol), used to select between a normal path and a timeout path. –No quantity in timer. More like a Boolean variable. –Means to reset timers, to select the normal path. n Modeling of the system and of its environment n Mappings to resource models –Deployment to processors –Description of various resources and activities

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Use Case Maps / URN Have… n Some constraints on time distances between two locations on UCM paths –Timestamps and response time requirements –A percentile can be used to qualify each such requirements (100% may be too hard). n Probabilities at OR-forks and dynamic stubs n Connections to business goals and NFRs (GRL) n Existing mappings to common performance analysis modeling languages (LQNs). Z.153?

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Opportunities for aligning relevant key concepts

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Marriage between URN and MSC/SDL/DCL/TTCN/UML… n What do we want out of this relationship? n What do we need at the requirements level? –The case for real-time requirements… n How to we get a coherent, transferable, and traceable view of time/performance annotations across languages?

Time and Performance in the User Requirements Notation, Geneva, March 1 st, Marriage between URN and MSC/SDL/DCL/TTCN/UML… n What should be duplicated, what should remain orthogonal? n Evolve URN (and MSC) to implementation level? –Containment of instances –Description of resources and access to data –Relationship to ODL, DCL –Flow every information to SDL n Performance tests in TTCN-3?

Time and Performance in the User Requirements Notation, Geneva, March 1 st, URN and UML n A performance profile for UML has been proposed for standardization (Carleton U., Rational, High-Performix?...) n Most of its concepts come from experience gained using UCM-based performance annotations and analysis n UCM annotations and scenario constructs still go beyond the proposed UML profile

Time and Performance in the User Requirements Notation, Geneva, March 1 st, References n n Chung, L., Nixon, B.A., Yu, E. and Mylopoulos, J., Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers, n Miga, A., Amyot, D., Bordeleau, F., Cameron, D., and Woodside, M., Deriving Message Sequence Charts from Use Case Maps Scenario Specifications, 10 th SDL Forum, Copenhagen, Denmark, June n Monkewich, O., Sales, I., and Probert, R., OSPF Efficient LSA Refreshment Function in SDL, 10 th SDL Forum, Copenhagen, Denmark, June n Petriu, D. and Woodside, M. (2001) Generating a Performance Model from a Design Specification. In: Third Workshop on Generative Programming, ECOOP 2001, June n Sales, I. (2001) A Bridging Methodology for Internet Protocols Standards Development. M.Sc. thesis, SITE, University of Ottawa, Canada, August n Scratchley, W.C., Evaluation and Diagnosis of Concurrency Architectures, Ph.D. thesis, Carleton University, Canada, November n Scratchley, W.C. and Woodside, C.M. (1999) Evaluating Concurrency Options in Software Specifications. In: MASCOTS99, College Park, MD, USA, October 1999, n Siddiqui, K.H. and Woodside, M. (2001) Performance Aware Software Development Using Execution Time Budgets. In: Proceedings of the 6th Mitel Conference, Ottawa, Canada. n Woodside, M. (2001) Performance Analysis with Use Case Maps. In: URN Workshop, CASCON01, Toronto, November.