Presentation by Jason Kealey jkealey@shade University of Ottawa CSI5180

1

Presentation by

Jason [email protected]

University of OttawaCSI5180

Deriving Behavior Specifications

from Textual Use Cases

Vladimir Mencl, Proceedings of Workshop on Intelligent Technologies for Software Engineering (WITSE04), Linz, Austria, September 2005, 331-341.

Available at: http://nenya.ms.mff.cuni.cz/publications/Mencl-DerivingBehSpec-WITSE04.pdf

2Jason Kealey, [email protected]

Textual Use Cases

• Sequence of steps representing a high level view of the interactions between a system under discussion (SuD) and other entities (actors, users).

• Black-box view of a system

• Used early in the development cycle

• Written in natural language


Example


Why are Use Cases Important?

• Requirements and use cases written in natural language are easily understood by all stakeholders.

• Use Cases are a good starting point when refining the scope and functionality required by the client

• Formal languages cannot be accepted as a contract for a software system [Schwitter and Fuchs, 1996]


What are the drawbacks?

• Natural language is ambiguous

• Informal languages can’t verify completeness and coherence automatically.

• Use cases are (usually) no longer maintained once code has been written. The maintenance effort seems too great and doesn’t appear to offer a good return on investment.


Research Goals

• Employ readily available linguistic tools to construct a behavior specification automatically from textual use cases.

• Automate the conversion from use cases to Pro-cases [a notation to which a previous article presents the manual transformation].

• Refine the mapping between use case steps (NLP) and its equivalent behaviour specification.


Methods

• Use the statistical parser developed by Michael Collins at the University of Pennsylvania.– A new statistical parser based on bigram lexical dependencies

• From the parse tree, determine the equivalent use case concept.

• Tool to create the Pro-cases automatically


Key idea: simplified English

• Key idea: use a subset of English in use case steps. – References to Writing Effective Use Cases and other

books/papers to validate the simplified English to be used.

– Related work: Controlled languages (AECMA Simplified English: aviation industry standard)

• SVDPI pattern:– Subject – verb - direct object – preposition - indirect

object– Example: System sends a new password to the user


Use Case Step

• Three different action types – Communication between an actor and SuD

• Operation request received by SuD from actor (1)– User requests the detailed item description

• Operation request sent by SuD to actor (2)– System sends a new password to the user

– An internal action (SuD) (3)– System validates the user’s credit card number

• A use case step can also represent a redirection to another step


How to find the step’s action type?

• In an SVDPI sentence, the top of the parse tree should show S -> NP VP

• The NP is the subject. If it represents an actor, we have an operation request received by SuD from actor (1).

• Distinguish between (2) and (3) by looking at the indirect object. The actor must not be in possessive case.


Estimating Method Call (1)

• Find the principal verb – Headword of the topmost VP, exception made

of padding verbs.

– If we have a padding verbs (ask/be/select to/choose to), use the next verb.

– Example: System asks the Supervisor to validate the seller

• use validate instead of asks


Estimating Method Call (2)

• Find the representative object– First basic noun phrase subordinate to the principal

verb.

– We do not consider phrases already used as the subject and the indirect object.

– Example: Seller submits item description• Representative object: Item description

– Note: the authors further refine this to conceptual objects only (here: item) and create pseudo-method names (submitItem) but I do not agree with this idea.


Special Actions

• Termination actions: – Use case aborts/terminates/ends

• Goto actions:– Resume with step 2– Retry step 1

• Very simple syntax, will not cover here.


Conditions of Extensions and Variations

• Authors do not aspire to interpret conditions expressed in natural language.

• In pro-cases, conditions play only an informative role.

• In my opinion (and for my project), conditions are important; Stéphane Somé (uOttawa) defines them well in Beyond Scenarios: Generating State Models from Use Cases


Converting to Pro-cases

• Straightforward given their decomposition of use cases but we see they lack conditions


Lessons learned for use case writers

• For textual use cases to be automatically converted into behavior specifications, the generally accepted use case writing guidelines have to be adhered to.

• Simple sentences describing only communications or internal actions.

• Avoid synonyms, referring to context, etc. – Good reference on guidelines: A Controlled Language to Assist

Conversion of Use Case Descriptions into Concept Lattices

• At first glance, these guidelines seem to excessively constrain the writer but they ensure consistent, less ambiguous and easier to read use case requirements specifications.


Future Work

• Interactive tools for use case writing to give immediate feedback to the writer.

• Simulating the generated model, generate test cases from this simulation. – Stéphane Somé’s UCEd tool!

• Extract domain model from use cases• Extract state machine from use cases• Define scenarios• Simulation


What I feel is missing

• Personally, I don’t like pro-cases. – Hard to read, not very intuitive.– Conditions are important for extracting anything else

than the general structure of the use case.– From what I can see on pro-cases, they don’t offer

any inclusion mechanism to help with abstraction other than a macro-substitution.

– Exceptions in included use cases are also an problem inherent with this notation.


Solution? Use Case Maps!


Conclusion

– Vladimir Mencl describes a procedure used to convert textual use cases into a behavior specification

– Simple English is a great compromise in this situation. I would also like to note that Simple English is easy to translate. Anyone want to write a tool to automatically translate use cases?

Documents

Presentation by Jason Kealey jkealey@shade University of Ottawa CSI5180