| <?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><h3> |
| <a id="Definitions" name="Definitions">Definitions</a> |
| </h3> |
| <h4> |
| Use Case |
| </h4> |
| <p> |
| 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: |
| </p> |
| <ul> |
| <li> |
| <b>"use case instance"</b> 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. |
| </li> |
| <li> |
| <strong>"actions"</strong> 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. |
| </li> |
| <li> |
| <b>"performed by the system"</b> This means that the system provides the use case. An actor communicates with a |
| use-case instance of the system. |
| </li> |
| <li> |
| <b>"an observable result of value"</b> 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. <em>Correct level</em> refers to achieving use cases that are not |
| too small.&nbsp;&nbsp; |
| </li> |
| <li> |
| <b>"a&nbsp;particular actor"</b> 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&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. |
| </li> |
| </ul> |
| <p> |
| 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. |
| </p> |
| <p class="picturecenter" align="center"> |
| <img height="173" alt="Diagram described in caption." src="./resources/im_uc.gif" width="325" /> |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="picturetext"> |
| Figure 1: ATM use case example. |
| </p> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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&nbsp;determine the goal&nbsp;of a use-case task simply by observing its name.&nbsp;&nbsp; |
| </p> |
| <h4> |
| <a id="A Use-Case has Many Possible Instances" name="A Use-Case has Many Possible Instances">Use-Case</a> |
| Instance&nbsp; |
| </h4> |
| <p> |
| 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: |
| </p> |
| <ul> |
| <li> |
| <strong>Input from an actor&nbsp;</strong> |
| </li> |
| </ul> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| 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&nbsp;for returned items. |
| </p> |
| </blockquote> |
| <ul> |
| <li> |
| <strong>A check of values or types of an internal object or attribute</strong> |
| </li> |
| </ul> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| For example, the flow of events may differ if a value is greater or less than a certain value.&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&nbsp;different path. |
| </p> |
| </blockquote> |
| <h4> |
| Scenario |
| </h4> |
| <p> |
| A scenario is a specific sequence of actions that illustrates a behavior.&nbsp; A scenario may be used to illustrate a |
| use-case instance and to specify test cases. |
| </p> |
| <h4> |
| Use-Case Realization |
| </h4> |
| <p> |
| 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&nbsp;performs its tasks, in terms of collaborating objects. This is left for the use-case realizations |
| to show. |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| In the telephone example, the use case would indicate (among other things) that the system issues a signal when the |
| actor lifts the receiver,&nbsp; and that the system then receives digits, finds the receiving party, rings his |
| telephone, connects the call, transmits speech, and so on. |
| </p> |
| </blockquote> |
| <p> |
| In a running&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&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 <strong>realization of the use |
| case</strong>. 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. |
| </p> |
| <p> |
| You can&nbsp;think of&nbsp;a flow of events as consisting of several subflows that,&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. |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| 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. |
| </p> |
| </blockquote> |
| <h3> |
| Properties of Use Cases |
| </h3> |
| <h4> |
| <a id="Name" name="Name">Name</a> |
| </h4> |
| <p> |
| 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. |
| </p> |
| <blockquote> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| These are examples of variations of the name for the use case Recycle Items in the Recycling Machine example: |
| </p> |
| <ul> |
| <li> |
| Return Deposit Items |
| </li> |
| <li> |
| Deposit Items |
| </li> |
| </ul> |
| </blockquote> |
| <h4> |
| <a id="Brief Description" name="Brief Description">Brief Description</a> |
| </h4> |
| <p> |
| 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.&nbsp;If you need to, define new concepts. |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| Following are sample brief descriptions of the use cases Recycle Items and Add New Bottle Type in the |
| Recycling-Machine system. |
| </p> |
| <p class="example"> |
| <b>Recycle Items</b>: 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). |
| </p> |
| <p class="example"> |
| <b>Add New Bottle Type</b>: The manager can add options for the user to return new kinds of bottles can be added to |
| the machine by starting it in <em>learning</em> mode and inserting 5 samples, just&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. |
| </p> |
| </blockquote> |
| <h4> |
| Flow of Events |
| </h4> |
| <h5> |
| <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of |
| Events - Contents</a> |
| </h5> |
| <p> |
| The f<b>low of events</b> 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 <em>what</em> the system does, not <em>how</em> the system is design to perform the required |
| behavior. |
| </p> |
| <p> |
| Follow these guidelines for the contents of the flow of events: |
| </p> |
| <ul> |
| <li> |
| Describe how the use case starts and ends. |
| </li> |
| <li> |
| Describe what data is exchanged between the actor and the use case. |
| </li> |
| <li> |
| 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 "navigate", "browse", "hyperlink" "page", "submit", and |
| "browser". However, it is not advisable to include references to "frames" or "web pages" in such a way that you are |
| making assumptions about the boundaries between them; this is a critical design decision.&nbsp; |
| </li> |
| <li> |
| Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor |
| ... ". |
| </li> |
| <li> |
| Describe only the events that belong to the use case, and not what happens in other use cases or outside of the |
| system. |
| </li> |
| <li> |
| Avoid vague terminology. |
| </li> |
| <li> |
| Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify |
| test cases. |
| </li> |
| </ul> |
| <p> |
| If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and |
| that&nbsp;the meaning of the terms is consistent. To manage common terms, put them in a glossary. |
| </p> |
| <h5> |
| <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events - Structure</a> |
| </h5> |
| <p> |
| The two main parts of the flow of events are <b>basic flow of events</b> and <a id="XE_flow_of_events__alternative_flow" name="XE_flow_of_events__alternative_flow"></a><b>alternative flows of |
| events</b>. The basic flow of events should cover what "normally" 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. |
| </p> |
| <p align="center"> |
| <img height="212" alt="Diagram described in caption." src="./resources/ucstrct.gif" width="231" /> |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="picturetext"> |
| Figure 2: Typical structure of a use case flow of events |
| </p> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| <p class="picturetext"> |
| 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,&nbsp;others end the use |
| case. |
| </p> |
| <p> |
| 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 <em>Flow of Events - Style</em> section, which follows). A&nbsp;guideline is |
| that a subflow should be a segment of behavior within the use case that has a clear purpose, and is "atomic" in the |
| sense that you do either all or none of the actions described. You may need to have several levels of subflows, |
| but&nbsp;avoid that if you can,&nbsp;since it makes the text more complex and harder to understand. |
| </p> |
| <p> |
| The nature of this type of written text, structured into consecutive subsections,&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: |
| </p> |
| <ul> |
| <li> |
| <strong>Business rules</strong>. For example, the user has to be authorized before the system can make certain data |
| available. |
| </li> |
| <li> |
| <strong>User-interface design.</strong> For example, the system should not enforce a certain sequence of behavior |
| that may be intuitive to some but not to other users. |
| </li> |
| </ul> |
| <p> |
| 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: |
| </p> |
| <ul> |
| <li> |
| Where the alternative flow can be inserted in the basic flow of events. |
| </li> |
| <li> |
| The condition that needs to be fulfilled for the alternative behavior to start. |
| </li> |
| <li> |
| How and where the basic flow of events is resumed, or how the use case ends. |
| </li> |
| </ul> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| This is an alternative subflow in the use case Return Items in the Recycling-Machine System. |
| </p> |
| <p class="example"> |
| 2.1. Bottle Stuck |
| </p> |
| <p class="example"> |
| 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. |
| </p> |
| </blockquote> |
| <p dir="ltr"> |
| 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. |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| This is an alternative subflow in the use case Return Items in the Recycling-Machine System. |
| </p> |
| <p> |
| 2.2. Front Panel is Removed |
| </p> |
| <p class="example"> |
| 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&nbsp;for&nbsp;operator attention. When the front panel is closed again, the machine resumes operation from |
| the point where it stopped in&nbsp;the basic flow of events. |
| </p> |
| </blockquote> |
| <p> |
| 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 "if-then-else" 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. |
| </p> |
| <p> |
| 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: |
| </p> |
| <ul> |
| <li> |
| An <strong>alternative</strong> flow of events within the base use case if it is a simple variant, option, or |
| exception to the basic flow of events. |
| </li> |
| <li> |
| As an <strong>explicit</strong> 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. |
| </li> |
| <li> |
| As an <strong>implicit</strong> 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. |
| </li> |
| <li> |
| A <strong>subflow</strong> 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. |
| </li> |
| </ul> |
| <h5> |
| <a id="Flow of Events - Style" name="Flow of Events - Style">Flow of Events - Style</a> |
| </h5> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| Finally,&nbsp;Example 4&nbsp;provides an example of a complete description of a use case flow of events.&nbsp; |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p> |
| <a id="Example 1:" name="Example 1:"><strong>Example 1:</strong></a> <strong>Recommended style for describing a use |
| case</strong> |
| </p> |
| <p> |
| In this style, the text is easy to read and the flow of events is easy to follow. |
| </p> |
| </blockquote> |
| <div align="center"> |
| <table style="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" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1"> |
| <tbody> |
| <tr> |
| <td width="100%"> |
| <b>1.1. Start of Use Case</b> |
| <p> |
| 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. |
| </p> |
| <p> |
| <b>1.2. Configure Measurement Order</b> |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| The system allows the Operator to enter a textual comment on the measurement order. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| <b>1.3. Initialize Order</b> |
| </p> |
| <p> |
| 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 "Scheduled" status of the |
| measurement order. |
| </p> |
| <p> |
| <b>1.4. Use Case Ends</b> |
| </p> |
| <p> |
| The system confirms initialization of the measurement order to the Operator, and the measurement |
| order is made available for other actors to view. |
| </p> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| <div align="center"> |
| <br /> |
| </div> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p> |
| <a id="Example 2:" name="Example 2:"><strong>Example 2:</strong></a> <strong>Alternative way of describing a use |
| case</strong> |
| </p> |
| <p> |
| This style is readable, but there is no clear flow of events. |
| </p> |
| </blockquote> |
| <div align="center"> |
| <table style="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" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1"> |
| <tbody> |
| <tr> |
| <td width="100%"> |
| Orderers can create Orders to collect measurement data from the Network Elements. |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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 "scheduled". (Possible values for the status are: Scheduled, Executing, Completed, |
| Canceled, and Erroneous.) |
| </p> |
| <p> |
| 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. |
| </p> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p> |
| <a id="Example 3:" name="Example 3:"><strong>Example 3:</strong></a> <strong>Another way of describing a use |
| case</strong> |
| </p> |
| <p> |
| 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. |
| </p> |
| </blockquote> |
| <div align="center"> |
| <table style="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" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="50%" bordercolorlight="#808080" border="1"> |
| <tbody> |
| <tr> |
| <td width="100%"> |
| <pre> |
| <font size="2"><small>'Administrate order' (User identity) |
| REPEAT |
| &lt;='Show administer order menu' |
| IF (=&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. |
| &lt;= 'Show order' (Default attributes) |
| REPEAT |
| IF (=&gt; 'Edit order' (Attribute to change, New value of attribute)) THEN |
| &lt;= 'Update screen' (New attributes) |
| ELSIF (=&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'. |
| &lt;= 'New order created' (The order) |
| ENDIF |
| UNTIL (=&gt; 'Quit') |
| ENDIF |
| UNTIL 'Quit administer order'</small> |
| </font> |
| </pre> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| <h5> |
| <a id="Example 3:" name="Example 3:">Example 4:</a>&nbsp;Complete description fo the flow of events&nbsp; |
| </h5> |
| <p> |
| 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: |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p> |
| <b>1.&nbsp;BASIC FLOW&nbsp;OF EVENTS</b>&nbsp; |
| </p> |
| <p> |
| <b>1.1. Start use case</b> |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| <b>1.2. Configure measurement order</b> |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| The system allows the Operator to enter a textual comment on the measurement order. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| <b>1.3. Initialize order</b> |
| </p> |
| <p> |
| 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 "Scheduled" status of the measurement order. |
| </p> |
| <p> |
| <b>1.4. End use case</b> |
| </p> |
| <p> |
| The system confirms initialization of the measurement order to the Operator, and the measurement order is made |
| available for other actors to view. |
| </p> |
| <p> |
| <b>2.&nbsp;ALTERNATIVE FLOW OF EVENTS</b>&nbsp; |
| </p> |
| <p> |
| <b>2.1. No network elements available</b> |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| <b>2.2. No measurement functions available</b> |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| <b>2.3. Cancel measurement order</b> |
| </p> |
| <p> |
| 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. |
| </p> |
| </blockquote> |
| <h4> |
| <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Special Requirements" name="Special Requirements">Special |
| Requirements</a> |
| </h4> |
| <p> |
| 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 <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>. 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. |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <h5> |
| Example |
| </h5> |
| <p class="example"> |
| In the Recycling-Machine System, a special requirement of the Return Deposit Items use case could be: |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="example"> |
| The machine has to be able to recognize deposit items with a reliability of more than 95 percent. |
| </p> |
| </blockquote> |
| </blockquote> |
| <h4> |
| <a id="XE_postcondition__guidelines_for" name="XE_postcondition__guidelines_for"></a><a id="XE_precondition__guidelines_for" name="XE_precondition__guidelines_for"></a><a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a> |
| </h4> |
| <p> |
| A <strong>precondition</strong> is the state of the system and its surroundings that is required before the use case |
| can be started.&nbsp;Post-Conditions are&nbsp;the states the system can be in after the use case has ended. It can |
| be&nbsp;helpful to use the&nbsp;concepts of <b>precondition</b> and <b>post-condition</b> 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. |
| </p> |
| <p align="center"> |
| <img height="278" alt="Diagram described in caption." src="./resources/ucprepst.gif" width="344" /> |
| </p> |
| <br class="picturetext" /> |
| <br /> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p> |
| Figure 3: Illustration of preconditions and resulting post-conditions |
| </p> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| <p> |
| Consider the following when specifying preconditions and post-conditions: |
| </p> |
| <ul> |
| <li> |
| The states described by pre- or post-conditions should be states that the user can observe. "The user has logged on |
| to the system" or "The user has opened the document" are examples of observable states. |
| </li> |
| <li> |
| A precondition is a constraint on when a use case can start. It is not the event that starts the use case. |
| </li> |
| <li> |
| 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. |
| </li> |
| <li> |
| 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 "The |
| action is completed, or if something failed, the action is not performed", rather than just "The action is |
| completed". |
| </li> |
| <li> |
| When you use post-conditions together with <em>extend</em> 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. |
| </li> |
| <li> |
| 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. |
| </li> |
| </ul> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| Examples |
| </p> |
| <p class="example"> |
| <strong>A precondition for the use case Cash Withdrawal in the ATM machine:</strong> 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. |
| </p> |
| <p class="example"> |
| <strong>A pos-tcondition for the use case Cash Withdrawal in the ATM machine:</strong> 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. |
| </p> |
| </blockquote> |
| <h4> |
| <a id="Extension Points" name="Extension Points">Extension Points</a> |
| </h4> |
| <p> |
| An <b>extension point</b> 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. |
| </p> |
| <p> |
| Using&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. |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="exampleheading"> |
| <strong>Example</strong> |
| </p> |
| <p class="example"> |
| 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 "Caller ID", 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: |
| </p> |
| <p class="example"> |
| <b>Name</b>: Show Identity |
| </p> |
| <p class="example"> |
| <b>Location</b>: After section 1.9 Ring Receiving Party's Telephone. |
| </p> |
| </blockquote> |
| <h3> |
| Specifying Use Cases |
| </h3> |
| <h4> |
| <a id="How to Find Use Cases" name="How to Find Use Cases">How to Find Use Cases</a> |
| </h4> |
| <p> |
| See the&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for guidance on finding Actors |
| and Use Cases. |
| </p> |
| <h4> |
| <a id="How a Use Case Evolves" name="How a Use Case Evolves">How a Use Case Evolves</a> |
| </h4> |
| <p> |
| See the <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance on evolving use cases. |
| </p> |
| <h4> |
| Level of detail necessary in use cases&nbsp; |
| </h4> |
| <p> |
| 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. |
| </p> |
| <p> |
| For more information on possible formats and level of detail captured for each use case see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>. |
| </p> |
| <h4> |
| <a id="XE_use_case__scope_of_a_use_case" name="XE_use_case__scope_of_a_use_case"></a><a id="The Scope of a Use Case" name="The Scope of a Use Case">The Scope of a Use Case</a> |
| </h4> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Use-Case Diagrams" name="Use-Case Diagrams">Use-Case Diagrams</a> |
| </h3> |
| <p> |
| 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 "local" 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&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a> for more information.<br /> |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |