Time and Performance in the User Requirements Notation (URN )

1. Time and Performance in theUser Requirements Notation (URN ) Daniel Amyot Q18/17 (URN) Rapporteur damyot@site.uottawa.ca

2. Objectives • Overview of URN support for performance and time • In the Goal-oriented Requirements Language • In Use Case Maps • Discuss relationships to proposed timed extensions for SDL (D.21/GEN) • Towards a marriage between URN and other languages

3. URN supportfor performance and time

4. URN - Relevant Objectives • Capture user requirements when little design detail is available • No messages, components, or component states required • Early performance analysis • Express, analyse and deal with non-functional requirements (NFRs) • Connect to other ITU-T languages (and to UML)

5. Current Proposal for URN • Draft documents for Z.150, Z.151, Z.152 • http://www.UseCaseMaps.org/urn/ • 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/) • Create ITU-T standard by end of 2003 (Z.150-153)

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

7. Time and Performance in GRL • Focus on business goals and NFRs • No formal definition or support of time • 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. Examples of GRL attributes

9. Contributions in a GRL Model

10. Time and Performance in UCMs • Focus on scenarios and causal relationships between responsibilities • Time found in several attributes, but no formal semantics • 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 • Target the conversion to models suitable for performance analysis (e.g. Layered Queuing Networks – LQNs)

11. UCM Performance Attributes • 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. T2 UCM Performance Annotations • Device Characteristics • Processors, disks, DSP, external services… • Speed factors • Arrival • Characteristics • Exponential, or • Deterministic, or • Uniform, or • Erlang, or • Other • Population size Timestamp • Response Time • Requirement • From T1 to T2 • Name • Response time • Percentage User:A Agent:A Agent:B User:B T1 chk upd vrfy ring req denied • Components • Allocated responsibilities • Processor assignment • Responsibilities • Data access modes • Device demand parameters • Mean CPU load (time) • Mean operations on other devices • OR Forks • Relative weights(probability)

13. Early Performance Aware Development: E-PAD • UCM specification of the system using UCMNav • Add workload parameters • based on workloads from similar systems • based on known parameters from existing components • possibly use a budgeting approach • Completions for missing detail • re-use from a library • Generate LQN model using UCM2LQN • LQN-level completions • Solve LQN model using existing solvers • LQNS analytic solver • ParaSRVN simulator

14. … E-PAD • 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

15. Relationships to proposedtimed extensions for SDL

16. Use Case Maps / URN Do Not Have… • Standard time semantics • Provided by conversion to other models • Time-guarded behaviour • Local time • Urgency • Time-driven scenarios per say • but start points supports various distributions of arrivals, with percentiles • Support for multiple queues, priorities, and scheduling

17. Use Case Maps / URN Have… • 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. • Modeling of the system and of its environment • Mappings to resource models • Deployment to processors • Description of various resources and activities

18. Use Case Maps / URN Have… • 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). • Probabilities at OR-forks and dynamic stubs • Connections to business goals and NFRs (GRL) • Existing mappings to common performance analysis modeling languages (LQNs). Z.153?

19. Opportunities for aligning relevant key concepts

20. Marriage between URN and MSC/SDL/DCL/TTCN/UML… • What do we want out of this relationship? • What do we need at the requirements level? • The case for real-time requirements… • How to we get a coherent, transferable, and traceable view of time/performance annotations across languages?

21. Marriage between URN and MSC/SDL/DCL/TTCN/UML… • What should be duplicated, what should remain orthogonal? • 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 • Performance tests in TTCN-3?

22. URN and UML • A performance profile for UML has been proposed for standardization (Carleton U., Rational, High-Performix?...) • Most of its concepts come from experience gained using UCM-based performance annotations and analysis • UCM annotations and scenario constructs still go beyond the proposed UML profile

23. References • http://www.UseCaseMaps.org/pub/index.html • Chung, L., Nixon, B.A., Yu, E. and Mylopoulos, J., Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers, 2000. • Miga, A., Amyot, D., Bordeleau, F., Cameron, D., and Woodside, M., Deriving Message Sequence Charts from Use Case Maps Scenario Specifications, 10th SDL Forum, Copenhagen, Denmark, June 2001. • Monkewich, O., Sales, I., and Probert, R., OSPF Efficient LSA Refreshment Function in SDL, 10th SDL Forum, Copenhagen, Denmark, June 2001. • Petriu, D. and Woodside, M. (2001) “Generating a Performance Model from a Design Specification”. In: Third Workshop on Generative Programming, ECOOP 2001, June 2001. • Sales, I. (2001) A Bridging Methodology for Internet Protocols Standards Development. M.Sc. thesis, SITE, University of Ottawa, Canada, August 2001. • Scratchley, W.C., Evaluation and Diagnosis of Concurrency Architectures, Ph.D. thesis, Carleton University, Canada, November 2000. • Scratchley, W.C. and Woodside, C.M. (1999) “Evaluating Concurrency Options in Software Specifications”. In: MASCOTS’99, College Park, MD, USA, October 1999, 330-338. • Siddiqui, K.H. and Woodside, M. (2001) “Performance Aware Software Development Using Execution Time Budgets”. In: Proceedings of the 6th Mitel Conference, Ottawa, Canada. • Woodside, M. (2001) Performance Analysis with Use Case Maps. In: URN Workshop, CASCON’01, Toronto, November. http://www.UseCaseMaps.org/urn/cascon01/UCMperf.pdf