Panthera - A Helpdesk System developed in Visual Studio.NET

Transcription

1 Panthera - A Helpdesk System developed in Visual Studio.NET Master Thesis, 40 Credits Katarina Gyll & Peter Gyll November 2003

2 ii

3 Abstract Every company that has products or services on the market has the need of a Help desk system to help structuring the different questions and error reports that comes from the customers. A help desk system makes it possible to create a history log on the matters that is stored in the system, this way it is possible to get statistics as well. A help desk system is not just an asset in serving the customers, but also the employees. If the company is fairly big or if the employees are situated in many different locations it is of even more usage to have a help desk system. It would be of much help where the individual employees might have a problem that he/she does not have a solution to or wants to find another way of solving the problem, then a matter can be registered and the other employees will be able to help solving the matter. After the matter has been registered and hopefully solved, the employees just have to search the system for the matter if a similar problem occurs at a later time. In this Master Thesis we have developed a help desk system named Panthera. We used a subset of the parts defined by RUP (Rational Unified Process), when developing the Panthera system. Panthera makes it possible for the customer to report matters over the Internet and the employees will be able to handle the matter and have access to all information needed about the customer, the product, and about similar matters that has been registered previously. It is also possible to register workorders that will help defining the different tasks that needs to be done in a company. The workorder is then assigned to an employee that will be responsible of the task. Panthera is developed to be of use for both the customers and the entire company, not just the help desk. iii

4 iv

5 Sammanfattning Alla företag som har produkter eller tjänster på marknaden har behov av ett ärendehanteringssystem för att hjälpa till att strukturera de olika frågor och felanmälningar som kommer in från de olika kunderna. Ett ärendehanteringssystem gör det möjligt att skapa en händelselogg på alla ärenden som finns lagrade i systemet, detta gör att det är möjligt att skapa statistik på de ärenden som handhas. Om företaget är lite större eller om de anställda sitter och jobbar i olika städer är det ännu mer motiverat att ta hjälp av ett ärendehanteringssystem i det dagliga arbetet. Det skulle till exempel vara till hjälp om en anställd stöter på ett problem som han/hon inte har någon lösning på eller som den anställde skulle vilja hitta en annan lösning på, då kan ett ärende registreras och de övriga anställda kan hjälpa till att lösa problemet. Efter det att ett ärende har registrerats och förhoppningsvis blivit löst är det möjligt för de anställda att söka rätt på ärendet om ett nytt liknande ärende registreras och behöver lösas. I detta examensjobb har vi utvecklat ett ärendehanteringssystem som heter Panthera. När vi utvecklade Panthera använde vi oss av en delmängd av de delar som ingår i RUP (Rational Unified Process). Panthera gör det möjligt för kunderna att själva rapportera in ärenden över Internet och de anställda kommer att kunna jobba med ärendet samtidigt som de har tillgång till all den information som finns på kunden, produkten och tidigare registrerade ärenden som är av liknande karaktär. Det är även möjligt att registrera arbetsordrar som är till hjälp vid definierandet av olika arbetsuppgifter som måste göras inom företaget. Varje arbetsorder tillsätts sedan en ansvarig, vars uppgift är att se till att arbetsuppgiften utförs. Panthera har utvecklats för att vara till hjälp för både kunderna och för alla inom företaget och inte bara för help desk. v

6 vi

7 Acknowledgements We would like to thank Per Magnusson for making it possible for us to write this Master Thesis at SchlumbergerSema (former Sema InfoSynergi) and for making the effort of putting a specification together of possible subjects for this master thesis. We would also like to thank our supervisors at SchlumbergerSema, Hans-Ove Borg and Mats G. Olofsson whom have been there for us whenever we have had questions. Thank you, Peter Sjölund at SchlumbergerSema, for making it possible for us to use Visual Studio.NET and to attend courses in Visual Basic.NET and ASP.NET, which helped making our work more effective. We would like to thank Eric Qvist at ADB Arkitektur, for helping us find the best approach to the design of the system and for taking time to answer all the questions that came up while specifying the design and implementing the system. Thank you, Maria Thors at SchlumbergerSema, for taking care of hotel reservations, car rentals and so on and for being such a good friend and caring so much. Thanks to all the people that work at SchlumbergerSema for taking such good care of us during our time at the office in Sundsvall. Thank you for your always shown interest of our progress and for your input to what the system should be able to do. We would like to thank our supervisor Jürgen Börstler, at the Department of Computer Science at the University of Umeå, for giving such good feedback on the material that we have sent to him during this time. And last, but certainly not least we would like to thank our parents and our friends for all the support and understanding. vii

8 viii

9 Company The company where we have written this Master Thesis is named SchlumbergerSema, but when we started writing this thesis it was named Sema InfoSynergi so later in the thesis you will find that we refer to the company as Sema InfoSynergi or SISAB in short. We will give you a short description of the company as of today when it is purchased of Schlumberger and therefore the name is changed to SchlumbergerSema. Sema InfoSynergi is active in Energy and Utilities, but first we give you a description of SchlumbergerSema as a whole. SchlumbergerSema SchlumbergerSema is a leading information technology services company providing a unique combination of domain expertise and global capabilities delivered on a local basis. The company has proven capabilities delivering consulting, systems integration, managed services and products serving the telecommunications, energy and utilities, finance, transport, and public sector markets. Together with Schlumberger Oilfield Services, it is one of two business segments of Schlumberger Limited. Headquartered in New York City, SchlumbergerSema was formed in April, 2001, when Schlumberger Limited acquired Sema plc, and combined it with part of its former Test & Transaction business and other recent acquisitions. With more than 2,000 customers across the globe, SchlumbergerSema provides consulting, systems integration, managed services and products to the world s leading telecommunications, financial, transportation, oil and gas, and utilities corporations, as well as government organizations. SchlumbergerSema partners cooperate with its customers to manage business processes and infrastructure that reduce both costs and risks. The company leverages its technology expertise to provide a wide range of critical services: Help desks Data centers Business continuity centers Network infrastructure outsourcing Network connectivity ix

10 SchlumbergerSema offers a broad portfolio of hardware and software products. Product expertise includes: Enterprise software systems, such as billing, customer relationship management (CRM) and trading systems Smart cards Web payphones Point-of-sale (POS) terminals Parking and mass transit terminals SchlumbergerSema focuses its strong domain expertise on five key industries: Energy and Utilities Finance Telecommunications Transport Public sector Other Areas of Expertise Beyond the public sector, SchlumbergerSema is also a key IT provider to major public events around the globe, building a reputation for delivering complex, large-scale IT projects on time, to budget and at a guaranteed level of service. SchlumbergerSema has achieved the world s largest ever sports IT-related contract, encompassing eight years and four Olympic Games in Salt Lake City in 2002, Athens in 2004, Turin in 2006, and Beijing in Addressing the IT integration needs of the oil and gas industry is another area in which SchlumbergerSema excels. Leveraging its parent company s more than 70 years experience providing technology solutions to the oil and gas industry, SchlumbergerSema works together with its sister organizations - Schlumberger Information Services and Schlumberger Network Solutions to help Schlumberger Oilfield Services customers transform their businesses to achieve critical real-time reservoir management. Energy and Utilities With more than 30 years experience serving the energy and utilities industries, SchlumbergerSema is the only company that enables complete end-to-end business transformation solutions across the entire energy value chain. The company s extensive solutions combine the power of real-time energy consumption information with leading digital technologies and proven business process models. SchlumbergerSema has deployed the largest wireless data network in the US to enable more than six million residential and industrial customers, transformed Cinergy s business into an integrated webenabled digital energy enterprise, and delivered the world s largest personal energy management program to Puget Sound Energy. It has deployed a stateof-the-art trading and exchange solution to 85% of Europe s energy trading exchanges, managed all nuclear power plant command and control for EDF in x

11 France, and is the largest provider of customer care, billing and supplier change and settlement solutions in Scandinavia. Mission critical solutions for the energy and utilities industries include: Strategic consulting and business process design Systems integration, managed services and industry-leading technology Power generation and network control Energy trading Energy and water delivery and use management Customer management xi

12 xii

13 Table of Contents ABSTRACT SAMMANFATTNING ACKNOWLEDGEMENTS COMPANY III V VII IX SCHLUMBERGERSEMA ENERGY AND UTILITIES IX X LIST OF TABLES LIST OF FIGURES XIX XXI INTRODUCTION 1 PROBLEM STATEMENT SYSTEM BACKGROUND PRIMARY NEEDS 5 RUP DYNAMIC STRUCTURE STATIC STRUCTURE ROLES ACTIVITIES ARTIFACTS BUSINESS MODELING WORKFLOW REQUIREMENTS WORKFLOW ANALYSIS AND DESIGN WORKFLOW IMPLEMENTATION WORKFLOW TEST WORKFLOW DEPLOYMENT WORKFLOW CONFIGURATION AND CHANGE MANAGEMENT WORKFLOW PROJECT MANAGEMENT WORKFLOW ENVIRONMENT WORKFLOW REVIEWS AND MODEL DEPENDENCIES 14 xiii

14 REQUIREMENTS OVERVIEW TARGET ENVIRONMENT FUNCTIONAL REQUIREMENTS INFORMATION MATTER CATEGORIES SYSTEM USERS WORKLOAD NOTIFICATION PROCESS PROGRESS PRIORITY NON-FUNCTIONAL REQUIREMENTS NF 1: USABILITY NF 2: LEARNABILITY NF 3: PERFORMANCE NF 4: MAINTAINABILITY NF 5: SECURITY FUTURE PLANS 25 ANALYSIS ACTORS ACTOR 1: CUSTOMER ACTOR 2: EMPLOYEE ACTOR 3: DEVELOPER ACTOR 4: SUPPORT EMPLOYEE ACTOR 5: MANAGER ACTOR 6: SCHEDULER ACTOR 7: ADMIN USE CASES UC C1: LOGIN UC C2: LOGOUT UC C3: REPORT MATTER UC C4: VIEW COMPANY MATTER UC C5: MODIFY OWN USER UC C6: MODIFY OWN COMPANY UC E1: REPORT WORKORDER UC E2: VIEW STATISTICS UC E3: HANDLE WORKORDER UC E4: MANAGE OWN MATTER SPECIFIC NOTIFICATION UC E5: VIEW USER UC E6: VIEW PRODUCT UC E7: VIEW COMPANY UC E8: VIEW MATTER UC D1: HANDLE MATTER UC D2: VIEW AGREEMENT 33 xiv

15 UC S1: MANAGE FAQ UC S1.1: ADD FAQ UC S1.2: EDIT FAQ UC S1.3: DELETE FAQ UC S2: SEND FEEDBACK TO CUSTOMER UC S3: MANAGE NOTIFICATION FOR PROCESS STEP UC S3.1: ADD NOTIFICATION FOR PROCESS STEP UC S3.2: EDIT NOTIFICATION FOR PROCESS STEP UC S3.3: DELETE NOTIFICATION FOR PROCESS STEP UC S4: MANAGE CUSTOMER USER UC S4.1: ADD CUSTOMER USER UC S4.2: EDIT CUSTOMER USER UC S4.3: DELETE CUSTOM USER UC S5: MANAGE WORKLOAD UC S5.1: ADD WORKLOAD UC S5.2: EDIT WORKLOAD UC S5.3: DELETE WORKLOAD UC M1: STUDY BACKLOG UC M2: CREATE REPORTS UC M3: VIEW WORKORDER UC M4: MANAGE AGREEMENT UC M4.1: ADD AGREEMENT UC M4.2: EDIT AGREEMENT UC M4.3: DELETE AGREEMENT UC SCH1: SEND NOTIFICATION UC A1: MANAGE USER UC A1.1: ADD USER UC A1.2: EDIT USER UC A1.3: DELETE USER UC A2: MANAGE ACTOR UC A2.1: ADD ACTOR UC A2.2: EDIT ACTOR UC A2.3: DELETE ACTOR UC A3: MANAGE PRODUCT UC A3.1: ADD PRODUCT UC A3.2: EDIT PRODUCT UC A3.3: DELETE PRODUCT UC A4: MANAGE COMPANY UC A4.1: ADD COMPANY UC A4.2: EDIT COMPANY UC A4.3: DELETE COMPANY UC A5: MANAGE MATTER TYPE UC A5.1: ADD MATTER TYPE UC A5.2: EDIT MATTER TYPE UC A5.3: DELETE MATTER TYPE UC A5.4: DEFINE PROCESS STEP USER RIGHTS 39 xv

16 5.4 PRIORITY NON-FUNCTIONAL REQUIREMENTS PRIORITY USE CASE PRIORITY 40 DESIGN DISCUSSION SYSTEM ENVIRONMENT PROGRAMMING LANGUAGE WEB DATABASE NET FRAMEWORK COMMON LANGUAGE RUNTIME NET FRAMEWORK BASE CLASSES SECURITY 48 XML HISTORY XML BASICS ELEMENTS RULES PROCESSING INSTRUCTIONS XML DECLARATION VALID XML XML PARSER XML IN.NET DATASETS WEB SERVICES 60 DESIGN SYSTEM ARCHITECTURE THREE-TIER SOLUTION PRESENTATION SERVICES BUSINESS SERVICES DATA SERVICES OBJECT MODEL DYNAMIC MODEL UC C1: LOGIN UC C2: LOGOUT UC C3: REPORT MATTER UC E8: VIEW MATTER UC D1: HANDLE MATTER UC SCH1: SEND NOTIFICATION UC A1.1: ADD USER GENERAL MANAGE DATABASE 73 xvi

17 8.5 FILE STRUCTURE MENU STRUCTURE 74 TESTING SURVEY DOCUMENTS REQUIREMENTS DOCUMENT ANALYSIS DOCUMENT DESIGN DOCUMENT USER INTERFACE FUNCTIONALITY TEST TC1: LOGIN WINDOW TC2: MAIN WINDOW TC3: EXPLORER WINDOW TC4: USER WINDOW TC5: MATTER WINDOW TC6: ABOUT WINDOW RESULTS DOCUMENTS USER INTERFACE FUNCTIONALITY TEST 80 RESULTS INCLUDED IN THIS RELEASE NEXT RELEASE SCREENSHOTS FROM PANTHERA 82 GLOSSARY 87 BIBLIOGRAPHY 89 APPENDIX A: A EXAMPLE OF AN XML DOCUMENT 93 APPENDIX B: SURVEY OF INFOLINK VERSUS PANTHERA 95 xvii

18 xviii

19 List of Tables TABLE 1: SISAB S FIVE DIFFERENT MATTER TYPES TABLE 2: THE SIX ORIGINAL USER GROUPS TABLE 3: TYPES OF NOTIFICATION TABLE 4: USER RIGHTS NEEDED FOR THE USE CASES TABLE 5: PRIORITIES OF THE NON FUNCTIONAL REQUIREMENTS TABLE 6: PRIORITIES OF THE USE CASES TABLE 7: THE STRUCTURE OF THE NAVIGATION MENU TABLE 8. ERRORS FOUND IN INTEGRATION TEST xix

20 xx

21 List of Figures FIGURE 1. NAVIGATION IN INFOLINK... 3 FIGURE 2. A MATTER IN INFOLINK... 4 FIGURE 3. RUP IS AN ITERATIVE PROCESS MODEL FIGURE 4. THE TWO STRUCTURES STATIC AND DYNAMIC FIGURE 5. EXAMPLE OF ROLES, ACTIVITIES, AND ARTIFACTS FIGURE 6. THE DEPENDENCIES OF THE MODELS FIGURE 7. A GENERAL FLOW FOR A MATTER IN SISAB FIGURE 8. HOW THE NEXT PROCESS IS CHOSEN FIGURE 9. USE CASE MODEL DESCRIBING THE ACTORS AND THE USE CASES ASSOCIATED WITH THEM FIGURE 10: AN OVERVIEW OF THE MAJOR COMPONENTS IN.NET FRAMEWORK FIGURE 11: AN EXAMPLE OF THE LOGICAL STRUCTURE OF A XML DOCUMENT FIGURE 12: EXAMPLE OF PROPER NESTING FIGURE 13: SYNTAX OF A PROCESSING INSTRUCTION FIGURE 14: EXAMPLE OF AN XML DECLARATION FIGURE 15: THE SYNTAX OF THE DOCUMENT TYPE DECLARATION FIGURE 16: EXAMPLE OF A DTD INCLUDED IN THE XML DOCUMENT FIGURE 17: A DOCTYPE DECLARATION THAT USES BOTH INTERNAL AND EXTERNAL SUBSETS FIGURE 18: THE XML PARSER AS THE BRIDGE BETWEEN THE XML DOCUMENT AND THE APPLICATION FIGURE 19: THE OBJECT MODEL OF THE RELATION CAPABILITIES OF A DATASET FIGURE 20: THE DIFFERENCE BETWEEN UNTYPED VERSUS TYPED DATASETS.. 60 FIGURE 21: AN OVERVIEW OF A SOAP CALL TO A WEB SERVICE FIGURE 22: THREE-TIER ARCHITECTURE FIGURE 23: AN OVERVIEW OF THE BUSINESS SERVICE FIGURE 24. AN OVERVIEW OF THE SYSTEM FIGURE 25: THE RELATIONS BETWEEN THE CLASSES IN THE WEB SERVICE FIGURE 26: THE SEQUENCE FOR LOGIN FIGURE 27: THE SEQUENCE FOR LOGGING OFF THE SYSTEM FIGURE 28. THE SEQUENCE FOR REPORTING A MATTER FIGURE 29. THE SEQUENCE FOR VIEWING A MATTER FIGURE 30: THE SEQUENCE FOR HANDLING A MATTER FIGURE 31: THE SEQUENCE FOR SENDING A NOTIFICATION FIGURE 32: THE SEQUENCE TO ADD USER FIGURE 33. THE SEQUENCE OF A GENERAL MANAGE FIGURE 34: THE DATABASE MODEL FOR THE PANTHERA SYSTEM FIGURE 35: WEB CLIENT FILE STRUCTURE FIGURE 36. STEP 2 IN REPORTING A MATTER VIA THE WEB xxi

22 FIGURE 37. THE EXPLORER SHOWING THE REPORTED MATTERS FIGURE 38. THE FIRST VIEW THE USER MEETS WHEN OPENING A QUESTION ANSWER MATTER FIGURE 39. THE VIEW OF AN USER IN THE WINDOWS APPLICATION xxii

23 Chapter 1: Introduction Chapter 1 Introduction This thesis describes the design and development of a Help desk system that is to be used by former Sema InfoSynergi that presently is a part of the Swedish section of Energy and Utilities at SchlumbergerSema. A Help desk system is a system that helps when dealing with matters related to company activities, but also in taking measures needed to solve a problem. A help desk system might also be described as The process of handling unstructured data in a structured manner. What a user of a help desk system wants to accomplish when using a help desk system, is to be able to create a stable environment where it is easy to make decisions and find solutions to problems. [SSAB98]. A help desk is usually associated with an end-user support centre. The help desk is responsible for managing issues that the customers of the company have. If they cannot solve the issue themselves, then they takes help from other resources with the knowledge that is necessary to solve the issue [PhVer]. The help desks are often only staffed during business hours, and this is also the case with SISAB, Sema InfoSynergi AB. A help desk system is a system, whose purpose is to help the help desk personal do their job in quickest and smoothest possible way. The system stores all kinds of information that are needed by the help desk, for example information on the different issues, or matters as they will be referred to in the future. Since the work of designing and implementing a help desk system from scratch is a task that takes a lot of time, knowledge, and effort we decided to use a subset of RUP as development process to make the development more manageable. A description of RUP can be found in Chapter 3 RUP. To be able to make a system that is going to be useful for the organisation we gathered the requirements (see Chapter 4 Requirements) and modelled them as actors and use cases. Since the help desk system is developed during a limited amount of time the requirements are prioritized to make sure that the requirements that are vital to the help desk and the users are implemented in 1

24 Chapter 1: Introduction this release. All actors and use cases are described in Chapter 5 Analysis. The use cases were prioritized and the project of developing a new help desk system was limited to a subset of the use cases in the first release. These use cases were then modelled as sequence diagrams to describe how objects interact with each other in more details. After identifying the requirements, then the programming language, database, and so on needed to be considered. The discussions and decisions are presented in Chapter 6 Design Discussion and the design is presented in Chapter 8 Design. The thesis includes a description of.net in section 6.5.NET Framework, since all implementation was done with Visual Basic.NET and ASP.NET. Some information in the help desk system is stored in XML. Chapter 7 is describing XML and the use of XML in.net. The testing of the first release of the Help desk system, that is named Panthera, was performed by us and by the users. The results from this thesis are presented in the Chapter 9 Testing and Chapter 10 Result. 2

25 Chapter 2: Problem Statement Chapter 2 Problem Statement 2.1 System background The help desk system that SISAB is currently using is named InfoLink. All the labels and menu choices in InfoLink are in Norwegian, because InfoLink was developed for the market in Norway by InfoSynergi A/S. Since InfoLink is an add-in to Lotus Notes, the user interface is very similar to the one used in Lotus Notes. In Figure 1 below it is shown how the navigation in InfoLink is done. To the left is a navigation tree that helps the user to find what he/she is looking for. To the right are some further navigations possibilities before the desired information can be found. Figure 1. Navigation in InfoLink. 3

26 Chapter 2: Problem Statement Figure 2. A matter in InfoLink. The figure above, Figure 2, shows an example of a matter in InfoLink. As shown in the figure, all labels and menu choices are in Norwegian. SISAB s purpose with InfoLink, according to their user guidelines [BOR00], is to: Get a smooth internal matter handling. Store customer information. Retrieve statistics on matters. Both on product and on customer basis. Store matters, so it will be easier and more efficient to solve similar/related matters. Get information for quality measures. Be able to coordinate mattering and reporting with InfoSynergi A/S. SISAB s use of InfoLink is built upon support personal entering matters from customers. With InfoLink there are three ways for customers to report matters: (preferred by SISAB), telephone and fax. The incoming matters can be divided into three categories: Questions and answers 4

27 Chapter 2: Problem Statement o Questions about products and the usage of the products Error reporting o Errors found in products Requested changes in product functionality o Suggested changes, in products, made by customers and employees. The workflow of a matter depends on which category the matter belongs to. There are no predefined workflows for the different categories in InfoLink, the users must decide by themselves the flow of each matter. There are some features that SISAB requires and that InfoLink does not support. Notification is for example not supported in InfoLink so the employees and managers do not get a signal if a matter is overdue. Another limitation is that the customers cannot report matters themselves, but have to fully depend on the helpdesk at SISAB. It is also very difficult to create new matter types that will make the system more describable. 2.2 Primary needs The helpdesk system will be developed to meet the requirements in Sweden, although the company is stationed in other countries than Sweden as well. The helpdesk system will be designed primarily for support personal, which will work with the system on a daily basis. It is necessary that their interaction with the system will be as friction free as possible. The customers will also be an important part of the system. The customers will report and follow matters over the World Wide Web, and since the knowledge of using systems based on the World Wide Web can vary among the customers this part of the system need to be as simple as possible. A limitation of InfoLink (the system used today) is that it has no support for notification, so a matter can be left unattended without anyone noticing. This will be avoided with the use of notifications, mainly done with an that is sent to responsible SISAB personal. 5

28 Chapter 2: Problem Statement 6

29 Chapter 3: RUP Chapter 3 RUP The Rational Unified Process (RUP) was originally founded back in 1996 when Rational Approach and Objectory Process were combined into one process. The name of the new process was not RUP at that time, instead in early years of the process it went under the name Rational Objectory Process [JaBoRu99]. From 1997 to 1999 a number of process releases were made and in 1998 the process received its current name. The process has grown during the years. The main reason for this is that the owner of the process, Rational Software Corporation, has bought other companies, which have brought other process elements into the process. The modeling language used throughout RUP is UML (Unified Modeling Language). RUP is an iterative process model for software development. The iterative model can be looked upon as several minor projects, each consisting of four parts: Requirements, Analysis & Design, Implementation, and Test. The advantages with an iterative model are that errors can be found and corrected at an early stage in the project and changes in the requirements are also easier handled. Requirements Analysis & Design Implementation Test Iteration Figure 3. RUP is an iterative process model. The work process in RUP can be described in two structures (or dimensions): static structure and dynamic structure. The dynamic structure, the life cycle of the process, is expressed in terms of phases, iterations, cycles, and milestones. It represents the dynamic aspect of the process. The static aspect is represented by static structure, which is expressed in terms of workflows, activities, artifacts, components, and workers [Kru99]. These structures are illustrated in Figure 4. 7

30 Chapter 3: RUP Figure 4. The two structures static and dynamic. (Based on [Kru99:FIGURE 2-2]) The curves in the diagram in Figure 4 illustrate how the work intensity of workflows differs in different phases. The values in the diagram are not exact, but should instead be considered as guidelines for resource allocating (if no prior experience of similar projects exists). 3.1 Dynamic Structure The life-cycle (cycle) of a RUP project involves four phases, which all end with a milestone that has to be passed before the next phase can go on. The cycle can either be an initial cycle, probably the first version of a product, or further development of an already existing product. The four phases included in a cycle are: Inception The purpose of the inception phase is to define how the stakeholders will cooperate to achieve the objectives of the project. This includes retrieving a business case for the system, finding the most significant use cases, and limiting the size of the project. Elaboration In the elaboration phase the problem areas will be analyzed and the architecture will be decided upon. Also the project plan will be established in the elaboration phase, which is the most critical phase in the project. Construction In the construction phase of the project the product will be developed, integrated, and tested. 8

31 Chapter 3: RUP Transition The transition phase involves the handover of the product to the user community. Eventual errors found by the end users might lead to a new release where the errors will be corrected and functionality not yet completed will be completed. If there is a need for more than one iteration in a phase, then the phase can be divided into two or more iterations. It is important to consider that in RUP each iteration must result in an executable subproduct, for instance a subsystem or a prototype. How many iterations there should be in a project depends on the complexity and the size of the project, but 6+/-3 is usually an appropriate number of iterations. 3.2 Static structure RUP consists of nine workflows, which are divided into six core process engineering workflows and three core supporting workflows. Each of these workflows contains zero or more detailed workflows. The six core process engineering workflows: Business modeling workflow Requirements workflow Analysis and design workflow Implementation workflow Test workflow Deployment workflow The core supporting workflows: Configuration and change management workflow Project management workflow Environment workflow A workflow can be looked upon as when something is done in RUP. In order to understand when something is done one must know who is doing it, how it is done, and what is done. The other three terms are in RUP represented by a Role (who), an Activity (how), and an Artifact (what). 9

32 Chapter 3: RUP Role Activities Designer Use-Case Analysis Use-Case Design Artifact responsible for Use-Case Realization Figure 5. Example of roles, activities, and artifacts. (Based on [Kru99:FIGURE3-1]) Roles There are about 30 different roles in RUP. The purpose of a role is to define the responsibility and the behavior of a person or a group. What kind of behavior a role has is depending on what the role is set to do. A person can have several different roles in a project. It is also important to understand that a role is not the same as a person, since a role can be played by one or more persons Activities An activity defines what should be done. Every activity is assigned to a specific role and every time the activity is repeated it is performed by the same role (not necessarily the same person though). The goal of an activity is often rather clear. Usually the goal involves updating or creating some artifacts [Scott01]. The information needed for the activity is often taken from artifacts that have been created earlier in the project. An activity consists of several steps that can be divided into three main categories: Thinking steps (formulates output from the input), performing steps (create or update artifact), and reviewing steps (see if the outcome was expected or not) Artifacts An artifact contains some kind of information that has been produced, used, or modified by the process. Examples of artifacts are models, model elements, documents, source code, and executables [Kru99]. Although regular documents are artifacts, they are not recommended in RUP. Instead should documents be kept and maintained within a tool, such as Rational Rose. Each artifact must have someone who is responsible for the specific artifact. This does not mean that others cannot use or update the artifact, but they must get permission from the one who is responsible. 10

33 Chapter 3: RUP Business modeling workflow Before the implementation of the system can take place it is important to make a business model. The business model is an integrated part of RUP and uses an extended version of UML for use-case modeling in the analysis. Its purpose is to better understand the dynamics and the structure of the organization. Other goals with business modeling are to ensure that there is a common understanding of the organization and to retrieve the system requirements that are needed to ensure a friction free environment within the organization. There exist several types of business modeling and the circumstances and needs show which kind of business modeling to perform. The result of business modeling, the business model, is useful when developing business systems. One disadvantage with using a use-case model to describe the business is that it is hard to see if any use-cases have been left out and thereby maybe missing some important requirements. The reason for developing a new system can be to make the work more effective. In order to fulfill this goal, the business must be analyzed and understood. It does not matter how great the system is, as long as it does not fulfill the demand the organization has on it Requirements workflow The goals with the requirements workflow are to make sure that all requirements in the project is being gathered, define what functionality the system shall provide, limit the size of the system, and to make an agreement with the customer on what shall be developed. There are two kinds of requirements: functional requirements and nonfunctional requirements. Functional requirements are the kind of requirements we usually think of as requirements, which is requirements that expresses the functionality of the system. A functional requirement often has some input and output conditions that further describe the situation in which the requirement occurs and also explain the expected outcome of the requirement. It is the functional requirements that are in the use-case model. The nonfunctional requirements are not in the use-case model. They are instead in an artifact called Supplementary Specification. The nonfunctional requirements are requirements that consider different types of constraints. Functional requirements do not consider that. To be able to deliver a high quality product one must not only look at the functionality of the system. It is also important that other attributes like usability, supportability, reliability, and performance are taken into consideration. The nonfunctional requirements are as important as the functional requirements to the end-user. Nonfunctional requirements specify system properties and physical constraints on the requirements. It is often much harder to define the nonfunctional requirements and it can also be difficult to describe them in a manner that is easy to understand. All requirements that are not functional requirements are nonfunctional requirements. 11

34 Chapter 3: RUP How are the requirements gathered then? There exist several ways to collect, verify, and validate the requirements for a system. One way to find requirements is by looking at the business model, which contains important input for many projects. Other ways to collect information for the requirements is to use information gathered from earlier iterations or from projects that is similar to the current one. Performing interviews with the end-users is also an important source when gathering requirements, besides that is it also a way to make the end-users feel that they are involved in the project Analysis and design workflow The main purpose with analysis and design is to create a specification that is later used when implementing the system. The primary input for the analysis is the use-case model. This means that the analysis focus on the functionality of the system, an ideal picture of the system. This also means that nonfunctional requirements and other limitations are bypassed. The design is then based on the analysis and the nonfunctional requirements. The main artifact in this workflow is the design model that is like a blueprint for the system. The model describes both the dynamic structure and the static structure of the system. It usually consists of sequence diagrams, class diagrams, and state diagrams. It is often not necessary to keep a separated analysis model. Instead the rough sketch, that the analysis model is, should be transformed into the design model Implementation workflow In the implementation the design model is transformed from a model into executables, source files, binaries, and other components [Scott01]. The components are also tested as units (decreases the errors with integration) and integrated into an executable system. An important part of the implementation workflow is the prototype. One of the purposes with the prototype is to verify that the current implementation manages to fulfill the requirements. If that would not be the case, then it is good that it is found at an early stage of the implementation. The prototype that has been developed must not necessary be a part of the final system, but it can instead be developed for certain purpose and then be thrown away when it has been used Test workflow The main purpose of the test workflow is to make sure that the quality of the newly implemented system is good enough. This is a workflow that stretches throughout almost the whole project, and the earlier the errors can be found the easier and less expensive they are to correct. 12

35 Chapter 3: RUP None of roles in RUP deals with quality assurance. Instead of assigning the responsibility to a single role, all of the project members are responsible for quality of the system. The testing can divided into four stages that stretch from a small unit test all the way to a complete application test. The four stages are: Unit test stage this test involves testing of the smallest individual testable components in system. Integration test stage this is where the integrated components are tested. System test stage- here is the complete system, and its applications if the system consists of several applications, tested. Acceptance test stage the purpose of this is to decide if the system is ready for deployment. This testing is done by the end-users, or representatives of them. In these stages different types of tests can be executed. Examples of test types are configuration test, installation test, function test, performance test, integrity test, and stress test Deployment workflow In the deployment workflow the final product is delivered to the customer. It is important that the system is delivered in a professional way. There are many different activities that are to be done in deployment workflow. Some of the activities are: Beta tests Packaging the system Distribution of the system Installation of the system Training end-users Migrate the existing data Configuration and change management workflow It is important to be able to cope with several versions of a product in a project, to have a good structure of the product, and to deal with changes in a manageable way. This is what configuration and change management is about. During the lifetime of a system many versions of the artifacts in the system will exist. It is important to understand the importance of the product structure that describes the dependency between the documentation and different parts of the product. Configuration and change management are in RUP represented by a cube, the CCM cube. This cube covers three different areas: Configuration management, status and measurement, and change request management. The configuration management involves identification of the product structure and artifacts. The purpose with status and measurement is to gather data that can 13

36 Chapter 3: RUP be used later, when analysing the outcome of the project. In change request management, CRM, different types of change requests are being handled, examples of change requests are error fixes and product enhancements Project management workflow One purpose of the project management workflow is to help the project manager with staffing, planning, executing, and monitoring projects. The other two purposes is to provide a framework for managing large software projects and a framework design for managing risks [Kru99]. Not all aspects of project management are covered in RUP. Issues like managing budgets, managing people, and managing suppliers and customers are not covered. The projects in RUP are planned in two plans: the phase plan and the iterations plans. The phase plan describes the project in general. Normally the phase plan stretches over a cycle, but if necessary the phase plan can be extended over multiple cycles. There is only one phase plan per project, but there is an iteration plan for every iteration in the project. The iteration plans describe the content of the current iteration in detail. When planning the project it is important to take into consideration the possible risks. The risks can be divided into direct risks and indirect risks. Direct risks are risks that have to do with the project itself and that the project can change (for instance lack of competence) and indirect risks are risks that the project cannot affect (for instance organization changes) Environment workflow The task that the environment workflow has to deal with is to support the developing organization with tools and processes, so that they can complete their activities in a satisfying way. This involves providing and adjusting the tools that are needed, or even building new tools. 3.3 Reviews and model dependencies Most of the workflows end with a review activity. In the review activity are the meeting documents, models, and source code reviewed. The main goal with this activity is to find errors and missing functionality at an early stage. The later the faults are found the more expensive they are to correct, which means that it is very important to find the errors and missing functionality as early as possible in the project. Another positive feature with the reviews is that it can give the co-workers a possibility to learn from each other, when they are reviewing each others work. 14

37 Chapter 3: RUP Core Process Workflows Business Modeling Requirements Analysis and Design Implementation Test Models Realized by Business Use-Case Model Use-Case Model Realized by Implemented by Verified by Business Object Model Design Model Implementation Model Test Model Figure 6. The dependencies of the models. (Based on [Kru99:FIGURE 6-2]) The models shown in Figure 6 are important parts of RUP. They improve the understanding of the process. The use-case model is the most central model. As seen in Figure 6, the core process workflows following the requirements workflow have models that are dependent upon the use-case model. 15

38 Chapter 3: RUP 16

39 Chapter 4: Requirements Chapter 4 Requirements 4.1 Overview The Panthera system should be a tool that will help and guide the employees in their help desk work and also in their work to handle the matters reported to the help desk. The whole life-cycle of a matter should be easy to follow and essential information on customers, such as installation information, should be easy to access. A typical flow for a matter, as it is handled within Sema InfoSynergi today, is shown in Figure 7. It is important that different types of matters can be dealt with in Panthera, so that each matter type can be adjusted individually for its purpose. Another necessary feature is the notifications that will be sent by system. The primary reason for using notifications is to avoid that matters get stuck in the process and never get handled. The users of Panthera should have some kind of rights, since both customers and internal employees will have access to the same system and it is not desirable that the customers have the same access to the system as the internal employees. 1st line 2nd line ProdIn Matter resolving unit Testing unit ProdOut Figure 7. A General flow for a matter in SISAB. It should be possible to define the flow of the matter for each matter type, but most matter types have a general flow just like the one Sema InfoSynergi uses today (seen in Figure 7). The general flow consists of six steps: Process step 1st line 2nd line ProdIn Purpose Receive the matter. Collects as much information as possible from the reporting customer. Prepare the matter with more information. Can for instance try to recreate the problem in an internal environment. In some cases the 2nd line is able to solve the matter. For example if it is a question that the customer has asked and that it is relative easy to find the answer. From the information in the matter try to decide which 17

40 Chapter 4: Requirements Matter resolving unit Testing unit ProdOut matter resolving unit, or which member of a matter resolving unit, should get the matter in the next step. Resolve the matter with help from the information in the matter. Test if the outcome from the matter resolving unit were successful. If the testing unit feels that matter has not been resolved then the matter is given back to the matter resolving unit. Approve that the matter has been resolved. 4.2 Target Environment The Panthera system will primarily be used by the help desk at Sema InfoSynergi and since they are exclusively using PC s with Windows as operating system the system is designed for this requirement. Since the customers needed an easy and trouble free application to be able to report matters to the help desk of Sema InfoSynergi, one of the requirements was that the customers should use a web application. The basic functionality of the web application is platform independent. Supported web browsers are Microsoft Internet Explorer 4.0 or higher and Netscape Navigator 4.0 or higher. But the recommendation is to use Microsoft Explorer 5.0 or higher for full functionality. 4.3 Functional Requirements Information To be able to make the system work, there should be some background information that put the different parts together. The background information can be divided into three different categories: Product information Customer information Person information All of the categories that are mentioned above have some kind of connection between each other and with the different matter types Product information SISAB has several products on the market and in order to handle matters the right way, the information on these products must be easily accessed and upto-date. Some of the main products can be expanded with different modules. In addition to the main products and their modules there can be local adjustments. These local adjustments can be considered as unique for that customer. 18

41 Chapter 4: Requirements Customer information This part should be kept relatively simple. The customer information should contain properties that are unique for the customer. There should also be the possibility to relate users and product to the customers. Example of information that are needed: Links to the customers products. Description of local adjustments, such as which agreements that has been made with the customer. Links to the ones that are responsible for the different products. Links to the customers employees. Links to the SISAB employee that is responsible for the customer. Customer priority Links to other customers, which this customer has a relation to. Links to maintenance agreements Person information Information on how to contact the person and what position the person has is necessary. This information is linked to customer information. The person can either be a SISAB employee or a customer Matter categories Most of the work done within SISAB is performed in several, but relatively short commissions (from less than an hour up to a few days). These commissions can be divided into five different categories: Category Usually reported by Result usually sent to Error correction Customer Customer PTF library Question answer Development request Description and demands Can involve many different people from different divisions within SISAB. Important that the customers get feedback. Must follow the routines of the quality system. Statistic gathering is important for analysis. Customer Customer Fast response to customer, and often few individuals involved. Customer Other category An Idea from Stored for later evaluation. Possible unique sale to customer. Must be able to categories requests, and also the possibility to mark requests as reviewed but not approved (do not want to mix with requests that 19

42 Chapter 4: Requirements Invoice complaint an employee Customer Customer (and invoice system) not yet have been reviewed). The one who is responsible for the economics must be able to see which invoices there are complaints on, before a 2 nd invoice is sent out. Workorder Employee Employee One employee (usually a manager) tell another to perform a task, which often is time limited. Table 1: SISAB s five different matter types. The categories described in Table 1 are the commission types SISAB has today. In the future this may change and thereby additional types of matters can be necessary. Therefore should there be the possibility to define new categories. The information that is needed in the new categories may differ greatly. That is why it is only necessary to provide the most common types of information (such as name, date and so on) when creating new types of matters dynamically. Each type of matter has a standard process, but matters can of different reasons differ from the path of the standard process. That means that the process path of the matter should not be locked, it should instead be individually adjustable for each matter. It is not sure that a matter is categorized under the correct category when it is reported, and that is why matters must be able to be transformed from one type of matter to another. It is possible that similar questions arise. There should therefore be a FAQ (Frequently Asked Questions) where these questions are answered. This FAQ should be easily accessible by all users of the system System users There should be user groups, actors, which will limit the access for the users to certain parts of the system (For example to disallow the regular user to perform administrator tasks). These groups should stand as templates for the rights that the future users will have. There should also be the possibility to configure these rights for each user individually. All of the user groups may not be used today, but in the future as the company grows they may be necessary. Later in this report these groups will be referred to as actors of the system. Group Customers Description Should be able to report matters, from all categories (see Table 1) except workorders, and follow their reported matters. The customers should also have the possibility to edit the information on the company that they work for. Example on information may be 20

43 Chapter 4: Requirements Employees Developers Support personal Managers Administrators contact person, address etcetera. Should be able to report all types of matters, including workorders, and watch all reported matters, but can only watch the work orders that are involving the employee. In addition to that, the employees should have the opportunity to look at information on all other users, the companies products, and all the companies in the system. The employees should also be able to configure when they are to be informed concerning workorders that they are involved in. Employees can also be assigned a workorder, which they can alter the information on. The developers can do everything that an employee can do, but they can also be assigned to all types of matters (not only workorders, like employees). They can also change the information on these matters. Can do everything that a developer can do. The support personal can also add new FAQs, modify the process steps in the different matters, send notification to customers, add new customers and edit old customers, add workloads, and assign users to workloads. In addition to rights of the developers, the managers can also study the backlog, create statistical reports, and watch all workorders in the system. The administrators can do everything that the other users of the system can do. In addition to these rights, the administrators should have other rights. The administrator should be able to add new users, edit current user and delete old users. The possibility to add new types of user groups should also exist. The administrators should also be able to configure the rights of these user groups, and remove user groups if necessary. The administrators should also be responsible for adding product and company information to the system. If there is a need for other categories of matters, the administrators should be able to define and edit these categories. Table 2: The six original user groups Workload A user of the system can be a member of a group. There should be no restriction of how many groups a user could be a member of. The main reason for creating groups is to simplify the handling of the matters. When being a member of a group all the tasks performed by an individual user are not linked to the user, but to the group. From now on a group will be called a workload. 21

44 Chapter 4: Requirements Every workload has a responsible, a workload responsible. The use of workloads will also make it possible to create a schedule between different workloads, if they are supposed to be responsible for a certain task at some interval. The workload can also have an internal schedule for rotation amongst the members of the workload, which will decide which member will be the responsible for the workload for the time being Notification Notification is an important part of the system. Notifications are used to inform system users of events that have occurred. They can also be used as reminders for matters that have not been taken care of. It is sufficient if these notifications will be sent via , but the system must be developed so other communication forms, such as SMS and fax, may be added in the future. Type Description Recipient New matter The user that is assigned to a new matter is notified about the new matter. matter. Information Remainder Escalation A user can be notified at different events, for example when a matter is closed. The owner of matter or the workload responsible (in case a workload is assigned as the current owner of the matter) is reminded, when his/hers matters have not been attended within a certain time (the time should be individually adjustable, both per user group, process step, and per matter). This user should receive information about all the matters that the user currently is assigned to do. A user (for example a manager or coordinator) is notified that a matter is lying still during a long period of time (individual adjustable, just as the notification time for the remainder) without anything happening. Table 3: Types of notification. Only the user that is assigned to the new This depends on type of matter, per process step, per individual matter, and so on. Only the owner or the workload responsible that is assigned to the matter. Depends on the matter type, the process step, the individual matter, which customer reported the matter, and so on. 22

45 Chapter 4: Requirements The notification messages should be extremely configurable. There should be a standard notification for each process step in each matter type. The notifications can be sent to the following types of handling officers: User Workload (Each workload must have at least one user assigned as responsible for it. Otherwise matters can be left unattended forever. Examples of workloads today are ProdIn and ProdOut) Depending on the matter (Can for example be a customer responsible or the customer that reported the matter) Notification settings The settings for notification processes should be set per process step. Each process should have its own profile for notification. This profile contains when and how different handling officers will be notified. For instance should it be possible to set that the handling officer wishes to receive notification by for New matters if the priority of the matter is equal or larger to 3 and notification by SMS (not a requirement, but should be considered) if the priority is 1 for the new matter. It should be possible to override these notification settings for an individual matter. For example if an employee has promised a customer a change in functionality, then the employee may want updates on the progress of the matter Process progress When a matter has been handled at the current process step, it is ready for the next step in the process. Depending on the outcome of matter handling, the next step in the process may differ. In Figure 8 it is displayed how the next process step is chosen. The handling officer sends it back to the previous step in the process. For example if the handling officer feels that the matter is too poorly prepared. Previous step The handling officer sends it forward to the next defined process step. There may exist many possible paths to proceed with the matter. Next step Report matter Process step Resolved matter Completed Change matter type Annuled The handling officer feels that the matter is placed in the wrong category, and therefore changes the matter type to a matter type that the handling officer feels better describes the matter. Figure 8. How the next process is chosen. 23

46 Chapter 4: Requirements Every step in the process must be logged. This will make it easy to see when someone did something with the matter. And also which user did something to with the matter Priority Every matter shall be assigned a priority on a scale from 1 to 5, where 1 is the highest priority. The default value should be 4. This priority will be used when assigning processing time and setting notification time. Every company shall be assigned a priority on a scale from 1 to 4, where 1 is the highest priority. Just like the priority for matters the priority for companies will be used when assigning processing time and setting notification time. 4.4 Non-functional Requirements NF 1: Usability The layout of the application, which will be used within the company, should be built in such way that the users can fast and easily switch between different parts of the system. The users should be able to do their work faster than it is done in the current system. The text should be easy to read against the background (for example not red text against brown background). Overall should the colors be peaceful for the eyes of the users, so that they do not have to exhaust their eyes. Today all SISAB s employees use Windows as operating system, therefore the system must run on a Windows machine NF 2: Learnability The web pages, from which the customers will be able to report and follow matters, should be constructed according to the same layout as SISAB s ordinary web pages. This will help the customers to understand that the web pages belong to SISAB. It should be easy for a customer that is not used to Panthera to use the web version. Panthera should inform the user in an informative manner, for example about what mistake that has been made and how to correct it NF 3: Performance SISAB s users must have fast access to the information in the system, since they must be able to quickly respond to the customers. It should not take more than one second before the request has been sent to the server. 24

47 Chapter 4: Requirements NF 4: Maintainability The system should be constructed in such manner that it will be easy to expand. This means that if the surroundings of the company change, it should still be easy to configure the system so that it meets the company s current demands. The database must be accessible by all users. The database must provide the necessary features for realizing the system. There must also be the possibility to add more information into the database at a later stage. All the information needed by the system must fit into the database (also considering future data). All the users that work with the system must be able to do this simultaneously, without loosing so much power in the system that the performance requirement can not be satisfied NF 5: Security It is important that the information in the system only is accessible by authorized users. The data sent over the network must be protected against eavesdroppers or other unwanted activities. The security requirements must be tested and ensured every time the system has been maintained and modified. 4.5 Future plans In the future the helpdesk system could be integrated with other application, for example a project management program. This must be taken into consideration when constructing the helpdesk system. In the future the notifications will also be able to be sent with other communication media, not only . Examples of future communication media are SMS, fax, and an automatic telephone system. Other companies may in the future use the helpdesk system, and they may have slightly different demands on the system. Therefore it must be rather easy to make small adjustments to the system. 25

48 Chapter 4: Requirements 26

49 Chapter 5: Analysis Chapter 5 Analysis All actors and their associated use cases are described in this chapter. The reason for the actors and the use cases to be modelled is to describe the requirements for the system. The actors describe the different user groups that will be using the system. Each actor describes the different demands that the individual user group have on the system. The actors are defined in a certain order with inheritance, showing that the Actor 1: Customer is the base actor in the system and that every other actor in the system can do everything that the customer can do. Every actor that inherits from another actor inherits all the use cases associated with that actor as well. This means that the last actor with inheritance from another actor, Actor 7: Admin can do everything that any other actor, except the Actor 6: Scheduler, can do. We also specify the different user rights that are needed in the system. These user rights gives an idea of what rights every actor need to have to be able to perform the use cases that is associated with each individual actor. Since the work of developing this system is very time consuming we also present the different priorities that is set on each use case. When setting these priorities it is important to prioritise them both individually, but also as a group of use cases that is needed to accomplish the use cases that is most vital to the functionality of the system. The use case diagram in Figure 9 gives an overview over the different requirements that have been defined for the system. The use cases showing in the diagram are a subset of the use cases that are specified in this chapter, but they are fully describing the requirements. The use cases are named to describe the relation to the actor that it is associated with, for example has UC A1.1: Add user an A in the name right before the numbering to describe that it is associated with the Actor 7: Admin. 27

50 Chapter 5: Analysis UC C 6: Modif y own company UC C5: Modif y own user UC E1: Report workorder UC E2: View statistics UC E3: Handle workorder UC C4: View company matter Actor 1: Customer UC E4: Manage own matter specif ic notification UC C3: Report matter UC C2: Logout UC C1: Login Ac tor 2: Employ ee UC E5: View user UC D2: View agreement UC E6: View product UC D1: Handle matter UC E8: View matter UC E7: View company UC S5: Manage workload Actor 3: Dev eloper UC M1: Study backlog UC S4: Manage customer user Actor 5: Manager UC M2: Create reports UC S3: Manage notif ica tion f or proces s step Actor 4: Support employ ee UC M4: Manage agreement UC M3: View workorder UC S2: Send f eedback to customer UC S1: Manage FAQ UC A5: Manage matter ty pe Actor 7: Admin Actor 6: Scheduler UC A4: Manage company UC A1: Manage user UC Sch1: Send notif ication UC A3: Manage product UC A2: Manage actor Figure 9. Use case model describing the actors and the use cases associated with them. 5.1 Actors The actors in the system describe what the different users can do in the system. The Actor 6: Scheduler is the only actor that does not have any relation to the other actors in the system. The other actors have relations to each other where they inherit from each other to be able to associate to the same use cases. The Actor 1: Customer can be looked at as the base actor that only can perform the use cases directly associated to it. The last actor with inheritance from another actor, the Actor 7: Admin, can do everything that any other actor can do. The remaining actors both inherit from other actors, and are also inherited from. 28

51 Chapter 5: Analysis Actor 1: Customer When logged in the Customer can change the password and also change parts of their company information. The Customer is able to report a matter over the World Wide Web or by e- mail to the Actor 4: Support employee. When reporting over the World Wide Web the customer will be asked to at least give a description of the matter, give a contact person to whom SISAB will report to or contact if the description of the matter is not satisfactory. The customer will also be able to set a priority of the matter that will be evaluated by the Actor 4: Support employee when the matter reaches them. When reporting a matter the Customer will be able to choose if a notification will be sent to some Customer. After having reported a matter the customer will be able to follow the matter on the World Wide Web and see information concerning the matter. The information that can be viewed is set to be the information that SISAB allows the customer to see Actor 2: Employee An Employee can do everything the Actor 1: Customer is allowed to do in the system, but the Employee can also watch information on users of the system, information on companies that have information in the system, and the information that is stored of the products developed by SISAB. The Employee can also watch statistics. An Employee can report a workorder where a user of the system will be assigned to perform the workorder. The Employee that issues the workorder will be able to set the priority of the workorder and also follow the workorder in the process. If an Employee is assigned to a workorder the Employee will be able to set a new priority if the priority set by the issuer does not seem reasonable Actor 3: Developer The Developer is allowed to do everything the Actor 2: Employee is allowed to do within the system. The Developer can also handle a matter in the sense that the developer can at least set the priority of a matter, set the status, set the type, set the difficulty, and change who is responsible for the matter Actor 4: Support employee Since the Support Employee is the first person in the process to handle a matter the Support employee will be able to do everything the Actor 3: Developer is allowed to do. When a matter arrives from Actor 1: Customer the Support employee registers the matter. If a lot of matters reported are about the same problem the Support employee will be able to enter a FAQ that will be visible for all users. 29

52 Chapter 5: Analysis The Support employee can add customer users to the system and also edit and delete these users. The Support employee is able to send customer notifications and also to add, delete, and edit notifications for all the steps in the process. The Support employee is able to add workloads and to assign and unassign users to a workload. Every workload can also be assigned a workload responsible Actor 5: Manager The Manager can do everything the Actor 3: Developer can do. The Manager is not only allowed to follow the workorders issue by the Manager, but can follow all workorders. The Manager is also able to create reports and study the backlog. A manager can also get notifications if a matter does not follow the time limits set up for the particular matter that some user is responsible for. These notifications are called escalations and it is possible to set which user that is supposed to receive the notification in every process step for the specific matter or matter type Actor 6: Scheduler The Scheduler is an application that on regularly basis checks if a specific task needs to be performed. Examples of tasks can be either to send a mail or to update the system Actor 7: Admin The Admin can do everything the Actor 4: Support employee and the Actor 5: Manager can do. The Admin can add users to the system and delete users from the system. The user rights and the user information can be edited. Actors can also be added to the system. Actors can be edited or deleted as well. Matter types can be added, edited, or deleted. The Admin inserts the information about products and companies into the system. The company information should contain at least company name, contact persons, company priority, what products the company have purchased, and what versions of the products they are using. 5.2 Use cases The names of the use cases follow a certain structure to make it easier to associate them with the associated actor. The structure of the naming is like following UC Xx:short description of the requirement where the different parts stands for: UC stands for use case X The unique letter of letter combination that is composed of at least the first letter in the actor name, for example C for customer and Sch for scheduler. 30

53 Chapter 5: Analysis x The sequence number that the use case have within the set of use cases associated with the current actor. Use cases that are included or excluded by another will have a the same number as the parent, but followed by a notation and a sequence number that is unique within the set of use cases that are included or excluded by the same use case. :short description of the requirement A unique description of what the use case is about. The name should speak for itself. Every use case can be performed by at least one actor, but since the actors inherit from one another most use cases can be performed by more than one actor UC C1: Login The Actor 1: Customer is the base actor in the system, this means that everything the customer can do every other actor can do as well. This means that all users that have access to the system can login to it using their user name and password UC C2: Logout Every user in the system is able to logout when they are in the main view of the application UC C3: Report matter Actor 1: Customer can report a matter over the World Wide Web and that matter will later be registered by the Actor 4: Support employee. When reporting a matter the customer needs to give a description of the matter and also a priority. If the customer wants to be notified, then a notification needs to be set. It is possible to set the time to be either an event or a time limit. The matter should also be categorized to a type. Some types would also require the customer to select in what module the matter has risen. It is also possible to set the priority of the matter. The priority is a recollection of how vital this matter is to their company and how fast they wish SISAB to take action to the matter. The priority will later be evaluated by the Actor 4: Support employee that will set a priority that is weighted by the priority set in the customer information, see use case UC A4.1: Add company UC C4: View company matter Actor 1: Customer is able to follow up the matters reported which belongs to the company that the customer works for. It is possible for the customer to view all the matters reported by his/her company. 31

54 Chapter 5: Analysis UC C5: Modify own user Actor 1: Customer is able to edit the user information belonging to the customer. The information that can be edited is for example the address of the customer and the password UC C6: Modify own company Actor 1: Customer is able to edit the company information, which belongs to the company that the customer works for. The customer cannot alter sensitive information, such as contracts or other agreements made with the customer UC E1: Report workorder Actor 2: Employee is able to report a workorder. It is at least possible to set the workorder responsibility when reporting it. This will make an to be sent to the responsible actor. The priority can be set to get an idea of how to set the priorities compared to other workorders. Due-date is also set UC E2: View statistics Actor 2: Employee is able to view statistics over the reported matters. The statistics can at least contain overviews over reported and completed matters over a period of time, or over where in the process of handling a matter the handling time seem to raise UC E3: Handle workorder Actor 2: Employee is able to handle the workorder that he/she is responsible for. The employee is able to change the responsibility of a workorder. This will make an to be sent to the new responsible employee. The employee can also set the priority of an issued workorder, if the priority set by the issuer or previously responsible does not seem reasonable UC E4: Manage own matter specific notification Actor 2: Employee is able to set the properties for notification belonging to a specific matter. The notification will be sent to the employee when an event occurs or a time limit is reached UC E5: View user Actor 2: Employee is able to view the information of any user. Employee can edit its own user information UC E6: View product Actor 2: Employee is able to view the information stored about a specific product. 32

55 Chapter 5: Analysis UC E7: View company Actor 2: Employee is able to view information of any company stored in the system UC E8: View matter Actor 2: Employee is able to view all matters stored in the system UC D1: Handle matter Actor 3: Developer is able to track a matter and when the matter is found the developer is also able to handle the matter. The developer is able to set the type of a matter. A type describes what kind of matter it is, for example a question-answer, or a development request. The developer may also set a matter priority, if necessary. It is possible to set the status of a matter. Status can be graded in a scale similar to: opened, received, handling, waiting, complete, and annulled. It is also possible for the developer to give a percentage of how far the process of completing the matter has come. When handling a matter the developer is able to set the difficulty of the matter, type of matter, and also change the responsibility of a matter. When the developer changes the responsibility of the matter and passes the matter to the next step in the process, the date and time are stored together with the developer s identity and possibly a comment from the developer UC D2: View agreement Actor 3: Developer is able to view all agreements related to a specific customer and product UC S1: Manage FAQ Actor 4: Support employee is able to manage FAQs. A FAQ can be added to the system and also deleted from the system. All the current FAQs that are inserted into the system can be edited if necessary. The support employee can list the FAQs in a certain order (by title, by product) UC S1.1: Add FAQ If a question is frequently asked by the customers, then the Actor 4: Support employee can add this question as a FAQ, Frequently Asked Question. All the entered FAQ will be available for the customers over the World Wide Web. A FAQ consist of a question and an answer UC S1.2: Edit FAQ Actor 4: Support employee is able to edit a FAQ when the question or answer is inaccurate. 33

56 Chapter 5: Analysis UC S1.3: Delete FAQ Actor 4: Support employee is able to delete a FAQ, this can be desirable when a FAQ is out-of-date or unnecessary UC S2: Send feedback to customer When a matter is completed, or a milestone has been reached, the Actor 4: Support employee can send a message to the customer that reported the matter. The information in this message is entered in text field among with other information on the matter. At the moment the message can only be sent through , but in the future other communication media can be added UC S3: Manage notification for process step Each process consists of a number of steps. The Actor 4: Support employee can see how, when and to whom notifications will be sent in each process step for each type matter. Different settings are possible for different communication media UC S3.1: Add notification for process step Actor 4: Support employee is able to add a notification to a step in the process. This new notification contains information on under which circumstances the new notification will be sent UC S3.2: Edit notification for process step Actor 4: Support employee is able to edit the notification settings in a process step of a matter. Such information as notification time, notification media and notification receiver can be altered UC S3.3: Delete notification for process step Actor 4: Support employee is able to delete a specific notification in a step of a process UC S4: Manage customer user Actor 4: Support employee is able to manage the information belonging to a customer user. Amongst other things the costumer information include name, telephone, cellular phone, address, and what company they are currently working for UC S4.1: Add customer user Actor 4: Support employee is able to add a customer to the system. The customer gets a user and can therefore report and follow matters involving the company where the customer works. 34

57 Chapter 5: Analysis UC S4.2: Edit customer user Actor 4: Support employee is able to edit the information on a customer user if the data describing the customer user is incomplete or inaccurate UC S4.3: Delete custom user Actor 4: Support employee is able to delete existing customers in the system, when these customers no longer are needed. For example, if the company no longer uses the products provided by SISAB, or if the customer user terminates its employment with its current employer UC S5: Manage workload Actor 4: Support employee is able to add a workload to the system and to delete workloads stored in the system. The support employee can also modify the information of an individual workload. A workload is a group of users that need to handle matters without being looked at as an individual user. In SISAB at least ProdIn, ProdOut, 1 st line support, and 2 nd line support are workloads. Every user assigned to a workload can handle the matters assigned to the workload, but only the user(s) assigned as workload responsible will get notifications if a matter is not handled within the time limit UC S5.1: Add workload Actor 4: Support employee is able to add a workload to the system. When adding a workload the support employee needs to specify some information. The information should be at least the name of the workload. Every workload needs to have a user assigned to the workload. This workload user will then be able to handle matters, where the workload is set as responsible, as a workload user. The support employee is also able to assign a user that belongs to a workload as responsible for a workload. This user will get the notifications, which involves the matters that the workload is responsible for UC S5.2: Edit workload Actor 4: Support employee is able to edit a workload that already exists in the system. The users assigned to the workload can be deleted and new users can be added. The workload responsible can also be exchanged UC S5.3: Delete workload Actor 4: Support employee is able to delete a workload, if the workload is no longer used UC M1: Study backlog Actor 5: Manager is able to study the matters that are currently unresolved. The manager can see what kind of matters that remains unresolved and in what process steps the matters remains. 35

