OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/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&amp;#92;guidances&amp;#92;guidelines&amp;#92;&amp;#92;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: 1537362934 --><p>
     A use-case realization represents how a use case will be implemented in terms of collaborating objects. The
     realizations reside within the design. By walking through a design exercise of showing how the design elements will
     perform the use case, the team gets confirmation that the design is robust enough to perform the required behavior.
 </p>
 <p>
     The realization 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 requirements, in the
     form of use cases, to be managed separately from the design, in the form of realizations. This decoupling will prove
     invaluable if the architecture is changed enough that the realization needs to be reworked while the requirements
     remain unaffected. Even without such a circumstance, the clear separation of concerns between requirements and design
     is valuable.
 </p>
 <p>
     In a model, a use-case realization is represented as a UML (Unified Modeling Language) collaboration that groups the
     diagrams and other information (such as textual descriptions) that form the use-case realization.
 </p>
 <p>
     Like other aspects of the design, the UML diagrams that support use-case realizations can be produced at various levels
     of abstraction. A first pass in creating the realization might produce a diagram at an analysis level of abstraction
     where the participants will be high-level elements that are expected to be revisited and detailed down to the design
     level in&nbsp;a second pass. If the architecture and design idioms are well-understood, the realization could
     immediately be created at a low level of abstraction that specifies more detail on the elements and how they will
     collaborate to&nbsp;realize the behavior of the use case. In the latter case, it is valuable to model patterns and
     architectural mechanisms to reduce the amount of low-level detail in each realization.
 </p>
 <p>
     For each use case in the requirements, there can be a use-case realization in the design with a realization
     relationship to the use case, as the following figure shows. 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
     (see the figure that follows).
 </p>
 <p align="center">
     <strong><font face="Verdana, Arial, Helvetica, sans-serif" size="2">The UML notation for use-case
     realization</font></strong>
 </p>
 <p align="center">
     <img height="109" alt="Use Case Realisations" src="./resources/ucrea1.gif" width="277" />
 </p>
 <h3>
     Class diagrams owned by a use case realization
 </h3>For each use-case realization, there may be one or more class diagrams that depict its participating classes. A class
 and its objects often participate in several use-case realizations. While designing, it is important to coordinate all of
 the requirements related to a class 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. Notice the use of
 boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Guideline: Entity-Control-Boundary Pattern</a>).
 <p align="center">
     <strong><font face="Verdana, Arial, Helvetica, sans-serif" size="2">The use case Receive Deposit Item and its
     analysis-level class diagram</font></strong>
 </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><br align="center" />
 <br />
 <h3>
     Sequence and communication diagrams
 </h3>
 <p>
     For each use-case realization, there&nbsp;can be&nbsp;one or more interaction diagrams that depict&nbsp;the
     participating objects and their interactions. There are two types of interaction diagrams: <i>sequence</i> diagrams and
     <i>communication</i> diagrams. They express similar information, but show it in different ways.
 </p>
 <ul>
     <li>
         <b>Sequence diagrams</b> show the explicit sequence of messages and are better when it is important to visualize
         the time order of messages.
     </li>
     <li>
         <b>Communication diagrams</b> show the communication links between objects and are better for understanding all of
         the effects on a given object and for algorithm design.
     </li>
 </ul>
 <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 elements:
 </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&#92;guidances&#92;guidelines&#92;&#92;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: 1537362934 --><p>
	A use-case realization represents how a use case will be implemented in terms of collaborating objects. The
	realizations reside within the design. By walking through a design exercise of showing how the design elements will
	perform the use case, the team gets confirmation that the design is robust enough to perform the required behavior.
	</p>
	<p>
	The realization 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 requirements, in the
	form of use cases, to be managed separately from the design, in the form of realizations. This decoupling will prove
	invaluable if the architecture is changed enough that the realization needs to be reworked while the requirements
	remain unaffected. Even without such a circumstance, the clear separation of concerns between requirements and design
	is valuable.
	</p>
	<p>
	In a model, a use-case realization is represented as a UML (Unified Modeling Language) collaboration that groups the
	diagrams and other information (such as textual descriptions) that form the use-case realization.
	</p>
	<p>
	Like other aspects of the design, the UML diagrams that support use-case realizations can be produced at various levels
	of abstraction. A first pass in creating the realization might produce a diagram at an analysis level of abstraction
	where the participants will be high-level elements that are expected to be revisited and detailed down to the design
	level in a second pass. If the architecture and design idioms are well-understood, the realization could
	immediately be created at a low level of abstraction that specifies more detail on the elements and how they will
	collaborate to realize the behavior of the use case. In the latter case, it is valuable to model patterns and
	architectural mechanisms to reduce the amount of low-level detail in each realization.
	</p>
	<p>
	For each use case in the requirements, there can be a use-case realization in the design with a realization
	relationship to the use case, as the following figure shows. 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
	(see the figure that follows).
	</p>
	<p align="center">
	<strong><font face="Verdana, Arial, Helvetica, sans-serif" size="2">The UML notation for use-case
	realization</font></strong>
	</p>
	<p align="center">
	<img height="109" alt="Use Case Realisations" src="./resources/ucrea1.gif" width="277" />
	</p>
	<h3>
	Class diagrams owned by a use case realization
	</h3>For each use-case realization, there may be one or more class diagrams that depict its participating classes. A class
	and its objects often participate in several use-case realizations. While designing, it is important to coordinate all of
	the requirements related to a class 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. Notice the use of
	boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Guideline: Entity-Control-Boundary Pattern</a>).
	<p align="center">
	<strong><font face="Verdana, Arial, Helvetica, sans-serif" size="2">The use case Receive Deposit Item and its
	analysis-level class diagram</font></strong>
	</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><br align="center" />
	<br />
	<h3>
	Sequence and communication diagrams
	</h3>
	<p>
	For each use-case realization, there can be one or more interaction diagrams that depict the
	participating objects and their interactions. There are two types of interaction diagrams: <i>sequence</i> diagrams and
	<i>communication</i> diagrams. They express similar information, but show it in different ways.
	</p>
	<ul>
	<li>
	<b>Sequence diagrams</b> show the explicit sequence of messages and are better when it is important to visualize
	the time order of messages.
	</li>
	<li>
	<b>Communication diagrams</b> show the communication links between objects and are better for understanding all of
	the effects on a given object and for algorithm design.
	</li>
	</ul>
	<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 elements:
	</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>