23
SCHOOL OF INFORMATION TECHNOLOGY AND ENGINEERING UNIVERSITY OF OTTAWA, CANADA Daniel Amyot Q18/17 (URN) Rapporteur [email protected] Time and Performance in the User Requirements Notation (URN )

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA, C ANADA Daniel Amyot Q18/17 (URN) Rapporteur [email protected] Time and

Embed Size (px)

Citation preview

Page 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

SCHOOL OF INFORMATION TECHNOLOGY AND ENGINEERING

UNIVERSITY OF OTTAWA, CANADA

Daniel AmyotQ18/17 (URN) Rapporteur

[email protected]

Time and Performance in theUser Requirements Notation

(URN )

Page 2: 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

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

Page 3: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 3

URN supportfor performance and time

Page 4: 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

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

Page 5: 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

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

Page 6: 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

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

Page 7: 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

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

Page 8: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 8

Examples of GRL attributes

GOAL VoiceConnectionBeSetup

ATTRIBUTE

Object: UrgentCall

Time-constraint: “in 1 minute”

HOLDER IncomingCallServiceProvider

SOFTGOAL Performance OF Router

ATTRIBUTE

Transmission-delay: “less than 10ms”

Response-time: “<= 0.5 s”

HOLDER IncomingCallServiceProvider

Page 9: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 9

Contributions in a GRL Model

Page 10: 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

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

Page 11: 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

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

Page 12: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 12

Response TimeRequirement• From T1 to T2• Name• Response time• Percentage

Agent:A Agent:B User:B

ringvrfy updchk

User:A

req

T1

Timestamp

T2

UCM Performance AnnotationsDevice Characteristics• Processors, disks, DSP, external services…• Speed factors

denied

ArrivalCharacteristics• Exponential, or• Deterministic, or• Uniform, or• Erlang, or• OtherPopulation 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

Page 13: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 15

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

Page 14: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 16

… 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

Page 15: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 17

Relationships to proposedtimed extensions for SDL

Page 16: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 18

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

Page 17: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 19

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

Page 18: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 20

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?

Page 19: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 21

Opportunities for aligning relevant key concepts

Page 20: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 22

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?

Page 21: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 23

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?

Page 22: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 24

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

Page 23: 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

Time and Performance in the User Requirements Notation, Geneva, March 1st’, 2002 25

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