58 Chapter 5: Analysis UC M2: Create reports Actor 5: Manager is able to create statistic reports, which also can be printed. The reports can give the manager information on how the matter handling is proceeding UC M3: View workorder Actor 5: Manager is able to view all the workorders that are inserted into the system UC M4: Manage agreement The Actor 5: Manager is able to add an agreement to the system and delete an already existing agreement from the system. It is also possible to edit the information stored in the system concerning the agreement UC M4.1: Add agreement Actor 5: Manager is able to create an agreement that belongs to a certain customer and product. The agreement is added to the system UC M4.2: Edit agreement Actor 5: Manager is able to edit an existing agreement UC M4.3: Delete agreement Actor 5: Manager is able to delete an agreement UC Sch1: Send notification Actor 6: Scheduler is able to send notifications to users of the system if an event occurs or a time limit is passed. Every matter consists of one or more process steps and every process step has a maximum time limit that the matter should not exceed while processed. The scheduler is the application that checks if the maximum time limit in a process step in a matter is overdue. If a matter has exceeded the time limit for an individual process step the scheduler sends a notification to the users specified in the notification settings for the specific process step UC A1: Manage user The Actor 7: Admin is able to add a user to the system, but also to delete a user that already exists in the system. Every user can be edited, where the user information and user rights can be modified UC A1.1: Add user A new user can be added to the system by the Actor 7: Admin. When adding a new user to the system a username needs to be specified. The username has to be unique to the system. Along with the username a password is entered to 36

59 Chapter 5: Analysis ensure that no unauthorized person can enter the system. When adding a user the Admin need to specify the user rights for the new user UC A1.2: Edit user An already existing user can be edited by Actor 7: Admin. Examples on information that can be modified are the personal information, such as name and address, but also username, password and the user rights. The user right can either be limited or increased UC A1.3: Delete user An already existing user in the system can be deleted. After deletion the deleted user no longer has access to the system UC A2: Manage actor Actor 7: Admin is able to manage an actor. An actor can be added, deleted and edited. An actor in this system is a user that belongs to a certain group, for example a developer or an administrator. Further can the actor be looked upon as a user type with user rights that corresponds to a user rights guideline for a valid actor UC A2.1: Add actor The Actor 7: Admin can add actors. When adding a new actor an actor name needs to be specified along with user rights UC A2.2: Edit actor The actor can be edited. The Actor 7: Admin can change the name and the user rights for the actor UC A2.3: Delete actor Every actor that exists in the system can be deleted from the system by Actor 7: Admin. The actor is then no longer a member of the system. A user in the system that is specified to be a member of the actor that is to be deleted is set to another actor that is specified in the system UC A3: Manage product The Actor 7: Admin is able to add products along with information of the specific product to the system. After the product has been added to the system it is possible to edit the information on the specific product and also to change the name of the product. An already existing product can be deleted from the system. 37

60 Chapter 5: Analysis UC A3.1: Add product The Actor 7: Admin can add any product developed by SISAB, and information concerning that product. If the product is an add-on to another product, it can be associated with that product UC A3.2: Edit product Actor 7: Admin is able to edit the product information if the information for some reason is incorrect, for example when a new version is release UC A3.3: Delete product A product that exists in the system can be deleted entirely from the system. This can be practical if a product is no longer owned by SISAB or if it is no longer in use UC A4: Manage company The Actor 7: Admin is able to add companies to the system and also able to remove already existing companies from the system. When a company is added it is possible to set information on the certain company that will be of help for the employees of SISAB in their contact with the company. This information can also be edited if needed UC A4.1: Add company The Actor 7: Admin can add a company, which is a customer to SISAB, along with information concerning that company. The information should contain at least company name, contact persons, company priority, what products the company has purchased, what versions of the products they are using, and also what versions they previously have been using UC A4.2: Edit company The information concerning a company that exists in the system can be edited. The information normally includes such things as product responsible, products, special contracts, machines, and so on UC A4.3: Delete company If a company no longer is using any product owned by SISAB, or for some other reason no longer should be in the system. Then the Actor 7: Admin can delete the company UC A5: Manage matter type The Actor 7: Admin is able to add matter types to the system that will help the users to categorize the matters and force them to follow predefined process steps. 38

61 Chapter 5: Analysis UC A5.1: Add matter type Actor 7: Admin can add a matter type to the system that makes it possible for the users to categorize the matters UC A5.2: Edit matter type Actor 7: Admin can edit a matter type, for example change the name of the matter type UC A5.3: Delete matter type Actor 7: Admin can delete a matter type from the system. When the matter type is deleted, the admin can choose to keep or delete all the reported matters of that matter type UC A5.4: Define process step Each process consists of a number of steps. The Actor 7: Admin can define a standard path for each process, what different steps that are usually performed for that type of process. In each step is it possible to define, which handling officer or workload that is to be responsible for that step. It should also be possible to add a description to each process step, so that the handling officer knows what is expected of him/her. This standard path should later be used as a recommendation when the handling officer is to choose the next step in the process. 5.3 User Rights Each user in the system should have rights given to them independent of each other. The rights that can be given to a user are the following: User right Edit own company information Manage matter View all matters Report workorder View all worksorders View user information View product/company information View statistics Study backlog/create reports Send customer notification Manage FAQ Manage notification settings Manage customer user Includes use cases UC C6: Modify own company UC D1: Handle matter UC E8: View matter UC E1: Report workorder UC E3: Handle workorder UC M3: View workorder UC E5: View user UC E6: View product UC E7: View company UC E2: View statistics UC M1: Study backlog UC M2: Create reports UC S2: Send feedback to customer UC S1: Manage FAQ UC S3: Manage notification for process UC S4: Manage customer user 39

62 Chapter 5: Analysis Manage all users Manage actor Manage workload Manage matter type Manage products Manage company View agreement Manage agreement UC A1: Manage user UC A2: Manage actor UC S5: Manage workload UC A5: Manage matter type UC A3: Manage product The Actor 7: Admin is able to add products along with information of the specific product to the system. After the product has been added to the system it is possible to edit the information on the specific product and also to change the name of the product. An already existing product can be deleted from the system. UC A3.1: Add product UC A4: Manage company UC D2: View agreement UC M4: Manage agreement Table 4: User rights needed for the use cases. 5.4 Priority Each non-functional requirement and use case is given a priority between 1 and 3, where: 1 Absolutely necessary. 2 Should be implemented. 3 Implemented if it fits within the time limit. The foundation of the priorities is based upon which requirements that should be implemented to be sure to get a usable system. Which priority each requirement was assigned were decided together with Sema InfoSynergi Non-functional Requirements Priority Non-functional Requirement Priority NF 1: Usability 1 NF 2: Learnability 2 NF 3: Performance 2 NF 4: Maintainability 1 NF 5: Security 2 Table 5: Priorities of the non functional requirements Use Case Priority Use case Priority UC C1: Login 1 UC C2: Logout 1 40

63 Chapter 5: Analysis UC C3: Report matter 1 UC C4: View company matter 1 UC C5: Modify own user 2 UC C6: Modify own company 2 UC E1: Report workorder 2 UC E2: View statistics 3 UC E3: Handle workorder 2 UC E4: Manage own matter specific notification 2 UC E5: View user 3 UC E6: View product 2 UC E7: View company 2 UC E8: View matter 1 UC D1: Handle matter 1 UC D2: View agreement 3 UC S1: Manage FAQ 2 UC S1.1: Add FAQ 2 UC S1.2: Edit FAQ 2 UC S1.3: Delete FAQ 2 UC S2: Send feedback to customer 3 UC S3: Manage notification for process step 2 UC S3.1: Add notification for process step 2 UC S3.2: Edit notification for process step 2 UC S3.3: Delete notification for process step 3 UC S4: Manage customer user 2 UC S4.1: Add customer user 2 UC S4.2: Edit customer user 2 UC S4.3: Delete custom user 3 UC S5: Manage workload 2 UC S5.1: Add workload 2 UC S5.2: Edit workload 2 UC S5.3: Delete workload 3 UC M1: Study backlog 3 UC M2: Create reports 3 UC M3: View workorder 3 UC M4: Manage agreement 3 UC M4.1: Add agreement 3 UC M4.2: Edit agreement 3 UC M4.3: Delete agreement 3 UC Sch1: Send notification 1 UC A1: Manage user 2 UC A1.1: Add user 1 UC A1.2: Edit user 2 UC A1.3: Delete user 3 UC A2: Manage actor 3 UC A2.1: Add actor 3 41

64 Chapter 5: Analysis UC A2.2: Edit actor 3 UC A2.3: Delete actor 3 UC A3: Manage product 2 UC A3.1: Add product 2 UC A3.2: Edit product 2 UC A3.3: Delete product 3 UC A4: Manage company 2 UC A4.1: Add company 2 UC A4.2: Edit company 2 UC A4.3: Delete company 3 UC A5: Manage matter type 3 UC A5.1: Add matter type 3 UC A5.2: Edit matter type 3 UC A5.3: Delete matter type 3 UC A5.4: Define process step 3 Table 6: Priorities of the use cases. 42

65 Chapter 6: Design Discussion Chapter 6 Design Discussion 6.1 System Environment SISAB s current helpdesk system, InfoLink, runs in Lotus Notes. This may be an advantage if the users are familiar with the environment. But since SISAB is currently working in a Windows environment the users would probably be just as familiar with a system developed for usage outside of Lotus Notes. A great advantage with such a system is that the system can be distributed as an independent system. Another advantage is that the system will be easier to maintain if it does not reside within another application. Therefore we think that it would be better with a system that is situated outside of Lotus Notes or any program that makes the helpdesk program dependent, such as Microsoft Access. Another alternative would be to have the helpdesk sited on the web, but this is not really an option when this would have made the system to slow. The system needs to be fast since it will be an important part of the support personal daily work. 6.2 Programming Language This is a very large project, with a tight schedule, and therefore we would like to speed up the development as much as possible. In order to improve the usability of the system is it important that a well-design user interface is made. It is not desirable to spend a great part of the implementation time with building up the user interface. That is the reason why we would like to use a Rapid Application Development (RAD) tool. Which, among other things, means that you can design the user interface and assign properties to objects without writing any code [ArEk00]. This makes it easy to create the ground for the application, which saves a lot of time. The system can be developed in many different types of programming languages and environments, such as Visual C++, Borland C++ Builder, Visual Basic 6.0, Visual Basic.NET, C#, and Borland JBuilder 5. We decided at an early stage that the first alternative for developing the helpdesk system, Visual C++, was not really an option in our case since we wanted to design the system with a RAD tool and there are not so many benefits with Visual C++ that weighs up for that is not a RAD tool. Neither of us had used some of the other alternatives in a way that would make it more preferable against the others and none the alternative had some functionality that would make it the 43

66 Chapter 6: Design Discussion obvious choice. Therefore we decided to narrow down the number of alternatives to the RAD tools that SISAB has license of, which are Visual Basic 6.0, Visual Basic.NET, and C#. Both Visual Basic.NET and C# is part of Microsoft s new.net platform (see more in 6.5.NET Framework).There are a lot advantages with choosing one of those language instead of choosing Visual Basic 6.0. There are only really two advantages with Visual Basic 6.0, those are that more documentation can be found and the developing environment is more reliable. But when.net is released, expected release is sometime in the spring of 2002, the environment will probably be more reliable than today and documentation will not be a problem either. One of the big advantages with the.net platform shows when it comes to expanding the system. It does not matter what language we choose to develop the system in since any other.net language can be used for expanding the system. The choice stands between Visual Basic.NET and C#, and when we got the opportunity to attend a course in Visual Basic.NET the choice became obvious. So the Panthera system will be developed in Visual Basic.NET. The new Visual Basic.NET differs in many areas from Visual Basic 6.0. Visual Basic.NET is for example truly object-oriented and the levels of type safety are much higher. To be able to write the best code possible in Visual Basic.NET you probably must use features that are not supported in the previous versions of Visual Basic [Pat01]. Also the Visual Basic.NET syntax differs from the previous versions. Overall it seems like that Visual Basic.NET will be a step forward in the right direction for Microsoft, with all the benefits of the.net platform, such as the potential to run Visual Basic code on other platforms (i.e. Pocket PC). 6.3 Web One of the goals with SISAB s helpdesk system is that customers should be able to report and follow their matters over the web. Today SISAB are using ASP, Active Server Pages, as their way to view and modify data dynamically over the web. ASP has the features that are required for implementing the demands of SISAB s helpdesk system. But since the rest of the system will be developed in.net, so will also the web part of the system. As mentioned later, in 6.5.NET Framework, is Internet an important part of the.net platform. The web features in.net is accomplished through ASP.NET, therefore will we use ASP.NET when we develop the web part of the system. Some of the advantages with ASP.NET is that the code will be easier to read, easier to maintain, and easier to integrate with rest of the system. 6.4 Database Today SISAB has the licenses to three different databases: Microsoft Access 2000, SQL Server 7.0 and Oracle 8. SQL Server 7.0 and Oracle 8 are examples of a Database Management System, DBMS, which are constructed to handle many concurrent users and large amounts of data (SQL Server 7.0 can handle terabytes of data). Access 2000 is a desktop application, which 44

67 Chapter 6: Design Discussion builds on the default Microsoft Jet 4.0 engine or Microsoft Data Engine (MSDE). The Jet engine has some limitations that make it inappropriate for bigger systems. It supports only 2GB of data and 255 users at the maximum [CNET00]. Although 255 users are supported it is not recommended to have so many, simultaneously users is appropriate if the system should work smoothly. Even though MSDE has lost many of the disadvantages with the Jet Engine it has not lost all. MSDE also only supports 2GB of data [SQLMAG]. This together with other limitations in MSDE, such as it is only recommended for a handful concurrent users, makes it inappropriate for our helpdesk system. As we see it both SQL Server and Oracle has what it takes when it comes to the features that are required for SISAB s helpdesk system. Both DBMS s supports SQL (Structured Query Language), multiple concurrent users, large storage space and much more. Both SQL Server and Oracle have some specific features that are not supported by the other system, but none of these features are so important that it makes that DBMS the obvious choice for our solution. We have never used or worked with neither of the systems, and that is why we will have to go with the system that is the easiest to use for novice user like ourselves. According to a test made by American Institutes for Research (AIR) [AIR99] seems it like SQL Server 7.0 is easier than Oracle 8i to use, even for professional database administrators. Oracle demands more from the developers and if you are an inexperienced developer you can get yourself into trouble with an Oracle solution of the problem [TaMi00]. Therefore we think that SQL Server will make the best DBMS for SISAB s helpdesk system. Since SQL Server 7.0 was released another version of SQL Server has been released, SQL Server The question is then if there are any new features in SQL Server 2000 that will be of used when developing the helpdesk system. The new features in SQL Server 2000 include (taken from What s new in SQL Server 2000 [WNSS00]): Built-in support for XML o XML documents can be returned from the relational database engine o XML can be use to insert, delete and update data Full-text search o Querying can be made in both unstructured and in structured documents. User-defined functions o Can create Transact-SQL functions that can return a table or a scalar value. Previously only Transact-SQL procedures where supported. Indexed views o Can improve performance if certain joins or aggregations are performed frequently INSTEAD OF trigger 45

