1 / 20

Presentation by Jason Kealey jkealey@shade University of Ottawa CSI5180

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.

Download Presentation

Presentation by Jason Kealey jkealey@shade University of Ottawa CSI5180

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related