CSC/ECE 517 Fall 2010/ch4 4a I: Difference between revisions
No edit summary |
|||
(58 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
=Introduction= | ==Introduction== | ||
A '''use case''' is set of interactions between the external '''actors''' and the '''system''' under consideration with an objective of achieving specific goals as defined by the users of the system. A use case is used to capture the functional requirements of a particular system which in turn are used to capture the intended behavior of the system. The notion of an '''actor''' can be used to represent the external users, or the roles of the users, in fact even the systems other than the one under consideration are considered to be and '''actor'''.[http://www.bredemeyer.com/use_cases.htm 2] | A '''use case''' is set of interactions between the external '''actors''' and the '''system''' under consideration with an objective of achieving specific goals as defined by the users of the system. A use case is used to capture the functional requirements of a particular system which in turn are used to capture the intended behavior of the system. The notion of an '''actor''' can be used to represent the external users, or the roles of the users, in fact even the systems other than the one under consideration are considered to be and '''actor'''.[http://www.bredemeyer.com/use_cases.htm 2] | ||
=Overview= | ==Overview== | ||
In general '''use cases''' are used to capture the '''who''' i.e the actors, the '''what''' i.e interactions, and the '''purpose''' i.e the goal of a particular system without having to worry too much about the internal workings of the system. | In general '''use cases''' are used to capture the '''who''' i.e the actors, the '''what''' i.e interactions and system reactions, and the '''purpose''' i.e the goal of a particular system without having to worry too much about the internal workings of the system. Use cases originated in the Object oriented community but their applicability is not limited to object oriented systems. [http://en.wikipedia.org/wiki/Use_case 1] | ||
= | ==Use cases in detail== | ||
===Purpose of Use cases=== | |||
Use cases are used in different stages on the development life cycle. In the '''planning''' stage, the process of defining important use cases helps to clarify the most important goals of the system. Use cases helps to narrow the scope of the project. They can surface often unspoken assumptions about the desired behavior of the system. | |||
In the '''execution''' stage of the development life cycle, use cases provide developers key parts of the specification. Some systems are built entirely with only use case descriptions from sponsors | |||
*[2]: [http://www.bredemeyer.com/use_cases.htm Functional Requirements and Use cases] | ===Use case templates === | ||
*'''Use case''' | |||
Each use case should have a unique name describing in a manner which describes its purpose. The name usually is a active phrase, in a verb-noun format. Use cases can also have a reference number associated with them, this is to indicate how they relate to other use cases. Also the use case name should maintain creation and modification history of the template, this information should be preceded by the keyword '''history'''. | |||
*'''Description''' | |||
In the description field of the use case template we maintain the goals of the use case. The description should list the source for the functional requirement, this information should be preceded by the keyword '''sources'''. | |||
*'''Actors''' | |||
Use cases identify the intent satisfying the role assumed by external '''actors''' interacting with the “system under discussion/test”. The actors can be classified into '''primary actor''' or '''secondary actor'''. A '''primary actor''' is one having a goal requiring the assistance of the system. A '''secondary actor''' is one from which the system needs assistance to satisfy a goal.[http://www.wilsonmar.com/1usecase.htm 8] | |||
*'''Assumptions''' | |||
Assumptions made in order to achieve the goals defined should be stated in a declarative manner. The assumptions should be evaluated to a true or false and in case if the assumption is false then it is unspecified as to what the use case will do. Behavior in case of an assumption failure can accounted for using use-case extensions. | |||
*'''Steps''' | |||
The sequence of interactions necessary to successfully meet the goal. The interactions between the system and actors are structured into one or more steps which are expressed in natural language. A step completes when all its component interactions have completed. A step has the form | |||
<sequence number><interaction>. If there are multiple steps then each step should have a sequence number showing its position in the list of interactions. The execution of one or more steps can be made conditional by using programming-like IF-then-ELSE constructs.[http://www.bredemeyer.com/pdf_files/use_case.pdf 3] | |||
*'''Variations''' | |||
Variations represent any variation in the steps of the use case. The format of the variation is <step reference> < list of variations separated by or>. | |||
*'''Non functional requirements''' | |||
Non functional requirements related to fault tolerance,performance,etc are listed as <keyword> : < requirement>. Here again the non functional requirements are list in a natural and understandable format. | |||
*'''Issues''' | |||
This section lists the issues which are awaiting the resolution. | |||
===Use case template example=== | |||
[[Image:usecasetemplateexample.png]] | |||
===Types of Use cases=== | |||
*'''System use cases''': System use case describes the service which the system provides for the actor. The system use case describes <i>what</i> the system would do in response to the actor's actions. An actor in the system use cases can be wither a human user or another system interacting with the system under consideration. | |||
*'''Business use cases''': Business use cases are used to define the processes which will be used by the external actors. The business use cases treat the system under consideration as a black box in which the actors are given a description as to <i>what</i> the process does by specifying a value. [http://www.agilemodeling.com/artifacts/systemUseCase.htm#Informal 5] | |||
==Use case extension== | |||
In order to deal with the case of assumption failure, a variant of the use cases can defined using the use case extension. | |||
===Use case extension template=== | |||
*'''Use case extension''' [http://www.bredemeyer.com/pdf_files/use_case.pdf 3] | |||
The extension name includes a unique identifier for the extension and a reference to the use case to which the extension applies | |||
*'''Changed field''' | |||
This field documents the field of the use case template which are going to be changed. | |||
*'''Steps''' | |||
This field mentions the steps field of the use case which require change, the changes are expressed in terms of new or altered steps which require change that apply to a use case at extension point, if some condition is true. | |||
===Use case extension example=== | |||
Continuing the example of the online shopping portal system use case previously explained, on extending the use case we get the following use case extension template.[[Image:Usecaseextensiontemplateexample.png]] | |||
==Use cases in UML== | |||
UML represents the use cases in a diagrams called as the '''use case diagrams'''. [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_4_2q 4] | |||
Lines in a UML use case between an actor and the system represent a more abstract concept of relationship of communication, acquaintance, or inheritance. | |||
A use case circle can be more than a user invoking an on-demand service that passively waits until called upon. | |||
A Use case circle can be event-driven, which proactively notifies one or more subscribers when specific events occur. | |||
Services that run on their own without formal invocation may be better represented as an (automated) actor rather than as a use case circle. | |||
The general representation of the use case environment in '''Unified Modeling Language'''(UML)is represented in the figure below | |||
[[Image:Generalusecase.png]] | |||
'''Example''': Consider a scenario in which a customer is visiting a online shopping portal system. In this scenario as we see the customer as the actor interacting with the online shopping portal system. [http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm 6] | |||
The use case diagram covers the basic operations which the customer would normally perform while ordering an item from the shopping portal. This use case diagram can be extended to include extra scenarios such as the multiple item order, order cancellation and so on. | |||
[[Image:Usecaseexample.png]] | |||
==See Also== | |||
*[http://en.wikipedia.org/wiki/List_of_UML_tools List of UML Tools] | |||
*[http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases] | |||
==References== | |||
*[1]: Wikipedia.2010.Wikipedia-Use Case. wikipedia.org | |||
*[2]: Bredemeyer.2006.Functional Requirements and Use cases. Bredemeyer Consultancy | |||
*[3]: Coleman,Derek.1998.A Use Case Template:draft for discussion. Hewlett Packard | |||
*[4]: Mediawiki.2007.Wiki reference wiki2_4_2q.North Carolina State University | |||
*[5]: Ambler,W.Scott.2009.System Use Cases.Ambysoft Inc. | |||
*[6]: Braun,David.2000.UML tutorial[online].Kennesaw State University | |||
*[7]: Mall,R.2004. Fundamentals of Software Engineering. Prentice Hall, New Delhi. | |||
*[8]: Mar,Wilson.2010. Use cases. Wilson Mar | |||
==Links for References== | |||
*[http://en.wikipedia.org/wiki/Use_case Use case] | |||
*[http://www.bredemeyer.com/use_cases.htm Functional Requirements and Use cases] | |||
*[http://www.bredemeyer.com/pdf_files/use_case.pdf Use case extension template] | |||
*[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_4_2q Wiki reference] | |||
*[http://www.agilemodeling.com/artifacts/systemUseCase.htm#Informal Use case Types] | |||
*[http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm Use cases HOW TO?] | |||
*[http://www.wilsonmar.com/1usecase.htm Use cases explained (8) ] |
Latest revision as of 18:04, 28 October 2010
Introduction
A use case is set of interactions between the external actors and the system under consideration with an objective of achieving specific goals as defined by the users of the system. A use case is used to capture the functional requirements of a particular system which in turn are used to capture the intended behavior of the system. The notion of an actor can be used to represent the external users, or the roles of the users, in fact even the systems other than the one under consideration are considered to be and actor.2
Overview
In general use cases are used to capture the who i.e the actors, the what i.e interactions and system reactions, and the purpose i.e the goal of a particular system without having to worry too much about the internal workings of the system. Use cases originated in the Object oriented community but their applicability is not limited to object oriented systems. 1
Use cases in detail
Purpose of Use cases
Use cases are used in different stages on the development life cycle. In the planning stage, the process of defining important use cases helps to clarify the most important goals of the system. Use cases helps to narrow the scope of the project. They can surface often unspoken assumptions about the desired behavior of the system. In the execution stage of the development life cycle, use cases provide developers key parts of the specification. Some systems are built entirely with only use case descriptions from sponsors
Use case templates
- Use case
Each use case should have a unique name describing in a manner which describes its purpose. The name usually is a active phrase, in a verb-noun format. Use cases can also have a reference number associated with them, this is to indicate how they relate to other use cases. Also the use case name should maintain creation and modification history of the template, this information should be preceded by the keyword history.
- Description
In the description field of the use case template we maintain the goals of the use case. The description should list the source for the functional requirement, this information should be preceded by the keyword sources.
- Actors
Use cases identify the intent satisfying the role assumed by external actors interacting with the “system under discussion/test”. The actors can be classified into primary actor or secondary actor. A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance to satisfy a goal.8
- Assumptions
Assumptions made in order to achieve the goals defined should be stated in a declarative manner. The assumptions should be evaluated to a true or false and in case if the assumption is false then it is unspecified as to what the use case will do. Behavior in case of an assumption failure can accounted for using use-case extensions.
- Steps
The sequence of interactions necessary to successfully meet the goal. The interactions between the system and actors are structured into one or more steps which are expressed in natural language. A step completes when all its component interactions have completed. A step has the form <sequence number><interaction>. If there are multiple steps then each step should have a sequence number showing its position in the list of interactions. The execution of one or more steps can be made conditional by using programming-like IF-then-ELSE constructs.3
- Variations
Variations represent any variation in the steps of the use case. The format of the variation is <step reference> < list of variations separated by or>.
- Non functional requirements
Non functional requirements related to fault tolerance,performance,etc are listed as <keyword> : < requirement>. Here again the non functional requirements are list in a natural and understandable format.
- Issues
This section lists the issues which are awaiting the resolution.
Use case template example
Types of Use cases
- System use cases: System use case describes the service which the system provides for the actor. The system use case describes what the system would do in response to the actor's actions. An actor in the system use cases can be wither a human user or another system interacting with the system under consideration.
- Business use cases: Business use cases are used to define the processes which will be used by the external actors. The business use cases treat the system under consideration as a black box in which the actors are given a description as to what the process does by specifying a value. 5
Use case extension
In order to deal with the case of assumption failure, a variant of the use cases can defined using the use case extension.
Use case extension template
- Use case extension 3
The extension name includes a unique identifier for the extension and a reference to the use case to which the extension applies
- Changed field
This field documents the field of the use case template which are going to be changed.
- Steps
This field mentions the steps field of the use case which require change, the changes are expressed in terms of new or altered steps which require change that apply to a use case at extension point, if some condition is true.
Use case extension example
Continuing the example of the online shopping portal system use case previously explained, on extending the use case we get the following use case extension template.
Use cases in UML
UML represents the use cases in a diagrams called as the use case diagrams. 4 Lines in a UML use case between an actor and the system represent a more abstract concept of relationship of communication, acquaintance, or inheritance. A use case circle can be more than a user invoking an on-demand service that passively waits until called upon. A Use case circle can be event-driven, which proactively notifies one or more subscribers when specific events occur. Services that run on their own without formal invocation may be better represented as an (automated) actor rather than as a use case circle. The general representation of the use case environment in Unified Modeling Language(UML)is represented in the figure below
Example: Consider a scenario in which a customer is visiting a online shopping portal system. In this scenario as we see the customer as the actor interacting with the online shopping portal system. 6 The use case diagram covers the basic operations which the customer would normally perform while ordering an item from the shopping portal. This use case diagram can be extended to include extra scenarios such as the multiple item order, order cancellation and so on.
See Also
References
- [1]: Wikipedia.2010.Wikipedia-Use Case. wikipedia.org
- [2]: Bredemeyer.2006.Functional Requirements and Use cases. Bredemeyer Consultancy
- [3]: Coleman,Derek.1998.A Use Case Template:draft for discussion. Hewlett Packard
- [4]: Mediawiki.2007.Wiki reference wiki2_4_2q.North Carolina State University
- [5]: Ambler,W.Scott.2009.System Use Cases.Ambysoft Inc.
- [6]: Braun,David.2000.UML tutorial[online].Kennesaw State University
- [7]: Mall,R.2004. Fundamentals of Software Engineering. Prentice Hall, New Delhi.
- [8]: Mar,Wilson.2010. Use cases. Wilson Mar