<?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" epf:version="1.0.0" xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" name="use_case,_KudM0NcJEdqz_d2XWoVt6Q" guid="-BQLZ5GRUNrMdU6XeZAfe9Q" changeDate="2006-11-03T12:00:52.609-0500">
  <mainDescription>&lt;h3&gt;
    &lt;a id=&quot;Definitions&quot; name=&quot;Definitions&quot;&gt;Definitions&lt;/a&gt;
&lt;/h3&gt;
&lt;h4&gt;
    Use Case
&lt;/h4&gt;
&lt;p&gt;
    A use case instance defines a sequence of actions performed by the system that yields an observable result of value to
    a particular actor. There are several key words in this definition:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;b&gt;&quot;use case instance&quot;&lt;/b&gt; The sequence referred to in the definition is actually a specific flow of events through
        the system, or an instance. Many flows of events are possible, and many may be very similar. To make a use-case
        understandable, you should group similar flows of events into one use case. Therefore, identifying and describing a
        use case really means identifying and describing a group of related flows of events.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;&quot;actions&quot;&lt;/strong&gt; An action is a computational or algorithmic procedure. It is invoked either when the
        actor provides a signal to the system or when the system gets a time event. An action may imply signal
        transmissions to either the invoking actor or other actors. An action is atomic, which means it is performed either
        entirely or not at all.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;&quot;performed by the system&quot;&lt;/b&gt; This means that the system provides the use case. An actor communicates with a
        use-case instance of the system.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;&quot;an observable result of value&quot;&lt;/b&gt; You can put a value on a successfully performed use case. A use case should
        make sure that an actor can perform a task that has an identifiable value. This is very important in determining
        the correct level or granularity for a use case. &lt;em&gt;Correct level&lt;/em&gt; refers to achieving use cases that are not
        too small.&amp;nbsp;&amp;nbsp;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;&quot;a&amp;nbsp;particular actor&quot;&lt;/b&gt; The actor is key to finding the correct use case, especially because the actor
        helps you avoid use cases that are too large. As an example, consider a visual modeling tool. There are really two
        actors&amp;nbsp;in this application: a developer, who develops systems using the tool as support; and a system
        administrator, who manages the tool. Each of these actors has his own demands on the system, and will therefore
        require his own set of use cases.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    The functionality of a system is defined by different use cases, each of which represents a specific goal (observable
    result of value) for a particular actor. The description of a use case defines what happens in the system when the use
    case is performed.
&lt;/p&gt;
&lt;p class=&quot;picturecenter&quot; align=&quot;center&quot;&gt;
    &lt;img height=&quot;173&quot; alt=&quot;Diagram described in caption.&quot; src=&quot;./resources/im_uc.gif&quot; width=&quot;325&quot; /&gt;
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
        &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
            &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
                &lt;p class=&quot;picturetext&quot;&gt;
                    Figure 1: ATM use case example.
                &lt;/p&gt;
            &lt;/blockquote&gt;
        &lt;/blockquote&gt;
    &lt;/blockquote&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    In an automated teller machine the client can, for instance, withdraw money from an account, transfer money to an
    account, or check the balance of an account. These correspond to specific goals that the actor has in using the system.
&lt;/p&gt;
&lt;p&gt;
    Each use case has a task of its own to perform. The collected use cases constitute all the possible ways of using the
    system. You should be able to&amp;nbsp;determine the goal&amp;nbsp;of a use-case task simply by observing its name.&amp;nbsp;&amp;nbsp;
&lt;/p&gt;
&lt;h4&gt;
    &lt;a id=&quot;A Use-Case has Many Possible Instances&quot; name=&quot;A Use-Case has Many Possible Instances&quot;&gt;Use-Case&lt;/a&gt;
    Instance&amp;nbsp;
&lt;/h4&gt;
&lt;p&gt;
    A use-case can follow an almost unlimited, but enumerable, number of paths. These paths represent the choices open to
    the use-case in the description of its flow of events. The path chosen depends on events. Types of events include:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;strong&gt;Input from an actor&amp;nbsp;&lt;/strong&gt;
    &lt;/li&gt;
&lt;/ul&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        For example, an actor can decide, from several options, what to do next. In the use case Recycle Items in the
        Recycling-Machine System the Customer always has two options: insert another deposit item or get the
        receipt&amp;nbsp;for returned items.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;strong&gt;A check of values or types of an internal object or attribute&lt;/strong&gt;
    &lt;/li&gt;
&lt;/ul&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        For example, the flow of events may differ if a value is greater or less than a certain value.&amp;nbsp;In the use case
        Withdraw Money in an automated teller machine system, the flow of events will differ if the Client asks for more
        money than he has in his account. In that situation, the use-case instance follows a&amp;nbsp;different path.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;h4&gt;
    Scenario
&lt;/h4&gt;
&lt;p&gt;
    A scenario is a specific sequence of actions that illustrates a behavior.&amp;nbsp; A scenario may be used to illustrate a
    use-case instance and to specify test cases.
&lt;/p&gt;
&lt;h4&gt;
    Use-Case Realization
&lt;/h4&gt;
&lt;p&gt;
    A use case describes what happens in the system when an actor interacts with the system. The use case does not define
    how the system&amp;nbsp;performs its tasks, in terms of collaborating objects. This is left for the use-case realizations
    to show.
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        In the telephone example, the use case would indicate (among other things) that the system issues a signal when the
        actor lifts the receiver,&amp;nbsp; and that the system then receives digits, finds the receiving party, rings his
        telephone, connects the call, transmits speech, and so on.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    In a running&amp;nbsp;system, an instance of a use case does not correspond to any particular object in the implementation
    model (for example, an instance of a class in the code). Instead, it corresponds to a specific flow of events that is
    invoked by an actor and&amp;nbsp;performed as a sequence of events among a set of objects. In other words, instances of use
    cases correspond to communicating instances of implemented objects. We call this the &lt;strong&gt;realization of the use
    case&lt;/strong&gt;. Often, the same objects participate in realizations of more than one use case. For example, both the use
    cases Deposit and Withdrawal in a banking system may use a certain account object in their realization. This does not
    mean that the two use cases communicate, but only that they use the same object in their realization.
&lt;/p&gt;
&lt;p&gt;
    You can&amp;nbsp;think of&amp;nbsp;a flow of events as consisting of several subflows that,&amp;nbsp;taken together, yield the
    total flow of events. You can reuse the description of a subflow in other flows of events for other use cases. Subflows
    in the description of one use case's flow of events may be common to those of other use cases. In the design you should
    have the same objects perform this common behavior for all the relevant use cases. That is, only one set of objects
    should perform this behavior no matter which use case is running.
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        In an automated teller machine system, the initial subflow is the same in the flow of events of the use cases
        Withdraw Money and Check Balance. The flow of events of both use cases start by checking the identity of the card
        and the client's personal access code.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;h3&gt;
    Properties of Use Cases
&lt;/h3&gt;
&lt;h4&gt;
    &lt;a id=&quot;Name&quot; name=&quot;Name&quot;&gt;Name&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have
    to be several words to be understood. Note: No two use cases can have the same name.
&lt;/p&gt;
&lt;blockquote&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        These are examples of variations of the name for the use case Recycle Items in the Recycling Machine example:
    &lt;/p&gt;
    &lt;ul&gt;
        &lt;li&gt;
            Return Deposit Items
        &lt;/li&gt;
        &lt;li&gt;
            Deposit Items
        &lt;/li&gt;
    &lt;/ul&gt;
&lt;/blockquote&gt;
&lt;h4&gt;
    &lt;a id=&quot;Brief Description&quot; name=&quot;Brief Description&quot;&gt;Brief Description&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    The brief description of the use case should reflect its purpose. As you write the description, refer to the actors
    involved in the use case and the glossary.&amp;nbsp;If you need to, define new concepts.
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        Following are sample brief descriptions of the use cases Recycle Items and Add New Bottle Type in the
        Recycling-Machine system.
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        &lt;b&gt;Recycle Items&lt;/b&gt;: The user uses this machine to automatically have all the return items (bottles, cans, and
        crates) counted, and receives a receipt. The receipt is to be cashed at a cash register (another machine).
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        &lt;b&gt;Add New Bottle Type&lt;/b&gt;: The manager can add options for the user to return new kinds of bottles can be added to
        the machine by starting it in &lt;em&gt;learning&lt;/em&gt; mode and inserting 5 samples, just&amp;nbsp;as when the customers
        return items. The machine can measure the bottles and learns to identify them. The manager specifies the refund
        value for the new bottle type.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;h4&gt;
    Flow of Events
&lt;/h4&gt;
&lt;h5&gt;
    &lt;a id=&quot;XE_use_case__flow_of_events&quot; name=&quot;XE_use_case__flow_of_events&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_flow_of_events__guidelines_for&quot; name=&quot;XE_flow_of_events__guidelines_for&quot;&gt;&lt;/a&gt;&lt;a id=&quot;Flow of Events - Contents&quot; name=&quot;Flow of Events - Contents&quot;&gt;Flow of
    Events - Contents&lt;/a&gt;
&lt;/h5&gt;
&lt;p&gt;
    The f&lt;b&gt;low of events&lt;/b&gt; of a use case contains the most important information derived from use-case modeling work. It
    should describe the use case's flow of events clearly enough for an outsider to easily understand. Remember, the flow
    of events should represent &lt;em&gt;what&lt;/em&gt; the system does, not &lt;em&gt;how&lt;/em&gt; the system is design to perform the required
    behavior.
&lt;/p&gt;
&lt;p&gt;
    Follow these guidelines for the contents of the flow of events:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Describe how the use case starts and ends.
    &lt;/li&gt;
    &lt;li&gt;
        Describe what data is exchanged between the actor and the use case.
    &lt;/li&gt;
    &lt;li&gt;
        Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system.
        For example, it is often good to use a limited set of web-specific terminology when it is known beforehand that the
        application is going to be web-based. Otherwise, your run the risk that the use-case text is being perceived as too
        abstract. Words to include in your terminology could be &quot;navigate&quot;, &quot;browse&quot;, &quot;hyperlink&quot; &quot;page&quot;, &quot;submit&quot;, and
        &quot;browser&quot;. However, it is not advisable to include references to &quot;frames&quot; or &quot;web pages&quot; in such a way that you are
        making assumptions about the boundaries between them; this is a critical design decision.&amp;nbsp;
    &lt;/li&gt;
    &lt;li&gt;
        Describe the flow of events, not only the functionality. To enforce this, start every action with &quot;When the actor
        ... &quot;.
    &lt;/li&gt;
    &lt;li&gt;
        Describe only the events that belong to the use case, and not what happens in other use cases or outside of the
        system.
    &lt;/li&gt;
    &lt;li&gt;
        Avoid vague terminology.
    &lt;/li&gt;
    &lt;li&gt;
        Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
        test cases.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
    that&amp;nbsp;the meaning of the terms is consistent. To manage common terms, put them in a glossary.
&lt;/p&gt;
&lt;h5&gt;
    &lt;a id=&quot;Flow of Events - Structure&quot; name=&quot;Flow of Events - Structure&quot;&gt;Flow of Events - Structure&lt;/a&gt;
&lt;/h5&gt;
&lt;p&gt;
    The two main parts of the flow of events are &lt;b&gt;basic flow of events&lt;/b&gt; and &lt;a id=&quot;XE_flow_of_events__alternative_flow&quot; name=&quot;XE_flow_of_events__alternative_flow&quot;&gt;&lt;/a&gt;&lt;b&gt;alternative flows of
    events&lt;/b&gt;. The basic flow of events should cover what &quot;normally&quot; happens when the use case is performed. The
    alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and
    also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow
    of events, some of which will return to the basic flow of events and some of which will end the execution of the use
    case.
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
    &lt;img height=&quot;212&quot; alt=&quot;Diagram described in caption.&quot; src=&quot;./resources/ucstrct.gif&quot; width=&quot;231&quot; /&gt;
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
        &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
            &lt;p class=&quot;picturetext&quot;&gt;
                Figure 2: Typical structure of a use case flow of events
            &lt;/p&gt;
        &lt;/blockquote&gt;
    &lt;/blockquote&gt;
&lt;/blockquote&gt;
&lt;p class=&quot;picturetext&quot;&gt;
    The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
    relation to the normal. Some alternative paths return to the basic flow of events, whereas,&amp;nbsp;others end the use
    case.
&lt;/p&gt;
&lt;p&gt;
    Both the basic and alternative flows should be further structured into steps or subflows. In doing this, your main goal
    should be readability of the text (see the &lt;em&gt;Flow of Events - Style&lt;/em&gt; section, which follows). A&amp;nbsp;guideline is
    that a subflow should be a segment of behavior within the use case that has a clear purpose, and is &quot;atomic&quot; in the
    sense that you do either all or none of the actions described. You may need to have several levels of subflows,
    but&amp;nbsp;avoid that if you can,&amp;nbsp;since it makes the text more complex and harder to understand.
&lt;/p&gt;
&lt;p&gt;
    The nature of this type of written text, structured into consecutive subsections,&amp;nbsp;implies to the reader that there
    is a sequence between the subflows. To avoid misunderstandings, you should always point out whether the order of the
    subflows is fixed or not. Considerations of this kind are often related to factors such as:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;strong&gt;Business rules&lt;/strong&gt;. For example, the user has to be authorized before the system can make certain data
        available.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;User-interface design.&lt;/strong&gt; For example, the system should not enforce a certain sequence of behavior
        that may be intuitive to some but not to other users.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    To clarify where an alternative flow of events fits in the structure, you need to describe the following for each
    detour to the basic flow of events:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Where the alternative flow can be inserted in the basic flow of events.
    &lt;/li&gt;
    &lt;li&gt;
        The condition that needs to be fulfilled for the alternative behavior to start.
    &lt;/li&gt;
    &lt;li&gt;
        How and where the basic flow of events is resumed, or how the use case ends.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        2.1. Bottle Stuck
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        If in section 1.5, Insert Deposit Items, a bottle gets stuck in the gate, the sensors around the gate and the
        measuring gate will detect this problem. The conveyer belt is stopped and the machine issues an alarm to call for
        the operator. The machine will wait for the operator to indicate that the problem has been fixed. The machine then
        continues in section 1.9 of the basic flow.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;p dir=&quot;ltr&quot;&gt;
    In the example above, the alternative flow of events is inserted at a specific location in the basic flow of events.
    There are also alternative flow of events that can be inserted at more than one location, some can even be inserted at
    any location in the basic flow of events.
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
    &lt;/p&gt;
    &lt;p&gt;
        2.2. Front Panel is Removed
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        If somebody removes the front panel to the Recycling machine, the can compression is deactivated. It will not be
        possible to start the can compression with the front panel off. The removal will also activate an
        alarm&amp;nbsp;for&amp;nbsp;operator attention. When the front panel is closed again, the machine resumes operation from
        the point where it stopped in&amp;nbsp;the basic flow of events.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events
    section (using some informal &quot;if-then-else&quot; construct). This should be avoided. Too many alternatives will make the
    normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the
    text more pseudo-code like and harder to read.
&lt;/p&gt;
&lt;p&gt;
    In general, extracting parts of the flow of events and describing these parts separately, can increase the readability
    of the basic flow of events and improve the structure of the use case and the use-case model. You can model extracted
    parts as the situation requires:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        An &lt;strong&gt;alternative&lt;/strong&gt; flow of events within the base use case if it is a simple variant, option, or
        exception to the basic flow of events.
    &lt;/li&gt;
    &lt;li&gt;
        As an &lt;strong&gt;explicit&lt;/strong&gt; inclusion in the base use case, if it is something that you wish to encapsulate so
        that it can be reused by other use cases.
    &lt;/li&gt;
    &lt;li&gt;
        As an &lt;strong&gt;implicit&lt;/strong&gt; inclusion in the base use case, if the basic flow of events of the base use case is
        complete, that is, has a defined beginning and end. The nature of the extending flow should be such that you prefer
        to conceal it in the description of the base use case to render it less complex.
    &lt;/li&gt;
    &lt;li&gt;
        A &lt;strong&gt;subflow&lt;/strong&gt; in the basic flow of events, possibly as another option, if none of the above
        alternatives applies. For example, in a Maintain Employee Information use case, there may be separate subflows for
        adding, deleting and modifying employee information.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;h5&gt;
    &lt;a id=&quot;Flow of Events - Style&quot; name=&quot;Flow of Events - Style&quot;&gt;Flow of Events - Style&lt;/a&gt;
&lt;/h5&gt;
&lt;p&gt;
    You can describe use cases in many styles. As an example we show the basic flow of events of the use case Administer
    Order described in three different styles, varying primarily in how formal they are.
&lt;/p&gt;
&lt;p&gt;
    The first style, shown in Example 1, is the recommended one, because it is easy to understand, and the order in which
    things happen is clearly evident. The text is divided into numbered and named subsections. Numbers are there to make it
    easy to refer to a subsection. Names of subsections will let the reader get a quick overview of the flow of events by
    browsing through the text reading only the headers.
&lt;/p&gt;
&lt;p&gt;
    In Example 2, the description of the flow of events fails to clarify the order in which things happen. If you write in
    this style, you and others might miss important things that concern the system.
&lt;/p&gt;
&lt;p&gt;
    Example 3 below shows a yet another style, which can be useful if you find it difficult to express the sequence of
    events clearly. This pseudo-code style is more precise, but the text is hard to read and absorb for a non-technical
    person, especially if you want to grasp the flow of events quickly.
