联系方式

  • QQ:99515681
  • 邮箱:99515681@qq.com
  • 工作时间:8:00-23:00
  • 微信:codinghelp

您当前位置:首页 >> C/C++编程C/C++编程

日期:2021-03-03 10:16

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


版权所有:留学生编程辅导网 2020 All Rights Reserved 联系方式:QQ:99515681 微信:codinghelp 电子信箱:99515681@qq.com
免责声明:本站部分内容从网络整理而来,只供参考!如有版权问题可联系本站删除。 站长地图

python代写
微信客服:codinghelp