USE-CASE MODELING:
Use case modeling was originally developed by Jacobson et al. (1993) in the 1990s and was incorporated into
the first release of the UML (Rumbaugh et al., 1999). Use case modeling is widely used to support
requirements elicitation. A use case can be taken as a simple scenario that describes what a user expects from
a system.
Use-case Model: -
The use Đase ŵodel foƌ aŶLJ sLJsteŵ ĐoŶsists of a set of ͞use Đases͟. IŶtuitiǀelLJ, use Đases ƌepƌeseŶt the diffeƌeŶt
ways in which a system can be used by the users. A simple way to find all the use cases of a system is to ask the
ƋuestioŶ: ͞What the useƌs ĐaŶ do usiŶg the sLJsteŵ?͟
Thus, for the Library Information System (LIS), the use cases could be:
issue-book
query-book
return-book
create-member
add-book etc
into transactions, such that each transaction performs soŵe useful aĐtioŶ fƌoŵ the useƌ͛s poiŶt of ǀieǁ. To
complete each transaction may involve either a single message or multiple message exchanges between the
user and the system to complete.
Purpose of use cases: -
The purpose of a use case is to define a piece of coherent behavior without revealing the internal structure of
the system. The use cases do not mention any specific algorithm to be used or the internal data
representation, internal structure of the software, etc. A use case typically represents a sequence of
interactions between the user and the system. These interactions consist of one mainline sequence. The
mainline sequence represents the normal interaction between a user and the system. The mainline sequence
is the most occurring sequence of interaction.
Representation of use cases: -
Use cases can be represented by drawing a use case diagram and writing an accompanying text elaborating the
drawing. In the use case diagram, each use case is represented by an ellipse with the name of the use case
written inside the ellipse. All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which
represents the system boundary. The name of the system being modeled (such as Library Information System)
appears inside the rectangle.
Text Description: -
Each ellipse on the use case diagram should be accompanied by a text description. The text description should
define the details of the interaction between the user and the computer and other aspects of the use case. It
should include all the behavior associated with the use case in terms of the mainline sequence, different
variations to the normal behavior, the system responses associated with the use case, the exceptional
conditions that may occur in the behavior, etc.
Contact persons: This section lists the personnel of the client organization with whom the use case was
discussed, date and time of the meeting, etc.
Actors: In addition to identifying the actors, some information about actors using this use case which may help
the implementation of the use case may be recorded.
Pre-condition: The preconditions would describe the state of the system before the use case execution starts.
Post-condition: This captures the state of the system after the use case has successfully completed.
Non-functional requirements: This could contain the important constraints for the design and
implementation, such as platform and environment conditions, qualitative statements, response time
requirements, etc.
Exceptions, error situations: This contains only the domain-ƌelated eƌƌoƌs suĐh as laĐk of useƌ͛s aĐĐess ƌights,
invalid entry in the input fields, etc. Obviously, errors that are not domain related, such as software errors,
need not be discussed here.
Sample dialogs: These serve as examples illustrating the use case.
Specific user interface requirements: These contain specific requirements for the user interface of the use
case. For example, it may contain forms to be used, screen shots, interaction style, etc.
Document references: This part contains references to specific domain related documents which may be
useful to understand the system operation.
