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

2. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 20022 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

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

4. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 20024 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)

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

6. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 20026 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

7. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 20027 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

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

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

10. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200210 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)

11. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200211 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

12. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200212 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

13. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200213 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

14. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200214 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

15. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200215 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

16. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200216 … 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

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

18. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200218 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

19. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200219 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

20. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200220 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?

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

22. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200222 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?

23. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200223 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?

24. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200224 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

25. Time and Performance in the User Requirements Notation, Geneva, March 1 st, 200225 References n http://www.UseCaseMaps.org/pub/index.html http://www.UseCaseMaps.org/pub/index.html n Chung, L., Nixon, B.A., Yu, E. and Mylopoulos, J., Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers, 2000. 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 2001. n Monkewich, O., Sales, I., and Probert, R., OSPF Efficient LSA Refreshment Function in SDL, 10 th SDL Forum, Copenhagen, Denmark, June 2001. n Petriu, D. and Woodside, M. (2001) Generating a Performance Model from a Design Specification. In: Third Workshop on Generative Programming, ECOOP 2001, June 2001. n Sales, I. (2001) A Bridging Methodology for Internet Protocols Standards Development. M.Sc. thesis, SITE, University of Ottawa, Canada, August 2001. n Scratchley, W.C., Evaluation and Diagnosis of Concurrency Architectures, Ph.D. thesis, Carleton University, Canada, November 2000. n Scratchley, W.C. and Woodside, C.M. (1999) Evaluating Concurrency Options in Software Specifications. In: MASCOTS99, College Park, MD, USA, October 1999, 330-338. 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. http://www.UseCaseMaps.org/urn/cascon01/UCMperf.pdfhttp://www.UseCaseMaps.org/urn/cascon01/UCMperf.pdf