Transcript Lecture 42: Development Case Study

CS2200 Software Development
Lecture: UML II: Review and Case Study
A. O’Riordan, 2008
Incorporates notes by K. Brown and C. Korbyn
1
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
2
Use Case Diagram
Telephone Catalog
Check
status
Place
order
Salesperson
Fill orders
Shipping Clerk
Customer
Establish
credit
Supervisor
Fig. 3-53, UML Notation Guide
3
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 <<include>>
● If the base use case is complete and the usage may be
optional, consider use <<extend>>
4
Classes
Window
Window
size: Area
visibility: Boolean
display ()
hide ()
Window
{abstract,
author=Joe,
status=tested}
+size: Area = (100,100)
#visibility: Boolean = true
+default-size: Rectangle
#maximum-size: Rectangle
-xptr: XWindow*
+display ()
+hide ()
+create ()
-attachXWindow(xwin:Xwindow*)
5
Generalization
Shape
Separate Target Style
Polygon
Ellipse
Spline
. ..
Shape
Polygon
Ellipse
Shared Target Style
Spline
...
6
Objects
triangle: Polygon
center = (0,0)
vertices = ((0,0),(4,0),(4,3))
borderColor = black
fillColor = white
triangle
:Polygon
triangle: Polygon
scheduler
7
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)
8
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.
9
Use Case Diagram
request
help
attend
desk
front
desk
client
log call
delegate
report
review
logs
manager
tackle
problem
officer
10
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)
11
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
12
Class Diagram
1
1
HelpDesk
1
0..1
*
Officer
0..1
1
1
1
1
FrontStaff
CallList
0..1
2
1
*
Call
1
*
CallQueue
*
1
User
13
Detailed Class Diagram
1
1
*
Officer
-delegatedList: CallList
+acceptTask(Call c): void
+solveTask(Call c): void
+respondToDelay(Call c): String
+processTasks(): void
1
1
0..1
0..1
1
FrontStaff
-helpDesk: HelpDesk
-ownedList: CallList
-returnedList: CallList
+processCalls(): void
+processList(): void
+takeBackTask(Call c): void
+checkDelays(): void
HelpDesk
-front: FrontStaff
-taskList: CallList
-callQ: CallQueue
-officers: List<Officer>
+changeFrontStaff(FrontStaff): void
+processUserCall(): void
+getOfficers(): List<Officer>
+getNextCall(): Call
+finishTask(Call c): void
0..1
2
1
CallList
-list List<Call>
:
:
1
*
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
1
*
*
1
CallQueue
-queue Queue<Call>
:
:
1
User
-ID: String
:
: