Design Patterns (3) use case Diagram II

Source: Internet
Author: User

    • Introduction
    • Identify use cases
      • Use case master sequence and replaceable sequence
      • Scene
      • How to identify Use cases
        • A meaningful goal.
        • User perspective rather than system view
        • Use case naming
        • Granularity of Use cases
        • Little Tricks
    • Use case relationships
      • The association between the performer and the use case
      • Use case containment relationships
        • Example
        • Another containing relationship-a structured lengthy use case
      • Extended relationships
        • Brief introduction
        • Application of Extended relationships
        • The extended relationship needs to be noted
      • Extension points
        • Defined
      • Examples of extension points and extension cases
      • Generalization relationships
      • Use case Packages
      • Instance
    • Summarize

Introduction

In the previous blog post, we introduced the initial concepts of use cases, how participants and participants were categorized and how participants were identified, and then I will describe the identity of use cases and the relationship between use cases and some of the exercises.

Identify use cases

In order to determine the use cases in the system, it is useful to start from considering the participants and their interactions with the system. Each use case describes the sequence of interactions between the participant and the system. In this way, the functional requirements of the system are described by use cases, and the use case constructs the functional specification of the system. However, when developing use cases, it is important to avoid functional decomposition. In functional decomposition, several small use cases describe a single small function of the system, rather than a sequence of events that provides useful results to the participants.
Let's take a look at the example of the banking system (the second article mentions, look at the second article). In addition to withdrawals from ATMs, participants "ATM customers" are also allowed to check accounts or transfer funds between two accounts. Because these are different features that are initiated by the customer to bring different useful results. Therefore, the query and transfer functions should be modeled as separate use cases rather than as part of the original use case. This allows the customer to start three use cases as follows:

"Withdrawals" (Withdaw Funds), "Query" and "Transfer" (Transfer Funds) three use cases.

Use case master sequence and replaceable sequence

The main sequence of use cases describes the most common sequence of interactions between participants and systems.

The use case Master sequence also has branches to describe the less frequent interactions between the participants and the system, which deviate from the main sequence and execute only under certain circumstances, such as the input of the participant to the system. Replaceable sequences in use cases can sometimes be merged later with the main sequence, depending on the application requirements. The replaceable sequence is also described in the use case.

Scene

Each sequence in a use case is called a scene .
A use case typically describes multiple scenarios: a master sequence and multiple replaceable sequences. Note that the scene is a complete sequence in the use case, so the scene can begin with the execution of the main sequence and then a replaceable branch is connected at the decision point. For example, a scenario of "withdrawal" begins in the main sequence in which the customer speaks the ATM card into the card reader, enters the pin after the prompt, but receives an error message because the PIN code is wrong and then enters the correct PIN code.

How do I identify use cases? A meaningful goal.

Is there any point? The stakeholders are the boss!

Below you see a set of incorrect use case diagrams:

This set of use case diagram of use case ID is incorrect, input query keyword and select commodity query category, just a user to operate a step, not the user want to achieve the goal, use case is to describe the functional requirements, that is, the use case is to describe the function, that is, the goal, in other words, the user through the system to achieve what, We can see that the wrong use case diagram, these two use cases is only a step, then the user selects the Commodity query category and input query keywords, the most important thing is to do what, in fact, the user just want to query the product information through the system. So we finally re-painted.

User perspective rather than system view

Let's look at this use case:

This use case is wrong. Because the description of the use case is described in terms of the system. Rather than the user's perspective.

user angle to modify :

Use case naming

The use case should be named with the verb + (object). And the participants constitute a "Master + Move + (object)" structure.
Use the weak noun of weak verb cautiously

weak verbs : Make, use, copy, load, repeat
weak nouns : data, reports, forms, forms, systems

"Granularity" of use cases

Particle size principle:

The use case must have a path, the path must have the step. And all of this is "observable".

most often make mistakes --take steps as use cases
The following example is wrong
1. acting as an example of the action of the performer

2. Take system activity as a use case

3.CRUD Flooding
examples of flooding

Refactoring

Little Tricks

Form Check

"Performer" uses the system to "use case"

Use case relationships

