commit 516e7d81c0a0f029a323dfdd3f546dcbb24ea62e
author bmacisaac <bmacisaac> Wed Aug 13 00:17:45 2008 +0000
committer bmacisaac <bmacisaac> Wed Aug 13 00:17:45 2008 +0000
tree 18675dac29b3a456e567948450a9194e6d71caf6
parent 2487990879b431b1e9eb38d7c9568f24b465b2e5

240040

libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi

diff --git a/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi b/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi
index 5706189..3074d24 100644
--- a/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi
+++ b/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi
@@ -4,17 +4,14 @@
     xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-xsQ27TDaTcUQ1VKUQG_HIQ"
     name=",_T9FbYFRFEd2o7OqLaYh8nA" guid="-xsQ27TDaTcUQ1VKUQG_HIQ" changeDate="2008-08-12T16:52:20.187-0700"
     version="7.5.0">
-  <mainDescription>&lt;h3>&#xD;
-    Introduction&#xD;
-&lt;/h3>&#xD;
-&lt;p>&#xD;
+  <mainDescription>&lt;p>&#xD;
     Requirements&amp;nbsp;realization represents how one or more requirements will be implemented. This can take various forms.&#xD;
     It may include, for example, a textual description (a document), class diagrams of participating classes and&#xD;
     subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate the flow of interactions&#xD;
     between class and subsystem instances.&#xD;
 &lt;/p>&#xD;
 &lt;p>&#xD;
-    In a model, requirements realization is represented as a UML collaboration that groups the diagrams and other&#xD;
+    In a model, requirements realization is typically represented as a UML collaboration that groups the diagrams and other&#xD;
     information (such as textual descriptions) that form part of the realization.&amp;nbsp;&amp;nbsp; If using use cases, the&#xD;
     collaboration may be further stereotyped as a use-case realization.&#xD;
 &lt;/p>&#xD;
@@ -23,44 +20,5 @@
     for larger projects, or families of systems where the same requirements may be designed differently in different&#xD;
     products within the product family. Consider the case of a family of telephone switches which have many requirements in&#xD;
     common, but which design and implement them differently according to product positioning, performance and price.&#xD;
-&lt;/p>&#xD;
-&lt;p>&#xD;
-    In the case of use cases and use-case realizations, for each use case in the use-case model, you can create a use-case&#xD;
-    realization in a design model with a realization relationship to the use case. In the UML this is shown as a dashed&#xD;
-    arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of inheritance, as&#xD;
-    well as a dependency (i.e. it could have been shown as a dependency stereotyped with &amp;lt;&amp;lt;realize&amp;gt;&amp;gt;).&#xD;
-&lt;/p>&#xD;
-&lt;p class=&quot;picturecenter&quot; align=&quot;center&quot;>&#xD;
-    &lt;img height=&quot;109&quot; alt=&quot;Diagram described in caption.&quot; src=&quot;./resources/ucrea1.gif&quot; width=&quot;291&quot; border=&quot;0&quot; />&#xD;
-&lt;/p>&#xD;
-&lt;p class=&quot;picturetext&quot;>&#xD;
-    A use-case realization in the analysis/design model can be traced to a use case in the use-case model.&#xD;
-&lt;/p>&#xD;
-&lt;h3>&#xD;
-    Class Diagrams Owned by a Realization&#xD;
-&lt;/h3>&#xD;
-&lt;p>&#xD;
-    For each realization there may be one or more class diagrams depicting its participating classes. The figure below&#xD;
-    shows a class diagram for the realization of the &lt;b>Receive Deposit Item&lt;/b> use case. A class and its objects often&#xD;
-    participate in several realizations. It is important during design to coordinate all the requirements on a class and&#xD;
-    its objects that different realizations may have.&#xD;
-&lt;/p>&#xD;
-&lt;p class=&quot;picturecenter&quot; align=&quot;center&quot;>&#xD;
-    &lt;img height=&quot;213&quot; alt=&quot;a communication diagram depicting a use-case realization&quot; src=&quot;./resources/md_ucre3.gif&quot;&#xD;
-    width=&quot;328&quot; />&#xD;
-&lt;/p>&#xD;
-&lt;p class=&quot;picturetext&quot;>&#xD;
-    The use case Receive Deposit Item and its class diagram.&#xD;
-&lt;/p>&#xD;
-&lt;h3>&#xD;
-    Communication and &lt;a id=&quot;Sequence Diagrams&quot; name=&quot;Sequence Diagrams&quot;>Sequence Diagrams Owned by a Realization&lt;/a>&#xD;
-&lt;/h3>&#xD;
-&lt;p>&#xD;
-    For each realization there can be one or more interaction diagrams depicting its participating objects and their&#xD;
-    interactions. There are two types of interaction diagrams: Sequence diagrams and communication diagrams. They express&#xD;
-    similar information, but show it in different ways. Sequence diagrams show the explicit sequence of messages and are&#xD;
-    better when it is important to visualize the time ordering of messages, whereas communication diagrams show the&#xD;
-    communication links between objects and are better for understanding all of the effects on a given object and for&#xD;
-    algorithm design.&#xD;
 &lt;/p></mainDescription>
 </org.eclipse.epf.uma:ContentDescription>