I. Elements:
1. Roles, use cases (function description), relationships (generalization, dependencies, associations, implementations)
2. Element meaning:
Actor |
1. Can be a person, a thing, an object 2. Analyze role considerations: People who use the system directly, maintenance personnel, peripherals (people, printers), connected systems 3. Participate in the implementation process of use cases
3. Graphic characters: |
Case |
1. Name: to reflect the function of the system
2. Graphic characters: |
Relationship |
1.4 Kinds of relationships: Association-> are divided into: bidirectional and one-way, the relationship between the participant and the use case is often related Dependencies---> use relationships, such as a method of using another class for a class Generalization of a use case is cited by several use cases using 2. Other relations: The behavior of a use case containing the include one that contains another use case Extending the Extend (interface extension) A use case is defined as an incremental extension of the underlying use case, and the extension use case adds new behavior to the base use case |
Diagram Description:
Association:
Depend on:
Generalization:
Contains:
Extended:
Two. Role: Describe the needs of the user (emphasizing the function, the performer of the function, the system in use)
Three. Use case note points
1. Clearly define the boundaries of the system (i.e. to determine which functions belong to the system)
2. Prevent overuse of use cases (granularity)
3. Naming use cases from the performer's perspective
4. Description of the level of formality
5. Avoid inconsistent name of performer
6. Avoid the relationship between the performer and the use case too complex (add a new performer if it is too complex)
7. Use Case Size appropriate
8. Use Case Description Confusion
Four: main attributes
Event Flow |
1. The interaction between role and system during the execution of a use case; 2. Divided into basic flows (descriptions of general and expected paths in use cases) and alternative flows (other paths affected) |
Predecessor condition |
(Prerequisites for execution) under what conditions does an event flow begin |
Post condition |
The state of the system after the use case ends |
Five: Grain size
When drawing a system's use case diagram, how many use cases are drawn, and how many use cases are appropriate, often in the drawing of a system of use case diagram when a layer of use cases is not enough, often need to draw several layers, then the question comes, I this use case to the first floor, or the second layer that, then there is a criterion-granularity, The more the use case, the greater the granularity, the general use case in 10--50 a suitable.
The granularity used at different stages is different:
1. Business Modeling phase: A use case can describe a complete flow of events
2. Use case Analysis phase: A use case can describe the computer and user personnel can complete a successful interaction process
3. The development of the use case is about a week's time.
VI: Scope
Divided into: overview level, user target level, child function level
Two use cases use the same use case at the same time, which means that the two use cases contain the same relationship and reuse a relationship
VII: Generation phase and user use
Mainly in the system analysis phase, the user describes the user's needs (function), produced in the Requirements analysis report
Usage: User, system development, design, tester, project leader
Eight: Illustrations (take the computer room toll system as an example)
Analysis of the system's user requirements: The system has 3 roles, respectively, administrators, operators and general users,