Elsevier

Computer Communications

Volume 23, Issue 12, 1 July 2000, Pages 1135-1157
Computer Communications

Use Case Maps and Lotos for the prototyping and validation of a mobile group call system

https://doi.org/10.1016/S0140-3664(99)00242-XGet rights and content

Abstract

Spec-VALUe, a rigorous scenario-driven approach for the description and validation of complex system functionalities at the early stages of design, is presented. It is based on two notations. The first notation, called Use Case Maps (UCMs), is used to capture functional requirements. UCMs can help reasoning about system-wide functionalities at a high level of abstraction before a prototype is generated. The second notation is the formal specification language Lotos. UCM scenarios are translated into Lotos specifications, which animate UCMs with the help of tools. Lotos-based techniques, especially specification-level testing, can be used to validate designs. It is shown how Spec-VALUe can help to produce better-quality designs and standards and to improve human understanding with reduced time and costs. A real-life case study is provided: the Group Call service of the mobile data system General Packet Radio Services (GPRS).

Introduction

Numerous industries and standardization bodies (ITU, ISO, ANSI, ETSI, TIA, etc.) are constantly at work to design new telecommunications products and new standards for such products, involving increasingly complex functionalities. These services require increasingly complex architectures and protocols. In the early stages of many conventional design processes used in industry and in standardization bodies, many features, services, and functionalities are described using informal operational descriptions, tables and visual notations such as Message Sequence Charts (MSCs) [26]. As these descriptions evolve, they quickly become error-prone and difficult to manage. The need of precisely documenting all stages of the design process, which is very important in the industrial environment, becomes critical in the standardization process, where there is international scrutiny for which the stages are formalized and must undergo formal review and approval [3].

The following issues should be addressed:

  • While designing systems and services in the initial stages, the discussion must focus on a level of detail that reflects the level of knowledge (about data, messages, components, etc.) available at the time. Descriptions that include irrelevant details tend to obscure the main idea behind a feature/service/functionality, especially when the latter needs further modifications or refinements. Several levels of detail and abstraction, similar to viewpoints in Open Distributed Processing (ODP) [22] and planes in Intelligent Networks (IN) [25], are often mixed in a single description.

  • A simple visual notation, which abstracts from messages while focusing on the tasks to perform and their cause-to-effect (or causal) relations, can help focusing on the general control flow while providing for more maintainable and reusable scenario descriptions. The Message Sequence Charts (MSC) notation is very commonly used, but its focus is on message exchanges, which come into consideration later at the detailed design stages. Such a focus can be inappropriate while defining the functionalities in the initial stages of the design, when details related to messages and system components might be unknown [4].

  • There are possibly ambiguities, inconsistencies or undesirable interactions inside or between service descriptions, or between levels of abstraction of a given service. These remain difficult to detect with conventional inspection methods, and often remain hidden until errors are discovered after implementation, at which point corrections can be very costly and system interoperability can be jeopardized.

The process of going from informal functional or operational requirements to a high-level formal specification is a research subject where much work has been carried out [3], [6], [14]. However, many challenges, such as the ones presented in the previous section, still remain. Formal Description Techniques (FDTs), such as Lotos [21] and SDL [24], were created in order to formally express functional requirements, and hence to answer some of these challenges. In particular, FDTs are well suited for the precise definition of telecommunication systems. Although they help avoid ambiguities and inconsistencies, FDTs often require an inappropriate level of detail and completeness in the preliminary stages of standards definitions. Further, they are not easy to learn, and this slows down their penetration in industry.

Several techniques can be used to address the issues related to design and standardization processes (Section 1.1). Over the last few years, there has been a strong interest, in both academia and industry, in the use of scenarios for requirements engineering and system design [43]. The introduction of use cases [27] in the object-oriented world confirmed this trend. The exact definition of a scenario may vary depending on semantics and notations, but most definitions include the notion of a partial description of system usage as seen by its users [35]. In this paper, we consider the terms “scenario” and “use case” as synonyms, but the literature often distinguishes them by defining a scenario to be a specific realization of a use case [40], [34]. Many methodologies are now available and they often have a high degree of acceptance because of the intuitive and linear nature of scenarios [20], [40], [43]. However, many different meanings have been associated to the word “scenario”. They are related to traces (of internal/external events), to message exchanges between components, to interaction sequences between a system and its user, to a more or less generic collection of such traces, etc. Numerous notations are also used to describe scenarios: informal pictures [27]; natural language or structured text [34], [40]; grammars or automata [19]; tables [13]; and message exchange diagrams similar to MSCs [27], [34], [38], [40], to mention but a few. The approaches available differ on many aspects, depending on the definition and the notation used.