68 Chapter 6: Design Discussion o Instead of the triggering action (i.e. INSERT, DELETE or UPDATE), an INSTEAD OF trigger can be executed. Cascading Referential Integrity Constraints o Makes it possible to update or delete values in related tables automatically when values that contain foreign keys are updated or deleted. As with most upgrades of a product other parts of the product has been improved, so also with SQL Server SQL Server 2000 has higher reliability, higher security and better scalability than the previous versions of SQL Server. The improved features in SQL Server 2000 make it a better product than SQL Server 7.0, but is SQL Server 2000 really worth the upgrading cost if you already have a license for SQL Server 7.0? For SISAB s helpdesk we do not think it is necessary to use the newer version than SQL Server 7.0. The investment of a newer version would probably increase the performance of the system, but we feel that SQL Server 7.0 can handle the requirements that SISAB has today. In the future SISAB may want to upgrade their DBMS to a newer version as their expectations on the system grows. 6.5.NET Framework.NET is a new platform from Microsoft. The official version of.net was released in the spring of The.NET is a platform for building and running distributed applications. During the development of.net the goal has all along been to simplify component development and deployment, and to make it possible to achieve higher interoperability between programming languages than before. It involves features like tools (Visual Studio.NET) and a programming model that enables building of application and web services..net Framework is another name for the programming model in.net, which consists of the Common Language Runtime (CLR) and the class libraries. When first looked upon,.net seems very similar to other already existing architectures, such as Java. Although impressions and ideas have been taken from these architectures, it is also as simple to find new architectural design decisions in.net that has never been seen before. One of the most radical architectural decision is that.net is the first platform where considerations for Internet had been part of the development plan all the way, from the ground up. Since the Internet and distributed applications are an important part of.net they have made the use of such functionality very easy. 46

69 Chapter 6: Design Discussion The figure below (Figure 10) shows an overview of the.net Framework ASP.NET Windows Forms Web Services Web Forms Controls Drawing ASP.NET Application Services Windows Application Services.NET Framework Base Classes ADO.NET XML Threading IO Net Security Diagnostics Etc. Common Language Runtime Diagnostics Common Type Lifecycle Monitoring Figure 10: An overview of the major components in.net Framework. (Based on [HoLh01]) Common Language Runtime Common Language Runtime (CLR) is a fundamental piece of the.net Framework. It is here the key functionality is found and it is also CLR that manages all runtime aspects of the code. Regardless of what programming language a.net component is written in it is executed within the same runtime (CLR) [Low]. The CLR manages much of the object s behaviour, and that is why code aimed to CLR is called managed code. All languages with Visual Studio.NET, such as Visual Basic.NET and C#, produce managed code. There are also about 20 other languages which in the near future will have compilers that produce managed code, including languages like Perl, Cobol, and Eiffel. To be a.net language all constructs in the language must compile to types that are CLR-compatible. One key reason why it is possible with the multiple language support that CLR provides is the Common Type System (CTS). CTS define all data types provided by CLR, how they behave and their structure. All data types supported by CTS are in fact objects themselves, which means that every type in.net is derived from the System.Object class. Since every language uses the same type library, there is no need of type conversions between languages. In fact there are no restrictions between.net languages. It is for example possible in C# to use an object written in Visual Basic.NET, whose base class is written in Cobol. The compiling in.net is made in two phases. In the first phase the code, written in any.net language, is compiled into a general language. The general language is called Microsoft Intermediate Language (MSIL), often 47

70 Chapter 6: Design Discussion referred to as IL, and it is similar to machine code. The IL is common for all.net language and equivalent constructs should produce the same IL no matter what.net languages that are used. Because all languages produces very similar code it is in most cases not necessary to look at the language choice, when performance is an issue [HoLh01]. The second phase of the compiling is normally carried out at runtime, when the first call to IL code is made. The IL is compiled to native code and executed by the.net CLR. The second phase of the compilation is often only performed once during the lifetime of the application, because once compiled the native code can be cached for later use NET Framework Base Classes There are hundreds of classes and interfaces in the.net Class Framework, also referred to as.net base classes, which are implemented in the.net Framework. This makes it very easy to integrate them with programs developed in.net. Since the base class libraries are a part of the.net Framework individual applications do not need to install commonly used functions separately, which simplifies the deployment of the application. As mentioned above, all data types inherit from the System.Object class. It is not only the data types that does that, all classes inherits in some way from that class, directly or indirectly. Among these classes in the.net Class Framework exist most of the standard functions that a programmer needs. Here are some examples of functionality that reside in the.net Class Framework: ADO.NET, which includes data access and data manipulation. Application security. Network communication, with different protocols. Interfaces against the outside world, such as Web Forms, Windows Forms and so on. Input/Output, for example from files. XML functionality, including parsers. The classes in.net Class Framework are divided into different namespaces. The functionality gathered within a namespace can in some way be grouped together. All classes in the.net Class Framework is found within the System namespace. Deeper down in the namespace structure there will be more specific functionality, for instance classes that communicates with a specific type of database. 6.6 Security Since the information stored in the system is mostly confidential information, it is important that the security level of the system is high. To achieve this high security level all information will be sent over Secure Sockets Layer (SSL). It is Possible that the data sent between the Windows clients and the 48

71 Chapter 6: Design Discussion web service will use some existing security solution, such as a VPN (Virtual Private Network). This can also be the case for the data sent between the business service and the data service. A great disadvantage of using SSL instead of sending the data in clear-text is that it is significantly slower than using SOAP (Simple Object Access Protocol) alone [Kir01]. In our case this disadvantage must be accepted, since it is more important that no eavesdroppers or other dishonest people can get the information in clear-text. Another important security issue is that not everyone should be able to use the web service. First the user must authenticate himself/herself against the web service through logging on to the system. This can be done in several different ways, but most of them are out of the question because there will be both internal and external users. If all the users who will use the system were internal users, then it would be best with automatic logon via Integrated Windows Authentication or some other technique using Windows NT Domains or Active Directory accounts for authentication. But now there are system users that are customers and it would be a lot of extra work for the system administrators to add and delete these users. When choosing an authentication method for a programmable web service, it is important that the method can be easily used and that it does not require the users to input credentials [KeJe01]. A technique that meets those criteria is the technique that uses Windows accounts for authentication, for example Integrated Windows Authentication. Other authentication techniques, such as Certificate Mapping and custom authentication, also meet those criteria. The disadvantage with the Certificate Mapping authentication is that it requires that every user have a certificate supplied, and therefore it is not appropriate for the Panthera system that will have many different users at many locations. The custom authentication can be implemented in many different ways, but the general advantage over the other techniques mentioned above is that there is no need for a separate Windows account for each user. This is the technique that will be used for the web service in the Panthera system. There will be a login method that will be used to logon the user to the system. This method will return the user id and a session key. Those together will be used to authenticate the user when using the other method in the web service. The session key will have a valid time, and this valid time will be renewed for every call the user makes to the web service. If the user wants to use the system after the valid time of the session key has expired, then the user must logon to web service again. The users that are logged on will be held in a table in the database. To avoid that every method in the web service have to take the user id and the session key as parameters, these will instead be sent in the SOAP header (see more in ). This is one of the reasons why SSL should be used for every call to the web service, because without any encryption the SOAP header is sent in clear-text. 49

72 Chapter 6: Design Discussion 50

73 Chapter 7: XML Chapter 7 XML As seen in Chapter 7 Design Discussion we have come to the conclusion that the Panthera system will be developed in Visual Studio.NET. Since XML is integrated in.net, this chapter is dedicated to explaining and discussing XML. 7.1 History The history of XML, Extensible Markup Language, began in 1974 when Charles Goldfarb, Ed Morsher and Ray Lorie invented SGML, Standard Generalized Markup Language [BD00]. SGML, which is a text-based language, was developed to make it easy for computer programs to exchange information between each other. SGML adds metadata into a document to mark up data in a self-describing way [CGH+00]. Self-describing means that one should easily be able to see the meaning of the content, i.e. <FirstName>John</FirstName> says that John is a first name. SGML was designed to be able to mark up data for any purpose. Therefore SGML is a very complex language, but also very powerful. HTML, HyperText Markup Language, is an application of SGML. The purpose of HTML is to display information and to create links between different information sources. HTML only describes the presentation, not the data. Since SGML is to complex to exchange over the web and HTML is limited to viewing documents in a browser, something less complex than SGML was needed to interchange data over the web. This is why XML, which is a subset of SGML, was developed. When W3C, World Wide Web Consortium, in 1996 created XML they took into consideration the benefits and the weaknesses of SGML. The result of their work became a standard, XML 1.0, which has the power of SGML, but without the complex and rarely used functions [TMC 00]. The design goals for XML were according to W3C s standard, Extensible Markup Language (XML) 1.0 (Second Edition) [BPS+00]: 1. XML shall be straightforwardly usable over the Internet. 2. XML shall support a wide variety of applications. 3. XML shall be compatible with SGML. 51

74 Chapter 7: XML 4. It shall be easy to write programs which process XML documents. 5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. 6. XML documents should be human-legible and reasonably clear. 7. The XML design should be prepared quickly. 8. The design of XML shall be formal and concise. 9. XML documents shall be easy to create. 10. Terseness in XML markup is of minimal importance. One of the great advantages with XML is that it is possible to create own tags with XML. In HTML, which is a fixed markup language, there exists a fixed set of tags [MCG98], which are used to construct the HTML document. There is no limitation with a fixed set of tags in XML, but instead own set of tags can be defined. This makes the language much more adjustable, and thereby makes it easy to configure the XML documents for different purposes. This is also the reason why the language is called extensible. 7.2 XML Basics An XML document is designed to be used where ever it can be needed [CGH+00]. For instance, the same XML document can be used to show graphs in one program, edit the information in the XML document in another program and view the same data in a web browser. Despite that there are many media where XML can be of use, the only area where XML really has made a breakthrough is within the Internet world and the World Wide Web, www. document tableofcontents section appendix heading content Figure 11: An example of the logical structure of a XML document. All XML documents consist of a number of various elements that are grouped into a hierarchy. There are different relations between the elements in the hierarchy. The usual relations are parent/child and sibling/sibling relations, but also other family metaphors such as ancestor and descendant are used. If an XML document follows grammatical rules that are outlined in the XML 1.0 specification [BPS+00], it is said to be well-formed XML. To achieve this, the elements in the XML document must follow certain rules. 52

75 Chapter 7: XML Elements rules To be able to understand the basic concepts of XML, one must understand the element rules. An XML document must have exactly one top-level (root) element. If a document would have more than one root element, then it would not be well-formed. If an XML document was based on the logical structure from Figure 11, then it would have the document element as the only root element. That means that it cannot have two document elements in the XML document. Every element must have a start-tag and an end-tag (for example see the section element in Figure 12). The data that describes the elements goes between the start-tag and the end-tag, but if there is no data to describe the element one can end the element in the start-tag, see the content element in Figure 12. Elements can also have attributes associated with them. These attributes are meant to more closely describe the element. For example if we take the heading element from Figure 11, and we can have an attribute font for describing which font the heading should have (see the heading element in figure 4.2). Notice that the value of the attribute must be surrounded by quote characters ( or ). One reason for using attributes instead elements is that if you know that you have a value that most applications will not use, but some applications need. Others think that you do not need attributes at all, since they add an unwanted complexity to the language [CGH+00]. The tags in an XML document should be properly nested. This means that the children are closed with an end-tag before the end-tag of the parent. It is also means that all sibling elements are closed before the next can be opened. <section> <heading font= Arial >Heading 1</heading> <content /> </section> Figure 12: Example of proper nesting. The tags in XML are all case-sensitive, which means that <Document> differs from <document>. There are also some restrictions when naming tags: A tag name must start with a letter or _ character. After the first character also numbers and the - character and the. character are allowed. A tag name may never start with the letters xml, not even if they are mixed (for example Xml or XmL). Since it is up to the developer to decide the name of the elements, different developers can give elements with different meanings the same name. For example differ the representation of date format in different parts of the world. 53

76 Chapter 7: XML Processing Instructions Processing Instructions, PIs, can be used if it is necessary to embed application instructions into the XML document. The instructions are not part of the XML document, they are instead sent to the application. <?PITarget PIData?> Figure 13: Syntax of a processing instruction. The syntax of a PI is shown in Figure 13. The PITarget is the application that will receive the PI and the PIData is some data that will be sent to the application. PIs are rarely used, but it can be a good place to put information that you want to be passed on the application XML Declaration The purpose of an XML declaration is to label XML documents so everyone can see that it is an XML document. Along with the XML declaration comes the possibility to give extra information to the parsers (see more about parsers in 7.2.5), such as if the document is encoded in specific way and if the document may depend on other files (for example DTDs, see ) or not. <?xml version= 1.0 encoding= UTF-8 standalone= yes?> Figure 14: Example of an XML declaration. As one can see in Figure 14 is the syntax of the XML declaration is very similar to the one of PI, <??>. Despite of that is the XML declaration not a PI Valid XML When an XML document follows the XML 1.0 specification it is said that the document is well-formed. Often this is not enough. This because there are many ways to store the same information, but the XML syntax for these ways can be completely different from each other. This leads to problems when applications want to share their information with each other, application A does not understand the XML document constructed by application B and vice versa. Therefore there has to be ways to formally describe, which format the data in the document should have. In XML this is done with the help of validation rules. The syntax, which is specified in the XML recommendation for these rules, is called Document Type Definition (DTD). DTDs have some limitations (see ) and therefore there has come a new way for specifying validations rules, XML Schema. XML Schema is since also a W3C recommendation [XMLS]. It is optional to include a DTD or an XML Schema in the XML document. But an XML document is not valid, if it does not follow the validation rules that accompany the document and at same time is well-formed. 54

