Shulou(Shulou.com)06/03 Report--

I. the history and black box perspective of Usecase diagrams.

1. History of use case diagrams

In 1987, I.Jacbson first proposed

L has been adopted by many methodologies.

Adopted and standardized by UML in the late 1990s

two。 System boundary

Black box: what role does the system play in the external world and what business functions do it provide to show the system?

White box: how the system provides business functions.

N question: how to describe what kind of system users need when the system does not exist? How to define user requirements in a standardized way?

N thinking about the problem: think of the system as a black box, see what role it plays in the external objective world, and describe its externally visible behavior.

System boundaries and participants

System boundary: the dividing line between all the system components contained in a system and all kinds of things outside the system.

L system: the software used by the "user" and all the hardware associated with it. Refers to the developed computer software and hardware system, not the real world system.

L system components: system elements defined in OOA and OOD and implemented in programming-object system boundaries and actors

Participants: things that interact with the system beyond the boundaries of the system-personnel, equipment, external systems

Pay attention to the problems:

L system refers to the developed computer software and hardware system itself.

Some things in the problem domain will be treated as participants.

The pre-existing system is regarded as an external system.

L subsystems can be external systems to each other.

The relationship between things and systems in the real world includes the following situations:

Something is within the boundary of the system as a component of the system.

Some things are located outside the boundaries of the system, as participants.

Some things may be both as participants and as system components.

Something is neither a participant nor a component of the system.

II. The concept, classification and relationship of participants

Participant

In short, an actor is anything that interacts with the system outside the system.

L definition: an entity outside the participant model system that acts as a specific actor when an external entity interacts with the system.

N participants can make requests for system services

N provide services according to the requirements of the system

N interact with the system through a complex dialogue of service requests between the participant and the system

N the complete set of requests / responses of all participants constitutes the perceptible boundary of the system's problem domain.

N an instance of a participant represents a separate interaction with the system in a particular way.

N although participants are used in the model, participants are not actually part of the system. They exist outside the system.

The generalization relationship between participants

Some participants may have a common request for system calls.

One approach is to explicitly associate each such identical request with each participant. (not recommended)

2 if a group of participants have common properties, these properties can be extracted and placed in another participant, and they can inherit from them, and this relationship is called the generalization relationship between participants.

2 definition: the generalization relationship from participant A to participant B means that the instance of A can communicate with the use case instance that communicates with the instance of B.

four hundred and fifty

Strategies and skills for identifying participants

Identify participants

1. First of all, focus on the participants who initiate the system behavior.

two。 Participants are found from three aspects: users, external systems and devices.

3. Organize participants by identifying general or special roles.

Users, external systems and devices

User

Find participants from people who use the system directly

The emphasis here is on direct use, not indirect.

Specific people can play different roles in the system.

Is the category of the user role

External system

All external applications that interact with the system are participants

An external application system can be another subsystem, a superior system, or any system that collaborates with it.

Equipment

Identify all devices that interact with the system

U equipment connected to the system

To provide external information to the system or to operate under the control of the system.

Generally speaking, monitors, keyboards, mice and other standard user interface types of devices are not included.

Consider external sensors (input information) and controlled motors (output information).

External event

When we build real-time and asynchronous interactive systems, it becomes more important to identify external events as potential participants.

For example, it is common to stimulate the activity of the system by the passage of time. You can use time events as a participant or as part of the system.

IV. Use cases and simple cases

Use case

Definition: a use case is a description of the interaction that occurs when a participant uses a function of the system.

A use case is a special sequence of transactions, performed by auser and a system in a dialogue. [Jacobson 1987]

Reasons for usage

A use case is a standardized description of user requirements (mainly functional requirements).

U provides a means for domain experts, end users and developers to communicate with each other.

U provides developers with a way to understand and understand the system.

U use cases are the basis for testing each element as it evolves during development.

The relationship between use cases and participants

Definition: an association is the participant's participation in the use case (that is, the communication between the participant instance and the use case instance).

In the absence of special instructions, either party can send and receive messages.

This is the only relationship between the participant and the use case. The interaction is two-way, and participants can generate requests to the system, or certain actions that the system requires participants to take.

The association between the participant and the use case is represented as a solid line between the participant and the use case.

Example 1: voicemail system

In a voicemail system, when someone dials a number, if no one answers the call, the person leaves a message. Later, the information is retrieved by another person and retained or deleted.

