| <?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.3/uma.ecore" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-CFYVionNDLkMw6SG6runQA" name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA" changeDate="2006-09-26T15:24:33.595-0700" version="1.0.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="./../../../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></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |