Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You must be thinking of Use Case relationships. Quoting <a href="http://en.wikipedia.org/wiki/Use_case_diagram" rel="nofollow noreferrer">wikipedia</a>:</p> <blockquote> <p><strong>Use Case Relationships</strong></p> <p>Three relationships among use cases are used often in practice. </p> <p><strong>Include</strong></p> <p>In one form of interaction, a given use case may include another. "Include is a Directed Relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case"<a href="http://en.wikipedia.org/wiki/Use_case_diagram" rel="nofollow noreferrer">1</a>.</p> <p>The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from multiple use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label "«include»". This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no parameters or return values. To specify the location in a flow of events in which the base use case includes the behavior of another, you simply write include followed by the name of use case you want to include, as in the following flow for track order. </p> <p><strong>Extend</strong></p> <p>In another form of interaction, a given use case (the extension) may extend another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions<a href="http://en.wikipedia.org/wiki/Use_case_diagram" rel="nofollow noreferrer">1</a>. The notation is a dashed arrow from the extension to the extended use case, with the label "«extend»". Notes or constraints may be associated with this relationship to illustrate the conditions under which this behaviour will be executed.</p> <p>Modelers use the «extend» relationship to indicate use cases that are "optional" to the base use case. Depending on the modeler's approach "optional" may mean "potentially not executed with the base use case" or it may mean "not required to achieve the base use case goal."</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload