Early modeling and validation of timed system requirements using Timed Use Case Maps

Abstract

There is a general consensus on the importance of good requirements engineering for achieving high-quality software. Functional requirements capture the intended behavior of the system in terms of services, tasks, or functions the system is required to perform, while non-functional requirements capture required properties of the system, such as timing, performance, and security. These non-functional requirements play a crucial role during system development life cycle serving as selection criteria for choosing among myriads of design decisions. The ability to model and validate the system non-functional properties at the requirements level supports the detection of design errors during the early stages of a software development life cycle and helps reduce the cost of later redesign activities. The widespread interest in time modeling and analysis techniques at the requirements phase provides the major motivation for this research. This paper presents a novel and fully automated approach to describe and validate high-level timed requirements using the Timed Use Case Maps language. We extend the, ITU-T standard User Requirements Notation, Use Case Maps metamodel with time requirements. The resulting extensions are implemented within the jUCMNav tool and formalized using Abstract State Machines allowing for automated simulation and analysis. We illustrate the applicability of our approach using a business process model (conference review process model) and a real-time system model (IP multicast routing case study).

Appendices

Appendix: 1 ASM-based TUCM semantics

1.1 Timed OR-fork interleaving ASM rule

If the control is on the incoming connection of a timed OR-fork, the conditions are evaluated and the control passes to the connection associated with the true condition. If more than one condition evaluates to true (i.e., non-deterministic choice), the control passes randomly to one of the outgoing connections associated with the true conditions. Note that, in such a case, the selected outgoing edge might not lead to the successor construct with the least delay. Indeed, the branching decision is made based on the local evaluation of the timed OR-Fork conditions and no prior knowledge of successor nodes incurred delays is assumed. The set active is updated by removing the incoming connection in (with its associated delay) and by adding out _k (with its corresponding delay) that corresponds to the true condition Cond _k . Lock situations (i.e., none of the conditions evaluate to true) are reported to the user. Figure 27 illustrates the OR-fork ASM rule.

Fig. 27

Timed OR-fork interleaving ASM rule

1.2 Timed OR-join interleaving ASM rule

When one or many flows reach an OR-join (i.e., $\exists\,in_{i}\,\in$ active), the master clock is incremented by the value of the actual delay and by the value of the actual execution time, then the control passes to the outgoing connection out. Figure 28 illustrates the OR-join ASM rule.

Fig. 28

Timed OR-join interleaving ASM rule

1.3 Timed AND-join interleaving ASM rule

When all incoming connections of an AND-join are active (i.e., $[in_{i}]_{i \leq n}\,\subseteq$ in(active)), the master clock is incremented by the value of the actual delay then by the value of the actual execution time. The incoming parallel flows are joined and the control passes to the outgoing connection out. The set active is updated by removing the connections out _i (along with their associated delays) and by adding the incoming connection in with its associated delay. Figure 29 illustrates the AND-join ASM rule.

Fig. 29

Timed AND-join interleaving ASM rule

1.3.1 Timer interleaving ASM rule

If the control flow reaches a Timer, the continuation of the scenario on the regular path (i.e., out_rp) depends on the arrival of a trigger event (i.e., trigger = true) before the timer period expiry (i.e., tocc < timerPeriod), otherwise the timeout path (i.e., out_top) is taken. Figure 30 illustrates the timer ASM rule.

Fig. 30

Timer interleaving ASM rule

1.4 Stub interleaving ASM rule

The stub concept allows for hierarchical decomposition of complex TUCM maps. The TUCM path details can be hidden in separate sub-diagrams called plug-ins, contained in stubs (diamonds) on a path. No time constraints are defined for stubs since a stub is a simple container for plug-ins and the execution of a stub is simply the execution of one of its plug-ins. Once the control reaches a stub, the control passes to the selected plug-in and the execution continues following the TUCM semantics. The set of active connections is updated by adding the incoming connection of the selected plug-in map and by removing the connection entry _k from which the control reached the stub. Figure 31 illustrates the stub ASM rule.

Fig. 31

Stub interleaving ASM rule

1.5 Timed end point interleaving ASM rule

When the control reaches an end point, post-conditions (a list of conditions that must be satisfied once the scenario is completed) are evaluated and if satisfied, the master clock is incremented by the computed delay. Four cases have to be considered, depending on whether the end point is connected to a start point (called a waiting place) and whether it is inside a plug-in map or part of the root map (i.e., the main TUCM map):

• 1. If the end point is part of the root map (i.e., inRootMap = true) and it is not connected to a start point (i.e., out = undefConn), then the incoming connection is removed from the set of active connections and the master clock is incremented by the computed duration.

• 2. If the end point is part of the root map and it is connected to a start point (i.e., a waiting place), then the incoming connection is removed from the set of active connections, the master clock is incremented by the computed duration, and the control passes to the outgoing connection by adding out to the set of active connections.

• 3. If the end point is part of a plug-in and it is bound to a stub exit point (i.e., StubBinding(out) < > undefConn), then out is added to the set of active connections.

• 4. If the end point is part of a plug-in but it is not bound to a stub exit point, then the incoming connection is removed from the set of active connections and the master clock is incremented by the computed duration.

Figure 33 illustrates the ASM interleaving semantics rule of timed end points.

Appendix 2: TUCM-AsmL simulation engine utility methods

Figure 32 illustrates an excerpt of the AsmL implementation of some utility methods that are common to three concurrency variants.

Fig. 32

Excerpt of some utility methods

Appendix 3: AsmL implementation of the simulation engine

Since our focus is on time and concurrency variations, we only illustrate the AsmL rules of responsibilities (durative and involving delay) and AND-forks (used to split a single flow into many concurrent flows).

3.1 AsmL implementation of the interleaving semantics

Figures 33 and 34 illustrates an excerpt of the AsmL implementation of the interleaving semantics.

Fig. 33

Timed end point interleaving ASM rule

Fig. 34

Excerpt of the AsmL implementation of the interleaving variant

3.2 AsmL implementation of the true concurrency semantics

The activ data structure, presented in Fig. 34, is slightly modified to include responsibility’s remaining execution time (i.e., remExecTime). At each step, the master clock MClock is incremented by 1, all active delays greater than 0 are decremented by 1, and constructs reaching a delay equal to zero are selected for execution (Fig. 35).

3.3 AsmL Implementation of the run-to-completion semantics

Figure 36 illustrates an excerpt of the AsmL implementation of the run-to-completion multi-agent variant. When the control reaches an AND-fork, the currently running agent creates new subagents (e.g., let ag = new Agent("Agent-" + z.edge, z.edge, running, me.level, me.current_Stub)) and sets their mode to running, then sets its own mode to inactive. Each new subagent inherits the program for executing timed UCMs (e.g., ag.Program()), and its control starts at the associated outgoing edge of the AND-fork. The order of activation of subagents depends on the delay associated with the subsequent timed UCM constructs of each subagent (i.e., the subagent with the minimal delay is activated first). Each agent runs to completion (i.e., till it reached an end point or an AND-join) before the next agent starts executing.

Fig. 35

Excerpt of the AsmL implementation of the true concurrency variation

Fig. 36

Excerpt of the AsmL implementation of the run-to-completion variant