A use case may interact with multiple participants

Real-time interaction between participants through the system

The participants are in the same control flow as the system

Example 2: course selection system

In the course selection system, after logging in, students can query all the courses and select the courses they want to take, or they can give up the courses they have already selected. after logging in, the instructor can add a new course and delete a course. and can review the courses chosen by students together with the instructor, and cancel the selected courses if not appropriate.

Fifth, the relationship and cases between use case participants and use cases

The relationship between use cases-- extended relationship

Definition: the extended relationship from use case A to use case B means that an instance of use case B can be extended by the behavior specified by use case A (subject to the special conditions specified in the extension). The behavior is inserted into the location defined by the extension point in B.

The extended relationship between use cases is indicated by an open dotted arrow, which points from the use case that provides the extension to the base use case. The arrow is marked with keywords. The conditions of the relationship can be expressed near this keyword.

An extension point is a location in a use case where you can insert a sequence of actions for other use cases.

In a use case, the name of each extension point is unique.

You can list the extension point in a sub-column with the title "extension point" in the use case. The location description of the extension point is given in an appropriate way, usually in plain text.

The relationship between use cases-inclusion relationship

Definition: the inclusion relationship from use case A to use case B indicates that an instance of use case An also contains the behavior that use case B points to. The location defined in use case A contains this behavior.

The inclusion relationship between use cases is indicated by an open dotted arrow pointing from the base use case to the included use case. The arrow is marked with keywords.

Inclusion relationships allow us to localize a common sequence of activities in multiple use cases in one use case. In this way, you can avoid describing the same event flow multiple times; when this common sequence changes, it shows the advantage that you only need to make changes in one place.

VI. The differences between inclusion relationship and extension relationship among different scholars

Viewpoint 1

Identical point

N is incomplete.

N is inseparable from basic use cases.

N can be implemented as a subroutine.

Differences

The n direction is different.

N1-to-multiple inclusion relationship (1 sub-use case, multiple main use cases)

N many-to-1 optional extension (multiple sub-use cases, 1 main use case)

N includes handling general cases (unconditional invocation when called)

N extension handles special cases (when called, it is conditional)

Viewpoint 2

Maksimchuk & Naiburg, UML for Mere Mortals,2005

Include

Extend

Is this usecase optional?

No

Yes

Without this usecase, is the basic usecase complete?

No

Yes

Is there any condition for the implementation of this usecase?

No

Yes

Does this usecase change the behavior of the basic usecase?

No

Yes

Viewpoint 3

Usecases-Yesterday, today, and tomorrow, Ivar Jacobson

Identical point

NExtensions/inclusions that are concrete use cases. (extension / inclusion is specific use case)

NExtensions/inclusions that are just fragments of a use case. (extension / inclusion is part of the use case)

NExtensions/inclusions use cases are both related to a base use case. (extension / inclusion of related use cases are basic use cases)

NWhen the usecase instance has come to the end of the extension orthe inclusion usecase, it will return to the base usecase and to the positionin the flow described in the base usecase, where it left off.

Differences

NThe major difference between extension and inclusion use cases isthe way that use case instance is instructed to interrupt the base use case andinstead follow the extension or inclusion use case.

NIn the case of inclusion, the base flow itself explicitly instructsthe use-case instance to obey the inclusion use case.

NIn the case of extension, the base flow doesn't specify theinterruption; instead, the extension usecase specifies where in the base usecase the usecase instance shall make the interruption.

Viewpoint 4

UML Distilled,MartinFowler

Use include when you repeat yourself in two or more separate usecase and want to avoid repetition.

Generalization is used when a change in normal behavior is expressed and you want to express it temporarily.

Use extensions when you express a change in normal behavior and want to describe extension points in the base usecase in a more controlled form.

Viewpoint 5

Object-oriented system analysis, Shao Weizhong, Yang Fuqing

There is little semantic difference.

It's easy to get mixed up in practice.

Why there are no points included

Different directions

7. Generalization relationship between use cases, detailed description of use cases, identification strategies and problems needing attention.

Generalization relation

The behavior and meaning of the child use case inheriting the parent use case.

Child use cases can also increase or override the behavior of parent use cases.

The child use case can appear anywhere the parent use case occurs.

The generalization relationship between use cases is represented by a solid line with a closed hollow arrow pointing to the parent use case.