&lt;/p&gt;
&lt;p&gt;
    Finally,&amp;nbsp;Example 4&amp;nbsp;provides an example of a complete description of a use case flow of events.&amp;nbsp;
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p&gt;
        &lt;a id=&quot;Example 1:&quot; name=&quot;Example 1:&quot;&gt;&lt;strong&gt;Example 1:&lt;/strong&gt;&lt;/a&gt; &lt;strong&gt;Recommended style for describing a use
        case&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p&gt;
        In this style, the text is easy to read and the flow of events is easy to follow.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;div align=&quot;center&quot;&gt;
    &lt;table     style=&quot;BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid&quot;      cellspacing=&quot;0&quot; bordercolordark=&quot;#808080&quot; cellpadding=&quot;4&quot; width=&quot;85%&quot; bordercolorlight=&quot;#808080&quot; border=&quot;1&quot;&gt;
        &lt;tbody&gt;
            &lt;tr&gt;
                &lt;td width=&quot;100%&quot;&gt;
                    &lt;b&gt;1.1. Start of Use Case&lt;/b&gt; 
                    &lt;p&gt;
                        This use case starts when the actor Operator tells the system to create a measurement order. The
                        system will then retrieve all Network Element actors, their measurement objects and corresponding
                        measurement functions that are available to this particular Operator. Available Network Elements
                        are those that are in operation, and that the Operator has the authority to access. The
                        availability of measurement functions depends on what has been set up for a particular type of
                        measurement object.
                    &lt;/p&gt;
                    &lt;p&gt;
                        &lt;b&gt;1.2. Configure Measurement Order&lt;/b&gt;
                    &lt;/p&gt;
                    &lt;p&gt;
                        The system allows the actor Operator to select which Network Elements to measure and then shows
                        which measurement objects are available for the selected Network Elements. The system allows the
                        Operator to select from the measurement objects, and then select which measurement functions to set
                        up for each measurement object.
                    &lt;/p&gt;
                    &lt;p&gt;
                        The system allows the Operator to enter a textual comment on the measurement order.
                    &lt;/p&gt;
                    &lt;p&gt;
                        The Operator tells the system to complete the measurement order. The system will respond by
                        generating a unique name for the measurement order and setting up default values for when, how
                        often, and for how long the measurement should be made. The default values are unique to each
                        Operator. The system then allows the Operator to edit these default values.
                    &lt;/p&gt;
                    &lt;p&gt;
                        &lt;b&gt;1.3. Initialize Order&lt;/b&gt;
                    &lt;/p&gt;
                    &lt;p&gt;
                        The Operator tells the system to initialize the measurement order. The system will then record the
                        identity of the creating Operator, the date of creation, and the &quot;Scheduled&quot; status of the
                        measurement order.
                    &lt;/p&gt;
                    &lt;p&gt;
                        &lt;b&gt;1.4. Use Case Ends&lt;/b&gt;
                    &lt;/p&gt;
                    &lt;p&gt;
                        The system confirms initialization of the measurement order to the Operator, and the measurement
                        order is made available for other actors to view.
                    &lt;/p&gt;
                &lt;/td&gt;
            &lt;/tr&gt;
        &lt;/tbody&gt;
    &lt;/table&gt;
&lt;/div&gt;
&lt;div align=&quot;center&quot;&gt;
    &lt;br /&gt;
&lt;/div&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p&gt;
        &lt;a id=&quot;Example 2:&quot; name=&quot;Example 2:&quot;&gt;&lt;strong&gt;Example 2:&lt;/strong&gt;&lt;/a&gt; &lt;strong&gt;Alternative way of describing a use
        case&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p&gt;
        This style is readable, but there is no clear flow of events.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;div align=&quot;center&quot;&gt;
    &lt;table     style=&quot;BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid&quot;      cellspacing=&quot;0&quot; bordercolordark=&quot;#808080&quot; cellpadding=&quot;4&quot; width=&quot;85%&quot; bordercolorlight=&quot;#808080&quot; border=&quot;1&quot;&gt;
        &lt;tbody&gt;
            &lt;tr&gt;
                &lt;td width=&quot;100%&quot;&gt;
                    Orderers can create Orders to collect measurement data from the Network Elements. 
                    &lt;p&gt;
                        The system will assign the Order a unique name as well as default values that indicate the length
                        and time of the measurement and also how often it is to be repeated. The Orderer will be able to
                        edit these values.
                    &lt;/p&gt;
                    &lt;p&gt;
                        The Orderer must further specify which measurement function, network element and measurements
                        objects are applicable. The Orderer can also add a personal comment to the order.
                    &lt;/p&gt;
                    &lt;p&gt;
                        When the necessary information had been defined, a new Order is created and initialized with the
                        defined attributes, the name of the creator, and the date of creation. The status of the order will
                        be set to &quot;scheduled&quot;. (Possible values for the status are: Scheduled, Executing, Completed,
                        Canceled, and Erroneous.)
                    &lt;/p&gt;
                    &lt;p&gt;
                        The user interface is then notified that a new Order has been created and receives a reference to
                        the new Order so that it can be displayed.
                    &lt;/p&gt;
                &lt;/td&gt;
            &lt;/tr&gt;
        &lt;/tbody&gt;
    &lt;/table&gt;
&lt;/div&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p&gt;
        &lt;a id=&quot;Example 3:&quot; name=&quot;Example 3:&quot;&gt;&lt;strong&gt;Example 3:&lt;/strong&gt;&lt;/a&gt; &lt;strong&gt;Another way of describing a use
        case&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p&gt;
        Here the writer has chosen a formal style using pseudocode. This style makes it hard to quickly grasp the process
        steps, but can be useful if the flow of events is difficult to capture precisely.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;div align=&quot;center&quot;&gt;
    &lt;table     style=&quot;BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid&quot;      cellspacing=&quot;0&quot; bordercolordark=&quot;#808080&quot; cellpadding=&quot;4&quot; width=&quot;50%&quot; bordercolorlight=&quot;#808080&quot; border=&quot;1&quot;&gt;
        &lt;tbody&gt;
            &lt;tr&gt;
                &lt;td width=&quot;100%&quot;&gt;
&lt;pre&gt;
&lt;font size=&quot;2&quot;&gt;&lt;small&gt;'Administrate order' (User identity) 
REPEAT
  &amp;lt;='Show administer order menu'
  IF (=&amp;gt; 'Creating an Order' (Measurement function, network element, measurement object)) THEN
     The system finds a unique name, default values for when and how long the measurement should be executed. 
     &amp;lt;= 'Show order' (Default attributes)
    REPEAT
         IF (=&amp;gt; 'Edit order' (Attribute to change, New value of  attribute)) THEN
               &amp;lt;= 'Update screen' (New attributes)
         ELSIF (=&amp;gt; 'Save order' (Order identity, Attributes)) THEN
              The order is created and initialized in the system with
              the defined attributes, the name of the creator,
              date of creation and the status 'scheduled'.
              &amp;lt;= 'New order created' (The order)
         ENDIF
     UNTIL (=&amp;gt; 'Quit') 
  ENDIF 
UNTIL 'Quit administer order'&lt;/small&gt;
&lt;/font&gt;
&lt;/pre&gt;
                &lt;/td&gt;
            &lt;/tr&gt;
        &lt;/tbody&gt;
    &lt;/table&gt;
&lt;/div&gt;
&lt;h5&gt;
    &lt;a id=&quot;Example 3:&quot; name=&quot;Example 3:&quot;&gt;Example 4:&lt;/a&gt;&amp;nbsp;Complete description fo the flow of events&amp;nbsp;
&lt;/h5&gt;
&lt;p&gt;
    The complete description of the flow of events of the use case Administer Order, including its alternative flows, could
    look like the example that follows:
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p&gt;
        &lt;b&gt;1.&amp;nbsp;BASIC FLOW&amp;nbsp;OF EVENTS&lt;/b&gt;&amp;nbsp;
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;1.1. Start use case&lt;/b&gt;
    &lt;/p&gt;
    &lt;p&gt;
        This use case starts when the actor Operator tells the system to create a measurement order. The system will then
        retrieve all Network Element actors, their measurement objects and corresponding measurement functions that are
        available to this particular Operator. Available Network Elements are those that are in operation, and that the
        Operator has the authority to access. The availability of measurement functions depends on what has been set up for
        a particular type of measurement object.
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;1.2. Configure measurement order&lt;/b&gt;
    &lt;/p&gt;
    &lt;p&gt;
        The system allows the actor Operator to select which Network Elements to measure and then shows which measurement
        objects are available for the selected Network Elements. The system allows the Operator to select from these
        measurement objects, and then select which measurement functions to set up for each measurement object.
    &lt;/p&gt;
    &lt;p&gt;
        The system allows the Operator to enter a textual comment on the measurement order.
    &lt;/p&gt;
    &lt;p&gt;
        The Operator tells the system to complete the measurement order. The system will respond by generating a unique
        name for the measurement order and setting up default values for when, how often, and for how long the measurement
        should be made. The default values are unique to each Operator. The system then allows the Operator to edit these
        default values.
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;1.3. Initialize order&lt;/b&gt;
    &lt;/p&gt;
    &lt;p&gt;
        The Operator tells the system to initialize the measurement order. The system will then record the identity of the
        creating Operator, the date of creation, and the &quot;Scheduled&quot; status of the measurement order.
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;1.4. End use case&lt;/b&gt;
    &lt;/p&gt;
    &lt;p&gt;
        The system confirms initialization of the measurement order to the Operator, and the measurement order is made
        available for other actors to view.
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;2.&amp;nbsp;ALTERNATIVE FLOW OF EVENTS&lt;/b&gt;&amp;nbsp;
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;2.1. No network elements available&lt;/b&gt;
    &lt;/p&gt;
    &lt;p&gt;
        If in 1.1, Start use case, it turns out that no Network Elements are available to measure for this Operator, the
        system will inform the Operator. The use case then ends.
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;2.2. No measurement functions available&lt;/b&gt;
    &lt;/p&gt;
    &lt;p&gt;
        If in 1.2, Configure measurement order, no measurement functions are available for the selected Network Elements,
        the system will inform the Operator and allow the Operator to select other Network elements.
    &lt;/p&gt;
    &lt;p&gt;
        &lt;b&gt;2.3. Cancel measurement order&lt;/b&gt;
    &lt;/p&gt;
    &lt;p&gt;
        The system will allow the Operator to cancel all actions at any point during the execution of the use case. The
        system will then return to the state it was in before the use case was started, and end the use case.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;h4&gt;
    &lt;a id=&quot;XE_use_case__flow_of_events&quot; name=&quot;XE_use_case__flow_of_events&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_flow_of_events__guidelines_for&quot; name=&quot;XE_flow_of_events__guidelines_for&quot;&gt;&lt;/a&gt;&lt;a id=&quot;Special Requirements&quot; name=&quot;Special Requirements&quot;&gt;Special
    Requirements&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    In the Special Requirements of a use case, you describe all the requirements on the use case that are not covered by
    the flow of events. These are non-functional requirements that will influence the design model. See also the discussion
    on non-functional requirements in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0Wh-sMlgEdmt3adZL5Dmdw&quot;&gt;Concept: Requirements&lt;/a&gt;. You could organize these requirements in categories such as
    Usability, Reliability, Performance, and Substitutability, but normally there are so few of them that such grouping is
    not particularly value-adding.
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;h5&gt;
        Example
    &lt;/h5&gt;
    &lt;p class=&quot;example&quot;&gt;
        In the Recycling-Machine System, a special requirement of the Return Deposit Items use case could be:
    &lt;/p&gt;
    &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
        &lt;p class=&quot;example&quot;&gt;
            The machine has to be able to recognize deposit items with a reliability of more than 95 percent.
        &lt;/p&gt;
    &lt;/blockquote&gt;
