use+case



A Use Case Diagram is used to model the uses of a system carried out by an external entity. This external entity is usually referred to as the Actor. There can be one or more Actors involved in a system which communicate with one or two processes within a system. This combination of an actor communicating with one or more processes to achieve a task / use is actually one use case scenario. It is to be appreciated that the Actor resides outside the system and interacts with the system which is enclosed within a system boundary. In order to diagram the use case we use some specialized notations. A stick character is used and denoted as an Actor. Events are basically those processes which occur in series or in conjunction to each other in a particular Use Case.

Use case diagram is drawn by first identifying the actors of the system. After idenitification of actors, use cases associated with the actors are identified. This approach of first identifying the actors and then the use cases or events can be replaced with the approach of identifying an actor and all of its associated use cases. Similarly, identifying another actor and its use cases. Whichever approach is adopted it really does not matter. But it is important to identify all the actors and events/behaviours/use cases and relationships between the use cases. Example: Think of a hypothetical Library with some 50000 books only. The library only facilitate the students looking for books. A **student** walks in and //search// for the book he needs. After finding the **book,** using his **library card**, he //issues// the book from the **librarian**. Librarian marks it in his //register// that the book has been issued on [Current Date] against the student ID over his Library card. Policy of returning the book is within 2 days. After two days, the student //returns// the book. This scenario can be explained using following use case diagram.



Another Example: Describing a Library Management System

In drawing use case diagrams it is important to identify relationships between use cases. There are three types of relationships that exist between use cases. These are as follows:- Include Relationship** When one use case behaviour is added into another use case .It is used when several use cases need to complete the same action. This relationship saves our time ,that is, the document that we have created once can be reused.
 * relationships :

Notation A Broken arrow from one usecase to the other use casewith the label < >. When one wants to include the behaviour of a use case into another use case under certain conditions.That is it adds more sequence into the base use case.It helps us in avoiding the complexity of use case.
 * Extend Relationship**

Notation A Broken arrow from one use case to another use case with the label < > This use case is use to show inheritance that is how all the properties,functions and behaviour of a parent can be transferred to the child.
 * Generalization**

Notation Its a solid line that ends up in a hollow trriangle to show inheritance.

The idea of use cases was put forward in the mid 1980’s by Ivar Jacobson. Simply put a use case defines how a system is being used. For example a bank card holder using an ATM to get cash out of their account. There are three key elements in use case: actors, system being used and the functional goal that the actor achieves using the system or the reason behind using the system. An actor is a type of user who is interacting with the system e.g. a card holder. The actor who’s external to the system, and may or may not have to be a person (It can also be a system).There are primary and secondary actors. A primary actor is the user or the system while a secondary actor is one from which the system needs assistance in order to fulfill the relevant goal. Thereby, a use case is a set of interactions between actors and the system that take place in an attempt to achieve a certain goal and completes successfully when that goal is satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal, it may also include sequences that lead to possible failure. Each use case focuses on describing how to achieve a goal or task. For most software projects this means that multiple, perhaps dozens, of use cases are needed to define the scope of the new system.A complete set of use cases specifies all the different ways to use the system and therefore defines all behavior required of the system. Generally, use case steps are written in an easy to understand manner. This is engaging for users who can easily follow the use cases and be actively involved in defining its requirements. A scenario is an instance of a use case and represents a single path through the use case. Thus multiple scenarios will exist for a particular use case. Each scenario will be triggered by different options. A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that was originates from outside the system i.e. a primary actor. Use cases treat the system as a black box and the interactions with the system, including system responses, are perceived as from outside the system. A use case basically forces the system to focus on what the system must do and not get side tracked by concentrating on how it is done. It clarifies how the functionality will be accomplished. A use case should describe what the system shall do for the actor to achieve a particular goal, be at the appropriate level of detail, use case notation and not include detail regarding user interfaces and screens since this should be covered in a user interface design. The specific way use cases are used within the development process will depend on which development methodology is being used. In certain development methodologies, a brief use case survey is all that is required. In other development methodologies, use cases evolve in complexity and change in character as the development process proceeds. Usually they begin as brief business use cases, evolve into more detailed system use cases, and then eventually develop into highly detailed test cases. There is no standard template for documenting detailed use cases. Individuals are encouraged to use templates that work for them or the project they are on. Standardization within each project is more important than the detail of a specific template. However there is an underlying similarity between most use cases. Use cases may differ in terms of use case names-which are the unique identifiers in a use case, different versions, different goals- there will be a different use case for each goal, summary, actors – different actors will be relevant to different systems and goals, pre conditions-the conditions required for a goal to be achieved and the triggers that will ascertain a specific course of action or highlight the path in a use case and link the activities with their results. In essence use cases are used in the developing of a product or system. To do so gathering its functional requirements is essential and different strategies are required to capture different functional requirements of the system in question. In summary a use case defines a goal-oriented set of interactions between external actors and the system under consideration.

Example: You may consider the example of an ATM system where a bank intearacts with a customer through an ATM machine controlled by an operator. The entities include all those which are present within the bounds, there are actors operator, customers, and bank. Relationships are shown with end to end diagrams.

Group members: Sana Ali Saba Khan Mohd Ali Khan

Sources: • http://www.parlezuml.com/tutorials/usecases/usecases_intro.pdf • http://en.wikipedia.org/wiki/Use_case • http://www.bredemeyer.com/use_cases.htm • http://www.ask.com/bar?q=Use+Case+Definition&page=1&qsrc=6&zoom=%3CKW%3EUse+Case%3C%2FKW%3E+Template%7CWriting+%3CKW%3EUse+Cases%3C%2FKW%3E%7C%3CKW%3EUse+Case%3C%2FKW%3E+Modeling&ab=3&u=http%3A%2F%2Fwww.bredemeyer.com%2Fuse_cases.htm • http://www.ask.com/bar?q=Use+Case+Definition&page=1&qsrc=6&zoom=%3CKW%3EUse+Case%3C%2FKW%3E+Template%7CWriting+%3CKW%3EUse+Cases%3C%2FKW%3E%7C%3CKW%3EUse+Case%3C%2FKW%3E+Modeling&ab=4&u=http%3A%2F%2Fbss.sfsu.edu%2Fandrew%2Fitec745%2Fassignments%2Fusecase.htm • http://www.ask.com/bar?q=Use+Case+Examples&page=1&qsrc=6&zoom=Good+%3CKW%3EExample%3C%2FKW%3E+for+%3CKW%3EUse+Case%3C%2FKW%3E%7C%3CKW%3EUse+Case%3C%2FKW%3E+Diagram+%3CKW%3EExamples%3C%2FKW%3E%7C%3CKW%3EUse+Case%3C%2FKW%3E+Modeling&ab=1&u=http%3A%2F%2Fwww.gatherspace.com%2Fstatic%2Fuse_case_example.html


 * Source for ATM Example: http://www.math-cs.gordon.edu/courses/cs211/ATMExample/UseCases.html