Transcript jkealey_uc2ucm

Automatic conversion of
Use Cases to Use Case Maps
Presentation and tool by
Jason Kealey
[email protected]
1
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
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
2
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]
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
3
What are the drawbacks?
• Natural language is ambiguous
• Informal languages can’t verify completeness
and consistency 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.
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
4
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
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
5
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
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
6
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.
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
7
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
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
8
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
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
9
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.
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
10
Conditions of Extensions and Variations
(From UCEd documentation)
• A simple condition must adhere to the following syntax.
– [determinant] entity verb value
• Possible determinants are: a, an, the.
• Possible verbs are: is, isn’t, is not, are, aren’t, are not, has, hasn’t, has
not, have, haven’t, have not.
• A value may be one of the possible values of the condition
entity, or specified as a general comparison.
– For possible values, the sequence of words used to refer to the
value must be declared as a possible value of the entity in the
domain model.
– For general comparisons, the syntax for value specification must
adhere to the following: comparator value.
• Possible comparators are: >, <, =, <=, >=, <>, greater than, less than,
equal to, different to, greater or equal to, less or equal to.
• A complex condition is a negation, a conjunction or a
disjunction of conditions.
– [(NO|NOT)] condition ((AND|OR) condition)*
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
11
UCEd: Use Case Editor
• A tool that uses simple English to write use
cases
• Eclipse-based tool
• Validates the use cases with a domain model
• Can convert use cases into state machines
• Can execute scenarios on these state machines
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
12
Example UCEd Use Case
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
13
Quick note on Use Case Diagrams
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
14
Use Case Maps
• A graphical notation to express scenarios
running through architectural entities.
• Standardized by the International
Telecommunication Union
• Part of the User Requirements Notation (URN)
• jUCMNav is an Eclipse-based UCM editor
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
15
Example Use Case Map
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
16
Research Goals
• Study the NLP related to understanding the
different Use Cases constructs.
• Express improvements to be made to the NLP tool
used in UCEd.
• Define mappings between Use Case concepts
and Use Case Map concepts.
• Prototype the conversion utility from UCEd use
cases to jUCMNav Use Case Maps.
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
17
Concepts by example – Main Path
Title: General Scenario
Precondition:
jUCMNav is not UCM loaded
Postcondition:
jUCMNav is UCM loaded
Steps:
1. User Jason clicks import button
2. jUCMNav GUI displays file list
3. User Jason selects file
4. jUCMNav ImportExport forwards
request
5. UCEd loads Use Case
6. jUCMNav ImportExport UC2UCM
converts Use Case into Use Case
Map
7. jUCMNav loads UCM
8. jUCMNav GUI displays UCM
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
18
Quick Note – Auto layout
• jUCMNav has an auto layout feature, currently
only a prototype.
• The examples seen here are touched up versions
of these generated UCMs.
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
19
Concepts by example – Alternatives
Title: General Scenario
Precondition:
jUCMNav is not UCM loaded
Postcondition:
jUCMNav is UCM loaded
1. User Jason clicks import button
2. jUCMNav GUI displays file list
3. User Jason selects file
4. UCEd loads Use Case
5. jUCMNav ImportExport UC2UCM
converts UC into UCM
6. jUCMNav loads UCM
7. jUCMNav GUI displays UCM
3. a. User file is not found
3. a. 1. Goto step 2
4. a. UCEd Use Case is not valid
4. a. 1. jUCMNav GUI displays error
message
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
20
Concepts by example – Inclusion
Title: General Scenario
1. User Jason clicks import button
2. jUCMNav GUI displays file list
3. User Jason selects file
4. include Load Use Case
5. jUCMNav ImportExport UC2UCM
converts UC into UCM
6. jUCMNav loads UCM
7. jUCMNav GUI displays UCM
Title: Load Use Case
1. UCEd loads Use Case
2. IF UCEd Use Case is not valid
THEN jUCMNav GUI displays error
message
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
21
Concepts by example – Extensions
Title: General Scenario
Precondition:
jUCMNav is not UCM loaded
Postcondition:
jUCMNav is UCM loaded
1. User Jason clicks import button
2. User Jason selects file
3. include Load Use Case
4. jUCMNav ImportExport UC2UCM
converts UC into UCM
5. jUCMNav loads UCM
ExtensionPoint==> loaded
6. jUCMNav GUI displays UCM
Title: Logging
PART 1. At Extension Point loaded
1. jUCMNav logs usage
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
22
Concepts by example – Timing
Title: General Scenario
Primary Actor: User Jason
1. User Jason clicks import button
2. User Jason selects file
3. BEFORE 60 sec jUCMNav ImportExport
UC2UCM converts UC into UCM
4. jUCMNav loads UCM
5. jUCMNav GUI displays UCM
2. a. AFTER 60 sec
2. a. 1. jUCMNav GUI displays error message
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
23
Possible UCEd NLP Improvements
• Improve the domain extractor by using parse
trees instead of BNF grammar.
• Review use of determinants in conditions.
• Simplify notation required to reference components in
use case steps.
• Support scenario termination and extension
abortion.
• Use indirect object to refine communication model.
• Allow padding verbs as discussed previously
• (UCEd also needs a major usability overhaul)
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
24
Future work
• Current import limitations
– Doesn’t create stub InBindings/OutBindings.
– Can’t jump to later step.
• Illegal in UCEd, but could be implemented.
– Support for Any * alternatives
– Support for operation effects
– jUCMNav currently does not support scenarios
and has limited support for time.
• Causes many issues concerning conflicting
alternatives, especially with time issues.
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
25
Conclusion and references
•
D. Amyot, Introduction to the User Requirements Notation: Learning by Example, Computer Networks,
42(3), June 2003, 285-301.
–
•
http://www.usecasemaps.org/pub/ComNet03.pdf
D. Amyot and G. Mussbacher, “On the Extension of UML with Use Case Maps Concepts”, 2000, 3rd
International Conference on the Unified Modeling Language, York, UK, October 2000. LNCS 1939, 1631
–
•
http://www.usecasemaps.org/pub/uml2000.pdf
J. Kealey, E. Tremblay, J.-P. Daigle, J. McManus, and O. Clift-Noël, “jUCMNav: une nouvelle plateforme
ouverte pour l'édition et l'analyse de modèles UCM“, Actes du 5ième colloque sur les Nouvelles
Technologies de la Répartition (NOTERE 2005), Gatineau, Canada, août 2005, 215-222.
–
•
http://www.site.uottawa.ca/~damyot/pub/notere05.pdf
V. Mencl, “Deriving Behavior Specifications from Textual Use Cases”, Proceedings of Workshop on
Intelligent Technologies for Software Engineering (WITSE04), Linz, Austria, September 2005, 331-341,
–
•
http://nenya.ms.mff.cuni.cz/publications/Mencl-DerivingBehSpec-WITSE04.pdf
S. Somé, “Beyond Scenarios: Generating State Models from Use Cases”, ICSE 2002 Workshop
Scenarios and state machines: models, algorithms, and tools, May 2002.
–
http://www.site.uottawa.ca/~ssome/publis/ICSE02_Scenario_Workshop.pdf
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
26
Open questions
• Is this a success?
– I think that given the most common uses of UC, the
transformation is good. (I have no references for this)
• Is this useful?
– I think that in its current state it is not.
• Need to find industry leader UC editors, if they exist.
• Even then, still not hooked in properly with existing development
processes.
– Would the generation of UC from UCM be an interesting
addition?
• I think so. Keeping both in synch would be even better, but
100% compatibility is unreachable.
Jason Kealey, [email protected], http://www.softwareengineering.ca/jucmnav
27