When use cases become very complex, dependencies between use cases can be defined with inclusive (include) and extended (extend) relationships, which are designed to maximize scalability and reuse use cases. The inclusion use case (includion using cases) is used to identify common interaction sequences in multiple use cases, which can be extracted and reused.

The association between the performer and the use case

In a use case diagram, the interaction between the performer and the use case is represented by a straight line, called an Association Relationship (association) or a communication relationship (communication).

Use case containment relationships

A common sequence of interactions can be extracted from multiple original use cases and form a new use case, called a containing use case .

The include use case is abstract, that is, it cannot be executed independently.

An abstract use case must be executed as part of a concrete (i.e. executable) use case.

When a common function is separated into a containing use case, the use case can be reused by other use cases. It is then possible to define a more concise version of the old use case, which removes the common interaction sequence. This concise version of the old use case is called the base use case (or specific use case), and it contains the use case.

include use cases always reflect the common functionality between multiple use cases. When a common function is separated into a containing use case, the included use case can be reused by multiple base use cases (the executable use case).

There are no specific contributors to the included use cases. This is because a participant is a participant with a base case that contains a use case, and a different base use case uses a containing use case, so the inclusion use case may be used by different participants.

Example

There is a participant "ATM Client" (ATM customer). The system initial analysis identifies three use cases: "Withdrawals" (withdraw Funds), "Query account" and "Transfer" (Transfer Funds). These three are the main functions that are initiated by the participant. In the withdrawal use case, the master sequence contains the read ATM card, verifies the customer's password, checks that the customer has sufficient funds in the requested account, and then, if successful, sends out cash, prints the bar, and exits the card. Further discovery of these three use cases is that the first part of each use case, the read ATM card and the authentication client password are the same. There is no benefit in repeating the sequence in each use case, so the sequence of PIN verification is separated into a separate included use case called a "verification pin" (Validate pin), which can be used by the (modified) "withdrawal", "Query Account" and "transfer" use cases. Examples are as follows:

The "withdrawal", "Query Account", "transfer" use case contains the use case for "Verifying pin code".

Another containment relationship-(structured lengthy use case)

The inclusion relationship can also be used to organize a lengthy use case. The base use case provides a high-level interaction sequence between the actor and the system. Contains use cases to provide a low-level interaction sequence between participants and systems.
Here is an example:

The "Manufacturing high-volume parts" (manufacture High-volume part) Use case describes the sequence of interactions that make a part. The process consists of receiving raw materials for the production of the part (described in the "reveive part" use case), performing production steps at each plant station (process part at High-volume Workstation) and transportation of manufactured parts (described in the "shipping part" use case).

Introduction to Extended relationships

In some cases, a use case can be very complex, with many replaceable branches. Extension relationships are used to model alternative paths that a use case might take. If a use case has too many replaceable, optional, and anomalous interaction sequences, it can become very complex.
The solution for the above is to separate replaceable or optional interaction sequences into separate use cases. The purpose of this new use case is to extend the old use case if the appropriate conditions are maintained. The extended use case is called the base use case, and the use case for the extension is called an extension use case .

Under certain conditions, the base use case can be extended by the description given in the extension use case. Depending on which condition is true, the base use case can be extended in different ways.

Application of Extended relationships

Extended relationships can be used in the following situations:

Show conditional portions of base use cases that are only executed in certain environments
To a complex or replaceable path

The extended relationship needs to be noted

On the one hand, the base use case does not depend on extension cases.
On the other hand, the extension use case relies on the base use case and only executes if the condition in the base case causes it to execute.

An extension use case can extend more than one use case

A base case can be extended by multiple extension cases

Extension Point definition

An extension point is a precise location used to specify that the base case can be extended.

An extension use case can only extend the base case on these extension points

Each extension point is given a name. An extension use case has an insert fragment for an extension point that is inserted at the location of the extension point in its base use case.

Fragment defines the fragment of behavior that is performed when the extension point is reached
When an instance of a use case is executed and reaches the extension point in the base use case, if the condition is met, the execution of the use case is transferred to the corresponding fragment in the extension case. After the fragment is complete, perform the re-transfer back to the base use case.

