1. Use Case Diagrams

2. Roadmap

3. Agenda
Use case and use case driven development
How to read use case diagrams?
How to draw use case diagrams?
Applications of use case diagrams
Summary

4. Agenda
Use case and use case driven development
How to read use case diagrams?
How to draw use case diagrams?
Applications of use case diagrams
Summary

5. Practice of Modern Requirements
Commonality：Define systems from the standpoint of users and use languages that users can understand
Names
Descriptions
Use Case
describes the external visual requirements of a system, is an agreement on the system behaviors achieved by the stakeholders（风险承担人）
User Story
written by users in their languages, describes how the system works, usually contains about 3 sentence
Feature（特性）
a small function, can be represented as <action><result><object>

6. Process of Use Case Driven Development
There two typical use case driven development process, one is RUP the other is ICONIX .
In these processes, developers first capture the user requirements and construct the use case models. Next, the models are analyzed to build a system to meet the requirements. Then they implement the system. After that, they design a testing model to test the system.
The conversion from one model to another is not a linear (线性) process, but an iterative (迭代) and incremental (增量) process.

7. Actors
An actor is an entity that interacts with the system to complete a transaction. A user is a role against the system.
Actors can be not only humans, but also other systems, devices and even clocks.
1) Other systems: In the ATM system, the backend system is an actor. 2) Devices: In the IC card door guard system, the card reader is an actor. 3）Clocks: A clock is an actor when
the system need to be triggered timely.

8. Use Case
An instance of a use case is a series of actions in the system. use case should produce a result of observable value to a business actor.
A use case contains a set of use case instances. An instance is usually called a “scenario”. It’s a practical scenario that users use the system.
Use cases ought to bring benefits to the actors, this is very important.

9. Agenda
Use case and use case driven development
How to read use case diagrams?
How to draw use case diagrams?
Applications of use case diagrams
Summary

10. Reading Use Case Diagrams

11. Components of Use Case Diagrams
The components are actors, use cases, a rectangle, and connections which represent relationships.
All the use cases are in the rectangle. The rectangle is called “the boundary of the system”.
An actor and a use case is connected with a arrow line.
Relationships between use cases include: 1) Inclusion 2) Extension 3) Generalization

12. Inclusion and Extension
Use cases that are included (检查座位详情 in this example) are not isolated, but as a part of a larger base use case (预订座位、安排座位 in this example).
Base use cases (基用例) can be independent of any extending use cases. Their behaviors can be extended by another use case under certain conditions.

13. Generalization
Generalizations can be used to represent the general/specialized relationships between actors or between use cases.

14. Summary of Reading Use Case Diagrams
This diagram defines 3 base use cases: OrderingSeats, ArrangingSeats and CheckingOut.
Customers launch the OrderingSeats use case via the Internet. The CheckingSeatsDetails (included use case) use case will be launched then. If there are no vacant or satisfying seats, customers can choose to enter the waiting queue and launch the ProcessingWaitingQueue use case (extending use case).
The waiter launches the ArrangingSeats use case when the customer arrives. During the execution, the CheckingSeatsDetails (included use case) use case will be launched.
When the customer leaves, the head launches the CheckingOut use case and defines two Receiving use cases: CashReceiving and CardReceiving. The later needs to interact with the POS system.

15. Use Case Specification
Use cases describe what the system does (what) rather than how it does (how). The design model is responsible for explaining how the system does.
The event streams:

16. Template of Use Case Description
用例编号
[为用例制定一个唯一的编号，通常格式为UCxx]
用例名称
[应为一个动词短语，让读者一目了然地知道用例的目标]
用例概述
[用例的目标，一个概要性的描述] 范围
[用例的设计范围]
主参与者
[该用例的主Actor，在此列出名称，并简要的描述它]
次要参与者
[该用例的次要Actor，在此列出名称，并简要的描述它]
项目相关人
利益说明 利益
[项目相关人员名称]
[从该用例获取的利益] ……
前置条件
[即启动该用例所应该满足的条件。]
后置条件
[即该用例完成之后，将执行什么动作。]
成功保证
[描述当前目标完成后，环境变化情况。]
基本事件流 步骤 活动 1
[在这里写出触发事件到目标完成以及清除的步骤。] 2
……(其中可以包含子事件流，以子事件流编号来表示)
扩展事件流 1a
[1a表示是对1的扩展，其中应说明条件和活动] 1b
子事件流
[对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。]
规则与约束
[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]

17. Template of Use Case Description

18. Agenda
Use case and use case driven development
How to read use case diagrams?
How to draw use case diagrams?
Applications of use case diagrams
Summary

19. Procedure for Drawing Use Case Diagrams

20. Recording the Requirements (Feature Sheet)
Number
Introductions
FEAT01
Add books information
FEAT02
Modify an existing book information
FEAT03
Book information by computer and non-computer books class respectively file
FEAT04
When entry new books can automatically generate number
by rule
FEAT05
Computer and non-computer books using different numbers of rules
FEAT06
When entry new book if duplicate names will be automatically prompted
FEAT07
By title, author, category, Publisher, keyword query books
FEAT08
List all books
FEAT09
Record lending
FEAT10
Loan status can be automatically reflected in the books information
FEAT11
According to the people, according to the Book query borrowing
FEAT12
Lists all the loan
FEAT13
According to the statistics of a specific time period for amounts, number of copies
FEAT14
All queries, lists, statistics features should have a separate computer and non-computer classes

