OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/concepts/use_case_model.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>openup&amp;#92;guidances&amp;#92;concepts&amp;#92;&amp;#92;use_case_model.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: use_case_model.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_2jyfUAhVEduRe8TeoBmuGg CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_2jyfUAhVEduRe8TeoBmuGg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_2jyfUAhVEduRe8TeoBmuGg CRC: 3816755173 -->This artifact is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the project team.<!-- END:briefDescription,_2jyfUAhVEduRe8TeoBmuGg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-yEWkrWZ3VUcjZPhq6bvScg CRC: 4281346867 --><h3>
     Explanation
 </h3>
 <p>
     A use-case model is a model of how different types of users interact with the system to solve a problem.&nbsp; As such,
     it describes the goals of the users, the interactions between the users and the system, and the required behavior of
     the system in satisfying these goals.
 </p>
 <p>
     A use-case model consists of a number of model elements.&nbsp; The most important model elements are: use cases, actors
     and the relationships between them.
 </p>
 <p>
     A use-case diagram is used to graphically depict a subset of the model to simplify communications.&nbsp; There will
     typically be several use-case diagrams associated with a given model, each showing a subset of the model elements
     relevant for a particular purpose.&nbsp; The same model element may be shown on several use-case diagrams, but each
     instance must be consistent.&nbsp; If tools are used to maintain the use-case model, this consistency constraint is
     automated so that any changes to the model element (changing the name for example) will be automatically reflected on
     every use-case diagram that shows that element.
 </p>
 <p>
     The use-case model may contain packages that are used to structure the model to simplify analysis, communications,
     navigation, development, maintenance and planning.
 </p>
 <p>
     Much of the use-case model is in fact textual, with the text captured in the&nbsp;<a class="elementLink" href="./../../../openup/guidances/templates/use_case_specification_E97E98B0.html" guid="_0cpNwMlgEdmt3adZL5Dmdw">Use-Case Specification</a>s that are associated with each use-case model element.&nbsp;These specifications describe the flow of
     events of the use case.
 </p>
 <p>
     The use-case model serves as a unifying thread throughout system development. It is used as the primary specification
     of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning,
     as the basis of defining test cases and as the basis for user documentation&nbsp;&nbsp;
 </p>
 <h3>
     Basic model elements
 </h3>
 <p>
     The use-case model contains, as a minimum, the following basic model elements.
 </p>
 <h4>
     Actor
 </h4>
 <p>
     A model element representing&nbsp;each actor. Properties include the actors name and brief description. See&nbsp;<a class="elementLinkWithType" href="./../../../openup/guidances/concepts/actor_411726C.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Concept: Actor</a> for more information.
 </p>
 <h4>
     Use Case
 </h4>
 <p>
     A model element representing&nbsp;each use case. Properties include the use case name and use case specification. See
     <a class="elementLinkWithType" href="./../../../openup/workproducts/use_case_22BE66E2.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case_BB199D1B.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a> for
     more information.
 </p>
 <h4>
     Associations
 </h4>
 <p>
     Associations are used to describe the relationships between actors and the use cases they participate in. This
     relationship is commonly known as a “communicates-association”.
 </p>
 <h3>
     Advanced model elements
 </h3>
 <p>
     The use-case model may also contain the following advanced model elements.
 </p>
 <h4>
     Subject
 </h4>
 <p>
     A model element that represents the boundary of the system of interest.&nbsp;&nbsp;
 </p>
 <h4>
     Use-Case Package
 </h4>
 <p>
     A model element used to structure the use case model to simplify analysis, communications, navigation, and
     planning.&nbsp; If there are many use cases or actors, you can use use-case packages to further structure the use-case
     model in much the same manner you use folders or directories to structure the information on your hard-disk.
 </p>
 <p>
     You can partition a use-case model into use-case packages for several reasons, including:
 </p>
 <ul>
     <li>
         To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning.
     </li>
     <li>
         To support parallel development by dividing the problem into bite-sized pieces.
     </li>
     <li>
         To simplify communication with different stakeholders by creating packages for containing use cases and actors
         relevant to a particular stakeholder.
     </li>
 </ul>
 <h4>
     Generalizations
 </h4>
 <p>
     A relationship&nbsp;between actors to support re-use of common properties.
 </p>
 <h4>
     Dependencies
 </h4>
 <p>
     A number of dependency types between use cases are defined in UML. In particular, &lt;&lt;extend&gt;&gt; and
     &lt;&lt;include&gt;&gt;.
 </p>
 <p>
     &lt;&lt;extend&gt;&gt; is used to include optional behavior from an extending use case in an extended use case.
 </p>
 <p>
     &lt;&lt;include&gt;&gt; is used to include common behavior from an included use case into a base use case in order to
     support re-use of common behavior.
 </p>
 <p>
     The latter is the most widely used dependency and is useful for:
 </p>
 <ul>
     <li>
         Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of
         the use case to simplify communications.
     </li>
     <li>
         Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and
         ensure consistency.
     </li>
 </ul>
 <h3>
     Example Use-Case Diagram
 </h3>
 <p>
     Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
 </p>
 <p>
     &nbsp;<img height="410" alt="Figure 1: ATM Use-Case Diagram" src="./resources/atm_uc_diagram.GIF" width="565" />
 </p>
 <p>
     Figure 1: ATM Use-Case Diagram
 </p>
 <p>
     This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and Maintenance Person), five use
     cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three &lt;&lt;includes&gt;&gt;
     dependencies, and the associations between the performing actors and the use cases.
 </p>
 <p>
     The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to
     the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use
     cases &lt;&lt;include&gt;&gt;. The base use cases are independent of the method used for identification, and it is
     therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter
     whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on
     the result of Validate Customer.
 </p>
 <p>
     Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions
     of each actor, descriptions of each use case, and use-case specifications for each use case.&nbsp; For a more complete
     example of this use case model see <a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_model_evolution_960F136B.html" guid="_t4QdAMNqEdu2IdAIaWZyAw">Example: Evolution of the Use-Case Model</a>.<br />
 </p><!-- END:mainDescription,-yEWkrWZ3VUcjZPhq6bvScg -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>openup&#92;guidances&#92;concepts&#92;&#92;use_case_model.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: use_case_model.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_2jyfUAhVEduRe8TeoBmuGg CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_2jyfUAhVEduRe8TeoBmuGg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_2jyfUAhVEduRe8TeoBmuGg CRC: 3816755173 -->This artifact is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the project team.<!-- END:briefDescription,_2jyfUAhVEduRe8TeoBmuGg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-yEWkrWZ3VUcjZPhq6bvScg CRC: 4281346867 --><h3>
	Explanation
	</h3>
	<p>
	A use-case model is a model of how different types of users interact with the system to solve a problem.  As such,
	it describes the goals of the users, the interactions between the users and the system, and the required behavior of
	the system in satisfying these goals.
	</p>
	<p>
	A use-case model consists of a number of model elements.  The most important model elements are: use cases, actors
	and the relationships between them.
	</p>
	<p>
	A use-case diagram is used to graphically depict a subset of the model to simplify communications.  There will
	typically be several use-case diagrams associated with a given model, each showing a subset of the model elements
	relevant for a particular purpose.  The same model element may be shown on several use-case diagrams, but each
	instance must be consistent.  If tools are used to maintain the use-case model, this consistency constraint is
	automated so that any changes to the model element (changing the name for example) will be automatically reflected on
	every use-case diagram that shows that element.
	</p>
	<p>
	The use-case model may contain packages that are used to structure the model to simplify analysis, communications,
	navigation, development, maintenance and planning.
	</p>
	<p>
	Much of the use-case model is in fact textual, with the text captured in the <a class="elementLink" href="./../../../openup/guidances/templates/use_case_specification_E97E98B0.html" guid="_0cpNwMlgEdmt3adZL5Dmdw">Use-Case Specification</a>s that are associated with each use-case model element. These specifications describe the flow of
	events of the use case.
	</p>
	<p>
	The use-case model serves as a unifying thread throughout system development. It is used as the primary specification
	of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning,
	as the basis of defining test cases and as the basis for user documentation
	</p>
	<h3>
	Basic model elements
	</h3>
	<p>
	The use-case model contains, as a minimum, the following basic model elements.
	</p>
	<h4>
	Actor
	</h4>
	<p>
	A model element representing each actor. Properties include the actors name and brief description. See <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/actor_411726C.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Concept: Actor</a> for more information.
	</p>
	<h4>
	Use Case
	</h4>
	<p>
	A model element representing each use case. Properties include the use case name and use case specification. See
	<a class="elementLinkWithType" href="./../../../openup/workproducts/use_case_22BE66E2.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/use_case_BB199D1B.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a> for
	more information.
	</p>
	<h4>
	Associations
	</h4>
	<p>
	Associations are used to describe the relationships between actors and the use cases they participate in. This
	relationship is commonly known as a “communicates-association”.
	</p>
	<h3>
	Advanced model elements
	</h3>
	<p>
	The use-case model may also contain the following advanced model elements.
	</p>
	<h4>
	Subject
	</h4>
	<p>
	A model element that represents the boundary of the system of interest.
	</p>
	<h4>
	Use-Case Package
	</h4>
	<p>
	A model element used to structure the use case model to simplify analysis, communications, navigation, and
	planning.  If there are many use cases or actors, you can use use-case packages to further structure the use-case
	model in much the same manner you use folders or directories to structure the information on your hard-disk.
	</p>
	<p>
	You can partition a use-case model into use-case packages for several reasons, including:
	</p>
	<ul>
	<li>
	To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning.
	</li>
	<li>
	To support parallel development by dividing the problem into bite-sized pieces.
	</li>
	<li>
	To simplify communication with different stakeholders by creating packages for containing use cases and actors
	relevant to a particular stakeholder.
	</li>
	</ul>
	<h4>
	Generalizations
	</h4>
	<p>
	A relationship between actors to support re-use of common properties.
	</p>
	<h4>
	Dependencies
	</h4>
	<p>
	A number of dependency types between use cases are defined in UML. In particular, <<extend>> and
	<<include>>.
	</p>
	<p>
	<<extend>> is used to include optional behavior from an extending use case in an extended use case.
	</p>
	<p>
	<<include>> is used to include common behavior from an included use case into a base use case in order to
	support re-use of common behavior.
	</p>
	<p>
	The latter is the most widely used dependency and is useful for:
	</p>
	<ul>
	<li>
	Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of
	the use case to simplify communications.
	</li>
	<li>
	Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and
	ensure consistency.
	</li>
	</ul>
	<h3>
	Example Use-Case Diagram
	</h3>
	<p>
	Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
	</p>
	<p>
	<img height="410" alt="Figure 1: ATM Use-Case Diagram" src="./resources/atm_uc_diagram.GIF" width="565" />
	</p>
	<p>
	Figure 1: ATM Use-Case Diagram
	</p>
	<p>
	This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and Maintenance Person), five use
	cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three <<includes>>
	dependencies, and the associations between the performing actors and the use cases.
	</p>
	<p>
	The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to
	the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use
	cases <<include>>. The base use cases are independent of the method used for identification, and it is
	therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter
	whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on
	the result of Validate Customer.
	</p>
	<p>
	Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions
	of each actor, descriptions of each use case, and use-case specifications for each use case.  For a more complete
	example of this use case model see <a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_model_evolution_960F136B.html" guid="_t4QdAMNqEdu2IdAIaWZyAw">Example: Evolution of the Use-Case Model</a>.<br />
	</p><!-- END:mainDescription,-yEWkrWZ3VUcjZPhq6bvScg -->
	</body>
	</html>