Beyond Scenarios: Generating State Models from Use Cases An approach for the synthesis of State transition graphs from Use Cases Supporting Use Cases Based Requirements Simulation Presented by Chin-Yi Tsai UCEd

2 Outline Introduction Introduction Use Cases Use Cases Requirements Engineering Processes Requirements Engineering Processes From Use Cases to State Models From Use Cases to State Models Use Cases Simulation Use Cases Simulation Conclusion Conclusion

3 Introduction Use Cases describe possible interactions involving a system and its environment. Use Cases describe possible interactions involving a system and its environment. Represent user’s requirement Represent user’s requirement State models generation from Use Cases. State models generation from Use Cases. A formalization of use cases A formalization of use cases A natural language based syntax for use cases description (condition) A natural language based syntax for use cases description (condition) An algorithm that incrementally compose a set of use cases as finite state transition machine An algorithm that incrementally compose a set of use cases as finite state transition machine Simulation/Validation Restricted form

4 Use Cases A use case consists of intertwined scenarios, each scenario being a possible sequence of interactions. A use case consists of intertwined scenarios, each scenario being a possible sequence of interactions. Primary scenario (normal) Primary scenario (normal) Secondary scenario (alternative, error) Secondary scenario (alternative, error) A use case can be seen as a tuple A use case can be seen as a tuple [Title, Precondition, Steps, Postcondition] [Title, Precondition, Steps, Postcondition] Each step in Steps is a tuple Each step in Steps is a tuple [SCond, Oper, Ext] [SCond, Oper, Ext]

5 Domain Model A domain model is an integral part of requirements in approaches such as the Unified Software Development Process. A domain model is an integral part of requirements in approaches such as the Unified Software Development Process. Use a domain model as a complementary part of use case description Use a domain model as a complementary part of use case description A domain model is a high level class model that captures the most important types of object in the context of system. A domain model is a high level class model that captures the most important types of object in the context of system. relationship relationship Use case diagram Domain/conceptual model Sequence diagram

6 Operation Operation Added-conditions Added-conditions Withdrawn-conditions Withdrawn-conditions Domain model

7 Natural Language Representation of Use Cases Use a form of natural language for conditions and operations Use a form of natural language for conditions and operations Conditions describe situations prevailing within a system and environment. Conditions describe situations prevailing within a system and environment. A condition is written as predicative phrase, seeking a certain quality on an entity of the domain model A condition is written as predicative phrase, seeking a certain quality on an entity of the domain model Operations are active sentences in which a component perform an action given as verb. Operations are active sentences in which a component perform an action given as verb. state

8 DCG (Definite Clause Grammar) DCGs are contextural grammars used for natural language description. DCGs are contextural grammars used for natural language description. The DOG references the domain model through the predicates concept, concept_attribute, discrete, and pobbile_value. The DOG references the domain model through the predicates concept, concept_attribute, discrete, and pobbile_value. Concept(“User”) Concept(“User”) Condition description

9 concept(“User”) concept(“User”) concept(“PM System”) concept(“PM System”) concept_attribure(“User”, “number of attempts”) concept_attribure(“User”, “number of attempts”) concept_attribute(“User”, Card”) concept_attribute(“User”, Card”) discrete(“Card”) discrete(“Card”) possible_value([“User”, “Card”], “inserted”) possible_value([“User”, “Card”], “inserted”) possible_value([“User”, “Card”], “regular”) possible_value([“User”, “Card”], “regular”)

10 Requirements Engineering Processes Use cases based requirement engineering process Use cases based requirement engineering process

11

12 From Use Cases to State Models Generate a hierarchical type of finite state transition machines form use cases. Generate a hierarchical type of finite state transition machines form use cases. Operation can have withdrawn-conditions and added- conditions. (expressed as predicates on the domain entities) Operation can have withdrawn-conditions and added- conditions. (expressed as predicates on the domain entities) Each state is defined by characteristic predicates which hold in it. Each state is defined by characteristic predicates which hold in it. Two state are identical if they have the same characteristics predicates. Two state are identical if they have the same characteristics predicates. A state s b is a sub-state of a state s a, if its characteristics predicates include those of s a in the logical sense. A state s b is a sub-state of a state s a, if its characteristics predicates include those of s a in the logical sense.

13 From Use Cases to State Models Use the operations withdrawn and added condition to determine states. Use the operations withdrawn and added condition to determine states. operation Withdrawn condition Added condition state1 state2

14 From Use Cases to State Models A finite state transition machine is a tuple A finite state transition machine is a tuple is a finite alphabet is a finite alphabet is a finite set of states is a finite set of states is a transition function is a transition function is a set of initial state is a set of initial state Given a use case [Title, Pre, Steps, Post], the algorithm enriches a state transition machine M. Given a use case [Title, Pre, Steps, Post], the algorithm enriches a state transition machine M. M is initially such that

15

16 S0: { “ System is ON ”, “ No user is logged in ”, “ No card is inserted ” } S1: { “ System is ON ”, “ No user is logged in ”, “ Card is inserted ” } S2: { “ System id ON ”, “ No user logged in ”, “ Card is inserted ”, “ Card is not regular ” }S3: { “ System is ON ”, “ No user logged in ”, “ Card is inserted ”, “ Display is pin enter prompt ” }

17 Use Cases Simulation The simulator includes an “actor events panel” and a “simulation results panel”. The simulator includes an “actor events panel” and a “simulation results panel”. UCEd generates a button corresponding to each actor operation in the “actor events panel”. UCEd generates a button corresponding to each actor operation in the “actor events panel”. The operations are obtained from the domain model. The operations are obtained from the domain model. State machine

18 Conclusion Use cases Domain model State model simulator