From Textual Use Cases to Behaviour Specifications

by Vladimir Mencl

Traditionally, use cases are written in plain English to make the requirement specifications accessible to a wide audience. It is widely accepted that automatic processing of textual use cases is not feasible in general; this is considered as a trade-off for the high readability of textual use cases. Nonetheless, there is ongoing research exploring the options to apply linguistic techniques to textual use cases. The Procasor project of the Distributed Systems Research Group at the Charles University in Prague aims to convert textual use cases into event-based behavior specifications, behavior protocols.

The functional requirements for a future system are typically documented with use cases. In the traditional approach, plain English is used for use cases. A strong benefit of this approach is that use cases are comprehendible to a wide audience. A textual use case describes the possible scenarios of the future system, by showing how a particular goal is achieved by the System under design (SuD) and its surrounding actors in a sequence of steps. A step of a textual use case describes an action that is either a request or information passed between an actor and SuD actors, or an action internally processed by SuD. Figure 1 shows a fragment of a textual use case.

An obvious drawback of writing use cases in plain English is the lack of formal tools to reason upon the requirement specifications. Also, the subsequent stages of the software development process have to start with manually processing the use cases – eg, identifying operations of future objects. Luckily, use cases are typically not written in plain natural language. The guidelines for writing use cases significantly restrict the language by asking for simple and uniform sentence structure; a use case sentence should be in active voice, following the simple pattern 'subject – verb – direct object – prepositional phrase'. The subject should be the entity (SuD or an actor) active in the task.

Readily available linguistic tools, eg, the statistical parser developed by Michael Collins at the University of Pennsylvania, permit obtaining the parse tree for a sentence. While the parsing is not 100% reliable (it is statistical parsing), the accuracy improves for simple sentences – as is the case for use cases. The simple sentence structure permits us to obtain the principal attributes of the action described by the sentence from its parse tree. With only a simple domain model (names of entities and a list of conceptual objects), we can identify the entity active in a particular step of a use case. Depending on the role of the active entity in the use case (SuD vs. an actor), it is possible to determine whether the action described by the step is receiving a request, sending a request, or an internal action of SuD.

Figure 2: Parse tree of sentence "Seller submits item description".

We illustrate the approach on the parse tree of step 1 shown in Figure 2. The subject of the sentence, 'Seller', a noun (NN), is the name of an actor involved in the use case. Therefore, the step describes an event (a request) received by SuD from the entity Seller. Subsequently, we estimate the event label for representing the request. In the parse tree, we identify the verb (VBZ) 'submits' and the direct object 'item description'. Depending on conceptual objects captured in the domain model, the words constituting the direct object phrase are selected; here we acquire the event token ?SL.submitItemDescription to represent the step 1. The step 2 describes an action internally performed by the SuD, which we represent with the event token #validateDescription.

In a subsequent stage, we convert the whole use case into a behavior protocol (IEEE Trans. Software Eng. 28(11), developed within our group), a formal method featuring, eg, a decidable compliance relation. We have implemented the conversion outlined here in the Procasor tool (Pro-case stands for Protocol use case). As the tool is employing a statistical natural language parser, the output is only an estimate of the behavior specification; nonetheless, it can prove useful in obtaining an initial design of interfaces of the future system. Our future work focuses on enhancing the transformation to produce matching event tokens for complementary actions; the long-term goal is to apply reasoning available for behavior protocols to detect inconsistencies in use case specifications.

Link:
http://nenya.ms.mff.cuni.cz/

Please contact:
Vladimir Mencl, Charles University Prague/CRCIM,Czech Republic
Tel: +420 2 2191 4232
E-mail: vladimir.menclmff.cuni.cz