UML Use case diagram description

Transferred from: http://www.360doc.com/content/10/1206/23/3123_75672033.shtml

Some time ago participated in the technical lecture of Pangayu teacher, UML modelling technology benefited greatly. I also put some of the usual accumulation and the last harvest summarized in this article, mainly on the use case diagram related knowledge.
The use case diagram is the first step in the software requirements analysis to the final implementation, which describes how the user uses the system and what functions the system uses. Use case diagrams represent the business perspective of who uses the system, what services the user wants the system to provide, and what services the user needs to provide for the system, as well as the eventual implementation of these capabilities by the software developer. Use case diagrams are widely used in development, but it is most commonly used to describe what functions the system provides to the user.

In the official documentation, the use-case diagram contains six elements, namely: Performer (actor), use cases (usage case), Association Relationship (association), include relationship (include), extended relationship (Extend), and generalization relationship (generalization). However, some UML drawing tools provide a direct association relationship (Directedassociation).

A use case diagram can consist of a comment and a constraint, and a containing package that combines elements from the model into a larger module. Sometimes instances of a use case can be introduced into a diagram. The use case diagram model is shown below, where the performer is identified by a human icon, the use case is represented by an ellipse, and the line represents the relationship between them.

First, performer (actor)

1. Performer Concept

Refers to the role that the user plays in the system. 1-1 is a user-managed use case diagram, the user, the administrator is the use case performer.

Figure 1-1

2. Identify performers from the business

Get the system use case first to find out the performer of the system. We can identify the performer by answering the answers to some questions from the user. You can refer to the following questions:

1. Who uses the main features of the system (primary users)?
2. Who needs the system to support their daily work?
3. Who will maintain and manage the system so that it works (secondary users)?
4. What hardware does the system need to control?
5. What other systems do the system need to interact with? This includes other computer systems or applications.
6. What are the people and things that are interested in the results of the system?

3. Relationship between performers

Because the performer is a class, multiple performers can have the same relationship as the class. In a use case diagram, a generalization relationship is used to describe common behavior among multiple performers. If there are several performers in the system that play both their own roles and also play a more generalized role, then they are described with generalized relationships. This situation often occurs when the behavior of a general role is described in the performer superclass. The specialized performer inherits the behavior of the superclass and then extends this behavior in some ways. The generalization relationship between performers is represented by a triangular arrow pointing to the superclass that plays a general role. This is the same as the return relationship symbol between classes in UML. Figure 1-2

Figure 1-2

Ii. Use Cases

1. Use case concept

Use cases are externally visible system functions that describe the services provided by the system.

2. Find use cases from the business

To find out the use cases of the system, we start with the performer, ask a few questions for each performer, and then get the use case from the performer's answers to these questions. You can refer to the following questions:

1. What functions does the performer require the system to provide (what does the performer need to do)?
2. What types of information does the performer need to read, generate, modify, delete, or store on the system?
3. The performer must remind the system what the event is? These events are represented as system use cases.

3. Relationship between Use cases

Ii. Relationship between Use cases

1. Association Relationship (Association)

An association relationship is a connection performer and a use case, which indicates that the external system entity represented by the performer is related to the system requirements described by the use case.

Figure 1-3

2. Inclusion relationship (include)

The containment relationship is an abstraction from the use cases, that is, separating out the public parts from several different usage cases and becoming reusable.

Figure 1-4

3. Extended relationship (Extend)

An extended relationship represents a dialog process for a use case, and another use case may be temporarily inserted based on the condition, which is referred to as the underlying use case, which is referred to as an extension use case.

Figure 1-5

4. Generalization relationship (generalization)

A use case can be specifically enumerated as one or more use cases, which is called use-case generalization, and if one or more of the use cases in a system are specialized for a generic use case, the generalization of the case needs to be used.

relationships among several kinds of UML: inheritance, implementation, dependency, association, aggregation, combination of relations and differences

2009-03-01

This article was synchronized on: http://blog.csdn.net/sfdev/archive/2009/02/18/3906243.aspx