A more rigorous approach, based on scenarios and supported by a formal description technique, would allow the design process to focus on the main functional aspects of systems, and hence better to cope with some of the complex problems related to the design, documentation, validation, and maintenance of systems and standards. In Section 2, we present such an approach where informal requirements are partially captured as causal scenarios through the use of a visual notation called Use Case Map (UCM) [10], [11]. These designs are also documented with tables describing the activities to be performed. In order to detect logical errors, inconsistencies, ambiguities, and undesirable interactions between the scenarios, we use Lotos to specify the integration of the scenarios and their distribution over a topology of components. The choice of these two notations is justified in 2.1 Motivation, 2.3 Use case maps introduces the main UCM concepts with a simplified GPRS operation. The reader unfamiliar with Lotos is invited to read Section 2.4 for an overview of the operators.

The goal of this approach is to produce better quality standards and to improve the overall understanding of distributed systems, while decreasing the required time, costs, and efforts. We illustrate this approach on a real-life example from a mobile telephony standard: the Point-to-Multipoint Group Call service of General Packet Radio Services. One of its functionalities is illustrated as a Use Case Map (Section 3). We show how UCMs helped in the construction of our GPRS specification (Section 4) and in its validation (Section 5). A discussion that includes a comparison with similar techniques is given in Section 6, followed by our conclusions. Owing to the large number of acronyms used in this paper, a glossary of acronyms is included in Appendix A.

GPRS [16] is a mobile telephony service at an advanced stage of standardization at the time this paper is written. It allows its subscribers to send and receive data in an end-to-end packet transfer mode. Built on top of the concepts and technologies of Global System for Mobile Communications (GSM) [31], a connection-oriented service for mobile telephony, GPRS provides connectionless packet transfer within the Public Land Mobile Network (PLMN) in interworking with external networks (X.25 and TCP/IP).

There are two main categories of GPRS services: Point-To-Point (PTP) and Point-To-Multipoint (PTM), based on existing and standardized network protocols. Typical applications for PTP services include retrieval services (Web), messaging services (mailbox), real time conversations (Telnet), and short tele-actions (credit-card validation). Typical applications for PTM services include unidirectional distribution services (newsgroups), bidirectional dispatching services (for a taxi fleet), and multi-directional conferencing services, without store and forward, between multiple users. The PTM services have several capabilities, including geographical routing to restrict distribution and scheduled delivery.

In this paper, we focus on the PTM-Group Call (PTM-G). This service allows transmissions of messages to specific groups of users in specific geographical areas (see Fig. 1). At any point in time, the network has the knowledge of the actual group call participants present within the given area.

Section snippets

Motivation

In the first stages of design processes, we anticipate instabilities in the requirements as well as volatility of scenarios and potential component topologies (structures). Hence, an iterative and incremental process (in spiral form), which allows rapid prototyping and test cases generation directly from the same scenarios, seems appropriate.

We believe that the usage of Use Case Maps in a scenario-based approach represents a judicious choice for the description of communicating and distributed

Informal requirements and assumptions

Six operations are defined in Ref. [16] for the implementation of the PTM-G service: Initiate Call, to create a group call; Terminate Call, to delete a group call; Call Status, to get the attributes of a group call; Join Call, to join an existing group call; Leave Call, to quit a joined group call; Data Transfer, to send messages and data.

In order to generate the Call Terminate and Leave Call operations invoked by the network, we define three artificial operations that we can trigger at will.

Synthesis of specifications from UCMs

The synthesis of Lotos specifications (step

in Fig. 2), illustrated with our Join Call scenario in Fig. 3d, allows for the rapid generation of prototypes that represent UCM scenarios. The behaviour of each component is translated into a Lotos process (Fig. 9b) that preserves the internal causality relationships between the responsibilities and events that are part of path segments crossing this component. The structure itself is converted (Fig. 9a) to a set of processes composed through shared

