<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore"
    xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.2.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.2.0" xmi:id="-CFYVionNDLkMw6SG6runQA"
    name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA"
    changeDate="2006-09-26T15:24:33.595-0700">
  <mainDescription>&lt;p>&#xD;
    A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact&#xD;
    can take various forms. It may include, for example, a textual description (a document), class diagrams of&#xD;
    participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate&#xD;
    the flow of interactions between class and subsystem instances.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The reason for separating the use-case realization from its use case is that doing so allows the use cases to be&#xD;
    managed separately from their realizations. This is particularly important for larger projects, or families of systems&#xD;
    where the same use cases may be designed differently in different products within the product family. Consider the case&#xD;
    of a family of telephone switches which have many use cases in common, but which design and implement them differently&#xD;
    according to product positioning, performance and price.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For larger projects, separating the use case and its realization allows changes to the design of the use case without&#xD;
    affecting the baselined use case itself.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information&#xD;
    (such as textual descriptions) that form part of the use-case realization.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    UML diagrams that&amp;nbsp;support use-case realizations can be produced in an analysis context, a&amp;nbsp;design context, or&#xD;
    both, depending on the needs of the project. For each use case in the use-case model, there&amp;nbsp;can be&amp;nbsp;a use-case&#xD;
    realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a&#xD;
    dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of&#xD;
    inheritance, as well as a dependency.&lt;br />&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;109&quot; alt=&quot;Use Case Realisations&quot; src=&quot;./resources/ucrea1.gif&quot; width=&quot;277&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A use-case realization in the&amp;nbsp;design can be traced to a use case in the use-case model.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Class Diagrams Owned by a Use-Case Realization&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    For each use-case realization there may be one or more class diagrams depicting its participating classes. A class and&#xD;
    its objects often participate in several use-case realizations. It is important&amp;nbsp;while designing to coordinate all&#xD;
    the requirements on a class and its objects that different use-case realizations may have. The figure below shows an&#xD;
    analysis&amp;nbsp;class diagram for the realization of the Receive Deposit Item use case. Note the use of&#xD;
    boundary-control-entity stereotypes to represent analysis classes (see &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.slot.base/guidances/concepts/entity_control_boundary_pattern_C4047897.html&quot;&#xD;
    guid=&quot;_uF-QYEAhEdq_UJTvM1DM2Q&quot;>Concept: Entity-Control-Boundary Pattern&lt;/a>).&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;213&quot; alt=&quot;Class diagram for the realization of Receive Deposit Item&quot; src=&quot;./resources/md_ucre3.gif&quot;&#xD;
    width=&quot;328&quot; />&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;strong>The use case Receive Deposit Item and its analysis-level class diagram&lt;/strong>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Communication and Sequence Diagrams Owned by a Use-Case Realization&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    For each use-case realization there&amp;nbsp;can be&amp;nbsp;one or more interaction diagrams depicting its participating&#xD;
    objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication&#xD;
    diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence&#xD;
    of messages and are better when it is important to visualize the time ordering of messages, whereas communication&#xD;
    diagrams show the communication links between objects and are better for understanding all of the effects on a given&#xD;
    object and for algorithm design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning&#xD;
    responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to&#xD;
    contain the following:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Only the functionality actually used in support of a use case scenario&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Functionality that can be tested through an associated test case&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Functionality that is more easily traceable to requirements and changes&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Explicitly declared class dependencies that are easier to manage&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These factors help improve the overall quality of the system.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>