Case Study: conceptual modeling of a helpdesk request manager

Transcription

1 Case Study: conceptual modeling of a helpdesk request manager Prof. Dr. Gharaei UML, SoSe 2014 Version 1.3, 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 1

2 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 screenflows 1 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. 2

3 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 extracted 1 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. 3 The request manager (RM) 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 B: create request A: helpdesk user W: dispatching requests A: helpdesk analyst R: the whole requirement A: analyst B: selection of analyst E: competence group of the analysts A: helpdesk analysts B: logon to the helpdesk (= RM) 3

4 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. 11 A helpdesk user may view the processing state. 12 A helpdesk analyst sends policybased individual user notification about the state of the processing. 13 The RM sends regular standard state notification to its users. E: list of requests E: assigned request B: viewing own list of assigned requests A: analysts 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 R: the whole requirement 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 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 A: analyst E: analyst activity log B: view analyst activity log B: modify analyst activity log R: the whole requirement 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 A: helpdesk user E: processing state B: viewing processing state 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 R: the whole requirement E: standard state notification E: standard state of the processing B: sending notifications 4

5 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. 5

6 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. 6

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

8 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. 8

9 Considering the 7 th 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 8 th 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? 9

10 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. 10

11 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. 11

12 6. Selected activity diagrams The UC dispatch request 12

13 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. 13