aSoftware Engineering Lab., Department of Computer Science and Information Engineering, National Central University, Chungli 32054, Taiwan
bDepartment of Information Management, Chien-Kuo Institute of Technology, Chunghua, Taiwan
cDepartment of Computer Science and Information Engineering, Fu-Jen Catholic University, HsinChuang, Taipei Hsieu, Taiwan Received 18July 2000; revised 5 March 2001; accepted 22 August 2001
Abstract
Recently, a substantial amount of research activities has been focused on a user-oriented perspective to the development of software systems. One of the key elements in this perspective is the notion of scenarios: a description of what people do and experience as they try to make usage of computer systems and applications. A variety of applications of scenarios has been proposed, for example, to elicit user requirements, or to validate requirements speci®cations. As scenarios are useful for the lifecycle of requirements engineering, it is important to enable veri®cation of these scenarios, especially, to detect any wrong information and missing information that are hidden in scenarios.
However, scenarios are usually stated in an informal way, which impedes the easiness for veri®cation. The focus of this paper is on the use of time Petri-nets (TPNs) to serve as the veri®cation mechanism for the acquired scenarios. Use cases are used to elicit the user needs and to derive the scenarios. Each of the use cases is described from a user's perspective and depicts a speci®c ¯ow of events in the system. After specifying all possible scenarios, each of them can be transformed into its correspondent time Petri-nets model. Through the analysis of these TPNs models, wrong information and missing information in scenarios can be detected. The proposed approach is illustrated by means of a course registration problem domain. q 2001 Elsevier Science B.V. All rights reserved.
Keywords: Scenarios; Use case; Time Petri-nets; Veri®cation; Requirements engineering
1. Introduction
A substantial amount of research and development activ- ities has recently been focused on user-oriented perspective to the development of software systems [4,5,11,18,31]. One key element in this perspective is the notion of scenarios, a description of what people do and experience as they try to make use of computer systems and applications. Nowadays, most of the extant researches related to scenarios focus on applying scenarios on various phases of software develop- ment lifecycle [6,9,16,21,26,31]. A thorough survey on the current practice of scenarios for software development can be found in Ref. [32]. Since the scenario perspective is a potentially valuable enhancement of current software requirement development practices, the scenarios should be correct and valid. Therefore, it is highly important to enable veri®cation of these speci®ed scenarios, especially to detect any wrong information and missing information that are hidden in scenarios.
However, informally speci®ed scenarios usually impede the easiness of the process of veri®cation. In this paper, we
propose the use of time Petri-nets [22], to verify scenarios obtained in the requirements elicitation phase. The existing Petri-nets analysis techniques can be readily applied to verify the correctness of scenarios that are transformed into a Petri-nets model. In the proposed approach, use cases [17] are used to elicit the user needs. Use cases describe the behavior of a system from a user's standpoint by using actions and reactions. For each use case, we specify the possible scenarios that the ways users may act on the system. The scenarios have been seen as the instances of use cases in describing the interaction sequences between the actors and the system. A veri®cation process through the use of time Petri-nets (TPNs) model is supported to check the acquired scenarios by indicating any missing or wrong information hidden in these scenarios. A computer-aided toolset is built for supporting the proposed approach to transform scenarios to time Petri-nets automatically.
In the sequel, we ®rst review the essence of scenarios and time Petri-nets as a background information for our discussion in the next section. The transformation from scenarios to time Petri-nets model is fully discussed in Section 3. The use of a time Petri-nets model to verify scenarios is presented in Section 4. In Section 5, we outline the related work on scenario veri®cation. Finally, we make the conclusion
0950-5849/01/$ - see front matter q 2001 Elsevier Science B.V. All rights reserved.
PII: S0950-5849(01)00184-7
* Corresponding author. Tel.: 1886-34227-151; fax: 1886-34222-681.
E-mail address: [email protected] (J. Lee).
by outlining the potential bene®ts of the proposed approach in Section 6.
2. Background
The generally accepted meaning of the term scenario is that it describes possible ways of using a system to accom- plish functions the user desires [1,14±16,21,32]. It has been widely recognized that scenarios have advantages in terms of re¯ecting the user perspectives, ease of understanding, and communication with users. Subsequently, scenarios have a variety of usages in the software development life- cycle, for example, supporting requirements elicitation and speci®cations generation [7,13,31], facilitating require- ments validation [11], and assisting in architectural design [4,18].
Features of scenarios can be outlined as follows:
² Describing a process or a sequence of actions, not indi- vidual action, i.e. referring to a situation or more precisely, an episode;
² Representing views from a user who stands outside of a system;
² Describing a partial system behavior, not the whole;
² Sometimes explicitly including a certain time interval as the timing constraints.
We use sequence diagrams in Uni®ed Modeling Languages [3] to represent scenarios in our approach. A sequence diagram illustrates its scenario through the inter- actions between objects from a temporal standpoint. Fig. 1 shows a typical sequence diagram, where the rectangle stands for an object and the vertical line represents objects lifeline. Information carried by the horizontal arrows can be events or messages. An event is drawn with a solid arrow- head which focuses on the events occurred within the appli- cation domain without taking the synchronization into account. On the other hand, a message can be classi®ed
into synchronous broadcast and asynchronous broadcast.
A synchronous broadcast message is represented by a full arrowhead, for which the transmitter is blocked and waits until the called object has ®nished processing the message.
In a synchronous call, the return message may be omitted. It is assumed that every synchronous message has a paired return after any subordinate message. An asynchronous broadcast message is represented by a half arrowhead, for which the sender is not blocked and can continue executing.
Opposite to the synchronous call, the return message for an asynchronous call should be explicit. The timing marks are used to indicate particular time points that events or messages occurred, and the temporal constraints within these timing marks can be speci®ed by relational expres- sions.
As was pointed out by Hsia et al. [8,14], the end product of scenarios should be correct, consistent, and validated. In order to verify scenarios, we distinguish two types of fault in scenarios: missing information and wrong information, which are adopted from Ref. [29].
1. Missing information
Once a scenario is stated, each of the employed events and objects (both of source object and target object) in it should be speci®ed. We have identi®ed three cases of missing information:
± The name of an event or an object not speci®ed;
± The source object or destination object not speci®ed;
± No event into or out from an object.
2. Wrong information
Scenarios speci®ed in an unreachable state, which may be caused by contradictory events or wrong timing constraints.
Three cases of wrong information are identi®ed:
² Inconsistent timing constraints either in a single scenario or between two scenarios;
² Non-determinism within scenarios;
² Incorrectly speci®ed timing constraints.
In the proposed approach, the time Petri-nets (TPNs) [2,22] model is used to verify the scenarios. The TPNs model is chosen as the target veri®cation model for that:
(1) TPNs is useful for analyzing current systems whose behaviors are based on explicit temporal parameters; (2) TPNs is an extension of classical Petri-nets model, there- fore, the TPNs can deal with systems with or without temporal properties and (3) TPNs provides a rich analysis capability to formally detect and analyze the faults identi-
®ed in scenarios.
Time Petri-Nets is an extension of Petri-nets [24,25] with temporal constraints. A transition Tj in time Petri-nets is associated with a pair of delay and time-out, [dt(Tj),to(Tj)], in which dt(Tj) means that Tjmust wait for a delay before it
®res, and to(Tj) represents that Tjmust ®re by a time-out. In other words, if Tj is enabled at time T0, then Tj must ®re
Fig. 1. An example of sequence diagram.
during the interval from [T01 dt(Tj)] to [T01 to(Tj)], neither too early, nor too late. If Tjdoes not ®re during the interval, then Tjmust ®re at [T01 to(Tj)]. As shown in Fig.
2, the transition T1is associated with a pair of (1,3) which means that once T1 is enabled, it cannot ®re before three units of time and must ®re by ®ve units of time. A transition will ®re immediately if it is associated with a pair of (0,0) such as T2in Fig. 2. The default timing pair is (0,1) such as T4in Fig. 2. The classical Petri-nets is a special case of TPNs when all timing pairs of transitions are (0,1).
The coarse registration system (CRS) [27] is used as an example to illustrate the proposed approach. The problem description of the coarse registration system is outlined below:
² At the beginning of each semester, students may request a course catalog containing a list of courses offered in the coming semester. Information about each course, such as who the professor is, offered by which department, and what the prerequisites are, etc., will be included to help students make informed decisions.
² The system will allow students to select four courses for the coming semester. In addition, each student will indi- cate two alternative choices in case the student cannot be assigned to a primary selection. Each course should have a maximum of ten students and a minimum of three students. A course offering with fewer students will be cancelled.
² Professors can make a request to see who has signed up for their course offerings.
² For each semester, there is a period of time that students can change their schedules. Students must be able to
access the system during this time to add or to drop courses. Once the registration process is completed for a student, the registration system sends information to the billing of®ce so the student can be billed for the coming semester.
3. Transforming scenarios into time Petri-nets
An overview of our approach is shown in Fig. 3. The user requirements are captured in use cases and scenarios from the user's point of view. By an automatic transformation from scenarios to time Petri-nets model, we can have fault-free scenarios through the analysis of the time Petri- nets model in an iterative process.
3.1. Use cases construction
There are two steps involved in constructing use cases 1 [17]: identify actors and specify use cases. An actor repre- sents a role played by a person or a thing that interacts with the system. Actors are determined by observing the direct users of a system, those who are responsible for its use or its maintenance. A use case corresponds to a speci®c kind of system use. It is an image of a system's functionality, which is triggered in response to the simulation of an external actor. The same physical person may play the role of several actors which act on different use cases. Additionally, several use cases may all play on the same actor.
To represent the actors and use cases, we adopt use case diagrams in UML [10,23]. A use case diagram (Fig. 4) is a graph of actors, a set of use cases enclosed by a system boundary, communication (participation) associations between the actors and the use cases. The set of function- ality of a given system is determined through the study of the functionality requirements of each actor, expressed in
Fig. 2. An example of time Petri-nets.
Fig. 3. An overview of the proposed approach.
1 A goal-driven approach to constructing use cases can be found in Ref.
[19].
Fig. 4. The use case diagram for course registration system.
the use cases in the form of families of interaction. Actors are represented by little stick people who trigger the use cases, which are represented as ellipses contained within the system.
There are four main categories of actors:
² Primary actors: people who directly use the main system functions. In the case of a course registration system (CRS), the students and professors are the primary actors.
² Secondary actors: people that perform administration or maintenance tasks. In the case of CRS, the registrar plays as a secondary actor.
² External hardware: the unavoidable hardware devices that are part of the application domain and must be used. It has nothing to do with the computer on which the application is executed, but pertains to the other hard- ware peripherals.
² Other systems: the other system with which the system must interact. In the case of the CRS example, the billing system plays as the counterpart system to interact with the target system.
We have identi®ed four actors in the CRS example:
student, professor, registrar and billing system. In Fig. 4, the student and billing system perform the register for courses use case and the professor initiates the request course roster use case. The register for courses and
request catalog use cases are both associated with the student actor.
For each use case, as suggested by Rumbaugh [28], a clear description written in natural language should be docu- mented to express what happens from the user's point of view. Fig. 5 shows a partial description of register for courses use case.
3.2. Scenarios construction
Use cases are determined by observing and specifying, actor by actor, the interaction sequence (i.e. scenarios) from the user's standpoint. They are described in terms of the information exchanged and the way a system is used. A use case groups a family of usage scenarios according to a functional criterion. A scenario is seen as an instance of a use case. A two-stage process for specifying scenarios [21]
is adopted in our approach:
1. To develop scenarios to focus on the major system beha- vior, without regard to what should be the objects of the system. Scenarios in this stage are written in narrative text format. The analyst can use these scenarios to communicate with the users in order to validate the understanding of the system. In this stage, a scenario tree is used to identify possible scenarios.
2. To re®ne these scenarios to focus on the interaction
Fig. 5. A description for register for courses use case.
between objects of the system and the time sequence of these interactions. Scenarios in this stage are represented in sequence diagrams.
Fig. 6 shows a speci®c scenario for a student to use the system to create a new schedule. For a scenario-based approach, it is required to specify all scenarios as complete as possible. However, it is dif®cult to ensure that all possible scenarios have been speci®ed. To deal with this problem, we use the scenario tree [14] to explore all possible scenarios. A scenario tree is initialized from an actor's view on a speci®c use case. Each node in the scenario tree represents a state as the actor perceives it. The root indicates the initial system state. The arc thus shows the event between the actor and the system. Fig. 7 shows a scenario tree from the student's view on register for courses use case. Each path in the scenario tree represents a speci®c scenario. For example, an alterna- tive course scenario in Fig. 6: `Peter enters his student ID
number 84345005 and the system validates the number. The student ID is invalidated' can be speci®ed. Therefore, all the possible scenarios of the target system can be identi®ed through exploring all possible paths in a scenario tree.
Fig. 6. A scenario for creating new schedule.
Fig. 7. A scenario tree for a student to act on the register for courses use case.
Fig. 8. The sequence diagram for the creating new schedule scenario.
Scenarios represented in a natural language is easy for the user and analyst to communicate with each other. On the other hand, scenarios represented in sequence diagrams depict the explicit sequence of events. The sequence diagram displays interactions between the entity objects from a temporal standpoint, where the entity object is an object participating in this scenario. An entity object captures information needed for a system to handle over a long period of time, which generally re¯ects a real world entity. Referring to the course for register use case, we identi®ed several entity objects such as: student, course, schedule, and so on. A sequence for the creating new sche- dule scenario is shown in Fig. 8. The sequence diagrams are used to correspond to the documentation of use cases, to focus on the description of interactions between entity objects. An entity object is represented by a rectangle and a vertical bar called object's lifeline. The information carried by the arrows corresponds to events that occur within the application domain.
3.3. Transformation of scenario to time Petri-nets model In the sequence diagram, an object's lifeline is used to represent the partial behavior of one object. The described behavior consists of a sequence of states and events that the object performs. The object's lifeline is thus transformed into a set of places and transitions in sequence, to represent
the states and events, respectively. A sequence diagram shows the interactions among the participating objects arranged in time sequence, thus the transformation can be discussed in three ways: object lifeline, interactions between objects, and the timing constraints. Detailed transformation rules are described below.
3.3.1. Expressing object lifeline in sequence diagram 3.3.1.1. Object and its lifeline The existence of an object at a particular time is represented in the object's lifeline.
The vertical dimension shows the time ordering, where the events generated or received at the lifeline are in sequence.
An object's lifeline can thus be treated as a sequence of states and state transitions caused by generating and receiv- ing events. Therefore, an object lifeline can be transferred into a set of places and transitions, where each place repre- sents one state of that object at a particular time and a transition represents a state transition. For example, a sequence diagram (Fig. 1) is transformed into the correspon- dent time Petri-nets model (Fig. 9), by which the places Pa,1
to Pa,3are represented as the states of object-A's lifeline, and the transitions Ta,1 and Ta,3 are represented as the events (generating or receiving events) within this lifeline. The token in the TPNs model is used to pinpoint an object at a particular state. A token can be moved from one place to the next by ®ring an enabled transition that can be used to show the state changed.
3.3.1.2. Initial state of an object When a TPN's model transferred from a sequence diagram, a token will be placed in the initial place of an object' lifeline to indicate the initial state of that object. From the sample example (Fig. 9), Pa,1, Pb,1 and Pc,1 are the initial places of objects A, B and C, respectively. Therefore, one token will be placed in each place.
3.3.2. Expressing interactions between objects in sequence diagrams
Here, we discuss the transformation of interactions between objects, i.e. the events occurring in sequence, the
Fig. 9. The Petri-nets model transferred from sequence diagram in Fig. 1 which concerns without timing constraints.
Fig. 10. The transformation of synchronous message broadcasting.
events occurring in symchronization broadcast, the events occurring in concurrence, and the events occurring on itself.
3.3.2.1. Sequence The events occur in time ordering that explicitly show the latter event must occur until the former one occurred. The transferred TPNs model can easily represent the ordering relationship. For example, referring to Fig. 9, the object-A generates an event event-1 to the object-B, and the object-B generates an event event-2 to the object-C. The two events are occurring in sequence.
In this transformation, Pab,1and Pbc,1are the dummy places for bridging Ta,1and Tb,1, and Tb,2and Tc,1. When the TPNs model executes, the tokens in Pa,1 and Pb,1 will move in sequence as the sequence diagram de®ned.
3.3.2.2. Synchronization broadcasts As mentioned in Section 2, a synchronous message is sent from an object and implicitly received a return message from the destination object. The concept of transformation for a synchronous message broadcast is similar to the transformation of events occurring in sequence. However, one return message will be automatically added to explicitly constrain the sender object is blocked and wait until the called object has ®nished processing the message. Fig. 10 shows the transformation of the synchronous messages, by which the places Pa,2, Pb,2and Pba,1, and transitions Ta,2and Tb,2 are automatically generated to represent the return message return-m1.
On the other hand, an asynchronous message will not block the caller object and another message can continue sending. The return message for an asynchronous message is explicitly depicted in sequence diagram. The transformation of asynchronous broadcasting is shown in Fig. 11.
3.3.2.3. Concurrency Objects can generate events to different objects in concurrency. There are two ways of concurrence in a sequence diagram: an object generates the same events to different objects and an object generates different events to different objects. The former, for example (Fig. 12), is that object-B sends the event E2 to both object-A and object-C. The action of sending E2 can be translated as a single transition Tb,2
which has the connections to object-A and object-C through Pba,1and Pbc,1, respectively. After ®ring Tb,2, both of Pba,1and Pbc,1will receive a token to re¯ect the occurring event.
The second kind of concurrency, for example (Fig. 13), is that object-B sends E2 to object-A and E3 to object-C concurrently. To deal with this situation, we create a dummy transition Tb,2 and its related places Pb,3, Pb,4, Pb,5
and Pb,6to explicitly show that the two messages are occur- ring in concurrency. The transitions Tba,1 and Tbc,1 are created to represent the E2 and E3, respectively.
3.3.2.4. Self-delegation An object sends an event to itself
Fig. 11. The transformation of asynchronous message broadcasting.
Fig. 12. Case1: sending the same event to different objects. Fig. 13. Case2: sending the different events to different objects.
which is called self-delegation. Refer to the creating new schedule scenario (Fig. 8), the scenario object sends a check existing schedules event and returns to itself while receiving a request to create new schedule event. A general transformation rule to convert self-delegation is shown in Fig. 14, where transitions T1and T2represent the event to send and to receive the same event. The algorithm below will transform a sequence diagram into its corresponding time Petri-nets.
Algorithm 1. (Transforming sequence diagram into the time Petri-nets)
1. For each object in the sequence diagram
± If there are m states in an object lifeline, insert m places in TPNs model.
± If there are n diverse events connected to the object, insert n transitions in TPNs model.
± Connect these places and transitions in the lifeline based on the temporal ordering.
± Place a token in the initial place.
2. For each event in the sequence diagram
± If the read event is a synchronous message
± Insert a return message into the sequence diagram.
± If there is an event sent from the source object into the destination object
± Insert a dummy place between the two transitions w.r.t. the source and destination object.
± Connect the source transition, dummy place, and the destination transition in sequencing.
± Else if there are two same events sent from a source object into different destination objects at the same time, for each destination object
± Insert a dummy place between the source transition and the destination transition.
± Connect the source transition, dummy place, and the destination transition.
± Else if there are two or more different events sent from a source object into different destination objects at the same time, for each event
± Break the connection between source transition and place.
± Insert a source dummy transition and connect the source dummy transition and the source place.
± Insert a transition and three places including one dummy place and two concurrent places.
± Connect the source transition to the dummy place.
± Connect the dummy place to the two concurrent places.
± Connect the transition to the two concurrent places.
± Connect the concurrent place to the destination transi- tion.
± Connect another concurrent place to the source dummy transition.
± Else if there is an event sent from the source object to itself, no connection to other objects.
3.3.3. Expressing timing constraints
Two cases of representation of timing constraints are identi®ed in a sequence diagram. In the ®rst case, the timing constraint is speci®ed to restrict the delay time of an event (Fig. 15). In the second case, the timing constraint is speci-
®ed to constrain the time interval between two events (Fig.
16). The transformation of timing constraints uses the pair of delay-time (dt) and time-out (to) to associate with the transitions. Consider the ®rst case, we attach the timing pair (0,0) on the transition Ta,1 to indicate the starting time, and attach the timing pair (dt,to) on the transition Tb,1 to indicate the arrival time. To deal with the second case, we attach the timing pair (0,0) on the transitions where located within the time interval except the transition Tb,2 is set as (dt,to). In sequence diagram, the timing constraints can be speci®ed as four kinds of predicate by users, where a, b are timing marks and t is a time value and (ti,tj) is a time interval: (1) {b 2 a . t}, (2) {b 2 a , t}, (3) {b 2 a t} and (4) {ti, b 2 a , tj}. Algorithm 2 will transform the timing constraints into the timing pairs.
Fig. 14. The self-delegation and its transformation in TPNs.
Fig. 15. The transformation of timing constraint on delay-time of an event.
Fig. 16. The transformation of timing constraint on time interval between two events.
Algorithm 2. (Transforming timing constraint into timing pairs)
1. Set i 0, (dt,to) as the timing pair of delay-time and time-out, a and b are timing mark in a lifeline, where b 2 a . 0.
2. For all timing constraints in a sequence diagram.
3. Set tias a time value and (ti1,ti2) as a time interval.
± If b 2 a . ti, then (dt,to) (t,1).
± Else if b 2 a , ti, then (dt,to) (0,t).
± Else if b 2 a ti, then (dt,to) (t,t).
± Else if ti1, b 2 a , ti2, then dt; to ti1; ti2:
4. Read the next timing constraint.
5. Increase i.
6. Continue the previous steps until all timing constraints have been considered.
Note that, if there is no timing constraint in the sequence diagram, the timing pairs which are associated with the transitions of TPNs are all set to (0,1). However, if there is at least one timing constraint in the sequence diagram, the irrelevant timing pairs are set as (0,0), which is due to the nature of time Petri-nets.
4. Verifying scenarios by analyzing TPNs models A variety of Petri-nets analysis techniques can be applied to a time Petri-nets model to detect such faults as missing information and wrong information.
4.1. Detecting the missing information in scenarios We have identi®ed three kinds of missing information to pinpoint incomplete scenarios:
² The name of an event or object not speci®ed: an event or
be received by a destination object. If they are missing, the tokens in TPNs model cannot pass correctly. To verify the related places that are transformed from the events can detect this kind missing.
² No event in or out to an object: in a scenario, an object should interact with other objects to exchange informa- tion. It is unusual that an object only interacts with itself, or even worse no interaction with other objects. To verify whether any isolated subnet of TPNs exists, can detect this kind missing information.
A summary of the missing information that can be detected in the scenarios is outlined below:
1. For all places and transitions in time Petri-nets model,
± If there is a place without a particular name, print out
`object without a name'.
± If there is a transition without a particular name, print out `event without a name'.
2. For all places in time Petri-nets model,
± If there is a place that is not an initial place and has no input arc, print out `no destination object speci®ed for an event'.
± If there is a place that is not a ®nal place and has no output arc, print out `no source object speci®ed for an event'.
3. For the time Petri-nets, traverse all places and transitions,
± If there exists any place or transition that cannot be traversed, print out `an object lifeline is isolated in the sequence diagram'.
4.2. Detecting wrong information in scenarios
We have identi®ed three kinds of wrong information for examining incomplete scenarios:
1. Inconsistent timing constraints
When two or more timing constraints are speci®ed in a system, we should check whether any contradiction exists between these timing constraints. Two kinds of inconsistency of timing constraints that may occur in scenarios are further distinguished:
± Inconsistency in intra-scenario: this kind of inconsis- tency is caused by specifying contradictory timing constraints in a scenario. Referring to Fig. 17, two timing constraints are set as {c 2 b . 20, d 2 a , 15}. The ®rst and second constraints are contradictory to each other and are caused by the time interval from b to c and is included in a to d.
By applying reachability analysis on time Petri-nets
Fig. 17. An alternative scenario from the creating new schedule scenario.
models transferred from the scenario, we can detect this contradiction. Fig. 18shows the reachability tree for scenario-1.2. Two timing pairs are attached on markings which are generated from the two timing constraints, respectively. By comparing the two sequences of timing pairs, we can pinpoint the contra- diction: if the constraint {c 2 a . 20} is satis®ed, the delay time of marking M12 will violate the time-out restriction of constraint {d 2 a , 15}. Algorithm 3 shows how to detect the inconsistency in intra- scenario.
Algorithm 3.
(Detecting the inconsistency in intra-scenario)
1.1. Reading the reachability tree RT 2 S 2 i for the scenario-i.
1.2. Set the timing constraints as tcito tcm.
1.3. For every timing constraint tci, calculating the timing pair (delay time td, time-out to) for each marking.
1.4. While (not end of marking) 1.5. {If (td of tci. to of tcj) then
1.6. {Print out `the timing constraint i is contradictory to timing constraint j'.
1.7. Exit.}}
± Inconsistency in inter-scenarios: specifying two different values on the same interval of two events may cause this inconsistency. Referring to Figs. 8and 17, the vents of input student ID and student ID are both identi®ed in scenario-1.1 and scenario-1.2. Considering a new timing constraint {b 2 a . 5} in scenario-1.2, the timing constraint b 2 a , 10 in scenario-1.1 restricts the time interval from a to b to be less than 10 s, meanwhile, the newly added constraint in scenario-1.2 restricts the same time interval to be greater than 5 s. Therefore, the two timing constraints are inconsistent with each other.
Another case of inconsistency that can also be detected, is a same time interval in different scenarios has a differ- ent time value. Referring to the same example, we add a new timing constraint {c 2 b , 10} into the scenario- 1.2. Apparently, this constraint is inconsistent with {c 2 b , 20} in scenario-1.1. By applying reachability analysis, we can ®nd out the inconsistent information.
Algorithm 4 detects the inconsistency in inter-scenarios.
Algorithm 4.
(Detecting the inconsistency in inter-scenarios)
1.1. Reading the reachability tree RS 2 S 2 i and RT 2 S 2 j for the scenario-i and scenario 2 j, respec- tively.
1.2. For every timing constraint, calculating the timing pair (delay time td, time-out to) for each marking.
1.3. Comparing the places in marking of RT 2 S 2 I and RT 2 S 2 j.
1.4. If (Mk(RT 2 S 2 i) # Mk(RT 2 S 2 j) then 1.5. {For m 1 to p
1.6. For n 1 to q
Fig. 18. The reachability analysis for schedule already existed scenario.
Fig. 19. Non-determinism is occurred in different scenarios.
Fig. 20. The reachability trees transferred from scenarios in Fig. 19.
2. Non-determinism within scenarios
A non-deterministic behavior occurs when there is a same event sent from the same object with the same timing constraints, but with different objects to receive this event. For example, see Fig. 19, in scenario-1, the object-2 received event-1 from object-1, and sent event-2 back to object-1. However, in scenario-2, the object-2 receives event-1 from object-1 and sends event-2 to other object, i.e. object-3. By applying the reachability analysis, we can detect the non-deterministic behavior.
Fig. 20 shows the two reachability trees transferred from the two sequence diagrams, respectively. Refer to Fig.
20, both RT 2 S 2 1 and RT 2 S 2 2 have the same
®ring sequence of transitions Ta,1, Tb,1and Tb,2, and the places of markings M0, M1, M2of RT 2 S 2 1 is a subset of places of markings in RT 2 S 2 2, which means the two scenarios have the same partial behavior. However, from the marking M3, the places (Pa,2,Pb,3,Pba,1) of M3in RE 2 S 2 1 is not included in M3(Pa,2,Pb,3,Pbc,1,Pc,1) in RE 2 S 2 2 any more, which means the objects that receive the same event are different. Therefore, a non- deterministic behavior can be identi®ed by comparing the two reachability trees. A warning is reported to indicate the wrong information.
Non-determinism is sometimes desirable in the speci®ca- tion level [12]. For example, to make a choice of the received objects randomly. In this situation, the non- determinism should be left in the speci®cations.
Therefore, the non-deterministic can be treated as a warning, and not an error; a similar viewpoint is also noted in Ref. [8]. Algorithm 5 is to detect the non-deter- minism in different scenarios.
Algorithm 5.
(Detecting the non-determinism within scenarios)
2.1. For each use case 2.2. For i 1 to n 2.3. For j i to n
2.4. If i ± j then read scenario-i and scenario-j then
± If the same timing constraints exist in scenario i and scenario j
± Read reachability trees RT 2 S 2 i and RT 2 S 2 j
± Compare the sequence of markings and ®ring transi- tions
± If Tk RT 2 S 2 i Tk RT 2 S 2 j and Mk RT 2 S 2 i # Mk RT 2 S 2 j then
± {Print out a warning message `non-determinism has occurred in scenario-i and scenario-j'}
logical inconsistency, such as {b 2 a , 1} or {10 , b 2 a , 5}. This can be identi®ed by checking all the transi- tions' timing pairs.
5. Related work
It is widely recognized that verifying scenarios is impor- tant in the software development based on the user-oriented perspective. As a result, several researches [8,14,20] have reported successful progress towards the analysis of scenar- ios.Lee et al. [20] proposed to use Constraint-based Modular Petri-nets (CMPNs) to integrate and analyze use cases. A systematic procedure is developed to convert the use cases stated in informal language to a CMPN model. To facilitate the transformation, the action-condition table (ACT) is used to represent use cases, which has carried more precise infor- mation on use cases. Then, the ACTs are converted into CMPNs. In the transformation, an individual use case is modeled by a constraint net of CMPNs. The initial state of the use case is represented as a start place, and the events are represented as transitions in the net. Events occurring in multiple use cases, identi®ed in ACT, are declared as shared transitions. The output places connected to a shared transi- tion may need to be shared by either one of the two condi- tions that hold: successor events are the same or distinct successor events occurred, but they occur selectively.
While the use cases are transformed into CMPNs, the Petri-nets analysis techniques can be used to analyze the incompleteness and inconsistency properties of these use cases. Two cases are identi®ed for checking the inconsis- tency: if a set of transitions exists that are never enabled, and if there is a deadlock. Meanwhile, four situations are iden- ti®ed for checking the incompleteness: non-determinism, missing toggle place references, toggle place values never modi®ed, and slices with no shared transitions. These cases can be detected by using reachability analysis or others CMPNs analysis skill.
Hsia et al. [14] used a BNF-like grammar to formally describe scenarios. Scenarios, through elicitation phase, are represented as scenario trees and scenario schema. A scenario tree is constructed to describe and represent all the scenarios for a particular user view. Thus, a user view is a set of speci®c scenarios as seen by a certain user group.
The users in a group have employed the system in a like manner. It describes the user behavior as he interacts with the system. A scenario schema is a sequence of event types that accomplishes a functional requirement. While scenario trees are de®ned, each of them is converted into an equivalent
regular grammar. This grammar is used to construct a conceptual state machine that models system behavior from a particular user view. The grammar and its corre- sponding conceptual state machine compose the abstract formal model, which the analyst uses to capture, represent and display system behavior in terms of scenarios. Based on the abstract model, the properties of inconsistencies, redun- dancies and internal incompleteness in the scenarios can be automatically veri®ed. However, Hsia's approach is effec- tive only when applied to a small number of scenarios.
Some and his colleagues [8,30] took a slightly different view, seeing scenarios as a sequence of operations and time of occurrence. A semi-formal textual and graphical language is de®ned for representing scenarios. Timed auto- mata are used as a target formal method to interpret the scenarios. This algorithm synthesizes timed automata from scenarios with timing constraints. A scenario-restricted situation is a set of conditions that must hold in the system and environment prior to the scenario execution. Possible times of occurrence of operations may also depend on temporal constraints. An automatic generation algorithm is presented for constructing the speci®cations from scenar- ios, which reduces to the merging of partial behaviors into global speci®cations.
Compared with all these approaches (Table 1), the use of TPNs to verify scenarios offers three important bene®ts:
1. Makes it easy to handle scenarios with or without timing constraint.
2. Helps in detecting temporal inconsistencies in intra- scenario and inter-scenarios.
3. Serves a dynamic view to monitor the scenarios execu- tion through TPNs.
6. Conclusions
In this paper, we present an approach to verifying scenar- ios with time Petri-nets. Use cases are used to elicit the user requirements from the user's standpoint. Scenarios viewed the instance of use cases that describe the interaction sequences between the actors and the system. A veri®cation mechanism is proposed to check the acquired scenarios by indicating any missing information or wrong information hidden in these scenarios. Our approach is deadlock-free due to the fact that scenarios represented in sequence diagrams are constrained by the time line, and that no scenario integration is performed.
The main bene®ts of using TPNs in expressing scenarios and for veri®cation are that: (1) TPNs provides a dynamic view to monitor the scenarios execution and (2) the veri®ca- tion of scenarios can be performed through the reachability analysis on TPNs models. However, TPNs is somewhat limited in ef®ciently dealing with the scalability of reach- ability analysis.
The proposed approach offers two major bene®ts: (1) the transformation of scenarios to time Petri-nets model and the analysis of these models are automatically implemented by a CASE tool to facilitate the indication of errors in require- ments as early as possible to reduce the cost of software development and (2) the proposed approach can be
Table 1
Scenarios veri®cation. A comparison
[LCK98] [HSGKTC94] [DSVS99] Our work
Scenario representation Use case Scenario scheme Textual and graphical language Sequence diagram
Veri®cation mechanism CMPNs BNF-like grammar and
conceptual state machine Timed automata Time Petri-nets
Dealing with time properties No No Yes Yes
Missing information 1. Missing toggle place
references 1. System state changed
w/o the occurrence of any event
1. Temporal constraints
incomplete 1. The name of
event or object not speci®ed.
2. Toggle place values never
modi®ed. 2. Behavior incomplete. 2. The source or
destination object not speci®ed.
3. No event in or out to an object.
Wrong information 1. A set of transitions are never
enabled. 1. Reachability 1. Non-determinism 1. Timing
constraints inconsistentlyÐ inter- and intra- inconsistently 2. Deadlock 2. Non-determinism 2. Contradictory of delays and
temporal specifying in different scenarios
2. Non-determinism
3. Non-determinism 3. Exactly one initial and one termination state and they are the same
3. Invariant violation 3. Incorrectly speci®ed timing constraints
functional requirements to make the engineering of user requirements complete.
² To optimize the time Petri-nets models [2,22] trans- formed from sequence diagrams to improve the ef®- ciency of the veri®cation process in the elicitation phase.
Acknowledgement
This research is sponsored by the National Science Council, Taiwan (R.O.C.) under the grant NSC 89-2213- E-008-070.
References
[1] K.M. Benner, M.S. Feather, W.L. Johnson, L.A. Zorman, Utilizing scenarios in the software development process, in: N. Prakash, C.
Rolland, B. Pernici (Eds.), Information System Development Process, Elsevier Science Publishers BV, North-Holland, 1993, pp. 117±134.
[2] B. Berthomieu, M. Diaz, Modeling and veri®cation of time dependent systems using time petri nets, IEEE Transactions on Software Engi- neering SE-17 (3) (1991) 259±273.
[3] G. Booch, J. Rumbaugh, I. Jocobson, The Uni®ed Modeling Language User Guide, Addison-Wesley, Reading, MA, 1999.
[4] R.J.A. Buhr, Use case maps as architectural entities for complex systems, IEEE Transactions on Software Engineering 24 (12) (1998) 1131±1155.
[5] J.M. Carroll, The scenario perspective on system development, in:
J.M. Carroll (Ed.), Scenario-Based Design: Envisioning Work and Technology in System Development, John Wiley, New York, 1995, pp. 1±17.
[6] J.M. Carroll, M.B. Rosson, G. Chin Jr., J. Koenemann, Requirements development in scenario-based design, IEEE Transactions on Soft- ware Engineering 24 (12) (1998) 1156±1170.
[7] J. Desharnais, R. Khedri, M. Frappier, A. Mili, Integration of sequen- tial scenarios, Lecture Notes in Computer Science1997, pp. 310±326.
[8] R. Dssouli, S. Some, J. Vaucher, A. Salah, A service creation envir- onment based on scenarios, Information and Software Technology 41 (1999) 697±713.
[9] W. Dzida, R. Freitag, Making use of scenarios for validating analysis and design, IEEE Transactions on Software Engineering 24 (12) (1998) 1182±1196.
[10] M. Fowler, K. Scott, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, Reading, MA, 1997.
[11] P. Haumer, K. Pohl, K. Weidenhaupt, Requirements elicitation and
Engineering 3 (1998) 202±218.
[14] P. Hsia, J. Samuel, J. Gao, D. Kung, Y. Toyoshima, C. Chen, Formal approach to scenario analysis, IEEE Software (1994) 33±41 (March).
[15] P. Hsia, A. Yaung, Screen-based scenario generator: a tool for scenario-based, Proceedings of the 22nd Hawaii International Confer- ence on Systems Science1988, pp. 455±461.
[16] C.H. Holbrook III, A. scenario-based, A scenario-based methodology for conducting requirements elicitation, ACM SIGSOFT Software Engineering Notes 15 (1) (1990) 95±104 (January).
[17] I. Jacobson, Object-Oriented Software Engineering, Addison-Wesley, Reading, MA, 1992.
[18] R. Kazman, G. Abowd, L. Bass, P. Clements, Scenario-based analysis of software architecture, IEEE Software (1996) 47±55 (November).
[19] J. Lee, N.L. Xue, Analyzing user requirements by use cases: a goal- driven approach, IEEE Software (1999) 92±101 (July/August).
[20] W.J. Lee, S.D. Cha, Y.R. Kwon, Integration and analysis of use cases using modular Petri-nets in requirements engineering, IEEE Transac- tions on Software Engineering 24 (12) (1998) 1115±1130.
[21] M. Lubars, C. Potts, C. Richter, Developing initial ooa models, Proceedings of the 15th International Conference on Software Engi- neering, 1993, pp. 255±264.
[22] P. Merlin, D.J. Faber, Recoverability of communication protocols, IEEE Transactions on Communication COM-24 (9) (1976) 1036±
1043.
[23] P.A. Muller, Instant UML, Wrox Press, Paris, France, 1997.
[24] T. Murata, Petri nets: properties, analysis and application, Proceed- ings of the IEEE 77 (4) (1989) 541±580.
[25] J.L. Peterson, Petri Net Theory and the Modeling of System, Prentice- Hall, Englewood Cliffs, NJ, 1981.
[26] C. Potts, K. Takahashi, A.I. Anton, Inquiry-based requirements analy- sis, IEEE Software 11 (2) (1994) 21±32.
[27] T. Quatran, Visual Modeling with Rational Rose and UML, Addison- Wesley, Reading, MA, 1998.
[28] J. Rumbaugh, Getting started: using use cases to capture require- ments, Journal of Object-Oriented Programming 7 (5) (1994) 8±12.
[29] G.M. Schneider, J. Martin, W.T. Tsai, An experimental study of fault detection in user requirements documents, ACM Transactions on Software Engineering and Methodology 1 (2) (1992) 188±204.
[30] S. Some, R. Dssouli, J. Vaucher, From scenarios to timed automata:
building speci®cations from users requirements, Proceedings of Asia Paci®c Software Engineering Conference, Brisbane, Australia1995, pp. 48±57.
[31] A.G. Sutcliffe, N.A.M. Maiden, S. Minocha, D. Manuel, Supporting scenario-based requirements engineering, IEEE Transactions on Soft- ware Engineering 24 (12) (1998) 1072±1088.
[32] K. Weidenhaupt, K. Pohl, M. Jarke, P. Haumer, Scenarios in system development: current practice, IEEE Software (1987) 34±45 (March/
April).
