Concept: Use-Case Model |
This artifact is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the project team.
Relationships
Related Elements | Use Case Model Find and Outline Requirements Detail Requirements
Main Description
### Explanation A use-case model is a model of the system use cases and actors and the relationships between them. In addition, the use-case model may contain packages that are used to structure the model to simplify analysis, communications, navigation, development, maintenance and planning. Much of the use-case model is in fact textual, with the text captured in the Use-Case Specifications that are associated with each use-case model element. However, the addition of UML diagrams (and the underlying model) provides a graphical representation of the structure and relationships between the use cases and actors. This graphical representaiton acts as a kind of “Table of Contents” or navigation map to the information; simplifying communications, analysis and navigation of the information. The use-case model serves as a unifying thread throughout system development. It is used to capture functional requirements and as the basis for design, iteration planning, and testing. The use-case model contains, as a minimum, the following model elements: #### Actor A model element representing the actors. Properties include the actors name and brief description. See Artifact: Actor for more information. #### Use Case A model element representing a use case. Properties include the use case name and use case specification. See Artifact: Use Case and Concept: Use Case for more information. A use case may be abstract (cannot be instantiated) or concrete (will be instantiated). #### Associations Associations are used to describe the relationships between actors and the use cases they participate in. This is commonly known as “communicates-associations”. The use-case model may also contain the following model elements: #### Subject A model element that represents the boundary of the system of interest. #### Use-Case Package A model element used to structure the use case model to simplify analysis, communications, navigation, and planning. #### Generalizations Generalization between actors and between use cases are possible in order to support re-use of common properties. #### Dependencies A number of dependency types between use cases are defined in UML. In particular, <<extend>> and <<include>>. <<extend>> is used to include optional behavior from an extending use case in an extended use case. <<include>> is used to include common behavior from an included use case into a base use case in order to support re-use of common behavior. ### Use-Case Diagram The diagram below shows a part of a use-case model for the Recycling-Machine System. This diagram shows two actors (Customer and Operator), three use cases (Print Daily Report, Administer Deposit Item, and Recycle Items) and the associations between the performing actors and the use cases. There are many ways to model a system, each of which may serve a different purpose. However, the most important purpose of a use-case model is to communicate the system's behavior to the customer or user. Consequently, the model must be easy to understand. The users and any other system that may interact with the system are the actors. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actors' needs. This ensures that the system will turn out to be what the users expected. ### Structuring the Use-Case Model There are three main reasons for structuring the use-case model: To make the use cases easier to understand. To partition out common behavior described within many use cases. To make the use-case model easier to maintain. Structuring is, however, not the first thing you do. There is no point in structuring the use cases until you know a bit more about their behavior, beyond a one sentence brief description. You should at least have established a step-by-step outline to the flow of events of the use case, to make sure that your decisions are based on an accurate enough understanding of the behavior. #### Use-Case Package A model structured into smaller units is easier to understand. It is easier to show relationships among the model's main parts if you can express them in terms of packages. If there are many use cases or actors, you can use use-case packages to further structure the use-case model. A use-case package contains a number of actors, use cases, their relationships, and other packages; thus, you can have multiple levels of use-case packages (packages within packages). You can partition a use-case model into use-case packages for many reasons: You can use use-case packages to reflect order, configuration, or delivery units in the finished system. Allocation of resources and the competence of different development teams may require that the project be divided among different groups at different sites. Some use-case packages are suitable for a group, and some for one person, which makes packages a naturally efficient way to proceed with development. You must be sure, however, to define distinct responsibilities for each package so that development can be performed in parallel. You can use use-case packages to structure the use-case model in a way that reflects the user types. Many changes to requirements originate from users. Use-case packages ensure that changes from a particular user type will affect only the parts of the system that correspond to that user type. In some applications, certain information should be accessible to only a few people. Use-case packages let you preserve secrecy in areas where it is needed. #### Concrete and Abstract Use Cases There is a distinction between concrete and abstract use cases. A concrete use case is initiated by an actor and constitutes a complete flow of events. "Complete" means that an instance of the use case performs the entire operation called for by the actor. An abstract use case is never instantiated in itself. Abstract use cases are included, extend or generalize other use cases. When a concrete use case is initiated, an instance of the use case is created. This instance also exhibits the behavior specified by its associated abstract use cases. Thus, no separate instances are created from abstract use cases. The distinction between the two is important, because it is concrete use cases the actors will "see" and initiate in the system. You indicate that a use case is abstract by writing its name in italics. In the example below, the abstract use case Create Task is included in the use case Register Order. When Register Order is initiated, an instance of Register Order is created that, apart from following Register Order's flow of events, also follows the flow of events described in the included use case, Create Task. Create Task is never performed by itself, always as a part of Register Order (or any other use cases in which it is included). Create Task is therefore an abstract use case. #### Actor Generalization Several actors can play the same role in a particular use case. Thus, as shown in the example below, a Teller and an Accountant, both of whom check the balance of an account, are seen as the same external entity by the use case that does the checking. The shared role is modeled as an actor, Balance Supervisor, inherited by the two original actors. This relationship is shown with actor-generalizations. The actors Teller and Accountant inherit all the properties of a Balance Supervisor. Thus, both these actors can act as Balance Supervisors. A user can play several roles in relation to the system, which means that the user may, in fact, correspond to several actors. To make the model clearer, you can represent the user by one actor that generalizes several actors. Each inherited actor represents one of the user's roles relative to the system. #### Use-Case Generalization A parent use case may be specialized into one or more child use cases that represent more specific forms of the parent. Neither parent nor child is necessarily abstract, although the parent in most cases is abstract. A child inherits all structure, behavior, and relationships of the parent. Children of the same parent are all specializations of the parent. This is generalization as applicable to use cases. Generalization is used when you find two or more use cases that have commonalities in behavior, structure, and purpose. When this happens, you can describe the shared parts in a new, often abstract, use case that is then specialized by child use cases. In the example below, the use cases Telephone Order and Internet Order share a lot in structure and behavior. A general use case Place Order is defined where that structure and common behavior is defined. The abstract use case Place Order need not be complete in itself, but it provides a general behavioral framework that the child use cases can then make complete. The parent use case is not always abstract. #### Include relationships between use cases The include-relationship connects a base use case to an inclusion use case. The inclusion use case is always abstract. It describes a behavior segment that is inserted into a use case instance that is executing the base use case. The base use case has control of the relationship to the inclusion and can depend on the result of performing the inclusion, but neither the base nor the inclusion may access each other's attributes. The inclusion is in this sense encapsulated, and represents behavior that can be reused in different base use cases. You can use the include-relationship to: Factor out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case, only the result of it is important. Factor out behavior that is in common for two or more use cases. In the example below, the use cases Withdraw Cash, Deposit Cash, and Transfer Funds all need to include how the customer is identified to the system. This behavior can be extracted to a new inclusion use case called Identify Customer, which the three base use cases include. The base use cases are independent of the method used for identification, and it is therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on the result of Identify Customer, which is the identity of the customer. And vice versa, from the perspective of the Identify Customer use case, it does not matter how the base use cases use the customer identity or what has happened in them before the inclusion is executed - the method for identification is still exactly the same. A base use case may have multiple inclusions. One inclusion use case may be included in several base use cases. This does not indicate any relationship between the base use cases. You may even have multiple include-relationships between the same inclusion use case and base use case, provided the inclusion is inserted at different locations of the base use case. The include-relationship defines what the location is. All additions may be nested, which means that an inclusion use case may serve as the base use case for another inclusion. Since the inclusion use case is abstract, it does not need to have an actor associated with it. A communication-association to an actor is only needed if the behavior in the inclusion explicitly involves interaction with an actor. #### Extend relationship between use cases The extend-relationship connects an extension use case to a base use case. You define where in the base to insert the extension by referring to extension points in the base use case. The extension use case is often abstract, but does not have to be. You can use the extensions for several purposes: To show that a part of a use case is optional, or potentially optional, system behavior. In this way, you separate optional behavior from mandatory behavior in your model. To show that a subflow is executed only under certain (sometimes exceptional) conditions, such as triggering an alarm. To show that there may be a set of behavior segments of which one or several may be inserted at an extension point in a base use case. The behavior segments that are inserted (and the order in which they are inserted) will depend on the interaction with the actors during the execution of the base use case. The extension is conditional, which means its execution is dependent on what has happened while executing the base use case. The base use case does not control the conditions for the execution of the extension - the conditions are described within the extend-relationship. The extension use case may access and modify attributes of the base use case. The base use case, however, cannot see the extensions and may not access their attributes. The base use case is implicitly modified by the extensions. You can also say that the base use case defines a modular framework into which extensions can be added, but the base does not have any visibility of the specific extensions. The base use case should be complete in and of itself, meaning that it should be understandable and meaningful without any references to the extensions. However, the base use case is not independent of the extensions, since it cannot be executed without the possibility of following the extensions. In the example below, the primary service provided to the users is represented by the use case Place Call. Examples of optional services are: To be able to add a third party to a call (Place Conference Call). To allow the receiving party to see the identity of the caller (Show Caller Identity). We can represent the behaviors needed for these optional services as extension use cases to the base use case Place Call. This is a correct use of the extend-relationship: since Place Call is meaningful in itself, you do not need to read the descriptions of the extension use cases to understand the primary purpose of the base use case, and the extensions use cases have optional character. If both the base use case and the "base plus extension" use case must be explicitly instantiable, or if you want the addition to modify behavior in the base use case, you should use use-case-generalization instead. The extension use case can consist of one or more insertion segments, each of which may have alternative paths built into it. These insertion segments incrementally modify the behavior of the base use case. Each insertion segment in an extension use case can be inserted at a separate location in the base use case. This means that the extend-relationship has a list of references to extension points, equal in number to the number of insertion segments in the extension use case. Each extension point must be defined in the base use case. One base use case may be involved in several extend-relationships, which means a use case instance can follow more than one extension during its lifetime. One extension use case may extend into several base use cases, but this does not imply any dependency between the base use cases. There may even be multiple extend-relationships between the same extension use case and base use case, provided the extension is inserted at different locations in the base. This means the different extend-relationships need to refer to different extension points in the base use case. An extension use case may itself be the base in an extend-, include-, or generalization-relationship. For example, this means extension use cases can extend other extension use cases in a nested manner.
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright