| <?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.5/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-CFYVionNDLkMw6SG6runQA" |
| name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA" |
| changeDate="2008-01-25T10:04:23.710-0800" version="7.2.0"> |
| <mainDescription><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="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Guideline: 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></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