&lt;/blockquote&gt;
&lt;h4&gt;
    &lt;a id=&quot;XE_postcondition__guidelines_for&quot; name=&quot;XE_postcondition__guidelines_for&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_precondition__guidelines_for&quot; name=&quot;XE_precondition__guidelines_for&quot;&gt;&lt;/a&gt;&lt;a id=&quot;preconditions and Postconditions&quot; name=&quot;preconditions and Postconditions&quot;&gt;Preconditions and Post-conditions&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    A &lt;strong&gt;precondition&lt;/strong&gt; is the state of the system and its surroundings that is required before the use case
    can be started.&amp;nbsp;Post-Conditions are&amp;nbsp;the states the system can be in after the use case has ended. It can
    be&amp;nbsp;helpful to use the&amp;nbsp;concepts of &lt;b&gt;precondition&lt;/b&gt; and &lt;b&gt;post-condition&lt;/b&gt; to clarify how the flow of
    events starts and ends. However, only use them only if the audience for the description of the use case agrees that it
    is helpful.
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
    &lt;img height=&quot;278&quot; alt=&quot;Diagram described in caption.&quot; src=&quot;./resources/ucprepst.gif&quot; width=&quot;344&quot; /&gt;
&lt;/p&gt;
&lt;br class=&quot;picturetext&quot; /&gt;
&lt;br /&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
        &lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
            &lt;p&gt;
                Figure 3: Illustration of preconditions and resulting post-conditions
            &lt;/p&gt;
        &lt;/blockquote&gt;
    &lt;/blockquote&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    Consider the following when specifying preconditions and post-conditions:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        The states described by pre- or post-conditions should be states that the user can observe. &quot;The user has logged on
        to the system&quot; or &quot;The user has opened the document&quot; are examples of observable states.
    &lt;/li&gt;
    &lt;li&gt;
        A precondition is a constraint on when a use case can start. It is not the event that starts the use case.
    &lt;/li&gt;
    &lt;li&gt;
        A precondition for a use case is not a precondition for only one subflow, although you can define preconditions and
        post-conditions at the subflow level.
    &lt;/li&gt;
    &lt;li&gt;
        A post-condition for a use case should be true regardless of which alternative flows were executed; it should not
        be true only for the main flow. If something could fail, you would cover that in the post-condition by saying &quot;The
        action is completed, or if something failed, the action is not performed&quot;, rather than just &quot;The action is
        completed&quot;.
    &lt;/li&gt;
    &lt;li&gt;
        When you use post-conditions together with &lt;em&gt;extend&lt;/em&gt; relationships, you should take care that the extending
        use case does not introduce a subflow that violates the post-condition in the base use case.
    &lt;/li&gt;
    &lt;li&gt;
        Post-conditions can be a powerful tool for describing use cases. You first define what the use case is supposed to
        achieve, which is the post-condition. You can then describe the necessary flow of events, or how to reach this
        condition.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        Examples
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        &lt;strong&gt;A precondition for the use case Cash Withdrawal in the ATM machine:&lt;/strong&gt; The customer has a personally
        issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        &lt;strong&gt;A pos-tcondition for the use case Cash Withdrawal in the ATM machine:&lt;/strong&gt; At the end of the use case,
        all account and transaction logs are balanced, communication with the banking system is reinitialized and the card
        is returned to the customer.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;h4&gt;
    &lt;a id=&quot;Extension Points&quot; name=&quot;Extension Points&quot;&gt;Extension Points&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    An &lt;b&gt;extension point&lt;/b&gt; opens up the use case to the possibility of an extension. It has a name and a list of
    references to one or more locations within the flow of events of the use case. An extension point may reference a
    single location between two behavior steps within the use case. It may also reference a set of discrete locations.
