Presentation by Jason Kealey jkealey@shade University of Ottawa CSI5180

1. 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 Presentation by Jason Kealeyjkealey@shade.caUniversity of OttawaCSI5180

2. 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

3. Example

4. 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]

5. 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.

6. 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.

7. 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

8. 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

9. 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

10. 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.

11. 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

12. 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.

13. Special Actions • Termination actions: • Use caseaborts/terminates/ends • Goto actions: • Resume with step 2 • Retry step 1 • Very simple syntax, will not cover here.

14. 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

15. Converting to Pro-cases • Straightforward given their decomposition of use cases but we see they lack conditions

16. 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.

17. 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

18. 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.

19. Solution? Use Case Maps!

20. 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?