UML Use case diagram

Original address: http://blog.csdn.net/zhuojiajin/article/details/8657853

See the UML video, feel the UML content actually look very clear. When I started to paint, I found out that it was purely a teacher's job. Listen to understand or feel that you understand that it is just an illusion. For the UML diagram or understanding is not thorough enough, of course, now ask yourself to be thorough is also a dream. Although it is an illusion, trait also let me watch the video when I feel happy. Furthermore, the illusion must be based on certain "understanding". So I like this illusion! This blog begins with a summary of 9 diagrams in UML, which first speaks of use case diagrams.

Then the use case diagram is a graphical representation of the relationship between people and functions in a software system, that is, roles and use cases. Can clearly reflect the role of the permissions, the role of the corresponding function of the relationship between. It describes the behavior of systems, subsystems, or classes from the perspective of the external user of the software system. A use case model is a common understanding that developers and users have agreed upon. Use case models are described in several use case diagrams. A use case diagram must include a description of the function, a role, and a role and function correspondence.

Role (actor):

A role in a software system is the idealization of an external person, process, or thing that interacts with a system, subsystem, or class. An activity this can correspond to one or more use cases. As long as the external objects interacting with the software system are roles, such as: personnel, other systems, external servers, databases, etc. UML is represented by a villain figure. The characters are relatively easy to find when drawing.

--Can activate system interaction information;

-Can be input to the system;

--can receive information passively from the system.

Role: A character can be either a person or a thing

Several principles for finding the performer:

-Who uses the functionality of the system;

-Who needs the system to support daily work;

-who will maintain the relationship system;

-Systems need to manipulate those hardware-other systems that need to interact with the system;

-people or things that are interested in the results of the system.

Use Case (UseCase):

A use case is a functional unit in a software system, and the purpose of a use case is to define a clear block of behavior rather than explaining the structure of the system. A use case includes all the behaviors it has: the Main Line (ideal function), the different deformation of the behavior, the abnormal condition of the behavior, and the desired response. is actually a complete function, can be a large function module, can also be the system menu of each function.

Relationship (Assosciation):

There are four ways to describe the relationship between roles and features: Association, generalization, inclusion, and extension.

Main properties in a use case diagram: Event flow, preconditions, post conditions, granularity, range

Event Flow: Simply the question of what a use case should do, describing the process by which the use case interacts between the performer and the system at execution time. Includes basic streams (descriptions of general and expected paths in use cases, such as logins) and alternate streams (other paths that are executed when a use case occurs in special cases, such as error handling)

--Basic flow--description of normal and expected paths in use cases

--Alternate stream--the use case executes other paths due to other factors.

pre-and post-conditions: the conditions that need to be met when a use case executes and the result of processing at the end. should be similar to the two cases of a Do While loop.

　　Preconditions: A precondition for the execution of the use case that describes the conditions under which an event stream can be started.

Post condition: Indicates the state of the system at the end of force.

granularity and Range: A property that evaluates the merits and demerits of a use case diagram. Describes the width and the degree of dispersion of the use case diagram.

the granularity and scope of UML use case diagrams: How many use cases, overview level, user target level, sub-functional level. Design the important aspects to consider, the beginning of a rough design of the use case diagram, and then slowly refine. The granularity of a use case diagram should not be too coarse or too thin.

Use case Note points:

The system boundaries should be clearly defined

Prevent too many use cases

The use case should be named from the performer's point of view.

The formal degree of use case description

Avoid inconsistent names of performers

Avoid the relationship between the performer and the use case

Note whether the size of the use case is appropriate (granularity)

Avoid confusing use case descriptions

Distinguishing between force decomposition and functional decomposition

Avoid customers ' inability to understand use cases

On Some occasions, use cases to describe unsuitable  

Here is an example: the vending machine sells the goods function, the person involved in the process is as follows: The customer use case has: button, indicator, slot, coin slot. The use case diagram is as follows:

UML Use case diagram