Extension points with multiple extension cases can be used to model multiple replaceable cases, where each extension use case prescribes a different alternative.

To design an extension condition so that only one condition can be true in any given case, only one extension is selected.

The extended condition is set and changed at run time when the use case runs.

Examples of extension points and extension cases

Consider the examples shown in the following use case diagram:

Declare an extension point named "Payment" (Payment) in the base case "customer payment" (Checkout customer). The base use case handles customer checkout. Three expansion cases Process payment types: "Cash out" (pay by Cash), "Credit card Checkout" (Paid by) and "Debit card Checkout" (Debit card). Provides a selection criterion for each extension use case. Extended relationships are labeled with extension point names and selection criteria.

The mutually exclusive selection criteria are [cash payment], [credit card payment], [debit card payment], respectively. The appropriate selection criteria are set to true during the execution of the use case, depending on how the customer chooses to pay.

Generalization relationships

When multiple use cases share a similar structure and behavior, they can be abstracted as a parent use case, and other use cases as sub-cases in the generalization relationship.

In the generalization relationship of the use case, the child use case is a special form of the parent use case, and the child use case inherits all the structure, behavior, and relationships of the parent use case.
Generalization relationships are generally seldom used.

In the comet method, the concept of generalization is limited to classes. Extended relationships are sufficient to handle the variability of use cases.

Use case Packages

For large systems, it is often difficult to work with a large number of use cases in a use case model.

A good way to solve this problem is to introduce use case packages to group related use cases together. In this way, the use case package can represent high-level requirements that describe the primary functional subset of the system.

Because participants often start and participate in related use cases, use cases can be grouped into packages based on the major contributors that use them. Non-functional requirements that apply to a set of related use cases can be assigned to a use case package that contains these use cases.

For example, in the "Emergency Monitoring System", the main players of the system are "remote sensor", "monitoring Operator" (monitoring Operator) and "Emergency manager" (Emergency), each of which starts and participates in multiple use cases. An example of a use case package in an emergency monitoring system, called the "Emergency Monitoring Case Package" (Emergencymonitoringusecasepackage), contains 4 use cases. The monitoring operator is the primary contributor to the use case "view alerts" and "View monitoring data", and is a secondary contributor to other use cases. Remote sensors is the primary contributor to the Generate alerts (Generate Alarm) use case and the Generate monitoring data (Generate monitoring) use case.

Instance

1. A hotel reservation system is described below:
(1) Customers can choose to book online, or directly to the hotel through the front desk waiter booking;
(2) Front desk staff can use the system to book rooms directly at the front desk;
(3) Regardless of the booking method, you will need to pay the corresponding deposit at the time of booking;
(4) The front desk reservation can be paid by cash or credit card, but the online booking can only be paid by credit card;
(5) Communication with credit card system is required for payment with credit card;
(6) Housekeeping Manager can check the room reservation status and daily collection status at any time.
Construct the use case model of the system.

Solution:

Solutions-Identify performers
(1) customers can choose to book online, or directly to the hotel through the front desk waiter booking;
(2) front desk staff can use the system to book rooms directly at the front desk;
(3) Regardless of the booking method, you will need to pay the corresponding deposit at the time of booking;
(4) The front desk reservation can be paid by cash or credit card, but the online booking can only be paid by credit card;
(5) Communication with credit card system is required for payment with credit card;
(6) Housekeeping Manager can check the room reservation status and daily collection status at any time.

Solutions-Identifying use cases
(1) Customers can choose to Book online , or directly to the hotel through the front desk waiter booking;
(2) Front desk staff can use the system to book rooms directly at the front desk ;
(3) Regardless of the booking method, you will need to pay the corresponding deposit at the time of booking;
(4) The front desk reservation can be paid by cash or credit card , but the online booking can only be paid by credit card;
(5) Communication with credit card system is required for payment with credit card;
(6) Housekeeping Manager can check the room reservation status and daily collection status at any time.

solution-Drawing a use case diagram

Summarize

So far, we've covered the use case diagram, followed by a succession of other diagrams.

Design Patterns (3) use case Diagram II

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.