Use Case Diagrams

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

Practice of Modern Requirements • Commonality：Define systems from the standpoint of users and use languages that users can understand

Process of Use Case Driven Development • There two typical use case driven developmentprocess, one isRUP 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 actoris 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 alsoother systems, devices and even clocks. • 1) Other systems: In theATM 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 isusually 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.

Reading Use Case Diagrams

Components of Use Case Diagrams • The components areactors, 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 anyextending 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 casewhen the customer arrives. During the execution, the CheckingSeatsDetails (included use case) use case will be launched. • When the customer leaves, the head launches the CheckingOutuse 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

Procedure for Drawing Use Case Diagrams

Recording the Requirements (Feature Sheet)

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 personnelanalysis:personnel that interact with the system can be identified by the analysis. • Specifications andother 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

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

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

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

Use Case Diagrams