UML Modeling Learning 5:use-case Diagram

        A use case diagram Overview

The so-called use case diagram is used to describe the user's needs, describe the function of the system from the user's perspective, and point out the performer of the function, emphasizing who is using the system,

What functions the system has done for performers.

Use case diagram is the product of requirement analysis, which describes the function of system participants interacting with the system, which is the system function that the participant can observe and use.

Model Diagram. Its main purpose is to help development teams understand the functional requirements of the system in a visual way, including role relationships based on basic processes

and the various functions of the system . the relationship between the two. It captures the requirements of the system through use cases and, in combination with the actor, the requirements of the

Analysis and design.

Use case diagram is mainly used to chart the main event flow of the system, it is mainly used to describe the needs of the customer, that is, users want the system features, popular geography

The solution use case is the function module of the software, so it is the starting point of the design system analysis stage. The designer creates and interprets use-case diagrams based on customer needs to

Describes which functional modules the software should have and the call relationships between them, and the use case diagram contains the use cases and participants, which are connected by associations to

The whole structure and function of the system should be reflected to non-technical personnel (usually software users), the structure and function of software should be decomposed.

A use case is a behavior that is visible from the outside of the system and is a complete service provided by the system to one or several actors (actors). In principle,

with between the examples are independent, parallel, there is no package between them dependent relationships are included. But in order to reflect the business relationship between some use cases, we can improve the dimension

Protection Sex and consistency, use cases you can abstract several relationships that include (include), extend (extend), and pan (generalization).

A static view of the system's functions, consisting of the actors (actor), use cases, and their relationships, is called use-case diagrams.

       two composition of use case diagrams

The use case diagram consists of four parts: participants, use cases, system boundaries, subsystems, and relationships.

(1) participant (actor)

Before a system development, we must first determine the system's users, the system's users are the system's participants. In addition, we will also want to

How does the system we develop relate to other systems? Therefore, the participants in the system can be divided into two categories, one is human, including the system user, dimension

Other systems are also in the other category.

Participants represent users, organizations, or external systems that interact with the applications or systems that you do. A person or thing that interacts directly with the system outside the system

The following two points need to be noted:

1) The participant is a role rather than a specific person, and it represents the role of the participant in the process of dealing with the system. So the actual operation of the system

, an actual user may correspond to multiple participants in the system. Different users can also only correspond to one participant, thus representing the same participant's non-

The same instance.

2) Participants interact with the system as an external user (rather than as an internal), which is the main feature.

In UML, the actor uses a villain that says:

(2) Use cases

Use cases are system services or functional units that the actor can feel. is a description of a set of action sequences, including variables,

The system performs these actions and produces observable results that pass specific participants. Usually we use the things that the system can do or the functions that we can accomplish.

example, use a verb or a verb phrase to name a use case.

No use cases can exist independently in the absence of participants. Similarly, any participant must have a use case associated with it, so identify use cases

The best way to do this is to start with the analysis system participants, who often find new participants in the process.

A system function unit that is visible outside the system. The function of the system is provided by the system unit, and through a series of system units with one or more participants

The messages exchanged between them are expressed.

The use cases in UML are represented by ellipses, and the text in the ellipse outlines the functions of the system:

The use case is granular, and the granularity of the use case refers to how much of the system service or functional unit the use case contains. The greater the granularity of use cases, the

The more you can, the less functionality it contains.

Granularity Division of Use cases:

1) Concept level

2) User target level

3) Sub-functional level

(3) system boundary

The so-called system boundary refers to the boundary between the system and the system. Other parts of the system that are associated with systems outside the system boundary are called system environments.

The system boundary in UML uses a rectangular border to represent a system:

(4) subsystem (SUBSYSTEM)

Subsystems are used to demonstrate a part of the system's functionality, which is closely linked.

The subsystem in UML uses a rectangular border to represent a subsystem that can write a description of some of the systems:

(5) Relationship

A relationship is a relationship between a participant and a participant, a use case and a use case, a use case and a participant, usually divided into four types: association, generalization, inclusion,

Extended.

The following four relationships are included in the standard use case diagram in UML:

1) Association (association)

Represents an interaction between a participant and a use case, a communication route, in which either party can send or receive messages.

Arrow point to: Point to the message receiver

2) generalization (inheritance)

Is the commonly understood inheritance relationship, where the child use case is similar to the parent use case, but behaves more specifically, and the child use case inherits all the structure of the parent case, the row

For and relations. A child use case can use a section of the parent use case, or it can be overloaded. The parent use case is usually abstract.

Arrow pointing to: pointing to the parent use case

3) include (include)

The include relationship is used to break down the functionality represented by a more complex use case into smaller steps.

"Arrow pointing": pointing to decomposed function use cases

4) extension (Extend)

An extension relationship is an extension of a use case feature, which is equivalent to providing an additional function for the underlying use case. An extension use case is optional, and if an extension use case is missing,

Does not affect the integrity of the base use case.

Arrow pointing to: pointing to the underlying use case

Include (include), extension (extend), generalization (inheritance) differences:

conditionality: The sub-use cases in generalization and included occurrences in the include are unconditional, and the occurrence of extension cases in extend is a of;

Directness: Sub-use cases in generalization and extension cases in extend provide direct service to participants, while the use cases included in the include are for participants to

for indirect services.

For extend, the extension use case does not contain the content of the underlying use case, nor does the underlying use case contain the content of the extension use case.

For inheritance, a child use case contains all the content of the underlying use case and its relationship to other use cases or actors.

Provide a complete system of use case diagrams that give everyone a sense of a holistic understanding.

       Three use case descriptions

Describe use cases, and sometimes only use case diagrams are not enough, but also need use-case descriptions. It can describe the functionality of use cases in more detail. The composition of the use case description includes:

Use case name, brief description, priority, participant, precondition, basic event flow, other event stream, exception event stream, post condition.

(1) event flow

Describes the process by which a use case interacts between the performer and the system at execution time. An event flow is a control flow that consists of a sequence of activities when a use case executes. This

A process consists of multiple branches: a basic stream and an alternate stream.

Basic Event Flow: A description of the general and expected paths in a use case.

Other event flow: Because of other factors, the use case executes other paths.

The exception flow is mainly to describe some abnormal situations and select branches.

(2) front-facing conditions

What state the actor and system should put on when the use case starts. is a precondition for the execution of the use case to describe the conditions under which you can begin

Executes an event stream.

(3) Post conditions

Describes the state of the system at the end of the use case.

Preconditions and post conditions can be used for validation and review of use cases.

(4) Precautions for using use cases:

1) The system boundaries should be clearly defined

2) Prevent too many use cases

3) The use case should be named from the perspective of the performer

4) Use case description formal degree

5) Avoid inconsistent names of performers

6) Avoid the complexity of the relationship between the performer and the use case

7) Note the size of the use case is appropriate

8) Avoid use case description confusion

9) distinguish between force decomposition and functional decomposition

10) Avoid customer failure to understand use cases

11) In some cases, it is not appropriate to use use case diagrams to describe requirements

       Summary

In the requirements analysis phase of software engineering, it is often necessary to model the target system using the UML use case diagram, and through the visual use case models, the

The system to be developed has a visible description that enables developers and users to reach a consensus on requirements specifications, as well as developers and customers

A powerful tool for streaming.

The use case model describes the functional requirements of the system to be developed, and it treats the system as a black box, only from the perspective of the external performer to understand and describe the system, and drive

The development of all phases after the requirement analysis.

UML Modeling Learning 5:use-case Diagram