This is a tutorial on the basics of UML; now that we're doing a project too tight, we haven't really done a real class-level detail design, let alone using UML to implement canonical modeling; This article is mainly about the relationship between several classes that I have been confused about before, Let's make it clearer when we really use UML for example class diagram design, and here are some of the relationships:

Inheritance

Refers to the ability of a class (called a subclass, sub-interface) to inherit the functionality of another class (called the parent class, the parent interface) and to augment its own new functionality, which is the most common relationship between a class and a class or interface and interface, in Java where such relationships are explicitly identified by the keyword extends, In the design of the general is not controversial;

Implement

Refers to a class class implementation of the interface interface (can be multiple) function, the implementation is the most common relationship between the class and interface, in Java such relationships through the keyword implements clearly identified, at design time is generally not controversial;

Dependent

It can be simply understood that a class A uses another Class B, which is contingent, temporary, and very weak, but changes in class B affect A; For example, if someone wants to cross the river and borrow a boat, then the relationship between the man and the ship is dependent; At the code level, For Class B as a parameter is used by Class A in a methods method;

Associate

He embodies a strong dependency between the two classes, or the semantic level of the class and interface, such as me and my friends; this relationship is more than relying on the contingency, the relationship is not temporary, generally long-term, and the relationship between the two sides is generally equal, the association can be one-way, two-way At the code level, the associated class B appears as a class attribute in the association Class A, or the association Class A refers to a global variable of the type being associated with Class B;

Aggregation

Aggregation is a special case of association relationship, he embodies the whole and part, the relationship of ownership, that is, the relationship between the whole and the part is has-a, they can have their own life cycle, some can belong to multiple whole objects, can also be shared for multiple whole objects, such as computer and CPU, The relationship between the company and its employees, and the expression at the code level, and the association is consistent, can only be differentiated from the semantic level;

Combination

The combination is also a special case of the relationship, he embodies a contains-a relationship, which is stronger than aggregation, also known as strong aggregation, he also embodies the relationship between the whole and part, but at this time the whole and part is not divided, the whole life cycle end also means that part of the life cycle end , such as you and your brain; At the level of the code, the relationship is consistent and can only be differentiated from the semantic level;

There is little doubt about the inheritance and realization of these two relationships, they embody a kind of class and class, or the vertical relationship between the class and the interface; the other four relationships embody the class and class, or the reference between the class and the interface, the transverse relation, is more difficult to distinguish between, there are many things between the relationship to prepare for positioning is very difficult, These kinds of relationships are semantic level, so from the code level does not completely distinguish between the various relationships, but in general, the following relationships show the degree of strength: Combination > Aggregation > association > dependency;

Objective
A record of learning a UML process for a previous period of time

Cause

In order to clarify some of the mall's business logic, in order to develop smoothly in the future, need a tool to help themselves better and faster familiar with these businesses, a lot of tools, such as all kinds of mind mapping software, UML, I chose the UML. Because there is no painting before, knowledge is very scarce, began to learn while painting

After

Learn to draw before, to find a better picture of UML software, by colleague TJJ recommendation, with a Korean developed startuml, used to
After drawing a few pictures found is not particularly useful, sigh~ through the great Google, with the ArgoUML interface although ugly point, but really good, in here also recommended, haha.

In the process of learning UML, several concepts are exposed and recorded:

Association: A semantic connection between model elements is a weak connection between classes, such as when a class is associated with a parameter in another class method only

Composition: Represents the relationship between a whole and a part of a class, but the part and the whole of a composite relationship have a uniform lifetime. Once the overall
The object does not exist, and some objects will not exist. There is a common life-death relationship between some objects and the whole object.

Aggregation: Also refers to the relationship between the whole and the part. The words "contain" and "compose" in the requirement description often imply the aggregation relationship.

Intimacy from large to small for combination > Aggregation > Association

Results

By drawing a uml diagram to familiarize yourself with the business requirements in development, you will have a deeper understanding of your needs.

UML Use case diagram description