21. Identifying the Actors
Known context relationship and other related models: they define the system boundary; external entities that interact with the system can be identified from them.
Related personnel analysis: personnel that interact with the system can be identified by the analysis.
Specifications and other project documents
Notes of requirement and development meeting: these notes are important and the roles they represent may be actors.
Training guides and users manual: potential actors are usually contained in them.

22. Merge Requirement to Obtain Use Case
Properties
Use case
FEAT01. New books information
FEAT03. Book information by computer and non-computer books class respectively file
FEAT04. When entry new books can automatically generate number
by rule
FEAT05. Computer and non-computer books using different numbers of rules
FEAT06. When entry new book if duplicate names will be automatically prompted
UC01. New book information
FEAT02. Modify an existing book information
UC02. Modify book information
FEAT07. By title, author, category, Publisher, keyword query books
FEAT08. List all books
FEAT14. All queries, lists, statistics features should have a separate computer and non-computer classes
UC03. Query for book information
FEAT09. Record lending
FEAT10. Loan status can be automatically reflected in the books information
UC04. Registered loan information
FEAT11. According to the people, according to the Book query borrowing
FEAT12. Lists all the loan
UC05. Query for loan information
FEAT13. According to the statistics of a specific time period for amounts, number of copies
UC06. Statistical amount and number of copies

23. Draw Use Case Diagram

24. Detailed Use Cases Describe-Set framework
1. use case name: new book information (UC01)
2. brief description: new book entry information and
automatically stored file.
3. Event flow：
3.1 Basic event flow
3.2 Extended event flow
4. Non-functional requirements
5. The preconditions: user access to library management system.
6. The postconditions: complete new book information store file.
7. Extension point: none
8. Priority: highest (5 satisfaction, no satisfaction 5)

25. Detailed Use Cases describing-Complete Details……
3. Event flow：
3.1 Basic event flow
1）The librarian issues a new book information to the system;
2）System requirements for librarian selected for new books is computer and non-computer class;
3）Librarians have made a selection, display the appropriate interface, library management enter information and automatically generate numbers based on ISBN rules;
4）Librarian, enter the information about the books, including: title, author,Publisher, ISBN number, the size, number of pages, price, is there a CDROM;
5）Confirm the information you entered in the title does not have the same name as the system;
6）System will enter the information store files.
3.2 Extended event flow
5a） If you enter title names shows the same phenomenon,display names of books, library management and asked to select or modify the title abolished;
5a1）Librarian choose to cancel the input case will end without stored file;
5a2）After a librarian choose to modify the title, turn to 5)
4. Non-functional requirements: no special requirements……

26. Writing Essentials
Using a simple syntax: subject specific, semantics are easy to understand;
Clearly write "who controls the ball": that is, in the event description, allowing readers to visualize is a participant in the control or system control;
Written from the over looking view: pointed out that participants of the action, as well as the response, that is, from the angle of observation by a third party;
Displays the process forward: the first step has a sense of progression;
Show participants ' intentions rather than actions (if only describes an action, people could not easily understood directly from the flow of events describes use cases);

27. Writing Essentials
Include "reasonable set of activities" (with the data returned by the request, confirm, change, results);
Use “confirm” rather than “check if”
Optional reference to time limits;
Use the idiom“Users to make the system A and system B interaction";
Use the idiom "Loop step x to y, until the conditions are met".

28. Agenda
Use case and use case driven development
How to read use case diagrams?
How to draw use case diagrams?
Applications of use case diagrams
Summary

29. Application of Use Case Models
Incremental development
of use case models
Seamless transformation
of models

30. Modeling Essentials
Build structured use case： 1）Naming a single, identifiable, and reasonable atomic behavior for the system and part of the system； 2）Public behavior extracted into a contained use case, then the include in it;
3）Change parts, to extract it and put it into an extended case (of the extent of the connection);
4）Clearly describe the event stream, so readers can easily understand
Build structured use case diagram: display elements, should avoid the appearance of crossed lines; for semantically close behavior and role, it is best to bring them physically closer;
According to the system control granularity

31. Agenda
Use case and use case driven development
How to read use case diagrams?
How to draw use case diagrams?
Applications of use case diagrams
Summary

32. Summary
First from three modern demand technology, introduced the method of use case driven development process, and described in detail the concepts of participants and use cases
Combining a “chess museum management systems” use case diagram for explaining the method of reading use case diagrams, including system boundaries, include, extend and generalization relationships, and based on this introduced a method of use case descriptions、format and related key points
Drawing method：described and explained in detail from the record demand to the identification of the participants, the combination of demand generation cases and the final use case description
Describes the case of incremental development model, a seamless transition of a model element, the two important perspectives