Learn > Model & Process > Models
Use Case Model
|
In order to represent the Use Case life cycle we continued the extension to the UML State Machine Diagrams made in [Coa04].
The diagram allows specifying each Use Case using states, events, conditions, transitions and service invocations.
Events are fired by the user. When an event is fired, it starts a transition if the guard is satisfied. A transition goes from one state to another and can have an associated service invocation (to the Service Layer). 
States Use cases are defined using these state types: Initial State, Static State, Dynamic State, Composite State and Final State. The Initial State represents the beginning of the Use Case. It is unique and has a single transition towards the first state without event and guard (we auto-name it as epsilon). This transition, nevertheless, can invoke system services. A Dynamic State does not involve user interaction. It is used to branch off the flow of the Use Case and corresponds generally with decision making based on the use case information. Static States represent a period of time in which the user interface is waiting for a user-driven event. A Final State represents the completion of the use case. You can have many of them in the same state machine. A final state can be Successful or Fail. A Successful Final State indicates the use case complete conclusion, whereas a Fail one represents the occurrence of some exception. Information Space (Use Case variables) Each use case has its own information space. While server-side script languages (ASP) have session variables, Himalia has both session variables and use case variables. Session variables are global; you can get them anywhere. But session variables are not enough if more than one use case instance is running at the same time. For this reason we need use case variables, attached to the use case life cycle.
| |||||||