Understanding various terms in Use Case Modeling
Filed Under Design, Document, Techniques, Terms, Process, Model, Development | Posted on October 28, 2007
There would be few people in the world of software development who would not have heard of Use Case Modeling, but the number of people who know details about a Use Case would be far fewer. So let’s try and see what the various parts of Use Case Modeling are.
A use case is a technique used in software and systems engineering to capture the functional requirements of a system. Whenever we discuss the requirements of a system we recognize one or more people or things that have an interest in the behavior of that system. These are called the stakeholders of that system. A use case describes how the system should respond under various conditions to a request from one of the stakeholders to deliver a specific goal. This is primarily done in the form of a scenario that describes a sequence of steps. Each use case captures a “contract” for the behavior of the System under Discussion (SuD) to deliver a single goal.
A Use Case has several terms, so let’s try and explain some of those terms.
Actors: An actor is a person, organization, or external system that plays a role in one or more interactions with your system (actors are typically drawn as stick figures on UML Use Case diagrams).
* Actors are external to a system.
* Actors interact with the system. Actors may use the functionality provide by the system, including application functionality and maintenance functionality. Actors may provide functionality to the system. Actors may receive information provided by the system. Actors may provide information to the system.
* Actor classes have actors instances or objects that represent specific actors.
* Actors are typically found in the problem statement, and by conversations with customers and domain experts.
* When dealing with actors it is important to think about roles.
Relationships: Association relationships between actor classes and use case classes are used to indicate that the actor classes participates and communicates with the system containing the use case classes. Association relationships are denoted as solid lines or paths. Arrowheads may be used to indicate who initiates communication in the interaction. If an arrowhead points to a use case, the actor at the other end of the association initiates the interaction with the system. If the arrowhead points to an actor, the system initiates the interaction with the actor at the other end of the association.
There are several types of relationships that may appear on a use case diagram:
* An association between an actor and a use case
* An association between two use cases
* A generalization between two actors
* A generalization between two use cases
Use Cases: A sequence of actions that an actor performs within a system to achieve a particular goal. The purpose of this stage is to capture user requirements of the new system using use case diagrams.
* Use cases should be named using verb-noun phrases.
* Definition: A sequence of actions that an actor performs within a system to achieve a particular goal.
* A use case describes one or more courses through a user operation. The basic course must always be present; alternate courses are optional.
* Use cases should be described, indicating how they are started and end, any conditions that must be satisfied before the use case starts (pre-conditions), any conditions that must be satisfied when the use case ends (post-conditions), the sequence of exchanged messages and performed actions, the data exchanged, and any non-functional characteristics (reliability, performance, supportability, etc. constraints).
* Use cases are initiated by actors and may involve the participation of numerous other actors. Use cases should provide value to at least one of the participating actors.
* Use cases may have extension points that define specific points within an interaction at which other use cases may be inserted.
* Use case classes have use case instances or objects called scenarios that represent specific interactions. Scenarios represent a singe sequence of messages and actions.
* Use cases define the scope of a system and define the functionality provided by the system and those elements on which the system depends in order to provide the functionality.
* Use cases should facilitate actors in reaching their goals. Use cases are system functionality or responsibilities (requirements) that actors use in order to reach or satisfy their goals.
* Use cases should facilitate the architecture of a system. Use cases may be organized and partitioned using includes, extends, and generalization relationships to identify, extract, and manage common, optional, and similar functionality.
System Boundary Boxes: The rectangle around the use cases is called the system boundary box and as the name suggests it indicates the scope of your system – the use cases inside the rectangle represent the functionality that you intend to implement.
* Indicate Release Scope with a System Boundary Box.
* Avoid Meaningless System Boundary Boxes.
Sequence Diagrams: Sequence diagrams provide a graphical representation of object interactions over time. These typically show a user or actor, and the objects and components they interact with in the execution of a use case. One sequence diagram typically represents a single Use Case ’scenario’ or flow of events.
Sequence diagrams are an excellent way of documenting usage scenarios and both capturing required objects early in analysis and verifying object use later in design. The diagrams show the flow of messages from one object to another, and as such correspond to the methods and events supported by a class/object.
Implementation Diagram: A Use Case is a formal description of functionality that the system will have when constructed. An implementation diagram is typically associated with a Use Case to document which design elements (for example, components and classes) implement the Use Case functionality in the new system. This provides a high level of traceability for the system designer, the customer and the team that will actually build the system. The list of Use Cases that a component or class is linked to documents the minimum functionality that must be implemented by the component.
Leave a Reply
