1 CS2200 Software Development Lecture: UML II: Review and Case Study A. O’Riordan, 2008 Incorporates notes by K. Brown and C. Korbyn

2 Lecture Overview ●UML Notation for System/Application Modelling ●Review of UML from last lecture ●Use Cases for OOA ●Class Diagrams for OOD ●UML Case Study ●Computer Centre Helpdesk Application

3 Fig. 3-53, UML Notation Guide Use Case Diagram

4 When to use use cases and Tips on use ●Model user requirements with use cases ●Model test scenarios with use cases ●If you are using a use-case driven method start with use cases and derive your structural and behavioral models from it. ●Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and developers ●Factor out common usages that are required by multiple use cases ●If the usage is required use > ●If the base use case is complete and the usage may be optional, consider use >

5 Classes

6 Generalization

7 Objects

8 Structural Modeling Tips ●Define a “skeleton” (or “backbone”) that can be extended and refined as you learn more about your domain/develop system ●Focus on using basic constructs well; add advanced constructs/notation only as required. ●Defer implementation concerns until late in the modeling process ●Class diagrams should contain classes at the same level of abstraction ●Large numbers of classes should be organized into packages (not covered)

9 Case Study: Computer Centre Helpdesk Requirements: A university computing centre runs a helpdesk for handling problems with the hardware and software. When a client presents a problem its details are recorded, and it is either solved immediately at the front desk or delegated to an officer not at the front desk. The officer who initially received the problem "owns" it, and must ensure it is handled to completion. When a delegated task returns to the owner, the owner must decide whether it is solved, completely failed, or needs to be re-delegated. When it is completed, a report is given back to the client.

10 Use Case Diagram client officer front desk manager request help tackle problem attend desk review logs log call delegate report

11 Scenario: request help Main Success Scenario 1.Client calls for help 2.Front logs the call 3.Front delegates the call 4.Officer solves problem 5.Front completes call 6.Front reports to Client Extensions 4a. Officer reports failure 4a1. Front redelegates (return to 3)

12 Scenario: Attend Desk Main Success Scenario 1.while on duty 2. if client in queue log call 3. else if call in queue delegate task 4. else if owned task returned handle task 5. else if owned task delayed query 6. else if personal task in queue solve

* * * 1 * HelpDesk Officer FrontStaff CallList Call CallQueue User Class Diagram

Detailed Class Diagram 1 1 * * * HelpDesk -front: FrontStaff -taskList: CallList -callQ: CallQueue -officers: List +changeFrontStaff(FrontStaff): void +processUserCall(): void +getOfficers(): List +getNextCall(): Call +finishTask(Call c): void Officer -delegatedList: CallList +acceptTask(Call c): void +solveTask(Call c): void +respondToDelay(Call c): String +processTasks(): void FrontStaff -helpDesk: HelpDesk -ownedList: CallList -returnedList: CallList +processCalls(): void +processList(): void +takeBackTask(Call c): void +checkDelays(): void CallList -list List : CallQueue -queue Queue : Call -callID: String -user: User -description; String -time: Time -owner: FrontStaff -officer: Officer -finished: boolean +Call(String, User, Time) +setDescription(String): void +setOwner(FrontStaff): void +setOfficer(Officer): void +setFinished(boolean): void +getID(): String +getUser(): User +getDescription(): String +getTime(): Time +getOwner(): FrontStaff +getOfficer(): Officer +getFinished(): boolean User -ID: String : 1 *