Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated 2016

3510 Systems Analysis & Design * Bob Travica2 Outline The use case concept Business events and systems Elements of use case diagram Include and Extend relationships between use cases Reading use case diagrams Creating use case diagrams

3 Use case concept Use case is a model of system functionality. Think of main functions a system performs for users – “cases” of using a system. Figure 6-3 Use Case Diagram of Order-Entry Subsystem for RMO Use case

3510 Systems Analysis & Design * Bob Travica4 Use case diagram in system documentation Use Case helps to model system requirements Easier for users to understand than other diagrams

5 Business Event concept Figure 5-2 Events affecting a payment system that determine what system has to do – functions, use cases A stimulus that requires a system’s response Delineated in time; stands on its own External events occur outside the system “clerk calls up customer account” Temporal Events

3510 Systems Analysis & Design * Bob Travica6 Event types External Events (outside an IS) Caused by external agent (human, system) Temporal Events (inside an IS) Occur at a certain point in calendar time State Events (inside an IS) Changes in system states, such as data Event: QuantityOnHand =< ReorderAmount (QOH goes under a min.) System’s response: Create new purchase order Internal events - logic of automated decisions

3510 Systems Analysis & Design * Bob Travica7 Figure 5-10 InputOutput Events Table

3510 Systems Analysis & Design * Bob Travica8 Elements of use case diagram: Actor and System Actor is someone interacting with use case (system function). Named by a noun. Similar to the concept of user, but (a)can be non-human and (b)a user can play different roles ; (e.g.,: an employee can be worker and manager – plays 2 roles in a system*). Name System Shape of oval, contains small ovals that stand for use cases (system functions)

Actor-System relationship 3510 Systems Analysis & Design * Bob Travica9 of 14 Actor triggers (initiates, starts) use case (a system function). Actor has responsibility toward the system (inputs), and Actor has expectations from the system (outputs). System has responsibility to respond properly to events – to execute an appropriate function.

= Use Case 3510 Systems Analysis & Design * Bob Travica10 Elements of use case diagram: Use Case System function (process – automated or manual). Named by a v erb. Do something Each Actor must be linked to a UC, while some use cases may not be linked to actors (e.g., functions responding to temporal events, UC related to another UC).

11 Elements of use case diagram: Other components Boundary of a system > Include relationship between Use Cases (one UC must call another; e.g., Login UC includes User Authentication UC) > Extend relationship between Use Cases (one UC may call another under certain conditions; think: if-then logic among system functions) Connection between Actor and Use Case Relationships between Use Cases

3510 Systems Analysis & Design * Bob Travica12 Include relationship Include relationship – a standard UC linked to a mandatory UC. Standard use case can NOT execute without the include case  tight coupling. Example: to Authorize Car Loan (standard use case), a clerk must run Check Client’s Credit History (include use case). BUT, do not imply sequential logic, process thinking! The standard UC includes the mandatory UC (use the verb to figure direction arrow). Note: Visio calls this “uses” relationship. Do something (Process loan application) And do as part of Do something (Check credit history) includes

3510 Systems Analysis & Design * Bob Travica13 Reading use case diagram with Include relationship Note: An “s” missing in “include”.

3510 Systems Analysis & Design * Bob Travica14 Extend relationship – associating an optional use case to a standard use case. Extend relationship Example: Register Course (standard use case) may have Register for Special Class (extend use case) – class for non-standard students, in unusual time, with special topics, requiring no fees or extra fees…). The optional UC extends the standard UC Standard UC executes without the extend UC; an extend UC executes instead of standard UC.  loose coupling. Do something (Register Course Section) Do if conditions apply (bypass tuition fees for University Staff actor) extends

UC relationships – warning! Invoke UC relationship sparingly, only when necessary to show relationships (dependencies) between system functions. Do not fall in a process trap - thinking about UCs as steps of a large process. UCs are system functions (each consisting of specific steps). Note: UC diagram vs. Activity diagram 3510 Systems Analysis & Design * Bob Travica15 of 14 System collapsed into An activity diagram shows design of a a system function in UC diagram, the content of one oval.

Temptations with > and > 3510 Systems Analysis & Design * Bob Travica16 of 14 Log in > Over- draft WDL > Lots of errors! Better: One validation function included by the function “Log in” and delete all include and extend relationships.

3510 Systems Analysis & Design * Bob Travica17 How to create use case diagram 1. List main system functions (use cases) in a column: think of business events demanding system’s response users’ goals/needs to be accomplished via the system Create, Read, Update, Delete (CRUD) data tasks Naming use cases – user’s needs usually can be translated in data tasks 2. Draw ovals around the function labels (use cases) 3. Draw system boundary 4. Draw actors and connect them with use cases (if more intuitive, this can be done as step 2) 5. Specify include and extend relationships between use cases – if any (yes, at the end - not before, as this may pull you into process thinking, which does not apply in UC diagramming).