CSC 216程序设计讲解、C++程序调试、c/c++语言编程辅导
- 首页 >> Python编程 CSC 216 SE Materials
Home > Projects > CSC 216 Projects - Spring 2021 > Project 1, Part 1: ServiceWolf
CSC216: Project 1
Project 1, Part 1: ServiceWolf
Project 1, Part 1: ServiceWolf
Project 1 requires you to go through standard software development phases to design,
implement, and test a complete Java program consisting of multiple source code files and JUnit
test cases. The service group comes in two parts. Deliverables for Part 1 are:
1. Design document that includes a UML class diagram.
2. Black box test plan.
Part 1 Due Date: Thursday, February 25, 2021 at 11:45 PM
Late Deadline (Design): Friday, February 26, 2021 at 9:00 AM
Late Deadline (BBTP): Saturday, February 27, 2021 at 11:45 PM
Project 1, Part 1 MUST be completed individually
Table of Contents
Problem Overview
Requirements
Data Format
Design
Testing
Deployment
Problem Overview
If you were in charge of a single server, it would be likely easy to spot and take care of its
problems. That comment might also apply if you were in charge of 10 or even 50 servers. But the
more servers, the more difficult their management becomes. Large institutions such as major
banks, which can have well over 100,000 servers, rely on IT service management (ITSM) teams to
take care of their servers. ITSM is actually a broad term, covering the entire lifecycle of IT
services (think design, delivery, ongoing operations, decommissioning, and so on).
Top
NC State Home COVID-
19
RESOURCES
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 2/29
Some expensive software suites such as Service Now and Remedy were developed to support
ITSM, and all of them have modules for Incident Management. An incident is any unplanned
disruption or reduction in quality of an IT service, or any failure of an IT component used to
provide an IT service. Incidents can be reported by users or automatically detected by monitoring
software. In either case, they need to be addressed, typically via well defined, multi-state
processes.
For Service Groups at NC State, you must design, implement, and test an incident management
system that uses a FSM modified from the ServiceNow incident management system state
model. The FSM is illustrated in Figure 1. (The transitions are too detailed to fully label in the
diagram. Instead each transition is given a name corresponding to the state where it starts.
Descriptions of the transitions follow below.)
Figure 1: ServiceWolf Incident Finite State Machine
An incident in the ServiceWolf system can be in one of the following states: New, In Progress, On
Hold, Resolved, and Canceled.
Incidents are on hold with three possible on hold reasons:
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 3/29
Awaiting Caller: the incident is waiting for more information from the caller, which is the
person who created the incident.
Awaiting Change: the incident requires a change in some system so the incident is on hold
until the change is made.
Awaiting Vendor: the incident requires that an external vendor provides additional information
for resolution so the incident is on hold until the vendor provides the information.
Incidents are resolved with three possible resolution codes:
Permanently Solved: the reported incident has been resolved such that another incident like is
shouldn’t be reported in the future.
Workaround: the reported incident was resolved with a workaround. Future incidents may be
reported like this one.
Caller Closed: the reported incident was closed by the caller because they resolved the
incident on their own.
Incidents are canceled with four possible cancellation reason:
Duplicate: the incident is a duplicate of another incident in the system.
Unnecessary: the incident is not something that should be fixed or addressed.
Not an Incident: the report is not an incident.
Caller Canceled: the reported incident was canceled by the caller because it is no longer
needed.
The finite state machine for incidents in the Service Wolf system is described below. The
transitions are labeled with the state they are coming from and match the arrows in the FSM
diagram.
New: An incident enters the state model in the New state. Incidents in the New state should
be assigned to an owner who will be responsible for investigating and (typically) resolving the
incident.
NewA: An incident requires additional investigation and is assigned to an incident
management personnel and is in progress towards a resolution.
NewB: An incident does not require additional investigation and is canceled. The
cancellation reason is recorded.
In Progress: An incident In Progress is under investigation by the assigned incident
management personnel. The incident moves out of the In Progress state when the incident
management personnel records the results of their investigation in this state.
InProgressA: An incident moves to the On Hold state when the incident management
personnel requires additional information from the caller, the system developers working
on a change to the system, or from a vendor of a 3rd party system. The on hold code is set.
InProgressB: An incident is resolved through the application of a satisfactory fix. A
resolution code is recorded.
InProgressC: An incident is assigned to another incident management personnel due to
expertise, shift in workload, or leave affecting the original assignee.
InProgressD: An incident is canceled and the cancellation code is recorded. The owner is
removed. Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 4/29
On Hold: An incident In Hold is awaiting information from the caller, system developers, or a
vendor. The incident moves out of the On Hold state when the stakeholder responds.
OnHoldA: An incident moves to the In Progress state when the stakeholder responds with
information that can help the incident management personnel move forward with handling
the incident.
Resolved: An incident in the Resolved state has been fixed.
ResolvedA: An incident moves to the In Progress state because the resolution isn’t final and
more work is needed to fully resolve the incident. The resolution code is removed.
ResolvedB: An incident is canceled and the cancellation code is recorded. The resolution
code is removed. The owner is removed.
Canceled: An incident in the Canceled state is either a duplicate incident, unnecessary to
resolve, not an incident, or canceled by the caller. Once an incident is in the Canceled state,
the incident cannot leave (the caller would have to report a new incident, if needed).
The GUI for this app is being independently developed and will be provided to you at a later
time, but initial screenshots are available and shown below. Note, that the GUI is still under
development, so there may be some changes between the screenshots below and the delivered
GUI.
Requirements
The remaining requirements for the ServiceWolf program will be modeled with use cases that
will utilize the incident finite state machine described above. Use cases divide system behavior
into related scenarios around a core piece of functionality. These scenarios tie directly to user
experience with the GUI.
In this system, the user’s role may vary by operation. For example, a general staff member may
create an incident, one incident management personnel may triage the incident, and another
incident management personnel may be assigned to resolve the issue. The idea of authentication
and user roles is not part of this system to focus on the finite state machine. You may assume
that a person in the appropriate role would handle transitions appropriate to their role. We use
the generic “user” to indicate a person’s interaction with the system.
Startup
Use Case 0: Start ServiceWolf
Managing State
Use Case 1: Load System State
Use Case 2: Save System State
Use Case 3: Clear System State
Service Groups
Use Case 4: Create Service Group
Use Case 5: Edit Service Group
Use Case 6: Remove Service Group
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 5/29
Use Case 7: Select Active Service Group
Incidents
Use Case 8: List Incidents
Use Case 9: Add an Incident
Use Case 10: Delete an Incident
Use Case 11: Edit an Incident
Use Case 12: Edit Incident in New State
Use Case 13: Edit Incident in In Progress State
Use Case 14: Edit Incident in On Hold State
Use Case 15: Edit Incident in Resolved State
Use Case 16: Edit Incident in Canceled State
Shutdown
Use Case 17: Quit ServiceWolf
UseCase 0:StartServiceWolf
Open the ServiceWolf application
MainFlow
1. The user starts the ServiceWolf application.
2. The GUI opens and displays the menu to load [UC1], save [UC2], and clear [UC3] system state
and buttons to work with service groups [UC4-7] and incidents [UC9-11] (see Figure 2).
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 6/29
Figure 2: ServiceWolf GUI with File menu options
UseCase 1: LoadSystem State
Load a service group and its associated incidents from a file.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 7/29
Figure 3: ServiceWolf GUI with service groups and incidents loaded from a file
Precondition
A user has started the ServiceWolf application and the GUI has opened [UC0].
MainFlow
1. The user selects the option from the file menu to load from a file.
2. The system shows a file chooser.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 8/29
3. The user browses for and selects the file to open.
4. The system processes and loads the contents of the file in the format described in the [Data
Format] section [Missing File][Invalid Record].
5. The system populates service groups and keeps them ordered alphabetically by name.
6. The system populates the incidents in each service group and keeps them ordered by incident
id.
7. The first service group in the file is the active service group [UC7].
AlternativeFlows
[Missing File] If the file cannot be loaded, a dialog opens with the message “Unable to load
file.” The user clicks OK and is returned to the application.
[Invalid Record] An invalid record in the file is skipped and not imported to the system. Lines
that do not start as described in the [Data Format] section are considered invalid records.
UseCase 2:SaveSystem State
Save the current state of the system to a file that can be loaded later.
Precondition
The user is in the main window of the application.
MainFlow
1. The user selects the option from the file menu to save to a file.
2. The system shows a file chooser.
3. The user browses for and selects a filename for the file to save [Cannot Save].
4. The system saves the file in the same format described in the [Data Format] section.
AlternativeFlows
[Cannot Save] If the file cannot be saved, a dialog opens with the message “Unable to save
file.” The user clicks OK and is returned to the ServiceWolf application.
UseCase 3:ClearSystem State
Resets the system state to no service groups or incidents.
Preconditions
The user is in the main window of the application.
MainFlow
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 9/29
1. The user selects the option from the file menu to clear the state of the system.
2. The system removes all incidents.
3. The system removes all service groups.
4. The GUI updates to reflect the changes.
UseCase 4: AddService Group
The user is in the main window of the application.
Figure 4: ServiceWolf GUI - adding a Service Group
Precondition
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user clicks the Add Service Group button.
2. The user enters the name of the service group.
3. The user clicks the Add button [Invalid Name].
4. The system trims leading and trailing whitespace on the name, if any.
5. The system adds the new service group to the service group list in alphabetical order.
6. The user sees the service group as the active service group and an empty list of incidents.
AlternativeFlows
[Invalid Name] If the name is empty or if the name is already in use, the system shows the
error message “Invalid service group name.”
UseCase 5: EditService Group
The user is in the main window of the application.
Precondition
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 10/29
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user selects the service group they want to edit.
2. The user edits the name of the service group.
3. The user clicks the Edit button [Invalid Name].
4. The system trims leading and trailing whitespace on the name, if any.
5. The system updates the service group list maintaining alphabetical order.
6. The user sees the service group as the active service group and an empty list of incidents.
AlternativeFlows
[Invalid Name] If the name is empty or if the name is already in use, the system shows the
error message “Invalid service group name.”
UseCase 6:RemoveService Group
The user is in the main window of the application.
Precondition
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user selects the service group they want to remove.
2. The user clicks the Remove button.
3. The system removes the service group and all associated incidents.
4. The system updates the service group list maintaining alphabetical order.
UseCase 7:Select ActiveService Group
Select an active service group
Precondition
A user has started the ServiceWolf application and the GUI has opened. There is more than one
service group.
MainFlow
1. The user selects a service group from the service group list.
2. The list of incidents is updated to include the incidents associated with the service group
ordered by id [UC8].
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 11/29
UseCase 8: ListIncidents
Precondition
There is an active service group.
MainFlow
1. The incidents for a service group are listed. Incident ids, state, title, and status details are
displayed in a list ordered by id.
2. The user can add [UC9], remove [UC10], or edit [UC11] a incident in the given service group.
UseCase 9: Add an Incident
Add a new incident to the service group.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 12/29
Figure 5: ServiceWolf GUI - adding an Incident
Precondition
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user clicks the Add New Incident button.
2. The user enters the title, name of the caller, and a description of the incident.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 13/29
3. The user clicks the Add Incident button to add the incident or Cancel to not add the incident
[Missing Fields].
4. The incident is given an id that is one greater than the current largest id in the system (across
all incidents).
5. The incident is added to the selected service group in order by id.
6. The incident is in the New state.
7. The user is returned to the incident list [UC8]. The selected service group is active and the new
incident is the last incident on the list.
AlternativeFlows
[Missing Fields] If the title, name of the caller, or the description of the incident are empty, a
dialog opens with the message “Incident cannot be created.” The user clicks OK and is
returned to the Add New Incident window to fix their mistakes.
UseCase 10:Remove a Incident
Remove a incident from the active service group.
Precondition
There is an active service group.
MainFlow
1. The user selects a incident to remove.
2. The user clicks the Remove Incident button [No Selection].
3. The incident is removed from the service group and the incident list is updated [UC8].
AlternativeFlows
[No Selection] If an incident is not selected, a dialog opens with the message “No incident
selected.” The user clicks OK and is returned to the list with no changes.
UseCase 11: Edit a Incident
Edit a incident in the active service group.
Precondition
There is an active service group.
MainFlow
1. The user selects a incident to edit.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 14/29
2. The user clicks the Edit Incident button [No Selection]. The user is transferred to the edit page,
which lists the incident information, appropriate for the current state of the incident: New
[UC12], In Progress [UC13], On Hold [UC14], Resolved [UC15], Canceled [UC16].
3. The incident is updated and incident list reflects the changes [UC8].
AlternativeFlows
[No Selection] If an incident is not selected, a dialog opens with the message “No incident
selected.” The user clicks OK and is returned to the list with no changes.
UseCase 12: EditIncidentin New State
Edit a incident in the New state
Preconditions
A user has selected a incident to edit [UC11] that is in the New state. The user interface for editing
a incident in the New state is shown in Figure 5.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 15/29
Figure 6: ServiceWolf GUI interface for interacting with a incident in the New State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. assigns an owner to work on the incident by entering an owner id and clicking the Assign
button. The incident’s owner is updated and the incident moves to the In Progress state
[Invalid Info] Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 16/29
b. selects a cancellation reason and cancels the incident by clicking the Cancel button. The
incident’s status details are updated with the cancellation reason and the incident moves to
the Canceled state [Invalid Info]
c. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident was moved
to is active.
AlternativeFlows
[Invalid Info] A service group or cancellation reason is not selected or the message is empty. A
dialog opens with the message “Invalid information.” The user clicks OK and is returned to the
New state user interface to select correct information.
UseCase 13: EditIncidentin In ProgressState
Edit a incident in the In Progress state
Preconditions
A user has selected a incident to edit [UC11] that is in the In Progress state. The user interface for
editing a incident in the In Progress state is shown in Figure 7.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 17/29
Figure 7: ServiceWolf GUI interface for interacting with a incident in the In Progress State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. selects a hold reason and holds the incident for more information by clicking the Hold
button. The incident’s status details are updated with the hold reason and the incident moves
to the On Hold state [Invalid Info] Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 18/29
b. selects a resolution reason and resolves the incident by clicking the Resolve button. The
incident’s status details are updated with the resolution reason and the incident moves to the
Resolved state [Invalid Info]
c. assigns another owner to work on the incident by entering an owner id and clicking the
Assign button. The incident’s owner is updated and the incident remains in the In Progress
state [Invalid Info]
d. selects a cancellation reason and cancels the incident by clicking the Cancel button. The
incident’s status details are updated with the cancellation reason, the owner is set to
“Unowned”, and the incident moves to the Canceled state [Invalid Info]
e. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
AlternativeFlows
[Invalid Info] The on hold reason, resolution reason, or cancellation reason are not selected or
the owner id is empty or the message is empty. A dialog opens with the message “Invalid
information.” The user clicks OK and is returned to the In Progress state user interface to
select correct information.
UseCase 14: EditIncidentin On HoldState
Edit a incident in the On Hold state
Preconditions
A user has selected a incident to edit [UC11] that is in the On Hold state. The user interface for
editing a incident in the On Hold state is shown in Figure 8.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 19/29
Figure 8: ServiceWolf GUI interface for interacting with a incident in the On Hold State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. moves the incident forward with further investigation by clicking the Investigation button.
The incident’s status details are cleared to “No Status” and the incident moves to the In
Progress state. Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 20/29
b. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
AlternativeFlows
[Invalid Info] The message is empty. A dialog opens with the message “Invalid information.”
The user clicks OK and is returned to the On Hold state user interface to select correct
information.
UseCase 15: EditIncidentinResolvedState
Edit a incident in the Resolved state
Preconditions
A user has selected a incident to edit [UC11] that is in the Resolved state. The user interface for
editing a incident in the Resolved state is shown in Figure 9.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 21/29
Figure 9: ServiceWolf GUI interface for interacting with a incident in the Resolved State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. reopens the incident by clicking the Reopen button. The incident’s status details are cleared,
the reopen count is incremented by one, and the incident moves to the In Progress state.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 22/29
b. selects a cancellation reason and cancels the incident by clicking the Cancel button. The
incident’s status details are updated with the cancellation reason, the owner is set to
“Unowned”, and the incident moves to the Canceled state [Invalid Info]
c. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
AlternativeFlows
[Invalid Info] The cancellation reason is not selected or the message is empty. A dialog opens
with the message “Invalid information.” The user clicks OK and is returned to the New state
user interface to select correct information.
UseCase 16: EditIncidentinCanceledState
Edit a incident in the Canceled state
Preconditions
A user has selected a incident to edit [UC11] that is in the Canceled state. The user interface for
editing an incident in the Canceled state is shown in Figure 10.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 23/29
Figure 10: ServiceWolf GUI interface for interacting with a incident in the Canceled State
MainFlow
1. The user can view the incident information, but cannot edit any details.
2. The user clicks the Return button.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 24/29
UseCase 17: QuitServiceWolf
Quit the ServiceWolf.
Precondition
A user has started the ServiceWolf application and the GUI (shown in Figure 2) has opened.
MainFlow
1. The user selects the option from the file menu to quit the service group manager.
2. The user is prompted to save their file by either choosing a file to save to [UC2] or declines to
save the changes by selecting Cancel.
3. The user closes the application.
Data Format
The state of the system can be saved and loaded from a file in the right format.
ValidRecords
An example valid file would be:
# CSC IT
* 2,Canceled,Piazza,sesmith5,0,Unowned,Not an Incident
- Set up piazza for Spring 2021
- Canceled; not an NC State IT service
* 3,New,Moodle down,sesmith5,0,Unowned,No Status
- When I go to wolfware.ncsu.edu, I get a 500 error
* 4,Resolved,Set up Jenkins VMs,sesmith5,1,cgurley,Permanently Solved
- Please set up Jenkins VMs for Spring 2021 semester.
- Assigned to C. Gurley
- Set up test VM. Awaiting verification from caller.
- VM works great, please deploy the rest.
- VMs deployed. Marked resolved.
- One of the VMs has the wrong version of Checkstyle installed.
- Updated version of Checkstyle.
* 9,In Progress,Jenkins behind firewall,sesmith5,0,cgurley,No Status
- Jenkins requires VPN to access. Please open to general access.
- Assigned to C. Gurley
# ITECS
* 7,On Hold,Java not installed correctly,zmgrosec,0,itecs1,Awaiting Caller
- I can't install Java on my computer.
- Assigned to itecs1
- Awaiting caller's feedback on attempting to install Java from Oracle
# OIT
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 25/29
* 1,In Progress,Forgot password,jctetter,0,oit_staff,No Status
- I forgot my password and can't log into NC State accounts
- OIT staff member on call with support
Lines starting with a ‘#’ represent Service Groups. There must be at least one service group in
the file on the first line or the file cannot be processed.
Service groups are followed by one or more incidents.
If a service group does not have at least one incident, it is not loaded in the system.
Lines starting with ‘*’ represent incidents. A valid incident has the following information:
id,state,title,caller,reopen-count,owner,status-details.
If there are multiple incidents with the same id number, only the first is valid.
Lines starting with ‘-‘ represent items in the incident’s log.
The text may span multiple lines and all white space is preserved.
InvalidRecords
Records (lines) are considered invalid in at least the following situations:
Lines that are not formatted as above.
An incident without at least one log message.
Ids that are zero or less
Incidents with missing information
Incidents with incorrect state names (e.g., not New, In Progress, On Hold, Resolved, or
Canceled)
Reopen count is less than zero
Owners are required for incidents in the In Progress, On Hold, and Resolved states. Owners
are listed as “Unowned” in the New and Canceled states. Owners cannot be empty or null.
Incidents in the On Hold state without a hold reason listed for the status details
Incidents in the Resolved state without a resolution reason listed for the status details
Incidents in the Canceled state without a cancellation reason listed for the status details
Incidents in the New or In Progress states have a status details listing of “No Status”
Design
Trying to jump from requirements right into coding without doing some design first is bound to
lead to trouble. We will eventually have you implement our design, but first you need to propose
your own. To do this, we give you a scenario and insist on some restrictions for your design.
The scenario
As an effort to give everyone an opportunity to promote their design ideas, the project manager
in charge of the development of ServiceWolf has devised a process that requires every member
of the development team to propose a full design of the system (excluding GUI details) by
identifying the classes, their fields and methods, and the relationships between the classes in the
system before a final design is selected. The main constraint is that your design must include a
State Pattern that models the finite-state machine of a incident’s state. The project manager will
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 26/29
then use ideas from these proposals to come up with the final design that your team will have to
implement.
What you must do: DesignRationale and UML diagram
You must design an application that satisfies the requirements of the ServiceWolf application.
You will create a design proposal that shows the objects, their states and behaviors, and the
relationships among the objects needed to implement the requirements. Your design must be
described in document containing a design rationale and a UML class diagram.
Your design should:
utilize the Model-View-Controller (MVC) design pattern (see the note about MVC, below),
utilize the State Pattern (see the note about State Pattern, below),
contain at least one interface or abstract class,
contain at least one inheritance relationship (which could include implementing an interface),
and
contain at least one composition relationship.
To help your manager evaluate your design, you should answer the following technical questions
in your design document as part of the rationale:
1. What objects are important to the system’s implementation and how do you know they are
important?
2. What data are required to implement the system and how do you know these data are
needed?
3. Are the responsibilities assigned to an object appropriate for that object’s abstraction and
why?
4. What are the relationships between objects (such as inheritance and composition) and why
are these relationships important for addressing the requirements?
5. Have you identified any design patterns appropriate for implementing the system (i.e., the
State Pattern)? What are they and why are they appropriate?
6. What are the limitations of your design? Are there ways that your design might limit future
additions to the system (e.g., user roles or new states)?
MVC Note
Java Swing, the user interface (UI) libraries for Java, does not follow the strictly traditional
definition of MVC. Instead, Java Swing utilizes what might be called a separable model
architecture.This means that the model is separate and distinct from the view/controller classes
that make up the UI. Your design must focus on the model.
In your UML class diagram, you should represent the UI as a class with no state or behavior.
Your diagram should also show which class(es) your UI will interact with through some type of
composition/aggregation/association relationship. The relationship between your model and the
UI must be justified in your design rationale.
When thinking about the relationships between your UI and the model, consider the following
questions:
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 27/29
1. What are the data and behaviors of your model that will be shown through the UI?
2. How does your UI get those data to display; what methods of the model must be called?
State Pattern
The State Pattern is an object-oriented solution to a state-based application. The finite-state
machine that models the state of a incident should be modeled using the State Pattern. This
means the bubbles, which represent states, becomes classes. The transitions become the
behaviors of the classes. A context class encapsulates the state pattern for each incident and
delegates the transitions to the current state for the given incident. For more information on the
State Pattern, see the lecture notes (Lecture Notes, Wikipedia article and the example Horner’s
Rule State Pattern implementation.
Design Proposal andRationaleSubmission Format
Submit your design proposal via Gradescope under the assignment named P1P1: Design. Note
that we will grade the last submission to Gradescope.
Use the provided design proposal template as a starting point for your design proposal. Use a
UML diagramming tool (options are listed the Software Development Practices notes) to create
your UML diagram. Incorporate your UML diagram into your written proposal (using an editing
tool such as MS Word) and save the entire document as a PDF. Alternatively, create a PDF for the
design proposal and another PDF for the UML diagram, then append the diagram to the proposal
to make a single PDF document.
Need a little more direction?
See the following example design proposal: Sample Design Proposal.
Testing
This project requires you create and run unit/integration and system tests. You can defer
unit/integration testing until Part 2 of this project. But now, you need to prepare some system test
cases.
Scenario
You must create a system test plan that describes five test cases that will determine if the
finished program satisfies the requirements. Write the tests before you begin development to
clarify the inputs to and outputs from the system. Each test must demonstrate that the program
satisfies a scenario from the requirements. A scenario is one major path of functionality as
described by the requirements.
Assignment
You will write at least five (5) tests for this project. Use the provided system test plan template to
describe your tests.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 28/29
Your system test plan must meet the following expectations:
Each test must be repeatable and specific; all input and expected results values must be
concrete.
All inputs required to complete the test must be specified.
Provide instructions for how a tester would set up, start, and run the application. (What class
from your design contains the main method that starts your program? What do the input files
contain?). Describe the instructions at a level where anyone using Eclipse could run your tests.
To help you with your system test plan, we have provided some example test files.
ServiceWolf Test File
Format
Use the provided template as a starting point for your system test plan. Save your STP as a PDF.
Submit the PDF to Gradescope under the assignment named P1P1: STP.
Need a little help?
See the following example black box test plan: Sample System Test Plan.
Deployment
For this class, deployment means submitting your work for grading. For Part 1 of this
programming assignment, you must submit two PDF documents:
1. Design document with incorporated UML class diagram.
2. System test plan document.
Make sure that your submissions satisfy the grading rubrics.
You should submit the documents for Project 1 Part 1 to Gradescope. Please follow the
Submitting your PDF on Gradescope instructions, including selecting page for each question
(grade category). We will grade the last submission made to Gradescope before the deadline.
Submission Reminders
The electronic submission deadline is precise. Do not be late. You should count on
last minute system failures (your failures, ISP failures, or Gradescope failures).
You are able to make multiple submissions of the same file. (Later submissions to
a Gradescope assignment overwrite the earlier ones.) To be on the safe side, start
submitting your work as soon as you have completed a substantial portion.
Published with GitHub Pages
Home > Projects > CSC 216 Projects - Spring 2021 > Project 1, Part 1: ServiceWolf
CSC216: Project 1
Project 1, Part 1: ServiceWolf
Project 1, Part 1: ServiceWolf
Project 1 requires you to go through standard software development phases to design,
implement, and test a complete Java program consisting of multiple source code files and JUnit
test cases. The service group comes in two parts. Deliverables for Part 1 are:
1. Design document that includes a UML class diagram.
2. Black box test plan.
Part 1 Due Date: Thursday, February 25, 2021 at 11:45 PM
Late Deadline (Design): Friday, February 26, 2021 at 9:00 AM
Late Deadline (BBTP): Saturday, February 27, 2021 at 11:45 PM
Project 1, Part 1 MUST be completed individually
Table of Contents
Problem Overview
Requirements
Data Format
Design
Testing
Deployment
Problem Overview
If you were in charge of a single server, it would be likely easy to spot and take care of its
problems. That comment might also apply if you were in charge of 10 or even 50 servers. But the
more servers, the more difficult their management becomes. Large institutions such as major
banks, which can have well over 100,000 servers, rely on IT service management (ITSM) teams to
take care of their servers. ITSM is actually a broad term, covering the entire lifecycle of IT
services (think design, delivery, ongoing operations, decommissioning, and so on).
Top
NC State Home COVID-
19
RESOURCES
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 2/29
Some expensive software suites such as Service Now and Remedy were developed to support
ITSM, and all of them have modules for Incident Management. An incident is any unplanned
disruption or reduction in quality of an IT service, or any failure of an IT component used to
provide an IT service. Incidents can be reported by users or automatically detected by monitoring
software. In either case, they need to be addressed, typically via well defined, multi-state
processes.
For Service Groups at NC State, you must design, implement, and test an incident management
system that uses a FSM modified from the ServiceNow incident management system state
model. The FSM is illustrated in Figure 1. (The transitions are too detailed to fully label in the
diagram. Instead each transition is given a name corresponding to the state where it starts.
Descriptions of the transitions follow below.)
Figure 1: ServiceWolf Incident Finite State Machine
An incident in the ServiceWolf system can be in one of the following states: New, In Progress, On
Hold, Resolved, and Canceled.
Incidents are on hold with three possible on hold reasons:
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 3/29
Awaiting Caller: the incident is waiting for more information from the caller, which is the
person who created the incident.
Awaiting Change: the incident requires a change in some system so the incident is on hold
until the change is made.
Awaiting Vendor: the incident requires that an external vendor provides additional information
for resolution so the incident is on hold until the vendor provides the information.
Incidents are resolved with three possible resolution codes:
Permanently Solved: the reported incident has been resolved such that another incident like is
shouldn’t be reported in the future.
Workaround: the reported incident was resolved with a workaround. Future incidents may be
reported like this one.
Caller Closed: the reported incident was closed by the caller because they resolved the
incident on their own.
Incidents are canceled with four possible cancellation reason:
Duplicate: the incident is a duplicate of another incident in the system.
Unnecessary: the incident is not something that should be fixed or addressed.
Not an Incident: the report is not an incident.
Caller Canceled: the reported incident was canceled by the caller because it is no longer
needed.
The finite state machine for incidents in the Service Wolf system is described below. The
transitions are labeled with the state they are coming from and match the arrows in the FSM
diagram.
New: An incident enters the state model in the New state. Incidents in the New state should
be assigned to an owner who will be responsible for investigating and (typically) resolving the
incident.
NewA: An incident requires additional investigation and is assigned to an incident
management personnel and is in progress towards a resolution.
NewB: An incident does not require additional investigation and is canceled. The
cancellation reason is recorded.
In Progress: An incident In Progress is under investigation by the assigned incident
management personnel. The incident moves out of the In Progress state when the incident
management personnel records the results of their investigation in this state.
InProgressA: An incident moves to the On Hold state when the incident management
personnel requires additional information from the caller, the system developers working
on a change to the system, or from a vendor of a 3rd party system. The on hold code is set.
InProgressB: An incident is resolved through the application of a satisfactory fix. A
resolution code is recorded.
InProgressC: An incident is assigned to another incident management personnel due to
expertise, shift in workload, or leave affecting the original assignee.
InProgressD: An incident is canceled and the cancellation code is recorded. The owner is
removed. Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 4/29
On Hold: An incident In Hold is awaiting information from the caller, system developers, or a
vendor. The incident moves out of the On Hold state when the stakeholder responds.
OnHoldA: An incident moves to the In Progress state when the stakeholder responds with
information that can help the incident management personnel move forward with handling
the incident.
Resolved: An incident in the Resolved state has been fixed.
ResolvedA: An incident moves to the In Progress state because the resolution isn’t final and
more work is needed to fully resolve the incident. The resolution code is removed.
ResolvedB: An incident is canceled and the cancellation code is recorded. The resolution
code is removed. The owner is removed.
Canceled: An incident in the Canceled state is either a duplicate incident, unnecessary to
resolve, not an incident, or canceled by the caller. Once an incident is in the Canceled state,
the incident cannot leave (the caller would have to report a new incident, if needed).
The GUI for this app is being independently developed and will be provided to you at a later
time, but initial screenshots are available and shown below. Note, that the GUI is still under
development, so there may be some changes between the screenshots below and the delivered
GUI.
Requirements
The remaining requirements for the ServiceWolf program will be modeled with use cases that
will utilize the incident finite state machine described above. Use cases divide system behavior
into related scenarios around a core piece of functionality. These scenarios tie directly to user
experience with the GUI.
In this system, the user’s role may vary by operation. For example, a general staff member may
create an incident, one incident management personnel may triage the incident, and another
incident management personnel may be assigned to resolve the issue. The idea of authentication
and user roles is not part of this system to focus on the finite state machine. You may assume
that a person in the appropriate role would handle transitions appropriate to their role. We use
the generic “user” to indicate a person’s interaction with the system.
Startup
Use Case 0: Start ServiceWolf
Managing State
Use Case 1: Load System State
Use Case 2: Save System State
Use Case 3: Clear System State
Service Groups
Use Case 4: Create Service Group
Use Case 5: Edit Service Group
Use Case 6: Remove Service Group
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 5/29
Use Case 7: Select Active Service Group
Incidents
Use Case 8: List Incidents
Use Case 9: Add an Incident
Use Case 10: Delete an Incident
Use Case 11: Edit an Incident
Use Case 12: Edit Incident in New State
Use Case 13: Edit Incident in In Progress State
Use Case 14: Edit Incident in On Hold State
Use Case 15: Edit Incident in Resolved State
Use Case 16: Edit Incident in Canceled State
Shutdown
Use Case 17: Quit ServiceWolf
UseCase 0:StartServiceWolf
Open the ServiceWolf application
MainFlow
1. The user starts the ServiceWolf application.
2. The GUI opens and displays the menu to load [UC1], save [UC2], and clear [UC3] system state
and buttons to work with service groups [UC4-7] and incidents [UC9-11] (see Figure 2).
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 6/29
Figure 2: ServiceWolf GUI with File menu options
UseCase 1: LoadSystem State
Load a service group and its associated incidents from a file.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 7/29
Figure 3: ServiceWolf GUI with service groups and incidents loaded from a file
Precondition
A user has started the ServiceWolf application and the GUI has opened [UC0].
MainFlow
1. The user selects the option from the file menu to load from a file.
2. The system shows a file chooser.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 8/29
3. The user browses for and selects the file to open.
4. The system processes and loads the contents of the file in the format described in the [Data
Format] section [Missing File][Invalid Record].
5. The system populates service groups and keeps them ordered alphabetically by name.
6. The system populates the incidents in each service group and keeps them ordered by incident
id.
7. The first service group in the file is the active service group [UC7].
AlternativeFlows
[Missing File] If the file cannot be loaded, a dialog opens with the message “Unable to load
file.” The user clicks OK and is returned to the application.
[Invalid Record] An invalid record in the file is skipped and not imported to the system. Lines
that do not start as described in the [Data Format] section are considered invalid records.
UseCase 2:SaveSystem State
Save the current state of the system to a file that can be loaded later.
Precondition
The user is in the main window of the application.
MainFlow
1. The user selects the option from the file menu to save to a file.
2. The system shows a file chooser.
3. The user browses for and selects a filename for the file to save [Cannot Save].
4. The system saves the file in the same format described in the [Data Format] section.
AlternativeFlows
[Cannot Save] If the file cannot be saved, a dialog opens with the message “Unable to save
file.” The user clicks OK and is returned to the ServiceWolf application.
UseCase 3:ClearSystem State
Resets the system state to no service groups or incidents.
Preconditions
The user is in the main window of the application.
MainFlow
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 9/29
1. The user selects the option from the file menu to clear the state of the system.
2. The system removes all incidents.
3. The system removes all service groups.
4. The GUI updates to reflect the changes.
UseCase 4: AddService Group
The user is in the main window of the application.
Figure 4: ServiceWolf GUI - adding a Service Group
Precondition
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user clicks the Add Service Group button.
2. The user enters the name of the service group.
3. The user clicks the Add button [Invalid Name].
4. The system trims leading and trailing whitespace on the name, if any.
5. The system adds the new service group to the service group list in alphabetical order.
6. The user sees the service group as the active service group and an empty list of incidents.
AlternativeFlows
[Invalid Name] If the name is empty or if the name is already in use, the system shows the
error message “Invalid service group name.”
UseCase 5: EditService Group
The user is in the main window of the application.
Precondition
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 10/29
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user selects the service group they want to edit.
2. The user edits the name of the service group.
3. The user clicks the Edit button [Invalid Name].
4. The system trims leading and trailing whitespace on the name, if any.
5. The system updates the service group list maintaining alphabetical order.
6. The user sees the service group as the active service group and an empty list of incidents.
AlternativeFlows
[Invalid Name] If the name is empty or if the name is already in use, the system shows the
error message “Invalid service group name.”
UseCase 6:RemoveService Group
The user is in the main window of the application.
Precondition
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user selects the service group they want to remove.
2. The user clicks the Remove button.
3. The system removes the service group and all associated incidents.
4. The system updates the service group list maintaining alphabetical order.
UseCase 7:Select ActiveService Group
Select an active service group
Precondition
A user has started the ServiceWolf application and the GUI has opened. There is more than one
service group.
MainFlow
1. The user selects a service group from the service group list.
2. The list of incidents is updated to include the incidents associated with the service group
ordered by id [UC8].
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 11/29
UseCase 8: ListIncidents
Precondition
There is an active service group.
MainFlow
1. The incidents for a service group are listed. Incident ids, state, title, and status details are
displayed in a list ordered by id.
2. The user can add [UC9], remove [UC10], or edit [UC11] a incident in the given service group.
UseCase 9: Add an Incident
Add a new incident to the service group.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 12/29
Figure 5: ServiceWolf GUI - adding an Incident
Precondition
A user has started the ServiceWolf application and the GUI has opened.
MainFlow
1. The user clicks the Add New Incident button.
2. The user enters the title, name of the caller, and a description of the incident.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 13/29
3. The user clicks the Add Incident button to add the incident or Cancel to not add the incident
[Missing Fields].
4. The incident is given an id that is one greater than the current largest id in the system (across
all incidents).
5. The incident is added to the selected service group in order by id.
6. The incident is in the New state.
7. The user is returned to the incident list [UC8]. The selected service group is active and the new
incident is the last incident on the list.
AlternativeFlows
[Missing Fields] If the title, name of the caller, or the description of the incident are empty, a
dialog opens with the message “Incident cannot be created.” The user clicks OK and is
returned to the Add New Incident window to fix their mistakes.
UseCase 10:Remove a Incident
Remove a incident from the active service group.
Precondition
There is an active service group.
MainFlow
1. The user selects a incident to remove.
2. The user clicks the Remove Incident button [No Selection].
3. The incident is removed from the service group and the incident list is updated [UC8].
AlternativeFlows
[No Selection] If an incident is not selected, a dialog opens with the message “No incident
selected.” The user clicks OK and is returned to the list with no changes.
UseCase 11: Edit a Incident
Edit a incident in the active service group.
Precondition
There is an active service group.
MainFlow
1. The user selects a incident to edit.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 14/29
2. The user clicks the Edit Incident button [No Selection]. The user is transferred to the edit page,
which lists the incident information, appropriate for the current state of the incident: New
[UC12], In Progress [UC13], On Hold [UC14], Resolved [UC15], Canceled [UC16].
3. The incident is updated and incident list reflects the changes [UC8].
AlternativeFlows
[No Selection] If an incident is not selected, a dialog opens with the message “No incident
selected.” The user clicks OK and is returned to the list with no changes.
UseCase 12: EditIncidentin New State
Edit a incident in the New state
Preconditions
A user has selected a incident to edit [UC11] that is in the New state. The user interface for editing
a incident in the New state is shown in Figure 5.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 15/29
Figure 6: ServiceWolf GUI interface for interacting with a incident in the New State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. assigns an owner to work on the incident by entering an owner id and clicking the Assign
button. The incident’s owner is updated and the incident moves to the In Progress state
[Invalid Info] Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 16/29
b. selects a cancellation reason and cancels the incident by clicking the Cancel button. The
incident’s status details are updated with the cancellation reason and the incident moves to
the Canceled state [Invalid Info]
c. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident was moved
to is active.
AlternativeFlows
[Invalid Info] A service group or cancellation reason is not selected or the message is empty. A
dialog opens with the message “Invalid information.” The user clicks OK and is returned to the
New state user interface to select correct information.
UseCase 13: EditIncidentin In ProgressState
Edit a incident in the In Progress state
Preconditions
A user has selected a incident to edit [UC11] that is in the In Progress state. The user interface for
editing a incident in the In Progress state is shown in Figure 7.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 17/29
Figure 7: ServiceWolf GUI interface for interacting with a incident in the In Progress State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. selects a hold reason and holds the incident for more information by clicking the Hold
button. The incident’s status details are updated with the hold reason and the incident moves
to the On Hold state [Invalid Info] Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 18/29
b. selects a resolution reason and resolves the incident by clicking the Resolve button. The
incident’s status details are updated with the resolution reason and the incident moves to the
Resolved state [Invalid Info]
c. assigns another owner to work on the incident by entering an owner id and clicking the
Assign button. The incident’s owner is updated and the incident remains in the In Progress
state [Invalid Info]
d. selects a cancellation reason and cancels the incident by clicking the Cancel button. The
incident’s status details are updated with the cancellation reason, the owner is set to
“Unowned”, and the incident moves to the Canceled state [Invalid Info]
e. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
AlternativeFlows
[Invalid Info] The on hold reason, resolution reason, or cancellation reason are not selected or
the owner id is empty or the message is empty. A dialog opens with the message “Invalid
information.” The user clicks OK and is returned to the In Progress state user interface to
select correct information.
UseCase 14: EditIncidentin On HoldState
Edit a incident in the On Hold state
Preconditions
A user has selected a incident to edit [UC11] that is in the On Hold state. The user interface for
editing a incident in the On Hold state is shown in Figure 8.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 19/29
Figure 8: ServiceWolf GUI interface for interacting with a incident in the On Hold State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. moves the incident forward with further investigation by clicking the Investigation button.
The incident’s status details are cleared to “No Status” and the incident moves to the In
Progress state. Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 20/29
b. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
AlternativeFlows
[Invalid Info] The message is empty. A dialog opens with the message “Invalid information.”
The user clicks OK and is returned to the On Hold state user interface to select correct
information.
UseCase 15: EditIncidentinResolvedState
Edit a incident in the Resolved state
Preconditions
A user has selected a incident to edit [UC11] that is in the Resolved state. The user interface for
editing a incident in the Resolved state is shown in Figure 9.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 21/29
Figure 9: ServiceWolf GUI interface for interacting with a incident in the Resolved State
MainFlow
1. The user enters a message [Invalid Info] with an update on the incident and then does one of
the following:
a. reopens the incident by clicking the Reopen button. The incident’s status details are cleared,
the reopen count is incremented by one, and the incident moves to the In Progress state.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 22/29
b. selects a cancellation reason and cancels the incident by clicking the Cancel button. The
incident’s status details are updated with the cancellation reason, the owner is set to
“Unowned”, and the incident moves to the Canceled state [Invalid Info]
c. cancels the interaction by clicking the Return button.
2. The message is added to the end of the incident log for edited incidents.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
AlternativeFlows
[Invalid Info] The cancellation reason is not selected or the message is empty. A dialog opens
with the message “Invalid information.” The user clicks OK and is returned to the New state
user interface to select correct information.
UseCase 16: EditIncidentinCanceledState
Edit a incident in the Canceled state
Preconditions
A user has selected a incident to edit [UC11] that is in the Canceled state. The user interface for
editing an incident in the Canceled state is shown in Figure 10.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 23/29
Figure 10: ServiceWolf GUI interface for interacting with a incident in the Canceled State
MainFlow
1. The user can view the incident information, but cannot edit any details.
2. The user clicks the Return button.
3. The user is returned to the ServiceWolf list [UC8]. The service group the incident is in remains
active.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 24/29
UseCase 17: QuitServiceWolf
Quit the ServiceWolf.
Precondition
A user has started the ServiceWolf application and the GUI (shown in Figure 2) has opened.
MainFlow
1. The user selects the option from the file menu to quit the service group manager.
2. The user is prompted to save their file by either choosing a file to save to [UC2] or declines to
save the changes by selecting Cancel.
3. The user closes the application.
Data Format
The state of the system can be saved and loaded from a file in the right format.
ValidRecords
An example valid file would be:
# CSC IT
* 2,Canceled,Piazza,sesmith5,0,Unowned,Not an Incident
- Set up piazza for Spring 2021
- Canceled; not an NC State IT service
* 3,New,Moodle down,sesmith5,0,Unowned,No Status
- When I go to wolfware.ncsu.edu, I get a 500 error
* 4,Resolved,Set up Jenkins VMs,sesmith5,1,cgurley,Permanently Solved
- Please set up Jenkins VMs for Spring 2021 semester.
- Assigned to C. Gurley
- Set up test VM. Awaiting verification from caller.
- VM works great, please deploy the rest.
- VMs deployed. Marked resolved.
- One of the VMs has the wrong version of Checkstyle installed.
- Updated version of Checkstyle.
* 9,In Progress,Jenkins behind firewall,sesmith5,0,cgurley,No Status
- Jenkins requires VPN to access. Please open to general access.
- Assigned to C. Gurley
# ITECS
* 7,On Hold,Java not installed correctly,zmgrosec,0,itecs1,Awaiting Caller
- I can't install Java on my computer.
- Assigned to itecs1
- Awaiting caller's feedback on attempting to install Java from Oracle
# OIT
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 25/29
* 1,In Progress,Forgot password,jctetter,0,oit_staff,No Status
- I forgot my password and can't log into NC State accounts
- OIT staff member on call with support
Lines starting with a ‘#’ represent Service Groups. There must be at least one service group in
the file on the first line or the file cannot be processed.
Service groups are followed by one or more incidents.
If a service group does not have at least one incident, it is not loaded in the system.
Lines starting with ‘*’ represent incidents. A valid incident has the following information:
id,state,title,caller,reopen-count,owner,status-details.
If there are multiple incidents with the same id number, only the first is valid.
Lines starting with ‘-‘ represent items in the incident’s log.
The text may span multiple lines and all white space is preserved.
InvalidRecords
Records (lines) are considered invalid in at least the following situations:
Lines that are not formatted as above.
An incident without at least one log message.
Ids that are zero or less
Incidents with missing information
Incidents with incorrect state names (e.g., not New, In Progress, On Hold, Resolved, or
Canceled)
Reopen count is less than zero
Owners are required for incidents in the In Progress, On Hold, and Resolved states. Owners
are listed as “Unowned” in the New and Canceled states. Owners cannot be empty or null.
Incidents in the On Hold state without a hold reason listed for the status details
Incidents in the Resolved state without a resolution reason listed for the status details
Incidents in the Canceled state without a cancellation reason listed for the status details
Incidents in the New or In Progress states have a status details listing of “No Status”
Design
Trying to jump from requirements right into coding without doing some design first is bound to
lead to trouble. We will eventually have you implement our design, but first you need to propose
your own. To do this, we give you a scenario and insist on some restrictions for your design.
The scenario
As an effort to give everyone an opportunity to promote their design ideas, the project manager
in charge of the development of ServiceWolf has devised a process that requires every member
of the development team to propose a full design of the system (excluding GUI details) by
identifying the classes, their fields and methods, and the relationships between the classes in the
system before a final design is selected. The main constraint is that your design must include a
State Pattern that models the finite-state machine of a incident’s state. The project manager will
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 26/29
then use ideas from these proposals to come up with the final design that your team will have to
implement.
What you must do: DesignRationale and UML diagram
You must design an application that satisfies the requirements of the ServiceWolf application.
You will create a design proposal that shows the objects, their states and behaviors, and the
relationships among the objects needed to implement the requirements. Your design must be
described in document containing a design rationale and a UML class diagram.
Your design should:
utilize the Model-View-Controller (MVC) design pattern (see the note about MVC, below),
utilize the State Pattern (see the note about State Pattern, below),
contain at least one interface or abstract class,
contain at least one inheritance relationship (which could include implementing an interface),
and
contain at least one composition relationship.
To help your manager evaluate your design, you should answer the following technical questions
in your design document as part of the rationale:
1. What objects are important to the system’s implementation and how do you know they are
important?
2. What data are required to implement the system and how do you know these data are
needed?
3. Are the responsibilities assigned to an object appropriate for that object’s abstraction and
why?
4. What are the relationships between objects (such as inheritance and composition) and why
are these relationships important for addressing the requirements?
5. Have you identified any design patterns appropriate for implementing the system (i.e., the
State Pattern)? What are they and why are they appropriate?
6. What are the limitations of your design? Are there ways that your design might limit future
additions to the system (e.g., user roles or new states)?
MVC Note
Java Swing, the user interface (UI) libraries for Java, does not follow the strictly traditional
definition of MVC. Instead, Java Swing utilizes what might be called a separable model
architecture.This means that the model is separate and distinct from the view/controller classes
that make up the UI. Your design must focus on the model.
In your UML class diagram, you should represent the UI as a class with no state or behavior.
Your diagram should also show which class(es) your UI will interact with through some type of
composition/aggregation/association relationship. The relationship between your model and the
UI must be justified in your design rationale.
When thinking about the relationships between your UI and the model, consider the following
questions:
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 27/29
1. What are the data and behaviors of your model that will be shown through the UI?
2. How does your UI get those data to display; what methods of the model must be called?
State Pattern
The State Pattern is an object-oriented solution to a state-based application. The finite-state
machine that models the state of a incident should be modeled using the State Pattern. This
means the bubbles, which represent states, becomes classes. The transitions become the
behaviors of the classes. A context class encapsulates the state pattern for each incident and
delegates the transitions to the current state for the given incident. For more information on the
State Pattern, see the lecture notes (Lecture Notes, Wikipedia article and the example Horner’s
Rule State Pattern implementation.
Design Proposal andRationaleSubmission Format
Submit your design proposal via Gradescope under the assignment named P1P1: Design. Note
that we will grade the last submission to Gradescope.
Use the provided design proposal template as a starting point for your design proposal. Use a
UML diagramming tool (options are listed the Software Development Practices notes) to create
your UML diagram. Incorporate your UML diagram into your written proposal (using an editing
tool such as MS Word) and save the entire document as a PDF. Alternatively, create a PDF for the
design proposal and another PDF for the UML diagram, then append the diagram to the proposal
to make a single PDF document.
Need a little more direction?
See the following example design proposal: Sample Design Proposal.
Testing
This project requires you create and run unit/integration and system tests. You can defer
unit/integration testing until Part 2 of this project. But now, you need to prepare some system test
cases.
Scenario
You must create a system test plan that describes five test cases that will determine if the
finished program satisfies the requirements. Write the tests before you begin development to
clarify the inputs to and outputs from the system. Each test must demonstrate that the program
satisfies a scenario from the requirements. A scenario is one major path of functionality as
described by the requirements.
Assignment
You will write at least five (5) tests for this project. Use the provided system test plan template to
describe your tests.
Top
2021/3/1 CSC 216 SE Materials
https://pages.github.ncsu.edu/engr-csc216-staff/CSC216-SE-Materials/projects/project1/project1-part1#data-format 28/29
Your system test plan must meet the following expectations:
Each test must be repeatable and specific; all input and expected results values must be
concrete.
All inputs required to complete the test must be specified.
Provide instructions for how a tester would set up, start, and run the application. (What class
from your design contains the main method that starts your program? What do the input files
contain?). Describe the instructions at a level where anyone using Eclipse could run your tests.
To help you with your system test plan, we have provided some example test files.
ServiceWolf Test File
Format
Use the provided template as a starting point for your system test plan. Save your STP as a PDF.
Submit the PDF to Gradescope under the assignment named P1P1: STP.
Need a little help?
See the following example black box test plan: Sample System Test Plan.
Deployment
For this class, deployment means submitting your work for grading. For Part 1 of this
programming assignment, you must submit two PDF documents:
1. Design document with incorporated UML class diagram.
2. System test plan document.
Make sure that your submissions satisfy the grading rubrics.
You should submit the documents for Project 1 Part 1 to Gradescope. Please follow the
Submitting your PDF on Gradescope instructions, including selecting page for each question
(grade category). We will grade the last submission made to Gradescope before the deadline.
Submission Reminders
The electronic submission deadline is precise. Do not be late. You should count on
last minute system failures (your failures, ISP failures, or Gradescope failures).
You are able to make multiple submissions of the same file. (Later submissions to
a Gradescope assignment overwrite the earlier ones.) To be on the safe side, start
submitting your work as soon as you have completed a substantial portion.
Published with GitHub Pages