Mixed use of participant generalization and use case generalization

Use case classification

L High-level use case and low-level use case

2 the high-level use case description gives a general and brief description of the elements provided by valuable functions, regardless of how these valuable functions are obtained. (usecase figure)

2 low-level use case descriptions provide business details that represent the exact order of activities, tasks, or changes. (detailed description of the use case)

L essential and specific use cases

2 essential use cases are independent of implementation (hardware and software) business solutions

(2) the specific use case depends on design.

L primary and secondary use cases

(2) the main business functions of the use case capture system.

2 secondary use cases deal with unusual and exceptional situations. Optional use cases represent use cases that can be handled or not.

The use case is a summary of the scene.

Strategies for capturing use cases

1. First write down two or three of the most common simple scenarios (use cases).

two。 When two or three scenarios look similar, try to produce more "abstract" scenarios (use cases).

3. Additional use cases for unusual times should be carefully selected and maintained in manageable quantities.

4. Analyze it incrementally.

(2) first of all, develop the main and high-level use case model.

2 then use this model to develop major and essential use case models.

2 further use the resulting model to guide the development of secondary, essential use cases.

2.

Finally, use this model to develop secondary and specific use cases.

Use case document template

Use case name

Description: a description of one or two sentences of the use case.

Participants: identify the participants who participate in the use case.

Contains: identify the use cases contained in this use case.

Extension: identify use cases where the use case can be extended.

Generalization: if the use case is a child use case, state its parent use case.

Prerequisites: the conditions necessary to start this use case.

Details: identify the details of the use case.

Post conditions: identify the conditions that are guaranteed at the end of the use case.

Exceptions: identify exceptions that may arise during the execution of the use case.

Limitations: identify any restrictions that may occur in the application.

Note: provide any additional information that may be important to this use case.

For example:

Example: online job distribution system

In the online job publishing system, the editor of the job publisher prepares to publish the job title, job requirements, recruitment and other information, preview the layout of the published position, and then publish it online after passing the permission check. In addition to the general type of job posting, there is also a special effects job post that allows job publishers to post custom images / pages, and so on.

Detailed description of the use case

Three ways to describe the use case in detail

Describe the problem of the use case in detail

2 there is no system

2 there are no participants

2 too many user interface details

2 too low target level

VIII. Applications, complex cases and modeling points of use case diagrams

Application of use case Diagram in Software Lifecycle

2 is mainly used to identify requirements

2 is used to assist analysis

2 to assist in the design, especially the design of the user interface

2 is used for testing

Use case grouping

When many use cases have the same function or relate to each other in the same way, they are grouped together. The package of UML represents the clustering of use cases.

The basis of grouping

2 the same participants

2 common entity

Book: reader administrator

2 specific workflow

Review

2 participants

Identify all roles in the system environment and classify them as appropriate participants.

Each participant is associated with at least one use case

If one participant is part of another participant, merge them

If two participants play similar roles relative to the system, a generalization relationship should be used between them.

2 use cases

Each use case is associated with at least one participant

If two use cases have the same or similar sequences, you may need to merge them, or extract a new use case, and use include, extend, or generalize relationships between them.

If the use case is too complex, consider decomposing it for ease of understanding; if there is a completely different flow of events in a use case, it is best to break it down into different use cases.

Example:

Cardholders conduct business such as inquiry / withdrawal / transfer on the bank ATM. If ATM finds that the user has entered the wrong password three times in a row and the card has been reported lost or forgot to pick up the card, then swallow the card. If an invalid card is detected, the card will be returned. Every 12:00 at midnight. Count the total amount of withdrawals on that day and send it to the headquarters system, when the headquarters system will be notified when there is no cash in the machine.

Considerations for use case modeling

2 ensure that not only domain experts but also programmers can understand the significance of system use described in each use case.

2 when defining the use case text, nouns and verbs should be used accurately and consistently

2 distinguish the relationship between use cases / participants

2 A large number of use cases should be organized into packages

9. research on the method of use case-driven, and the comparative study of use case and user story, scenario and business use case

Research on use case Diagram

Use case-driven software development

2 positive significance

It is helpful to the establishment of analysis model and design model.

Help to improve analysis, design, implementation and testing

2 problem

Over-reliance on use cases

The old way that leads to functional decomposition.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.