Lotos testing and UCMs

A good overview of verification and validation techniques available for Lotos can be found in Ref. [7]. In this experiment, we were not able to use a formal approach for the generation of test cases. The main reason is that our interest resides primarily in validation testing, where the main source of information for test derivation are informal requirements, rather than in testing for conformance with respect to an existing formal specification [23]. Functionality requirements are not given

Problems detected in the PTM-G service

The application of Spec-VALUe to PTM-G raised many questions about the standard [16]. Multiple errors, inconsistencies, and ambiguities were unveiled in many steps of our approach, especially in the requirement capture, formal specification of causal scenarios, validation testing of the prototype, and measure of structural coverage. Some of the problems that were uncovered, for the part of the system considered in this paper, include the following.

  • Sending of indications: for the successful

Conclusion

We have demonstrated an iterative and incremental design approach, based on a visual scenario notation (Use Case Maps) and a formal description technique (Lotos). In this approach, causal scenarios, described as UCMs, guide the synthesis of prototypes and the generation of validation test cases specified in Lotos. The main features of UCMs were illustrated with a simplified PTM- G operation (Join Call) and a real operation (Initiate Call). Although we touch lightly upon this aspect in this

Acknowledgements

We are indebted towards Pascal Forhan for his work on the Group Call UCMs and Lotos specification. We thank the University of Ottawa Lotos research group (especially Jacques Sincennes, Brahim Ghribi, Laurent Andriantsiferana, and Neil Hart) for their usual yet very appreciated collaboration, and Ray Buhr for his work on Use Case Maps. We kindly acknowledge FCAR, NSERC, CITO, Motorola, Nortel, and Mitel for their financial support.

References (43)

  • D. Amyot et al.

    Formal support for design techniques: a Timethreads-Lotos approach

  • D. Amyot, L. Logrippo, R.J.A. Buhr, Spécification et conception de systèmes communicants: une approche rigoureuse basée...
  • D. Amyot, R. Andrade, L. Logrippo, J. Sincennes, Z. Yi, Formal methods for mobility standards. IEEE 1999 Emerging...
  • D. Amyot, R. Andrade, Description of Wireless Intelligent Network services with Use Case Maps, in: SBRC ‘99, 17th...
  • D. Amyot, R.J.A. Buhr, T. Gray, L. Logrippo, Use Case Maps for the capture and validation of distributed systems...
  • M.A. Ardis et al.

    A framework for evaluating specification methods for reactive systems—experience report

    IEEE Transactions on Software Engineering

    (1996)
  • T. Bolognesi et al.

    Lotosphere: Software Development with Lotos

    (1995)
  • F. Bordeleau, R.J.A. Buhr, The UCM-ROOM design method: from use case maps to communicating state machines, Conference...
  • E. Brinksma

    A theory for the derivation of tests

  • R.J.A. Buhr et al.

    Use Case Maps for Object-Oriented Systems

    (1995)
  • R.J.A. Buhr et al.

    High level, multi-agent prototypes from a scenario-path notation: a feature-interaction example

  • R.J.A. Buhr, Use Case Maps as Architectural Entities for Complex Systems, in: IEEE Transactions on Software...
  • A. Cockburn, Using Goal-Based Use Cases, in: JOOP, November/December 1997, pp....
  • J.-P. Courtiat, P. Dembinski, G.J. Holzmann, L. Logrippo, H. Rudin, P. Zave, Formal methods after 15 years: status and...
  • A. Eberlein, F. Halsall, Telecommunications Service Department: A Design Methodology and its Intelligent Support, in:...
  • ETSI, Digital Cellular Telecommunications System (Phase 2+), General Packet Radio Service (GPRS), Service Description...
  • B. Ghribi, L. Logrippo, Prototyping and formal requirement validation of GPRS: a mobile data packet radio service for...
  • C.A.R. Hoare

    Communicating Sequential Processes

    (1985)
  • P. Hsia et al.

    Formal approach to scenario analysis

    IEEE Software

    (1994)
  • IEEE Transactions on Software Engineering, Special Issue on Scenario Management 24 (12), December...
  • ISO, Information Processing Systems, Open Systems Interconnection, Lotos—A Formal Description Technique Based on the...
  • Cited by (0)

    View full text