77 Chapter 7: XML Document Type Definitions DTDs, Document Type Definitions, are XML documents that define the rules for the structure of XML documents. DTDs describe: Which elements that may exist in the document. Which elements that can contain other elements. In which sequence and how many elements are allowed. Which attributes the elements can have. <!DOCTYPE NAME CONTENT> Figure 15: The syntax of the Document Type Declaration. To associate a DTD with a document the Document Type Declaration is used. The Document Type Declaration is often referred to as the DOCTYPE declaration. The declaration consists of two parts (see Figure 15): the NAME, which should be equal to the name of root element of the XML document that will be described, and the CONTENT. The DTD content can be divided into two subsets: the internal subset, and the external subset. With the internal subset the DTD is included within the actual document. In Figure 16 there is an example of an internal subset of a DTD for the XML document in Figure 11. One of the greatest benefits with external subsets is that you maintain the DTD at one location, and therefore it will effect all applications that use that DTD. <!DOCTYPE document [ <!ELEMENT document(tableofcontents?, section+, appendix*)> <!ELEMENT tableofcontents (#PCDATA)> <!ELEMENT section (heading, content)> <!ELEMENT heading (#PCDATA)> <!ATTLIST heading font CDATA #IMPLIED > <!ELEMENT content (#PCDATA)> <!ELEMENT appendix (#PCDATA)> <!ATTLIST appendix name CDATA #REQUIRED > ]> Figure 16: Example of a DTD included in the XML document. 55

78 Chapter 7: XML The syntax for a DTD element is: <!ELEMENT ELEMENT-NAME CONTENT> Where the ELEMENT-NAME is name of the element (tag) and CONTENT specifies the restrictions and the rules for that element. It can for instance be specified that the element should be able to contain one element, or that the element will not be allowed to contain any text or child elements. The cardinality operators make it possible to specify how many instances of child elements that an element may have. The four cardinality operators are: [none] One and only one instance of that child element.? Zero or one instance of that child element. * Zero or more instances of that child element. + One or more instances of that child element. The document element in Figure 16 can have zero or one instance of the tableofcontents element, one or more instances of the section element, and zero or more instances of the appendix element. The syntax for adding attributes to a DTD element is: <!ATTLIST ELEMENT-NAME ATTRIBUTE-NAME TYPE DEFAULT-VALUE > Where the ELEMENT-NAME is the name of the element, which the attributes will belong to. The ATTRIBUTE-NAME is the name of the attribute, TYPE describes which content it can have (there are ten different types defined in XML 1.0), DEFAULT-VALUE refers to the default value of the element. It is also possible to specify if the input of the attribute is required (#REQUIRED), optional (#IMPLIED) or fixed (#FIXED). Fixed means that the attribute only can have certain predefined values that also are defined in the DTD. <?xml version= 1.0 encoding= UTF-8 standalone= no?> <!DOCTYPE document SYSTEM URL to external subset of the DTD [ Internal subset of the DTD ] > <document> </document> Figure 17: A DOCTYPE declaration that uses both internal and external subsets. One of the limitations with DTDs is that there can only be one DOCTYPE declaration in a single XML document, but this declaration can be divided into an internal subset and an external subset, see Figure 17. The DTD in the external subset can be overridden by the internal subset, this makes it possible 56

79 Chapter 7: XML to have a common template in the external DTD and then make local adjustments. There are some other limitations with DTDs that in some cases can make DTD inappropriate for the current solution. These limitations include: Weak data typing. Is not extensible. Does not work well XML namespaces. Despite of these limitation, DTDs has been the safe way to go since DTDs is a recommendation from W3C all validating parsers are able to use DTDs XML Schema An XML Schema, like DTDs, defines the structure of an XML element and what elements, and in which combinations they, are allowed. An XML Schema is functionally equivalent to a DTD [XMLG]. The XML Schema has some extended functionality that makes it more powerful than the DTDs, such as: Inheritance Strong data typing (all common datatypes) Extensibility Strong content model (can describe the content more precise) Dynamic schemas The reason behind many of the benefits, such as extensibility, with XML Schemas compared to DTDs is that XML Schemas themselves are wellformed XML documents. Since XML Schemas are XML, any XML tools that are used for viewing and altering usual XML documents can also be used for XML Schemas. There are 44 built-in datatypes in XML Schema [NOR01]. One of the advantages with XML Schema is that it possible to derive new datatypes from existing datatypes (built-in or derived). These derived datatypes must consist of well-formed XML, which also must be valid according to their datatype definition. One of the more important features in XML Schema is XML Namespaces, which allows elements with the same name to be unique. This is accomplished with help from namespace prefixes XML Parser Almost all XML applications are built on top of a parser. The parser can be seen as the bridge between the XML document and the application that processes that XML [XMLD], see Figure

80 Chapter 7: XML XML document XML Parser Application Figure 18: The XML parser as the bridge between the XML document and the application. The parser is responsible for going through the XML document and make sure that it follows the XML syntax. XML parsers can be divided into two categories: non-validating parsers and validating parsers. Non-validating parsers check if the document is well-formed and report all violations of the XML specification. Validating parsers do the same as non-validating parsers, but they also check the documents validating rules to see if the document is valid or not. 7.3 XML in.net In the Microsoft.NET Framework it has been made much easier to use XML when developing applications. One of the reasons for this is that much of the integration made internally in the.net Framework is accomplished with XML. Both ADO.NET and ASP.NET uses for instance XML as the transmission and persistence format for data [MaSe01]. Through this approach.net Framework is compatible with other systems, not necessary Microsoft systems, which also use XML. Besides from the internal use of XML in the.net Framework there are several classes that make it very easy to work with XML and XSLT stylesheets. These classes reside in the System.Xml namespace and the usage of them makes working with XML as easy as working with regular classes. This involves creating new instances of classes, changing properties, and making method calls [MaSe01] DataSets Information in a system is often stored in relational databases, but with ADO.NET it does not matter if it is stored in a relational database or as native XML. The reason for this is, as already mentioned above, that ADO.NET uses XML as internal format. Since all data in ADO.NET is stored as XML, it is obvious that is very easy to get the data represented in ADO.NET into XML and vice versa, which means that it is also easy to transform an XML document into ADO.NET. A DataSet can be seen as an object-oriented shell against the XML document that is stored like [ADBVB01]. 58

81 Chapter 7: XML There are many different objects in the ADO.NET object model. One of the most important ones of these is the DataSet. The DataSet is based on XML and can be described as a collection of data tables and the relationships between them that are kept in memory [HoLh01]. In some cases the DataSet can be looked upon as temporary in-memory database [ADBInt01]. The DataSet is always disconnected from the source, which means that it is a local copy of the data and that the processing of the data is made locally. All modifications and other operations applied to the data are made to the local copy with no connection to the original storage. One of the benefits with this solution is that the connection to the original data store, probably a database, does not need to be continuous. When all the desired operations have been performed on the local data, then it is resolved with the original data store. If there are any changes made to the DataSet then these changes are transferred to the original storage. In this way all updates, insertions, and deletions are accomplished very easily. DataSets are usually manipulated in memory and they are sent as XML when they are passed between different tiers in the application. Besides data the XML document for the DataSet also contains the XML schema, which is necessary when interpreting the DataSet. Another feature with DataSets is that it is very easy to sort and filter the information contained in them. DataSet RelationsCollection DataRelation TablesCollection DataTable ColumnsCollection DataColumn ConstraintsCollection Constraint RowsCollection DataRow Figure 19: The object model of the relation capabilities of a DataSet. 59

82 Chapter 7: XML To be functional there must be at least one DataTable object in the Tables- Collection of the DataSet. The layout of the rows in the DataTable is described in the ColumnsCollection. If the DataSet should contain any data, then the RowsCollection of the DataTable must contain some rows. The rest of the elements of the object model are optional. A regular DataSet does not have a schema file to describe the structure of the tables that the DataSet contains. A typed DataSet, a subclass of a DataSet, on the other hand has a schema file to describe its table structure. In the schema there is defined which tables and columns there are in the typed DataSet. There is also information about which data type each column in the tables of the typed DataSet have. There are several advantages with the typed DataSet. First of all it is easier to implement a typed DataSet than an untyped DataSet, and errors are also detected at an earlier level. Another advantage with typed DataSet are that theirs tables and columns are first-class objects [Friedland01]. For illustration on how this improves the readability and less error-prone code see the Figure 20 below. It is very easy to create a typed DataSet in Visual Studio.NET. The easiest way to create the schema for the DataSet is to either let Visual Studio.NET create it automatically from a stored procedure, or to attach it from an existing XML schema document. ' An example of an assigning of a value in an untyped DataSet untypedds.tables("user").rows(0).item("username") = username ' An example of the same assigned in a typed DataSet typedds.user(0).username = username Figure 20: The difference between untyped versus typed DataSets Web Services There has always existed a desire to have a common place where users can have their heavy computations made. The existing solutions, such as Remote Method Invocation (RMI), use object-model-specific protocols. But now there has come a new solution, web service, which has the entire industry behind it. A Web Service is a programmable component that can be reached over the Internet through already well-known standards like XML and HTTP (HyperText Transport Protocol). This means that it becomes as simple to call a method over the Internet, as it is to call a method on the local network or the local machine today. Web services use open and well-established Internet protocols. This means that firewalls and other security mechanisms that allow these protocols also allow web services. Through a web service a company can expose information that they wishes to share with their surroundings. For example information on how many products they have in stock, or the information they have stored about you as their customer. There exists numerous of areas where web services could be of use and there is an 60

83 Chapter 7: XML increasing interest for web services, both from creators and consumers. One of the advantages with web services is that the consumer of the web service can use the data received from the web service any way the consumer desires [HoLh01]. The standard for web services seems to be Simple Object Access Protocol (SOAP). The first has been taken by W3C for making SOAP a web standard, and SOAP version 1.2 is currently a working draft in development [W3CTR]. SOAP is an XML-based protocol used for communication through HTTP. Apart from SOAP there exists other standardized protocols that can be used in a web service (for example HTTP-Get and HTTP-Post), but SOAP is probably the most suitable protocol since it is XML-based. This means that it easily can express complex forms of data and represent them in plain text. This is why it is possible to return DataSets (see 7.3.1) and other serializable classes from a web service using SOAP as protocol. It is also possible to return not serializable classes, but then the object remains on the server. Client Computer Client Application SOAP Client Server Computer Web Service 1. Generate command 2. Translate command into SOAP message Internet 3. Execute command and return results. 5. Receive result 4. Receive result, translate into binary message Figure 21: An overview of a SOAP call to a web service (based on [MWS+01:Figure 13.1]) It is pretty clear that the market today is looking for a service like web services, where different companies can receive data from each other so that end-user in the end gets the wanted information in a smooth way. If not web service is the appropriate technique for that then there must be a very similar technique [ADBInt01]. It must just like web services support industry standard, work on different platforms, and be language independent. 61

84 Chapter 7: XML 62

85 Chapter 7: Design Chapter 8 Design 8.1 System Architecture The Panthera system will consists of a windows application and a web site. The application will primarily be designed for internal use, where speed is more necessary than ease of use. The web pages are primarily designed for customers and internal users that do not have the same speed demands as the daily user, such as the help desk personal. Although there is going to be two ways to access the information is it necessarily to store the information in the same database. It is also very desirable that business the logic for both the windows application and web pages are the same. The solution for achieving this is by using a web service. The web service will be accessible both from the web server and from the clients computers and will provide the set of functions and methods for satisfying the functionality of Panthera. The web site and the windows application will not contain any extended business logic. Instead should their main purpose be to act as a front-end to the help desk system, which means that the only logic they will contain is to show the end-user the information in the smoothest possible way. 63

86 Chapter 7: Design Three-tier solution The system architecture will be a three-tier solution, where only the front-end tier will be different from the windows client and the web client. The two solutions will use the same web service and therefore also the same database (see Figure 22). Windows Client Web Client Presentation Services Web Service XML Web Server HTTP Business Services XML OLEDB Data Services Database Figure 22: Three-tier architecture Presentation services The presentation services, or the front-end clients, contain those components that are unique to every user [ABMBH]. In the Panthera system the presentation services consists of the Windows client and the web client. The Windows client will be written in Visual Basic.NET and the web client will be written in ASP.NET Business services In the business services you will find the business logic and the shared parts of system. This part of the system requires support for services such as security, transactions and concurrency control. If it is possible then all intensive computing operations should take place in this tier [ABMBH]. The different 64

87 Chapter 7: Design parts of this tier may communicate with each other through intra-tier communication. So is the case in the Panthera system, where the web server communicates with the web service. Both the web server and the web service are written in ASP.NET. The web server communicates with the web client in the presentation services. The business service can be divided into three separate parts, the parts and the relationship between them is described in Figure 23 below. Business Service Facade Services Entity Services Data Access Services Figure 23: An overview of the business service. The purpose of the Facade is to act as an interface between the presentation service and the Entity Services. In the Entity Services lays the real business logic. The operations are usually stateless and concerning a specific type of entities, such as users or products. The task of the Data Access Services is to perform operations on the tables in the database, such as insertion, deletion, updates, and selection operations General description of the authentication in Panthera To be able to use any of the services provided by the Panthera web service the user must logon to the web service. When the user logs on, the user receives its user id and a session key that should be used when communicating with the web service for the rest of the session. Instead of passing the user id and the session key as parameters to all methods in the web service, the user id and session key are sent in the SOAP header. When the web service receives a call from a client, it first checks if the user is logged on to the system, and if the user is not logged on an exception is thrown. If the user was logged on, the facade receives an object of the SystemUser class containing the operating user. This SystemUser will be used when creating the needed services. Since the SystemUser is passed on to the service, the service is able to check if the user has the authority that the process requests. If the request is granted either a modifier or fetcher is called by the service. The modifier or the fetcher then calls a stored procedure in the database and if it is a fetcher it fills a DataSet with information. This DataSet is then returned all the way up through the web service to requesting client. 65

88 Chapter 7: Design Data services The data service handles the persistent storing in the system. Here all the additions, updates, and deletions made to the system are made persistent. In the case of Panthera, a SQL Server 7.0 will be used to store the information in the system. Retrieval and change of information will go through stored procedures in the database. This will not only improve the performance of the system, it will also improve the maintainability since all ways that the business service communicates with the system is stored in one place. 8.2 Object Model In this document only the object model of the packages in the system and the object model of the web service are provided. The reason for this is to get an overview of the system and that all the important logic and data modification is made in the business service and the main purpose of the clients is to present the information to the user. Figure 24 below shows how the main packages in the system are depending on each other. Panthera Web Panthera Web Service Classes Database Panthera Application Panthera Web Service Panthera Entity Services Panthera Data Access Panthera Class Library Figure 24. An overview of the system. 66

89 Chapter 7: Design LoginFacade UserFetcher UserFacade UserService UserModifier ActorFetcher ActorFacade ActorService ActorModifier CompanyFetcher CompanyFacade CompanyService CompanyModifier SystemRights MatterFetcher MatterFacade MatterService MatterModifier SystemUser AgreementFacade AgreementService AgreementFetcher AgreementModifier LoggedOnUsers ExplorerFacade ProductFetcher ProductFacade ProductService ProductModifier FAQFetcher FAQFacade FAQService FAQModifier WorkloadFetcher WorkloadFacade WorkloadService WorkloadModifier MatterTypeFetcher MatterTypeFacade MatterTypeService MatterTypeModifier SearchFetcher SearchFacade Se arch Service SearchModifier StatisticsFacade StatisticsService Statistics Fetcher Figure 25: The relations between the classes in the web service. Almost every facade checks against LoggedOnUsers to check if the current user is logged on to the system. If this should be the case a method or a function in an appropriate Service will be called. Then the service performs a thoroughly check on the information, if necessary, sent by the facade. If there is a modification of the information that is to be done then a function or a method in the corresponding modifier is called, otherwise the corresponding fetcher is being used. 8.3 Dynamic Model Since the primarily objective in this release was the use cases with the priority 1 (see 5.4 Priority for priority) only those and a general sequence of manage are dynamically modeled with sequence diagrams below. 67

90 Chapter 7: Design UC C1: Login Client LoginFacade UserService UserFetcher Database Login(Username, Password) Login(Username, Password) Login(Username, Password) Login(Username, Password) Generate session key InsertSessionKey(UserId, SessionKey) Figure 26: The sequence for login. When the user wants to login to the system then a call to the LoginFacade is made. The call is then sent further through the UserService and the UserFetcher to the database where the username and password are matched against the existing user of the system. If the credentials are valid then the user is allowed access to the other parts of the system. A session key is then generated and inserted into the database UC C2: Logout Client LoginFacade UserService UserModifier Database Logout(UserId, SessionKey) Logout(UserId, SessionKey) Logout(UserId, SessionKey) DeleteSessionKey(UserId, SessionKey) Figure 27: The sequence for logging off the system. When the user wants to logout of the system, then a call to the LoginFacade is being made. The call is then sent further through the UserService and the UserFetcher to the database where the session key is deleted. 68

91 Chapter 7: Design UC C3: Report Matter Client MatterFaca de MatterService UserLoggedOn MatterModifier UserFetcher Database SaveMatter(Matter) IsLoggedOn(UserId, SessionKey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) SaveMatter(Matter) Check(Matter) SaveMatter(Matter) Ins ertmatter(matter) Generate MatterCode Figure 28. The sequence for reporting a matter. When the user has completed filling in the information on the new matter he/she tries to report the matter by sending it to the MatterFacade, where the system checks that the user is still logged on the system (if its not an exception is thrown). Then the new matter is sent to the MatterService, where the system checks the information in the matter. If the information specified for the matter is correct then it is sent through the MatterModifier into the database. Where the matter is registered in the database the matter code is generated and sent back to the end-user, so it will know which unique matter code the newly reported matter has UC E8: View Matter Client ExplorerFacade MatterFacade MatterService MatterFetcher UserLoggedOn UserFetcher Database GetMatters() IsLoggedOn(UserId, Ses sionkey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) FetchAll() FetchAll() GetMatters() FetchMatter(MatterId) IsLoggedOn(UserId, SessionKey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) Fetch(MatterId) Fetch(MatterId) GetMatter(MatterId) Figure 29. The sequence for viewing a matter. 69

92 Chapter 7: Design When the user wants to view a matter the first thing that has to been done is the fetching of all possible matters. This is done by a call to the ExplorerFacade who checks that the user is logged on to the system and sends the request through the MatterService and the MatterFetcher to the database that then returns information about which matters that can be fetched. The user then chooses from the received information and selects a matter to fetch. This time a call to the MatterFacade is done. The Facade checks that the user is logged on the system and then sends the matter request through to the MatterService, which checks that the user is authorized to view the matter, before sending it further through the MatterFetcher and into the database where the matter is fetched. The sequence for viewing a company is rather similar to the one of viewing a matter. The difference lays within that only the matters for a certain company are fetched in this first part of the sequence. This is accomplished by sending an extra optional parameter for the company id UC D1: Handle matter Client MatterFacade MatterService MatterModifier UserLoggedOn UserFetcher Database SaveMatter(Matter) IsLoggedOn(UserId, SessionKey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) Save(Matter) Check(Matter) Save(Matter) UpdateMatter(Matter) Figure 30: The sequence for handling a matter. When the user has handled the matter (made the desired modifications) he/she chooses to save the matter by a call to the MatterFacade. The facade checks that the user is logged on and then sends the matter further to the MatterService for a check of the information that has been modified. When the check is done the matter is sent through the MatterModifier to the database, where the modified information is stored persistently. 70

93 Chapter 7: Design UC Sch1: Send notification Scheduler Database Mail Check() SendMail(Message) Figure 31: The sequence for sending a notification. On a regular basis the scheduler calls a program in the database, whose purpose is to go through all matters and see if the matter is delayed in any way described by the notification settings for each individual matter. The notifications that are selected are then sent through mail to the recipient of the notification UC A1.1: Add User Client UserFacade UserService UserLoggedOn UserModifier Database SaveUser(User) IsLoggedOn(UserId, SessionKey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) Save(User) Check(User) Save(Us er) InsertUser(User) Figure 32: The sequence to add user. When an end-user has filled in the information for creating a new user he/she creates the new user by calling SaveUser in the UserFacade. The UserFacade checks if the user is logged on before sending the user further to the UserService, where the information entered to create the new user is checked. The user is then sent through the MatterModifier into the database for permanently storage. 71

94 Chapter 7: Design General Manage Client ExplorerFacade XFacade XService Us erloggedon XFetcher UserFetcher XModifier Database GetXs() IsLoggedOn(UserId, SessionKey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) GetAll() GetAll() GetAllX() FetchX(XId) IsLoggedOn(UserId, SessionKey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) Fetch(XId) Fetch(XId) FetchX(XId) SaveX(X) IsLoggedOn(UserId, SessionKey) GetLoggedOn(UserId, SessionKey) GetLoggedOnUser(UserId, SessionKey) Save(X) Check(X) Save(X) InsertX(X) UpdateX(X) DeleteX(X) Figure 33. The sequence of a general manage. When the user wants to manage an object the first thing that has to been done is the fetching of all possible objects. This is done by a call to the ExplorerFacade. The facade checks that user is logged on to the system and sends the request through the objectservice and the objectfetcher to the database. The database then returns information on which objects that can be fetched. The user then chooses from the received information and selects an object to fetch. A call to the objectfacade is done. When the facade receives the fetch call a check against the system is made to decide whether or not the user is logged on. Then the facade sends the object request through to the objectservice, which checks that the user has authorization to view the object, before sending further through the objectfetcher and into the database. The database then returns the desired object. The paragraph above only goes for the edit and delete of an object. The following on the other hand goes for all three cases. When the end-user has made the changes that he/she desired to make to the object, a call is made to the objectfacade. The facade verifies that the user is logged on, and sends after that the object to the objectservice with a call to the Save method. The service checks that the user has the authority to perform the desired task and it also checks that the information in the object is valid. Then the object is sent 72

95 Chapter 7: Design to the objectmodifier that depending on the purpose calls the correct stored procedures in the database and the information is added, modified or deleted. 8.4 Database The database that is used for the Panthera system is a Microsoft SQL server 7.0. To decide the structure of the database we considered what kind of information that was going to be stored in the database and how the information is connected with other information that is to be stored in the system. We tried to group information in a way that would make it easier to expand the system at a later stage. Another point we took into consideration when designing the database was to build it so that it would be easy to collect statistics from the system. The Database model is presented in the figure below (Figure 34). Every relation is shown with arrows between the different tables. Figure 34: The Database Model for the Panthera system. 73

96 Chapter 7: Design 8.5 File Structure This part shows the file structure for the web application. All web pages are modeled so the user can get an understanding of how the pages are linked together. Login.aspx Default.aspx About.aspx FAQ.aspx Explorer.aspx Search.aspx Actor.aspx Workload.aspx Agreement.aspx Matter.aspx User.aspx Company.aspx MatterType.aspx Product.aspx Figure 35: Web client file structure Menu Structure The menu in Panthera system is built from an XML document. This document is arraigned in web service, where nodes are deleted and added depending on the rights of the user. Each node in the XML document will have different attributes set depending on the purpose with node, for example which kind of information that are held in the node. These attributes are described in table below. Attribute Valid values Location Description name Title Any valid string All elements The name of node (the name show in the tree) Type Node All elements Describes if the LeafNode node contains any other nodes 74

97 Chapter 7: Design Contain None Actor Agreement Company DevelopRequest ErrorCorrection FAQ InvoiceComplaint Matter MatterType OtherMatters Product QuestionAnswer ReportedBy Search User Workload Workorder Responsible B# c# u# w# or if it is a leaf node. All LeafNodes What kind of information the leaf node contains. All elements that contain a Matter or Workorder. Id s# All user defined search elements. Users all internal external MatterCategory Closed Open All elements that Contain User. All elements that Contain ReportedBy. Table 7: The structure of the navigation menu. Which user or which workload that currently is handling the matter. b gets all the matters that the user can handle. Which search criteria that are referred to. Which kind of user that the element contains. If the matters to be shown shall be closed or open. 75

98 Chapter 7: Design 76

99 Chapter 9: Testing Chapter 9 Testing The purpose of the testing is to assure that the requirements documented are fulfilled and to be able to guarantee a high quality product. We have concluded most of the testing ourselves, but some of the tests were conducted together with people from SISAB. 9.1 Survey When the first official version of Panthera will be released, then a group of individuals will be asked to participate in a survey (the English version of the survey can be found in Appendix B: Survey of InfoLink versus Panthera). The content of the survey will have a primarily focus on a comparison between Panthera and InfoLink. The participants will not be given any information on how to use Panthera. The reason for this is that we would like to know how long they think it will take them to learn system. 9.2 Documents Requirements document The requirements document will be tested, to assure that every requirement required from SISAB is documented in the requirements document. This is done by ourselves, but also by a representative from SISAB. The testing is done by reading the requirements document and relating to requirements given by SISAB Analysis document The Analysis document is to be tested by us and by SISAB to assure that the functionality documented in the Requirements document is fulfilled. Testing and assuring that the functionality from the Requirements documents has been included in the Analysis document. It is also important to decide upon if it is possible to implement the Panthera system as described in the Analysis document. 77

100 Chapter 9: Testing Design document The Design document is tested by us and by SISAB to assure that the requirements that are described in detail and the functionality requested in the Requirements document are realized. The tests must also assure that the method to achieve required functionality is reasonable. 9.3 User Interface The Graphical User Interface needs to be evaluated by users that are going to use the Panthera system on a frequent basis. It would be preferable if a user that is not used to working with InfoLink would test the user interface to give us an idea of how the customers that are going to report matters and follow matters interact with the Panthera system. But it is also important to verify that every functional requirement is made real in the user interface as well as the nonfunctional requirements concerning the user interface, for example usability. The testing of the user interface is done twice. Once early in the process of developing the Panthera system, to let the user and SISAB get a chance to give ideas for improvements in the user interface. The second test occasion will be later in the process, when it will be possible to test it as a part of the complete product. 9.4 Functionality test The purpose of the functionality test is to assure that all functionality in the release, works in the expected way. This is done by testing the functionality in the different windows that is included in this release of the windows application TC1: Login window 1. Assure that every button, label, combobox, and so on is present. 2. Check the login for both correct and incorrect usernames and passwords. 3. Make sure that the correct error message is given when you fail to logon. 4. Login to the system TC2: Main window 1. Check all menu choices. 2. Assure that all menu choices, for which the specific user owns rights, are present. 3. Check all toolbar choices. 4. Assure that all toolbar choices, for which the specific user owns rights, are present. 5. Check all branches in the tree. 78

101 Chapter 9: Testing 6. Try to navigate through a branch in the tree using the view that displays the content of the branches. 7. Close the view that displays the content of the branches. 8. Try to logoff TC3: Explorer window 1. Check that all menu choices are present. 2. Switch the list view to all possible choices. 3. Check that when you double click on a folder, then the content in that will be shown. 4. Check that when you double click on a list item, then the window corresponding to that list item is shown TC4: User window 1. Check all toolbar choices. 2. Assure that all toolbar choices, for which the specific user owns rights, are present. 3. Assure that every button, label, combobox, and so on is present. 4. Create a user. 5. Save the user and make sure that the save was successful. 6. Make modifications on the user. Such as personal information, rights, and so on. 7. Save the user and make sure that the user has been saved TC5: Matter window 1. Check all menu choices. 2. Check all toolbar choices. 3. Assure that all toolbar choices, for which the specific user owns rights, are present. 4. Assure that every button, label, combobox, and so on is present. 5. Assure that only the user with the right to alter information is able to alter it. 6. Make modifications. 7. Save the modifications. 8. Save the Matter. Assure that an error message is given, if the information is not correct or missing. 9. Try to send the matter to a new handling officer. 10. Make sure that a message is sent to the handling officer TC6: About Window 1. Close the about window by pressing the OK button. 2. Close the about window by pressing the Esc key. 79

102 Chapter 9: Testing 9.5 Results Documents All the documents have been approved by SISAB and by us. In some cases the review has shown that there have been minor errors in the document. In those cases the errors have been corrected and a new document has been released. The new document has then later been approved User interface The first test of the user interface was done at an early stage. There we got an acknowledgement that information in the windows was correct. This was confirmed by the survey (see 9.1 Survey) later on in the process. Most of the participants in the survey found the information structured, but some found that there in some cases were information missing. Most users also thought that there where only necessary information in the system and everybody thought that the color combination was peaceful. The conclusion is then that everybody seemed overall pleased with the usability of Panthera Functionality test The table shows that most of the functionality test went well, but not all of it. The most serious is that the system can terminate while saving a new user. Window Errors TC1: Login window No faults found. TC2: Main window No faults found. (No toolbar is used in this release). TC3: Explorer window No faults found TC4: User window Sometimes the system can terminate abnormally when trying to save a newly created user. This means that 5. Save the user and make sure that the save was successful. fails in some cases. TC5: Matter window At the moment no authority control is made once the matter is shown. This means that 3. Assure that all toolbar choices, for which the specific user owns rights, are present. and 5. Assure that only the user with the right to alter information is able to alter it. fails. TC6: About Window No faults found Table 8. Errors found in integration test. 80

103 Chapter 10: Results Chapter 10 Results There has been lot work going from the specification to the first release of Panthera. Numerous hours have been spent on this project and we have learnt much along the way. We have used RUP as development process. Although it is a very good process to follow when trying to achieve structure in a project, we came to the conclusion that there is much work that feels unnecessary when there are only two participants in the project. So we decided to only use a subset of RUP to ensure that our project would still be structured without us having to put all the effort in paper work. We also got the opportunity to learn a new environment, Visual Studio.NET. Now the first version of Panthera is completed, and it feels like we made the right decision concerning the programming language, the environment and the system architecture. We think that we have made a system that will be easy to expand and to maintain. Panthera will hopefully be a help desk system that is more appropriate than InfoLink for SISAB. When we made our survey (see 9.1 Survey) we got the impression that the employees at SISAB feels that Panthera can be more suitable for their demands than InfoLink. It is not only primary requirements like notifications and processes that were welcomed features. They were also pleased with common features that already exist in InfoLink, such as the way matters are registered and that it is easier finding the matters where you are the handling officer Included in this release This release has limited functionality. This is because the task of developing the Panthera system has grown to be much more complex, than specified in the beginning. We therefore made a decision to make an effort to design the Panthera system in a way that will make it easy for an outsider to continue the implementation of the project. This and previous documents that we have produced describes what is to be done and how it is to be done, but it is just a fraction of the Panthera system that has be implemented for our Master Thesis. 81

104 Chapter 10: Results Our goal was that the Panthera system would not have much less functionality than the functionality that SISAB demands from InfoLink today. But since we had limited time to implement the solution we had set priority on the use cases, described in Requirements document, to be able to decide what functionality must be reached in this release. We have implemented the use cases with priority 1, except from the notification that is not really completed since we do not have been able to send any yet. The other use cases must therefore be included in the next release Next release In a future release it will be possible to search for certain information in the system. Everything that is stored in the system can be modified and deleted directly through the User Interface. The web interface will be designed to make it possible, after having added customer users, for the customers to follow their matters. Unfortunately we had no time to implement the use of SSL in the current release. This was never a demand from SISAB, since Panthera for the moment only runs on their intranet Screenshots from Panthera Figure 36. Step 2 in reporting a matter via the web. 82

105 Chapter 10: Results The screenshot above shows the second step of three when reporting a matter. The screenshot is taken from the Panthera web page. In the first step of reporting the matter the type of the matter is set. In the second step the general information like company, product, and contact persons for the matter is set. In the third step more specific information concerning the matter is entered. What kind of information that is necessary to be entered depends on the matter type and the product. Figure 37. The explorer showing the reported matters. When the matter has been reported, then it is viewable from the Panthera application. The figure above shows all matters in the system, where our matter is one of the two existing matters. 83

106 Chapter 10: Results Figure 38. The first view the user meets when opening a Question Answer matter. When the user double clicks on the matter in Figure 37 then the matter is opened. The user can then handle the matter, if authorized to do so, or just look at it. 84

107 Chapter 10: Results Figure 39. The view of an user in the windows application. When viewing a user the general information like name, address, telephone number, and so on are shown. The user rights are also shown in this window. 85