OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/guidelines/uc_realizations.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_basic\guidances\guidelines\uc_realizations.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: uc_realizations.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_2uan8NbyEdqu5o2S60g5LA CRC: 3403947559 -->Use-Cases Realizations<!-- END:presentationName,_2uan8NbyEdqu5o2S60g5LA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_2uan8NbyEdqu5o2S60g5LA CRC: 71112661 -->A use-case realization represents how a use case will be implemented in terms of collaborating objects. This guideline describes its purpose and UML notation.<!-- END:briefDescription,_2uan8NbyEdqu5o2S60g5LA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-CFYVionNDLkMw6SG6runQA CRC: 3140887471 --><p>
     A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact
     can take various forms. It may include, for example, a textual description (a document), class diagrams of
     participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate
     the flow of interactions between class and subsystem instances.
 </p>
 <p>
     The reason for separating the use-case realization from its use case is that doing so allows the use cases to be
     managed separately from their realizations. This is particularly important for larger projects, or families of systems
     where the same use cases may be designed differently in different products within the product family. Consider the case
     of a family of telephone switches which have many use cases in common, but which design and implement them differently
     according to product positioning, performance and price.
 </p>
 <p>
     For larger projects, separating the use case and its realization allows changes to the design of the use case without
     affecting the baselined use case itself.
 </p>
 <p>
     In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information
     (such as textual descriptions) that form part of the use-case realization.
 </p>
 <p>
     UML diagrams that&nbsp;support use-case realizations can be produced in an analysis context, a&nbsp;design context, or
     both, depending on the needs of the project. For each use case in the use-case model, there&nbsp;can be&nbsp;a use-case
     realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a
     dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of
     inheritance, as well as a dependency.<br />
 </p>
 <p align="center">
     <img height="109" alt="Use Case Realisations" src="./resources/ucrea1.gif" width="277" />
 </p>
 <p>
     A use-case realization in the&nbsp;design can be traced to a use case in the use-case model.
 </p>
 <h4>
     Class Diagrams Owned by a Use-Case Realization
 </h4>
 <p>
     For each use-case realization there may be one or more class diagrams depicting its participating classes. A class and
     its objects often participate in several use-case realizations. It is important&nbsp;while designing to coordinate all
     the requirements on a class and its objects that different use-case realizations may have. The figure below shows an
     analysis&nbsp;class diagram for the realization of the Receive Deposit Item use case. Note the use of
     boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Concept: Entity-Control-Boundary Pattern</a>).
 </p>
 <p align="center">
     <img height="213" alt="Class diagram for the realization of Receive Deposit Item" src="./resources/md_ucre3.gif"     width="328" />
 </p>
 <p align="center">
     <strong>The use case Receive Deposit Item and its analysis-level class diagram</strong>.
 </p>
 <h4>
     Communication and Sequence Diagrams Owned by a Use-Case Realization
 </h4>
 <p>
     For each use-case realization there&nbsp;can be&nbsp;one or more interaction diagrams depicting its participating
     objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication
     diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence
     of messages and are better when it is important to visualize the time ordering of messages, whereas communication
     diagrams show the communication links between objects and are better for understanding all of the effects on a given
     object and for algorithm design.
 </p>
 <p>
     Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning
     responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to
     contain the following:
 </p>
 <ul>
     <li>
         Only the functionality actually used in support of a use case scenario.
     </li>
     <li>
         Functionality that can be tested through an associated test case.
     </li>
     <li>
         Functionality that is more easily traceable to requirements and changes.
     </li>
     <li>
         Explicitly declared class dependencies that are easier to manage.
     </li>
 </ul>
 <p>
     These factors help improve the overall quality of the system.
 </p><!-- END:mainDescription,-CFYVionNDLkMw6SG6runQA -->
 </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_basic\guidances\guidelines\uc_realizations.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: uc_realizations.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_2uan8NbyEdqu5o2S60g5LA CRC: 3403947559 -->Use-Cases Realizations<!-- END:presentationName,_2uan8NbyEdqu5o2S60g5LA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_2uan8NbyEdqu5o2S60g5LA CRC: 71112661 -->A use-case realization represents how a use case will be implemented in terms of collaborating objects. This guideline describes its purpose and UML notation.<!-- END:briefDescription,_2uan8NbyEdqu5o2S60g5LA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-CFYVionNDLkMw6SG6runQA CRC: 3140887471 --><p>
	A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact
	can take various forms. It may include, for example, a textual description (a document), class diagrams of
	participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate
	the flow of interactions between class and subsystem instances.
	</p>
	<p>
	The reason for separating the use-case realization from its use case is that doing so allows the use cases to be
	managed separately from their realizations. This is particularly important for larger projects, or families of systems
	where the same use cases may be designed differently in different products within the product family. Consider the case
	of a family of telephone switches which have many use cases in common, but which design and implement them differently
	according to product positioning, performance and price.
	</p>
	<p>
	For larger projects, separating the use case and its realization allows changes to the design of the use case without
	affecting the baselined use case itself.
	</p>
	<p>
	In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information
	(such as textual descriptions) that form part of the use-case realization.
	</p>
	<p>
	UML diagrams that support use-case realizations can be produced in an analysis context, a design context, or
	both, depending on the needs of the project. For each use case in the use-case model, there can be a use-case
	realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a
	dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of
	inheritance, as well as a dependency.<br />
	</p>
	<p align="center">
	<img height="109" alt="Use Case Realisations" src="./resources/ucrea1.gif" width="277" />
	</p>
	<p>
	A use-case realization in the design can be traced to a use case in the use-case model.
	</p>
	<h4>
	Class Diagrams Owned by a Use-Case Realization
	</h4>
	<p>
	For each use-case realization there may be one or more class diagrams depicting its participating classes. A class and
	its objects often participate in several use-case realizations. It is important while designing to coordinate all
	the requirements on a class and its objects that different use-case realizations may have. The figure below shows an
	analysis class diagram for the realization of the Receive Deposit Item use case. Note the use of
	boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Concept: Entity-Control-Boundary Pattern</a>).
	</p>
	<p align="center">
	<img height="213" alt="Class diagram for the realization of Receive Deposit Item" src="./resources/md_ucre3.gif" width="328" />
	</p>
	<p align="center">
	<strong>The use case Receive Deposit Item and its analysis-level class diagram</strong>.
	</p>
	<h4>
	Communication and Sequence Diagrams Owned by a Use-Case Realization
	</h4>
	<p>
	For each use-case realization there can be one or more interaction diagrams depicting its participating
	objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication
	diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence
	of messages and are better when it is important to visualize the time ordering of messages, whereas communication
	diagrams show the communication links between objects and are better for understanding all of the effects on a given
	object and for algorithm design.
	</p>
	<p>
	Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning
	responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to
	contain the following:
	</p>
	<ul>
	<li>
	Only the functionality actually used in support of a use case scenario.
	</li>
	<li>
	Functionality that can be tested through an associated test case.
	</li>
	<li>
	Functionality that is more easily traceable to requirements and changes.
	</li>
	<li>
	Explicitly declared class dependencies that are easier to manage.
	</li>
	</ul>
	<p>
	These factors help improve the overall quality of the system.
	</p><!-- END:mainDescription,-CFYVionNDLkMw6SG6runQA -->
	</body>
	</html>