case study: conceptual modeling of a helpdesk …©2011-2014, prof. dr. gharaei case study:...

©2011-2014, Prof. Dr. Gharaei Case Study: conceptual modeling for a request manager component 1

Case Study: conceptual modeling of a helpdesk request manager Prof. Dr. Gharaei UML, SoSe 2014 Version 1.3, 19.10.2013

1. Introduction An enterprise IT support team uses a helpdesk system to handle user requests concerning issues with regard to its infrastructure. This system consists of interacting components that exist independently. An outlook of them is given in the following illustration. It does not show the interrelationships between the components.

A brief summary of the most important tasks the components of this system perform is listed in the following.

Request management • tracks the history of calls for the callers • call (issue) management • updating the processing status of an issue

Service management • initiates the workflow to fulfill user service requests • tracks the status of the service request processing • administers the processing of service requests

Asset information • tracking of system or network components • supplying system resources including hierarchical relationships


• managing information about location and usage of assets • asset-related warranty information

Reporting • reporting call history • reporting processing status • providing search tools to select a collection of requests or processing status • managing a pool of parameterizable standard reports

Data access • central sharing of data for all components • central data update

Web interface • GUI for different user types including administrators, end users and analysts • screenflows1 • I/O mail handling

2. The requirements

A central part of the helpdesk system, the request manager (RM), handles the request lifecycle. Following requirements has been identified after a first review.

1. A helpdesk user must logging on to the system in order to use it.

2. The helpdesk user may create requests.

3. The request manager dispatches the requests received to individual helpdesk analyst.

4. The selection of analysts is based on the competence group of the analysts.

5. A helpdesk analyst must logon to the helpdesk system to view a list of all user requests assigned to him.

6. He has the possibility to sort them according to waiting time or priority.

7. Priorities are based on policies which consider the role of the requester, his department, the severity of the issue and the amount of similar requests.

8. Dependent on the request, the analyst may handle the issue by calling the requester, visiting him on the site or remotely logging in his computer.

9. For each request, an analyst can view and modify a log of activity.

10. A request will be removed automatically from the analyst`s queue, if it cannot be processed completely within 24 hours after assignment.

1 A screenflow designs interactions that a GUI user performs to complete a given task. It is based on a scenario of a user completing a given task. Hence it simulates all the screens, all the clicks and all the data entry necessary to start and complete that task.


11. A helpdesk user may view the processing state.

12. A helpdesk analyst sends policy-based individual user notification about the state of the processing.

13. The RM sends regular standard state notification to its users.

14. The RM can generate reports of activity for other helpdesk modules.

3. Primarily analysis We investigate the requirements to find out, which of the following information might be extracted:

• Roles • An elementary behavior • A compound behavior • Business rules • Entities

Let us use a table to outline the results. The following abbreviations are used in this table:

A (role) B (elementary behavior) W (compound behavior) R (business rule) E (entity) C (comment)

# requirement Information extracted1 A helpdesk user must logging on

to the system in order to use it. A: helpdesk user B: logging on to the system C: The system is the RM = that part of the helpdesk that is being modeled

2 The helpdesk user may create requests.

B: create request E: request A: helpdesk user

3 The request manager (RM) dispatches the requests received to individual helpdesk analyst.

W: dispatching requests A: helpdesk analyst E: request

4 The selection of analysts is based on the competence group of the analysts.

R: the whole requirement A: analyst B: selection of analyst E: competence group of the analysts

5 A helpdesk analyst must logon to the helpdesk system to view a

A: helpdesk analysts B: logon to the helpdesk (= RM) E: request


list of all user requests assigned to him.

E: list of requests E: assigned request B: viewing own list of assigned requests

6 He has the possibility to sort them according to waiting time or priority.

A: analysts E: request E: request list W: sorting a request list B: sorting a request list according to waiting time R: a priority is assigned to each request E: priority of requests B: priority sorting of a request list

7 Priorities are based on policies which consider the role of the requester, his department, the severity of the issue and the amount of similar requests.

R: the whole requirement E: request E: priority of requests E: policy E: the role of the requester E: issue E: the department the requester belongs to E: the severity of the issue E: the amount of similar requests

8 Dependent on the request, the analyst may handle the issue by calling the requester, visiting him on the site or remotely logging in his computer.

R: the whole requirement A: analyst E: the issue ( = the request) A: a requester = a helpdesk user W: handling the request B: visiting the requester B: calling the requester B: remote logging to the requester PC

9 For each request, an analyst can view and modify a log of activity.

A: analyst E: analyst activity log E: request B: view analyst activity log B: modify analyst activity log

10 A request will be removed automatically from the analyst`s queue, if it cannot be processed completely within 24 hours after assignment.

R: the whole requirement E: request E: analyst`s queue W: rule-based, automatic removal of a request from the analyst`s queue E: timer with time-out function pro request W: request assignment

11 A helpdesk user may view the processing state.

A: helpdesk user E: processing state B: viewing processing state

12 A helpdesk analyst sends policy-based individual user notification about the state of the processing.

R: the whole requirement A: helpdesk analyst E: policy

E: state of processing W: generating individualized policy-based state information E: user notification B: sending state notifications

13 The RM sends regular standard state notification to its users.

R: the whole requirement E: standard state notification E: standard state of the processing B: sending notifications


W: sending standard state notifications

14 The RM can generate reports of activity for other helpdesk modules.

W: generating activity report A: other helpdesk module E: activity report

4. The Use Case diagram After the first rapid analysis of the requirements, three roles are being detected. We show them in a preliminary use case diagram. This should contain merely a frame for the diagram and all the roles we can extract form the table constructed after the preliminary analysis.

Notes: This diagram is subject to augmentation.

The roles might be changed as we treat the requirements specifically.

It establishes a preliminary framework for our final UC diagram.

UML does not propose any approach for construction of UC diagrams.


In a second step, we will try to find use cases for some requirements in order to build a complete use case diagram step-by-step. After reviewing the requirements, we decide to take the first five requirements.

In this step, as well as in the future, we don`t hesitate to define relationships and stereotypes as soon as we recognize them.

Notes: The definitions are still subject to change as we approach further.


In a next step, we realize the 6th requirement. This is a slight augmentation.


After populating the diagram with the first use cases and their associations with the roles, we notice the following interesting features:

a) Both roles analyst and helpdesk user needs a session manager UC. However, the session types are fundamentally different, since each session type has its own characteristics.

b) Nevertheless, both sessions need a logon extension that seems to be similar for both.

c) The logon behavior encompasses the logout function as well. d) Both analyst and Helpdesk user are users of the system. They share

commonalities. e) Both kinds of sorting share commonalities as well.

After considering these features, the diagram will be improved to the following form.


Considering the 7th requirement:

“7. Priorities are based on policies which consider the role of the requester, his department, the severity of the issue and the amount of similar requests.”

It is clear that this statement specifies the policies instead of an action. It remains to be considered later in an activity diagram.

The 8th requirement says:

“8. Dependent on the request, the analyst may handle the issue by calling the requester, visiting him on the site or remotely logging in his computer.”

Here, a use case can only be recognized partially. It can be coarsely called “handle request”. This UC and the corresponding ones for the following two requirements are depicted in the next augmented diagram.

“9. For each request, an analyst can view and modify a log of activity.

10. A request will be removed automatically from the analyst`s queue, if it cannot be processed completely within 24 hours after assignment.”

Why do we use a UC inheritance here? Does UML 2 allow this? Does the tool permit it?


The last step in UC design is the realization of the four further requirements:

“11. A helpdesk user may view the processing state.

12. A helpdesk analyst sends policy-based individual user notification about the state of the processing.

13. The RM sends regular standard state notification to its users.

14. The RM can generate reports of activity for other helpdesk modules.”


5. Homework A textual description of use cases has being ignored up to this point. This shall be done as homework. A possible structure may include the following data:

a. Name: should always be user-centric, not system-centric (i,e, from the perspective of the user, not the system) e.g. “making a deposit" (user-centric) versus "accepting a deposit (system-centric)

b. Description: describe what the use case is accomplishing c. Desired outcome: might be a report, an event or condition or the like d. User goals: If the "Desired outcome" section describes what the user hopes to

accomplish, the "Goals" section describes why the user is doing it. e. Participants/Roles: these are not physical users f. Dependencies: like Subset/Combines, Uses/Is-used-by (includes),

Precedes/Follows, Requires, Extends/Is-specialization-of, Resembles, Equivalent g. Preconditions: What conditions must exist before this use case can complete

successfully? h. Assumptions: What assumptions are you making about the state of the world

when the use case runs? i. Postconditions: Frequently a use case changes the state of a system j. Scenarios: small narrative descriptions of someone working through the use case

(special cases, extreme cases, failures (not implementation relevant) k. Business rules: policies that the business establishes that might effect the

outcome of the use case

From this list, the attributes dependencies, preconditions, assumptions and postconditions are the most important ones. However, the following criteria should be considered before assigning attributes to a use case:

1. It must make sense. In other words, an attribute must add non-trivial information to a use case.

2. Some well-known use cases like logon are self-explanatory. The attributes for them should merely describe the specific behavior of them.


6. Selected activity diagrams

The UC dispatch request


The UC manage session This use case exhibits certain characteristics:

• It encompasses an interactive session that starts after a successful logon process. • Most activities during a session are event driven.

The following AD describes a possible model for this UC.

The above diagram has some shortcomings. For instance, the join node immediately preceding the node session object means that the creation of a session depends on receiving the event “show_req_queue”.

It remains as homework for the reader to modify the diagram in order to deal with this and other possible shortcomings.

case study: conceptual modeling of a helpdesk …©2011-2014, prof. dr. gharaei case study:...

Documents