Design Report:
Resource Management Software
CS400 – Senior Design I
Mark Briggs
Paul Knell
John Schluechtermann
Jeremy Vechinski
Electrical Engineering and Computer Science Department
Milwaukee School of Engineering
Milwaukee, WI, USA
Submitted To: Professor William Barnekow
Submitted: 7 February 2000
D
ESIGN
R
EPORT
– R
ESOURCE
M
ANAGEMENT
S
OFTWARE
P
AGE
1
Table of Contents
Table of Figures ………………………………………………………….. 2
Introduction ………………………………………………………………. 3
Use Cases ………………………………………………………………… 4
Use Case Diagrams ……………………………………………………... 33
Conceptual Model ……………………………………………………….. 36
Sequence Diagrams …………………………………………………….. 37
Class and Package Diagrams ………………………………………… 72
Package Diagram ……………………………………………………………… 72
Class Diagrams ………………………………………………………………… 73
Class Descriptions ………………………………………………………. 76
System Contracts ……………………………………………………….. 79
Graphical User Interface Design ……………………………………… 96
Windows and Dialog Boxes …………………………………………………. 96
Project and Resource Graphs ………………………………………………. 106
Conclusions ………………………………………………………………. 108
Works Cited …………………………………………………………….… 109
Appendix A – Specifications Document …………………………….. 110
Appendix B – Glossary …………………………………………………. 114
Appendix C – Java Code for the GUI ………………………………… 115
D
ESIGN
R
EPORT
– R
ESOURCE
M
ANAGEMENT
S
OFTWARE
P
AGE
2
Table of Figures
Figure 1: Use Case Diagram Showing Use Cases Only Available To AdminUsers................... 33
Figure 2: Use Case Diagram Showing Uses Cases Available to Both AdminUsers and
ProjectLeadUsers.............................................................................................................. 34
Figure 3: Use Case Diagram Showing Use Cases Available To All Users................................ 35
Figure 4: Conceptual Model ..................................................................................................... 36
Figure 5: Sequence Diagram for Add Client Use Case............................................................. 37
Figure 6: Sequence Diagram for Modify Client Use Case......................................................... 38
Figure 7: Sequence Diagram for Delete Client Use Case (No Projects Assigned to Client) ...... 39
Figure 8: Sequence Diagram for Delete Client Use Case (Some Projects Assigned to Client) .40
Figure 9: Sequence Diagram for Add Project Use Case........................................................... 41
Figure 10: Sequence Diagram for Modify Project Use Case..................................................... 42
Figure 11: Sequence Diagram for Delete Project Use Case (No Resource Allocations) ........... 43
Figure 12: Sequence Diagram for Delete Project Use Case (Some Resource Allocations) ...... 44
Figure 13: Sequence Diagram for Add Resource Use Case (Consultant Specific) ................... 45
Figure 14: Sequence Diagram for Add Resource Use Case (Machine Specific)....................... 46
Figure 15: Sequence Diagram for Add Resource Use Case (Room Specific)........................... 47
Figure 16: Sequence Diagram for Modify Resource Use Case (Consultant Specific) ............... 48
Figure 17: Sequence Diagram for Modify Resource Use Case (Machine Specific)................... 49
Figure 18: Sequence Diagram for Modify Resource Use Case (Room Specific)....................... 50
Figure 19: Sequence Diagram for Delete Resource Use Case (Consultant Specific) ............... 51
Figure 20: Sequence Diagram for Delete Resource Use Case (Machine Specific) ................... 52
Figure 21: Sequence Diagram for Delete Resource Use Case (Room Specific)....................... 53
Figure 22: Sequence Diagram for Add Resource Allocation Use Case..................................... 54
Figure 23: Sequence Diagram for Add Resource Allocation Use Case (Low-Level) ................. 55
Figure 24: Sequence Diagram for Delete Resource Allocation Use Case................................. 56
Figure 25: Sequence Diagram for Add Timeslot Use Case....................................................... 57
Figure 26: Sequence Diagram for Modify Timeslot Use Case .................................................. 58
Figure 27: Sequence Diagram for Delete Timeslot Use Case................................................... 59
Figure 28: Sequence Diagram for Add User Use Case ............................................................ 60
Figure 29: Sequence Diagram for Modify User Use Case ........................................................ 61
Figure 30: Sequence Diagram for Delete User Use Case......................................................... 62
Figure 31: Sequence Diagram for Change Password Use Case .............................................. 63
Figure 32: Sequence Diagram for Startup GUI Use Case......................................................... 64
Figure 33: Sequence Diagram for Shutdown GUI Use Case .................................................... 65
Figure 34: Sequence Diagram for Select Item in Tree Use Case (Client Selected)................... 66
Figure 35: Sequence Diagram for Select Item in Tree Use Case (Project Selected)................. 67
Figure 36: Sequence Diagram for Select Item in Tree Use Case (Consultant Selected)........... 68
Figure 37: Sequence Diagram for Select Item in Tree Use Case (Machine Selected) .............. 69
Figure 38: Sequence Diagram for Select Item in Tree Use Case (Room Selected) .................. 70
Figure 39: Sequence Diagram for Select Item in Tree Use Case (ResourceAllocation Selected)
.......................................................................................................................................... 71
Figure 40: Sequence Diagram for Select Item in Tree Use Case (Timeslot Selected) .............. 71
Figure 41: Package Diagram .................................................................................................... 72
Figure 42: Class Diagram for the View Package ...................................................................... 73
Figure 43: Class Diagram for the Entity Package ..................................................................... 74
Figure 44: Class Diagram for the Controller Package............................................................... 75
D
ESIGN
R
EPORT
– R
ESOURCE
M
ANAGEMENT
S
OFTWARE
P
AGE
3
Introduction
The primary goal of this project is to develop resource allocation management software to ease
scheduling of personnel, equipment, and office space across various projects for multiple
clients. The proposal outlined the goals of the project, presented a preliminary schedule, and
brought up areas in which further research was needed. Critical areas of technology were
researched and the findings were summarized in the technology research report. After deciding
on specific implementation technologies based on the research, work on the design of the
system was begun.
In order to properly design this software system, the procedures outlined in the textbook
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design by Craig
Larman were employed. The first step taken was to identify all the tasks a user might ask the
system to perform. Use cases (narratives which describe the interaction between the system
and the user) were written. Second, by looking at the nouns in the use cases, it was possible to
pick out a number of classes for possible implementation. Also, by going back to the proposal
and examining other information provided by the client, additional classes and the data to be
stored in these classes were obtained. This information was combined to form a conceptual
model, which shows the major classes and their attributes.
After the conceptual model was complete, high-level sequence diagrams, which visually depict
how the classes interact, were constructed. A sequence diagram was created for each use
case. The sequence diagrams aided design in two ways. First, they brought to light several
deficiencies in the design. Second, they gave the team an idea of the methods (member
functions) that would need to be present in each class. The last step in the design process was
to build a complete class diagram. The class diagram lists all the classes that will be
implemented in the software system, along with their attributes and methods. It also shows the
relationships that exist between the classes.
In parallel with the development above, a specifications document was drafted. The
specifications document was constructed to provide a textual description of the features of the
system and a general overview of the system implementation. The information covered in the
specifications document includes the data to be stored in the database, the graphical user
interface elements, and the general operation of the client and server software. The
specifications document was read and approved by our client, and will act as a contract
regarding the operation of the software. Additionally, design work on the graphical user
interface was completed. Layout of all major windows and dialog boxes was completed.
Finally, a glossary of terms was built as the design proceeded, ensuring that members of the
design team (as well as our client) shared an agreed upon vocabulary.
D
ESIGN
R
EPORT
– R
ESOURCE
M
ANAGEMENT
S
OFTWARE
P
AGE
4
Use Cases
Use cases are narrative descriptions of domain processes. They describe the sequence of
events an actor (user) performs to complete a task. They tell a story about the interaction
between a user and the software system. Uses cases help advance the design by aiding in
identification of classes, methods, and attributes (Larman 49).
The following use cases were written describing typical functions to be performed by the
Resource Management Software. These use cases were written using the requirements of the
system as outlined in the specifications document and as presented by our client. Note they are
essential use cases, meaning that they describe the user/system interaction without mentioning
any specific technologies.
Select Item
Purpose
The purpose of this use case is to allow the user to select an item such as: Client,
Project, Resource Allocation, Timeslot, Consultant, Machine, or Room. This use case will be
needed as a predecessor to most of the “Modify” and “Delete” use cases.
Overview
Any user will be able to perform this use case. The use case begins when the user
selects an item from the list of items that the GUI displays (which will most likely be in the form
of a graphical tree component). After selecting an item, the system will verify that the item still
exists since it is possible that the user’s display is obsolete (out-of-sync with the actual
database). If this verification fails, the user’s display will be updated. Otherwise, the system will
collect the information about the selected item, and display it in view-only mode using the lower-
right panel of the GUI. The system will determine whether or not the user has permission to
modify the information. If so, a button labeled “Modify” will be displayed. The system will also
display the Project-View graph if a project was selected. This would be done by initiating the
“Generate Project-View Graph” use case.
Typical Course of Events
Actor Action System Response
1. This use case begins when a user selects
an item shown in the display.
2. The system verified that the item still exists.
3. The system retrieves information about the
selected item. Some information deemed
“confidential” will be unavailable based on the
type of user.
4. The system will determine whether or not
the user has permission to modify the selected
item.
5. The system will display the information in
read-only mode. The “Modify” button will
optionally be displayed.
