Use Case Diagrams

Roadmap

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

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

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>

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.

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.

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.

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

Reading Use Case Diagrams

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

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.

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

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.

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:

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

Template of Use Case Description

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

Procedure for Drawing Use Case Diagrams

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

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.

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

Draw Use Case Diagram

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)

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……

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);

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".

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

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

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

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

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