&lt;/p&gt;
&lt;p&gt;
    Using&amp;nbsp;named extension points will help you separate the specification of the behavior of the extending use case
    from the internal details of the base use case. The base use case can be modified or rearranged, as long as the names
    of the extension points remain the same, it will not affect the extending use case. At the same time, you are not
    complicating the text describing the flow of events of the base use case with details of where behavior might be
    extended into it.
&lt;/p&gt;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;&gt;
    &lt;p class=&quot;exampleheading&quot;&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        In a phone system, the use case Place Call can be extended by the abstract use case Show Caller Identity. This is
        an optional service, often referred to as &quot;Caller ID&quot;, that may or may not have been requested by the receiving
        party. A description of the extension point in the use case Place Call could look like the following:
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        &lt;b&gt;Name&lt;/b&gt;: Show Identity
    &lt;/p&gt;
    &lt;p class=&quot;example&quot;&gt;
        &lt;b&gt;Location&lt;/b&gt;: After section 1.9 Ring Receiving Party's Telephone.
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;h3&gt;
    Specifying Use Cases
&lt;/h3&gt;
&lt;h4&gt;
    &lt;a id=&quot;How to Find Use Cases&quot; name=&quot;How to Find Use Cases&quot;&gt;How to Find Use Cases&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    See the&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html&quot; guid=&quot;_eyL0wCu-EdqSxKAVa9kmvA&quot;&gt;Guideline: Find and Outline Actors and Use Cases&lt;/a&gt;&amp;nbsp;for guidance on finding Actors
    and Use Cases.
&lt;/p&gt;
&lt;h4&gt;
    &lt;a id=&quot;How a Use Case Evolves&quot; name=&quot;How a Use Case Evolves&quot;&gt;How a Use Case Evolves&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    See the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html&quot; guid=&quot;_4BJ_YCxSEdqjsdw1QLH_6Q&quot;&gt;Guideline: Detail Use Cases and Scenarios&lt;/a&gt;&amp;nbsp;for guidance on evolving use cases.
&lt;/p&gt;
&lt;h4&gt;
    Level of detail necessary in use cases&amp;nbsp;
&lt;/h4&gt;
&lt;p&gt;
    There will often be use cases in your model that are so simple that they do not need a detailed description of the flow
    of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
    disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with
    the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
    of some data from the system.
&lt;/p&gt;
&lt;p&gt;
    For more information on possible formats and level of detail captured for each use case see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html&quot; guid=&quot;_qq0GMAXkEduj_7BEUj1JfQ&quot;&gt;Guideline: Use Case Formats&lt;/a&gt;.
&lt;/p&gt;
&lt;h4&gt;
    &lt;a id=&quot;XE_use_case__scope_of_a_use_case&quot; name=&quot;XE_use_case__scope_of_a_use_case&quot;&gt;&lt;/a&gt;&lt;a id=&quot;The Scope of a Use Case&quot; name=&quot;The Scope of a Use Case&quot;&gt;The Scope of a Use Case&lt;/a&gt;
&lt;/h4&gt;
&lt;p&gt;
    It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the
    use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling
    machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then
    exchange this receipt for money.
&lt;/p&gt;
&lt;p&gt;
    Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case?
    There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog
    with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the
    complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete
    case of use, a use case.
&lt;/p&gt;
&lt;p&gt;
    Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them
    together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in
    larger systems.
&lt;/p&gt;
&lt;h3&gt;
    &lt;a id=&quot;XE_use_case__flow_of_events&quot; name=&quot;XE_use_case__flow_of_events&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_flow_of_events__guidelines_for&quot; name=&quot;XE_flow_of_events__guidelines_for&quot;&gt;&lt;/a&gt;&lt;a id=&quot;Use-Case Diagrams&quot; name=&quot;Use-Case Diagrams&quot;&gt;Use-Case Diagrams&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual
    cases, more than one diagram). This is useful if the use case is involved with many actors, or has relationships to
    many other use cases. A diagram of this kind is of &quot;local&quot; character, since it shows the use-case model from the
    perspective of one use case only and is not intended to explain any general facts about the whole use-case model. Refer
    to&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0VAUsMlgEdmt3adZL5Dmdw&quot;&gt;Guideline: Use-Case Model&lt;/a&gt; for more information.&lt;br /&gt;
&lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>