MOWAHS - Evaluering og videreutvikling av MOWAHS

rammeverk for mobilt arbeid

Morten Brokerud

John Erik Taskerud Jensen

20 December 2005

NORWEGIAN UNIVERSITY OF SCIENCE AND TECHNOLOGY

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

ii

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

iii

Contents Preface ........................................................................................................................................ 2 1. Introduction ............................................................................................................................ 4

1.1 General introduction......................................................................................................... 4 1.2 Project Context................................................................................................................. 4 1.3 Motivation ........................................................................................................................ 5 1.4 Problem definition............................................................................................................ 5 1.5 Reader’s guide.................................................................................................................. 6

2. Research agenda, and associated development methods ....................................................... 8 2.1 Work plan......................................................................................................................... 8 2.2 Development process ....................................................................................................... 8

3. Problem elaboration ............................................................................................................. 10 4. Pre-study of Mobile Work Characterization Framework..................................................... 12

4.1 Mobile Work Characterization Framework (MWCF) ................................................... 12 4.2 Current practice .............................................................................................................. 14 4.3 Consistency rules............................................................................................................ 15 4.4 Technologies .................................................................................................................. 20

4.4.1 Java 2 Software Development Kit (Java 2 SDK).................................................... 20 4.4.2 JavaBeans ................................................................................................................ 21 4.4.3 Java Servlets ............................................................................................................ 23 4.4.4 JavaServer Pages (JSP) ........................................................................................... 26 4.4.5 Apache Jakarta Tomcat ........................................................................................... 27 4.4.6 Struts........................................................................................................................ 28 4.4.7 MySQL.................................................................................................................... 29

5. Technologies ........................................................................................................................ 30 5.1 Challenges of mobile computing.................................................................................... 30 5.2 Personal Digital Assistant (PDA)................................................................................... 31 5.3 Smartphones ................................................................................................................... 32 5.4 Which technology to use ................................................................................................ 34

6. The MWCF system .............................................................................................................. 36 6.1 Requirement specification.............................................................................................. 36

6.1.1 Functional requirements .......................................................................................... 36 6.1.2 Non-Functional requirements.................................................................................. 44

6.2 Design............................................................................................................................. 45 6.2.1 Database design....................................................................................................... 45 6.2.2 Sequence diagrams.................................................................................................. 46

6.3 Implementation............................................................................................................... 50 6.3.2 Technologies ........................................................................................................... 50 6.2.3 Database implementation ........................................................................................ 51 6.2.4 The extended MWCF Application .......................................................................... 52

6.4 Testing............................................................................................................................ 54 6.4.1 Test methods ........................................................................................................... 54 6.4.2 Functional requirements test plan ........................................................................... 55 6.4.3 Functional requirement test results ......................................................................... 55 6.4.4 Non-functional requirements test plan .................................................................... 55 6.4.5 Non-functional requirement test results .................................................................. 56

6.5 Adapting the MWCF system for PDA ........................................................................... 56

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

iv

7. User guide ............................................................................................................................ 58 7.1 Administer consistency rules ......................................................................................... 58 7.2 Validate characterization................................................................................................ 59

8. Results .................................................................................................................................. 62 9. Evaluation and discussion .................................................................................................... 64 10. Conclusion and further work.............................................................................................. 66 Appendix A - References ......................................................................................................... 68 Appendix B - SQL code ........................................................................................................... 70

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

v

List of Figures Figure 1: The incremental model ............................................................................................... 9 Figure 2: The MWCF site ........................................................................................................ 15 Figure 3: A Java program running on different machines ....................................................... 20 Figure 4: A program running on the Java platform.................................................................. 21 Figure 5: JBuilder 2, an example of a builder tool................................................................... 22 Figure 6: Clients talking to java Servlets in servers................................................................. 23 Figure 7: Different Servlet sources .......................................................................................... 24 Figure 8: JSP Model 1 architecture .......................................................................................... 26 Figure 9: JSP Model 2 architecture .......................................................................................... 27 Figure 10: Key components and connectors of Tomcat........................................................... 28 Figure 11: The JDBC architecture ........................................................................................... 29 Figure 12: The Garmin iQue 3600 PDA .................................................................................. 32 Figure 13: Nokia 3620, Smartphone ....................................................................................... 33 Figure 14: The actors of the system and their relationship ...................................................... 37 Figure 15: Main use case diagram............................................................................................ 39 Figure 16: Use case diagram for use case 4: Administer framework....................................... 40 Figure 17: Use case diagram for use case 4a: Administer groups............................................ 41 Figure 18: Use case diagram for use case 4b: Administer characteristics ............................... 42 Figure 19: Use case diagram for use case 4d: Administer consistency rules........................... 43 Figure 20: Use case diagram for use case 7: Characterize scenario......................................... 44 Figure 21: Administer consistency rules .................................................................................. 46 Figure 22: Add fragment .......................................................................................................... 47 Figure 23: Getting a rule from the database ............................................................................. 48 Figure 24: Delete rule............................................................................................................... 49 Figure 25: Validate................................................................................................................... 50 Figure 26: Framework .............................................................................................................. 58 Figure 27: Add new consistency rule ....................................................................................... 59 Figure 28: Validate characterization ........................................................................................ 60 Figure 29: Broken consistency rules ........................................................................................ 61

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

1

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

2

Preface This document has been written as the report for the course TDT4735 “Systemutvikling, Fordypning”. This project has been part of the MOWAHS project which is part of the Software Engineering group at the Norwegian University of Science and Technology (NTNU). The project started in August 2005 and lasted until 20 December 2005. We would like to thank out supervisor Alf Inge Wang for guidance and support during the project. Trondheim, December 20, 2005-12-09

John Erik Taskerud Jensen Morten Brokerud

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

3

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

4

1. Introduction This Chapter introduces the settings and the context of the project. A general introduction to mobile work and mobility is given in Chapter 1.1. In Chapter 1.2 the project context is described. The motivation of the project is presented in Chapter 1.3. A problem definition for the project is given in Chapter 1.4, and finally a reader’s guide is presented in Chapter 1.5.

1.1 General introduction The development of mobile devices advances rapidly each year, PDAs, notebook computers and mobile phones gets more advanced and integrate new technology and functionality. This means that more and more companies integrate mobile technology in their information systems. This makes a major impact on how employees carry out their daily work, not only can they be more mobile at the office, but they can also use information systems out in the field and work from home. According to the Telework Advisory Group [1] 45.1 million people did some type of work from home in 2005, an increase of about 2% from 2004. This has opened up for wide range of mobile applications and systems for occupational groups that traditionally has not used information systems to support their work. The increased use of mobile technology has lead to new challenges in developing information systems and infrastructures. Some of the challenges in designing software for mobile computing systems are quite different from those involved in the design of software for stationary networked systems. Systems have to be flexible, effective, portable and support information sharing over different platforms. [2] Mobile computing is still a quite new field, and lots of research is going on, not only on the technology, but also on user behaviour. An example of a research group that work with mobile computing is the Mobile Wireless Network Research Group at AT&T Labs-Research [3]. They work with issues such as Mobile Interdomain Roaming, Mobile Network Performance, Performance Enhancement Technologies, Mobile Applications and Signal Processing. Research projects like this helps companies, educational facilities and developers of mobile software to a better understanding on how to adapt technologies and resources to support mobility and mobile work.

1.2 Project Context This project is part of the Mobile Work Across Heterogenous System (MOWAHS) project, which is a basic research project supported by Norwegian Research Council [4]. The people involved in this project are mainly members of IDI’s software engineering group and database technology group. The MOWAHS project is divided in two parts: process support for mobile work using heterogeneous devices and support for cooperating transactions/workspaces on databases. The MWCF framework (Mobile Work Characterization Framework) has been developed as a part of the MOWAHS project to provide process support for mobile work. The MWCF framework is designed to help developers find requirements and challenges in mobile systems. This is done by assigning different weights on software scenarios, and then use these weights to calculate different indicators. A Web-based version of the MWCF system has also been developed to increase the usability and the availability of the framework.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

5

1.3 Motivation The MWCF framework was made to help developers analysing mobile scenarios, and to help them to better find and understand the challenges of mobile systems. The framework was originally made as a spreadsheet and was described in two articles [5] [6]. These two articles were the only documents describing the MWCF framework, so for people who were not familiar with the framework the documentation was a bit insufficient. The usability and availability of the spreadsheet-based framework was also not that good. Thus Siv Oma Rogdar developed a Web-based system for the framework in 2003, as part of her Master’s Thesis “A Web System for Characterising Mobil Work” [7]. This system serves as a user-friendly tool for applying the MWCF framework on mobile scenarios, and for retrieving the complexity indicators for the scenario/system. With the MWCF Web system the user can create different mobile scenarios and then identify different roles in the scenario. After that tasks for each role are identified. For each task the user writes a task description, using the task template. Then the user assigns task weights, and uses the system to characterize the tasks. By combining the scores of the characteristics several indicators can be found. Theses indicators are used to analyse the mobile scenario. The framework is further described in Chapter 4.1. The only lack of functionality in this Web-based system is the lack of data consistency checks and PDA support. The consistency checks are made by applying a set of rules on different software developing scenarios. These rules exist in theory and were made for preventing common user mistakes during the assignments of scores to the scenario tasks. An example on this is when the user has decided that a task must be executed at a specific time. The system will then suggest that this task also has to be planned for. The user can chose to ignore this suggestion, but that is not recommended. By applying these rules on the MWCF system, the user will be greatly helped during the assignments of scores on the different tasks. When you are developing software for mobile work it is not unlikely that you have to do some of the work out in the field. If a developer could make scenarios and analyse them straight a way, it would simplify the developers work a lot. At the moment the MWCF framework only exist for stationary system and not for mobile systems. This is why a PDA version of the MWCF framework is wanted.

1.4 Problem definition The main objective of this project is to implement the data consistency tests in the Web-based MWCF system. To do this we first have to study the current system and its technologies. This means we have to learn about JavaBeans, Java Servlets, the Struts framework and the other technologies used in the system. This will be done by installing the system and by studying different articles and Web pages. Another goal on this project is to plan and design a portable system for the MWCF framework. This will most likely be a PDA based system. To achieve this goal we have to learn about the challenges in mobile software development, read up on the newest technology and study the different methods used in mobile software development. The planning and design for the implementation of both the rules and a portable system have already been made by Siv Oma Rogdar [7] and Jakub Hajduk [8]. We will use these designs in our work, and improve them if necessary.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

6

1.5 Reader’s guide In this Chapter a reader’s guide and a short dictionary of the most common !""#$%&!'&()*+!#$+

,&%$)-+ In Chapter 2 the work plan and the development method are described, following by a problem elaboration in Chapter 3. Chapter 4 describe all the different system and technologies involved in the project. This includes the Mobile Work Characterization Framework, the current practice and status of the system, the consistency rules and all the technologies used in the MWCF system. In Chapter 5 the general challenges of mobile computing and the PDA and Smartphone technologies are presented and discussed. In Chapter 6 the different aspects of the MWCF system are discussed. This includes the requirements specification, the design of the system, testing and test results and the future PDA version of the system. Chapter 7 gives a user guide to the new functionality in the extended MWCF system. In Chapter 8 the results are described and these results are evaluated and discussed in Chapter 9. At last a conclusion and a discussion on further work are given in Chapter 10. Dictionary:

GUI Graphical User Interface IM Incremental Model MOWAHS Mobile Work Across Heterogenous System MVC Model View Controller MWCF Mobile Work Characterization Framework OS Operation System PDA Personal Digital Assistant

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

7

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

8

2. Research agenda, and associated development methods In this Chapter a short work plan is presented in Chapter 2.1. In Chapter 2.2 the development method used in the project is described.

2.1 Work plan Following is a work plan for the project: 21. Sep Study JSP

Study Struts Study JavaBeans Study Java Servlets Get to know the existing code Select and learn development tools

05. Oct Pre-study completed / Start planning the implementation 12. Oct Finished the planning of the implementation / Start the implementation 11. Nov Implementation finished / Start testing and refinement 18. Nov Implementation tested and completed / PDA planning starting 01. Des Oral exam 20. Des Final delivery of the report

2.2 Development process

There exist many different approaches to software development and design. These different models are designed to structure the development process, and each is designed to fit different scenarios, different work methods and different settings. We had little experience with both the existing MWCF system and the technologies used to develop it. Our approach to this was to learn different aspects of the system while we where developing it, and to adjust our requirements after we had developed a new part of the system. A development model that is designed for this type of work process is the incremental model.

The incremental model (IM) is designed, implemented and tested as a series of incremental builds until the product is finished, as illustrated in Figure 1. A build consists of pieces of code from various modules that interact together to provide a specific function. At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a whole. The product is only defined as finished when it satisfies all of its requirements.

This model combines the elements of the waterfall model with the iterative philosophy of prototyping. However, unlike prototyping the IM focuses on the delivery of an operational product at the end of each increment.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

9

Some of the advantages of the incremental model are that the system can be tested and used at an early stage. The most important parts of the system can be developed first if that is wanted. The requirement specification can also be updated during the development, to better approach the demands of the users.

Figure 1: The incremental model

The advantages of selecting the incremental model where that we could learn the different aspects of the MWCF system and its technologies while developing it. When using the incremental model we could develop the most trivial parts first, and in that way we learned gradually how the system worked. We also updated our design and requirements as we got more familiar with the system and its technologies.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

10

3. Problem elaboration This project is separated in two different goals. In this Chapter, we will describe the goals, and explain how we plan to achieve them. We will also describe how this project will help us with the upcoming Master’s Thesis. Goal 1: Implement data consistency tests in the Web-based MWCF system

The Web system has no data consistency rules implemented in the current version. The rules exist in theory, and the design/requirements for implementing them are described in the Master thesis of Siv Oma Rogdar [7] and Jakub Hajduk [8]. In our work with implementing data consistency rules we will use these plans and adjust them if necessary. To achieve this goal we have to install and study the current system. We also have to learn the different tools and techniques used in running and developing the system. The tools used are MySQL, Tomcat, Struts framework and different Java technologies.

Goal 2: Planning and designing a portable system for the MWCF framework When designing systems for mobile work much of the work has to be carried out in

the field. The Web-based MWCF system is only designed to run on stationary computers, so a portable version would increase the usability of the system. Our goal is to design and plan such a system. This will most likely be a PDA-based system. Much of this work has already been done in the earlier mentioned Master’s Thesis’s. We will improve and adjust this work with up to date technology and methods.

To achieve this goal we will study methods used in mobile software development and

determine which we want to use in future development of the system. We also have to study and adjust the current plans for a portable MWCF system. Since we are planning to make this system for PDA’s we also have to read up on the newest PDA technology.

We will most likely continue the work with the MWCF framework in an upcoming Master’s Thesis. This will include an implementation of the PDA system and testing this system on potential users.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

11

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

12

4. Pre-study of Mobile Work Characterization Framework This Chapter describe all the different system and technologies involved in the project. In Chapter 4.1 the Mobile Work Characterization Framework is described. The current practice and status of the system are described in Chapter 4.2, and following in Chapter 4.3 the consistency rules are presented. Finally in Chapter 4.4 all the technologies used in the MWCF system will be explained.

4.1 Mobile Work Characterization Framework (MWCF) The MWCF is a framework for characterizing mobile work. It was developed by the researchers in the MOWAHS research project. By using the MWCF framework on a mobile work scenario, one can elicit both functional and non-functional requirements. The framework consists of four main characterization groups, general, information, location and time. Each group has five characteristics which can be given a value from 1 to 5 where 5 indicate a high complexity. Some characteristics only use the values 1, 3 and 5. All the characteristics of the MWCF are shown in Table 1. To apply the framework to a mobile work scenario, one uses the following steps. 1. Select the mobile scenario and identify the different roles/actors. 2. For each role identify tasks. 3. For each task:

a) Write a task description using a task description template b) Assign task priority (1-5, where 5 is most important) c) Characterize the task using the framework (see Table 1). d) Calculate the requirement indicators for the task

4. Derive system requirements and priorities from the characteristics and indicators.

Table 1 Characteristic Possible values Description

General G1 Decomposable (1 No, 3 Uncertain, 5 Yes) Decides whether the task is composed of

subtasks or not. G2 Part of sequence (1 No, 3 Partial, 5 Yes) Specifies if a task has order dependencies

with respect to other tasks. G3 Pre-planned (1 Planned, 3 Partial, 5 Adhoc) Describes to what degree a task is planned

in beforehand. G4 Data synchronisation (1 No, 3 After task, 5 Within task) Specifies when a task has to synchronize /

merge updated data with other tasks. G5 Data exchange rate (1 None, 3 Once, 5 Many)

Specifies the rate of data exchange between the current task and other tasks (during its lifetime).

Information I1 Information contents (1 NA, 2 Text, 3 Graphics, 4 Audio, 5

Video) Describes the complexity of the information required or produced by the task.

I2 Information streaming (1 NA, 3 Discrete, 5 Continuous) Describes whether the task requires streaming of data or not.

I3 Information required related to time (1 NA, 2 Low, 3 Medium, 4 High, 5 Real-time)

Describes how important the information required to execute the task is related to time.

I4 Information produced related to time (1 NA, 2 Low, 3 Medium, 4 High, 5 Real-time)

Describes how important the information produced by the task is related to time.

I5 Information transmission speed (1 NA, 2 Slow, 3 Medium, 4 Fast, 5 Very fast)

Describing the expected transmission speed of information used or produced by the task.

Location L1 Location dependent (1 No, 3 Partial, 5 Yes) Describes to what degree a task must be

executed at a specific location (e.g. that a

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

13

lecturer must be in a classroom to teach students).

L2 Require services at location (1 No, 3 Partial, 5 Yes) Specifies if a task needs electronic services available at the location such as printers, network connections, video projectors, fax machines, etc.

L3 Produce services at location (1 No, 3 Partial, 5 Yes) Specifies if a task produces electronic services at the location that can be used by others at this location, such as information queries, beaming of information, network connectivity etc.

L4 Location report (1 No, 3 Partial, 5 Yes) Specifies if a task must report its location to the system.

L5 Route constraints (1 No, 3 Partial, 5 Yes) Specifies if a mobile task must follow a specific route or not when moving around.

Time T1 Event-triggered (1 No, 3 Partial, 5 Yes) Decides whether a task is triggered by an

event or not T2 Time constraint (1 No, 3 Partial, 5 Yes) Describes if a task must be executed at a

specific time or within a specific time-span (e.g. a task must be performed between 10:15 and 12:00).

T3 Temporal coordination (1 No, 3 Partial, 5 Yes) Describes if a task must be coordinated with other tasks (e.g. different military units must strike at the same time).

T4 Task resumption (1 No, 3 Partial, 5 Yes) Describes if a task can halt, and then later resume from where it left off (not requiring a complete restart of the task).

T5 Task lifetime (1 Seconds, 2 Minutes, 3 Hours, 4 Days, 5 Weeks)

Describes the expected lifetime of a task.

From the scores of these twenty characteristics indicators can be computed. These indicators will help in the analysis of the scenario and in the extraction of requirements. The MWCF has ten different indicators as listed below: General Task Indicator (GTI) is an average of G1-G5. A high GTI score indicates that the underlying process and transaction infrastructure (e.g. workflow system) must be advanced. Information Complexity Indicator (ICI) is an average of I1-I5. A high ICI score indicates that the end-system must cope with complex information presentation, management and transmission. The ICI can also be used to select the appropriate hardware and software to be used as a mobile client and server. Location Complexity Indicator (LCI) is an average of L1-L5. A high LCI score can indicate that the end-system must be location-aware, include Geographic Information System (GIS) functionality, and use a mobile client suitable for mobility in terms of weight, size, battery power etc. Time Complexity Indicator (TCI) is an average of T1-T5. A high TCI score indicates that time management and coordination of tasks, and advanced transaction support might be necessary. In addition, the TCI also indicates the level of performance and availability required. Network Connectivity Indicator (NCI) is an average of G3, G4, G5, L4, and T1 and indicates the level of connectivity between the mobile client and the server. It determines the required networking capabilities of the mobile client. Further, it indicates non-functional requirements for the system such as reliability and latency.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

14

Network Speed Indicator (NSI) is an average of I3-I5. A high NSI score means that the transmission speed and quality of service must be high between the mobile client and supporting servers. The NSI also indicates what wireless network technology can be used for the end-system. Energy Consumption Indicator (ECI) is an average of I5, L1, L2, L3, and T5. A high ECI score means that it is likely that the mobile client device can complete the task will consume much energy. Transaction Support Indicator (TSI) is an average of G3, G4, G5, T1, T4, and T5. TSI describes the need for flexible/advanced transactional support. A high TSI score indicates that the transactional support must go beyond ACID transactions. Mobility Indicator (MI) is an average L4 and L5, and indicates how much mobility is involved. The MI is useful for determining the complexity of the environment the mobile client will operate in, e.g. variation in wireless networks. A high MI will affect the choice of equipment (device) and tools necessary to accomplish the task. Task Complexity (TC) is an average of all characteristics of a task and indicates the complexity of one task. The TC is useful for finding the most complex task that should have the most attention in a further examination.

4.2 Current practice The MWCF framework was originally a spreadsheet, and was described in two articles [5] [6]. The spreadsheet was used to characterize mobile scenarios and to compute the mobile complexity indicators of the scenarios. One of the problems with system was that the system it self and information on how to use it was separated. The learning curve for users that was not well familiar with the system was too steep, so a Web-based system was desired. So far, two students have worked on the development of the Web-based MWCF system. Siv Oma Rogdar designed and implemented the system in 2003. This is a fully functional system, the only part of the system she did not implement was the consistency rules, but the design and description of these rules are written in detail in her Master’s Thesis [7]. Jakub Hajduk continued working on the system in 2004. His goals were to implement the consistency rules and to plan and implement a PDA version of the system. These tasks were never fully implemented, but the design and planning exists in his Master’s Thesis [8]. The Web-based MWCF system can be used by both registered users and non-registered users. A non-registered user can choose to view all the scenarios stored in the system, or to create an account by the register option. A registered user can create new scenarios, edit scenarios, delete scenarios and characterize scenarios. When a new scenario is created, the user adds tasks to the scenario. After a scenario is characterized, the user can see the calculated indicators of the scenario. Registered users may also retrieve his/hers password by mail if it is forgotten, and edit their current account settings.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

15

Figure 2: The MWCF site

4.3 Consistency rules A set of consistency rules has been developed to help the user in the process of characterising different mobile scenarios. These rules are related to the relations between the different characteristics in the framework. When the rules are implemented in the Web-based MWCF system they will prevent common user mistakes during the assignments of scores to the scenario tasks. If a user enters data in the system that is not consistent, the user will get a warning and a suggestion on how to correct the data. The user can choose to ignore these suggestions since projects vary greatly and the consistency rules may not apply on all projects. The following rules derived from the set of characteristics, description and value scales in Table 1. The numbers of the characteristics as found in Table 1 are combined with scores to form a consistency rule. The logical terms used in the rules are as follows:

Table 2

Symbol Meaning ! Implication " Greater or equal V Logical OR = Equal

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

16

Rule 1

I3 " 4 V I4 " 4 ! I5 " 4 Involves characteristics: • I3 - Information required related to time • I4 - Information produced related to time • I5 - Information transmission speed If there is a high score on either (or both) of the characteristics I3 or I4, the information required to execute the task related to time or the information produced by the task related to time is highly important. This implies that there is a need for high transmission speed of information used or produced by the task, which means that I5 should have a high value.

Rule 2

L5 = 5 ! L1 = 5 Involves characteristics: • L1 - Location dependent • L5 - Route constraints If a task needs to follow a specific route when moving around (score 5 (yes) on L5), it is dependent on being at specific locations to execute the task, which implies a value of 5 (yes) on L1. Rule 3

L4 = 5 ! L1 = 5 Involves characteristics: • L1 - Location dependent • L4 - Location report A task that has a score of 5 on L4, which means that the task must report its location to the system, implies that the task is dependent on being at a specific location (since that location is of importance to the system). Rule 4

T3 = 5 ! G2 = 5 Involves characteristics: • G2 - Part of sequence • T3 - Temporal coordination If a task must be coordinated with other tasks with respect to time (score 5 (yes) on T3), a task is part of a sequence of tasks (score 5 on G2).

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

17

Rule 5

I2 = 5 ! G5 = 5 Involves characteristics: • G5 - Data exchange rate • I2 - Information streaming If a task requires streaming (score 5 on I2), it requires a high rate of data exchange between the current task and other tasks during its lifetime (score 5 - Many on G5). Rule 6

G3 = 5 ! T1 = 5 Involves characteristics: • G3 - Pre-planned • T1 - Event-triggered If a task is Ad-hoc (score 5 on G3), then it is event-triggered (score 5 on T1). Ad-hoc tasks are activities that cannot be planned for and typically occurs as a reaction to some event. Rule 7

T2 = 5 ! G3 = 1 Involves characteristics: • G3 - Pre-planned • T2 - Time constraint If a task has time constraints and must be executed at a specific time (score 5 on T2), it must be planned for (score 1 on G3). Rule 8

G2 = 5 ! G3 = 1 Involves characteristics: • G2 - Part of sequence • G3 - Pre-planned If a task is part of a sequence (score 5 on G2), it has to be planned for in advance (score 1 on G3).

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

18

Rule 9

L5 = 5 ! G3 = 1 Involves characteristics: • L5 - Route constraint • G3 - Pre-planned If a task has a route constraint (score 5 on L5), it has to be planned for in advance (score 1 on G3). Rule 10

T4 = 5 ! T5 " 2 Involves characteristics: • T4 - Task resumption • T5 - Task lifetime If a task can halt and later resume from where it left off (score 5 on T4), it must have a lifetime that can at least be measured in minutes (score 2 or more on T5).

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

19

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

20

4.4 Technologies In this Chapter the technologies used in the MWCF system will be explained. This includes the different Java API’s, the Struts Platform, the Apache Jakarta Tomcat Web server and the MySQL database system. Each technology is explained thoroughly, and illustrated with figures, so readers that are not familiar with them easily can understand the different technologies used in the MWCF system.

4.4.1 Java 2 Software Development Kit (Java 2 SDK)

With most programming languages you either compile or interpret the program to make it run on your computer, the Java Programming language does both. Your program is compiled to an intermediate language called Java bytecodes before it is interpreted to run on your computer. Compilation happens once, interpretation happens every time you run the program. This makes the Java Language highly portable because the Java bytecodes can run on any machine as long as it has Java Virtual Machine (Interpreter) installed.

Figure 3: A Java program running on different machines

The Java technology is both a platform and a programming language. It is a software-only platform that runs on top of hardware-based platforms. The platform consists of two elements, the Java Virtual Machine and the Java Application Programming Interface (Java API). The Java API is a large collection of ready-made software components that provide many useful capabilities, such as graphical user interface (GUI) widgets [9]. The Java API is grouped into libraries of related classes and interfaces; these libraries are known as packages.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

21

Figure 4: A program running on the Java platform

4.4.2 JavaBeans

JavaBeans technology is the component architecture for the Java 2 Platform. The JavaBeans was originally developed by Sun to work with GUI components, but they are now used with every aspect of Java, including Web applications [9]. JavaBeans are platform-independent self-contained reusable software units. Any java object that conforms to certain rules can be a bean. JavaBeans specification contains the following definition of a Java Bean: “A Java Bean is a reusable software component that can be manipulated visually in a builder tool”. A reusable software component is a piece of software that is written once and can be reused several times. This enables developers to write reusable components once and run them anywhere. This also gives the opportunity to sell and buy software components. When software systems are developed, it can be timesaving to reuse certain components. These components can range from simple Web-based components to software components used in advanced systems. The definition of a JavaBean states that it is a software component that can be manipulated visually in a builder tool. Builder tools or application builders provide the environment to use the beans and manipulate them [10]. A builder tool is able to connect different JavaBeans without writing any code. This means that the developer can drag and drop components onto a form. A form can be a Java panel, window or canvas. Examples of builder tools are Borland JBuilder, Sun Java Workshop and JCreator. Figure 5 shows a screenshot from JBuilder. The Figure shows that it is possible to drag and drop components, buttons and text fields in this example, on to a Form. Components can then easily be modified with the object inspector.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

22

Figure 5: JBuilder 2, an example of a builder tool

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

23

4.4.3 Java Servlets

Servlets are modules of Java code that run in a server application to answer client requests. Servlets are the server side counterpart to applets (which are used only on clients) they are Java application components which are downloaded, on demand, to the part of the system which needs them [9]. Servlets provide a general framework for services using the request-response paradigm. This is illustrated in Figure 6 where clients are talking to Java Servlets in servers. Clients can be anything from a simple HTML form to a sophisticated Java applet.

Figure 6: Clients talking to java Servlets in servers

Servlets can be found at several different sources, this is illustrated in Figure 7. They can be found in individually administered locations (a), this can be a remote server or a local file. They can be located in the directory of Servlets (b) on the server, or they can be uploaded from authorized clients.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

24

Figure 7: Different Servlet sources

Servlets make use of the Java standard extension classes in the packages “javax.servlet”, for basic Servlet framework, and “javax.servlet.http” for Servlets that answer HTTP requests. Typical uses for HTTP Servlets include processing and storing data submitted by an HTML form, returning results from database queries to the client and maintaining and managing state information. As all other Java technologies Java Servlets are server- and platform-independent. A simple example of a Java Servlet which writes “Hello WWW” on the Web page:

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

25

import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloWWW extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " + "Transitional//EN\">\n" + "<HTML>\n" + "<HEAD><TITLE>Hello WWW</TITLE></HEAD>\n" + "<BODY>\n" + "<H1>Hello WWW</H1>\n" + "</BODY></HTML>"); }

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

26

4.4.4 JavaServer Pages (JSP)

JavaServer Pages is a technology for developing Web pages that displays dynamically-generated content. JSP pages use XML tags and scriptlets written in Java to encapsulate the logic that generates the content for the page. It passes any formatting tags directly back to the response page. In this way, JSP pages separate the page logic from its design and display. JSP pages are compiled into Servlets, and trough the Java APIs the Servlets can access different object such as JavaBeans components. A JSP page has the extension .jsp or .jspx, this tells the server that the JSP engine will process elements on this page [9]. There are two different approaches to building applications using JSP technology [11]. These two approaches are described in the JSP Model 1 and Model 2 architecture. In the Model 1 architecture the JSP page alone are responsible for processing incoming requests and replying to the client. All data access are done using beans, this separates the presentation from the content. The Model 1 architecture is well suited for simple application, but it may not be so good for advanced applications with many requests and a high number of scriptles. This is may not be a problem for developers, but it can certainly be an issue if the JSP pages are developed and maintained by designers.

Figure 8: JSP Model 1 architecture

The JSP Model 2 architecture combines both the uses of Servlets and JSP. It uses the JSP pages to generate the presentation layer and servers to perform process-intensive tasks. It is the Servlets that is in charge of processing the requests and the creation of beans or objects used by the JSP pages, and it also decide which JSP pages to forward the requests to. The JSP does no processing it self, it is only responsible for retrieving any objects or beans created by the Servlet, and for extracting dynamic contents from the Servlets. With this architecture the presentation and content are well separated, and the benefits of using the Model 2 architecture increases when complexity of the application is higher.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

27

Figure 9: JSP Model 2 architecture

An example of a JSP page that writes the date and time on the Web page: <HTML> <HEAD> <TITLE>JSP Example</TITLE> </HEAD> <BODY BGCOLOR="ffffcc"> <CENTER> <H2>Date and Time</H2> <% java.util.Date today = new java.util.Date(); out.println("Today's date is: "+today); %> </CENTER> </BODY> </HTML>

4.4.5 Apache Jakarta Tomcat

Apache Tomcat is the Servlet container that is used in the official Reference Implementation for the Java Servlet and Java Server Pages (JSP) technologies [12]. At the highest level, Tomcat is composed of two pieces. The first is the Catalina Servlet container. This engine provides the primary container for Servlets. The second is the Jasper JSP container. This means that Java Servlets can be used within it to enable programmers to use the Servlet in such things as Web pages. Whereas a JSP Web page has both HTML and Java JSP code within the same document, a Servlet is a block of code that can be reused [13]. These can then be compiled once and distributed to run on any standards compliant Servlet Container. The MWCF system uses Tomcat as a JSP/Servlet container and as a stand-alone Web server.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

28

Figure 10: Key components and connectors of Tomcat

Figure 10 illustrates the main components and connections of Tomcat, further described they are: Server: Represents the whole container. Service: An intermediate component which lives inside a Server and ties one or more

connectors to exactly one Engine. Engine: Represents request processing pipeline for a specific Service. Host: An association of a network name, e.g. www.yourcompany.com, to the Tomcat

server. Connector: Handles communications with the client. Context: Represents a Web application.

4.4.6 Struts

Struts is an open source framework for building Web applications and is a project of the The Apache Software Foundation [14]. The core of the Struts framework is a flexible control layer based on standard technologies like Java Servlets, JavaBeans, ResourceBundles, and XML, as well as various Jakarta Commons packages. Struts enables Web application development which follow the Model-View-Controller (MVC) design.

• Model - This is the data model which is usually developed by the end user of the Struts framework. This is typically the application's business logic and code to interact with a database.

• View - In a generic sense, the View is comprised of the components which make up the application's user interface. Struts utilizes JSPs to serve as the view. Struts includes a set of custom tag libraries that facilitate creating user interfaces that interacts with ActionForm beans. ActionForms capture and validate whatever input is required by the application.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

29

• Controller - This is the program control logic which accepts user input and decides how to respond. The response is generated via the View components. In Struts, the primary component of the Controller is a servlet of class ActionServlet. This servlet is configured by defining a set of ActionMappings. The ActionMappings defines wich Action a user request will be routed to. Actions encapsulate calls to business logic classes, interpret the outcome, and ultimately dispatch control to the appropriate View component to create the response.

4.4.7 MySQL

A database is a structured collection of data. To be able to add access and process data stored in a database you need a database management system. The Web-based MWCF system uses MySQL for this purpose. The MySQL database is an open source database which can freely be used for non-commercial purposes. The MySQL server contains a series of useful properties[15]:

• Multi-threading support for use on multiple CPUs. • Multiple user access • Support for APIs for several programming languages • High memory integrity

MySQL also has full support for Structured Query Language (SQL). SQL is an ANSI (American National Standards Institute) standard computer language for accessing and manipulating database systems. SQL statements are used to retrieve and update data in a database. There are many different versions of the SQL language, but to be in compliance with the ANSI standard, they must support the same major keywords in a similar manner (such as SELECT, UPDATE, DELETE, INSERT, WHERE, and others) The Web-based MWCF system uses the JDBC API to communicate with the MySQL database [16]. JDBC is a Java API that contains a set of classes and interfaces designed to support database access. JDBC supports several database technologies, including MySQL. Figure 11 shows how the JDBC architecture is structured.

Figure 11: The JDBC architecture

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

30

5. Technologies First in this Chapter the general challenges of mobile computing are described. In Chapter 5.2 and 5.3 PDA and Smartphone technology are presented and in Chapter 5.4 we discuss which of these technologies are best suited for a mobile version of the MWCF system.

5.1 Challenges of mobile computing This Chapter is based on the article “Challenges of mobile computing” by George H. Forman and John Zahorjan [2] and Alf Inge Wangs presentation of this article. This article was written in 1994, but the issues it deals with are still of current interest. More and more people are using mobile devices in their daily work, so the demand for mobile software is rising. Mobile devices like PDA (Personal Digital Assistants) and mobile telephones are used in a different way than traditional stationary computers. Thus the challenges of mobile software development are new to many developers. There are three main issues you need to think of when you are developing mobile software: communication, mobility and portability. Mobile devices depend on wireless communication which can be provided by either modulating radio waves, pulsing infrared light or by sound waves. The area a wireless network covers are called a cell, the size of a cell vary from only a few mm to several km. The main challenges of a wireless network are environmental surroundings blocking, interfering or introducing noise and echo on the signal. There are also limitations on the frequency and the power of the signal. This makes the following characteristics of wireless networks: lower band width, higher failure rate, frequent disconnections, longer delays, users outside the coverage area and the number of users reduce the band width. There are several methods to increase the performance of these networks and to avoid some of the common problems. Some of these methods are: Keep communication at a minimum, buffer data, make a good GUI that gives the user feedback on network status, use overlapping network cells for better band width, compress data for improved transfer rates and use scheduling. You also need to have in mind that a mobile device often has several interfaces like IR, Bluetooth, GSM and WLAN. Wireless networks also have a greater security risk than other networks, especially when operating over long distances. Communication can be secured by applying encryption of data, lockout of mobile clients based on ID and authentication of services, resources and users. The main issues on mobility are how to use the right/closest server, location awareness and where to store data. Mobile systems that depend on location awareness must be able to get the local configuration like time zones etc, and provide services based on the location. There are also a moral issue involved here, how to protect the user from abuse of his location. Mobile devices have to be portable, and that makes certain limitations on how the device is built. Things to keep in mind are: Weight, source of electricity, heat generation, its ability to operate under different weather conditions and noisy environment. Because of the limited screen size of mobile devices, software also has to be adapted. This means that only the most necessary should be displayed at all time. To save space alternative input devices like pen-based pointing devices, handwriting recognition, voice recognition and small keyboards can be used.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

31

A mobile device also have limited storage capacity and processing power. To make the software more efficient software should be kept as small as possible, the data amount should be reduces and servers can be used for demanding operations. MWCF is designed to deal with challenges with developing mobile systems, and the Web-based version of MWCF improves the user friendliness of the system. The MWCF tool makes it easier to find, analyse and prioritize challenges and requirements in mobile software systems. By further developing the Web-based MWCF system we hope to make the system even more helpful for developers of mobile systems.

5.2 Personal Digital Assistant (PDA) A PDA is a small hand-held device that provides computing and information storage for personal or business use. The main purpose of a PDA is to act as a personal planer and organizer, and to store information. PDAs are normally of small sizes so they easily can fit in a pocket. There are many manufacturers of PDA’s, but all share some basic features:

• Date book: The most important part of the PDA. It provides organization of meetings, appointments, etc.

• Memo pad: This feature makes it possible to make notes or other messages. Can also be used to make to-do lists.

• Calculator: An integrated calculator. • Address book: Keeps track of addresses, phone numbers, email addresses, etc. • Email: Compose and send email on HotSync or wireless. • Onscreen keyboard: Uses the touch screen for input. This makes it possible to use

handwriting instead of typing. • Synchronisation whit PC: This gives the opportunity to synchronise PDA data with

PC data. PDA’s as we think of them today was first made popular by PalmPilot. Over the years many more companies have entered the PDA marked. Today there are 2 major marked leaders, Palm devices that run the Palm OS and Microsoft Pocket PC that run Windows mobile [17]. Most Palm OS PDAs are made by palmOne and their most standard features are:

• A vast library of third-party applications (more than 20,000) that you can add to the system (most devices come bundled with e-mail, productivity, and multimedia software)

• An updated version of the Graffiti handwriting-recognition application • Synchronization with both Windows and Macintosh computers using the Palm

Desktop • Smaller displays than Pocket PCs to accommodate a dedicated Graffiti area on the

device (Some higher-end Palm devices now incorporate a virtual Graffiti area in the display, resulting in a larger display area.)

Windows mobile PDAs, known as pocket PCs, typical features are:

• Pocket versions of Microsoft applications such as Microsoft Word, Excel, and Outlook

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

32

• Synchronization with Microsoft Outlook on a Windows PC (synchronization with e-mail systems other than Outlook or with Macintosh computers requires additional software)

• Three handwriting-recognition applications: Transcriber, Letter Recognizer (similar to the new version of Graffiti), and Block Recognizer (similar to the original Graffiti)

• A virtual writing area, which maximizes the display size • Windows Media Player for multimedia content

PDAs are getting more and more advanced, and it can be hard to put them in a single category. Many PDAs come with features from mobile phones, such as sms, mms and standard phone features. PDAs are also starting to come with other features we usually know from other devises such as integrated mp3 players, cameras and GPS receivers. A good example of this is the Garmin iQue 3600 Palm OS based PDA which come with mp3 player, GPS receiver, voice recognition and all the standard PDA features. A picture of iQue 3600 is showed in Figure 12.

Figure 12: The Garmin iQue 3600 PDA

5.3 Smartphones Most phones nowadays have a calendar, a few games, and downloadable applications. But some phones go further to bring voice and data needs together, including syncing e-mail, surfing the Web, shooting pictures and supporting hundreds of third-party applications. Some of these phones have full keyboards to easily write e-mail or use other applications. This crossing between mobile phones and PDAs is called Smartphones [18]. A Smartphone is not necessary a phone with PDA capabilities, it can also be a PDA with phone capabilities.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

33

Smartphone features include e-mail and personal information storage, including phone numbers, contacts, addresses, calendar, and to-do lists. There exist hundreds of applications for Smartphones; you can perform business tasks, like reading PDFs and Excel spreadsheets. Many of these phones can also be used for entertainment such as 3D games, music and record and play back video. Most Smartphones come with a preinstalled OS that can host third-party applications. There are several available OSs, some of the most popular are:

• BlackBerry OS: This is an e-mail focused OS. It is very easy to read and send e-mail on any BlackBerry. But only a few third-party applications are available to enhance the OS. This OS is very popular in USA.

• Microsoft Windows Mobile for Smartphone: MS Windows mobile allows you to synchronize the phone with PCs, and offers many well known MS features such as an e-mail application similar with outlook.

• Palm OS: Palm OS is best known for its easy to use personal information manager, the Graffiti handwriting-recognition and for its vast range of applications.

• Symbian: Symbian is the most popular Smartphone OS in Europe. It has similar functionality as the Palm OS, and uses less memory and battery power than its competitors. Symbian supports the latest Java Community Process standards.

Smartphones are still in their infancy, but their popularity is increasing. According to analyst house Canalys Smartphone shipments increased over 100% from 2004Q2 to 2005Q2, with over twelve million devices shipped in the latter period. In a couple years, it is likely that most phones sold will be considered "smart", except for disposable phones[19].

Figure 13: Nokia 3620, Smartphone

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

34

5.4 Which technology to use One of the biggest challenges of making the MWCF system mobile is the small displays of mobile devices. This means that only the most necessary information should be displayed. Another challenge is to limit the input from the user, since input on mobile devices is more time consuming than on regular desktop computers. These to factors are very important when choosing which technology to use. Following are an overview of pros and cons of the different technologies. Smartphones Pros: Cons: Combines PDA and mobile phone functionality in a mobile phone

Limited text-entry capability

Plays videos and music files-a very portable multimedia-device

Smaller, harder to read screens than most PDAs

Strong support from third-party software developers, especially game/entertainment developers

Does not have the same set of built-in applications found on PDAs, word processing and spreadsheets are missing

Variety of accessories, including navigation systems, Bluetooth an IR

Inputting large amounts of data can be tedious

Good battery capacity, better than laptops Limited storage capacity Portable PDAs Pros: Cons: Have a better text-entry capability than most Smartphones, including handwriting-recognition

Do not have phone functionality

Strong support from third-party software developers, more office applications than Smartphones

Have a bigger screen than most Smartphones, but still the screen size is limited

Media Players for multimedia content Inputting large amounts of data can be tedious

Variety of accessories, including navigation systems, Bluetooth, IR and WLAN

Limited storage capacity, but better than Smartphones

Good battery capacity, better than laptops Portable As shown in these pros and cons PDAs and Smartphones have many similarities. They have good battery capacity, support a wide range of software and Technologies and are highly portable. The biggest different between PDAs and Smartphones are their display sizes and their input methods. Most Smartphones have smaller displays and a more limited input technology than PDAs. This applies on Smartphones that are phone based with PDA features. PDAs with phone features on the other hand have the same display sizes and input methods as other PDAs. This means that the mobile MWCF system will be best suited for PDAs, to give the best GUI as possible. PDAs also have a better text-entry capability, which is favourable because the mobile MWCF system will require text-entry.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

35

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

36

6. The MWCF system In this Chapter the different aspects of the extended MWCF system are discussed. In Chapter 6.1 the requirements are specified. The design of the system is described in Chapter 6.2. In Chapter 6.3 testing and test results are described. Finally, in Chapter 6.4 the future PDA version of the system is discussed.

6.1 Requirement specification This Chapter describes the requirements for the MWCF system. In Chapter 6.1.1 the functional requirements are specified, and in Chapter 6.1.2 the non-functional requirements are described.

6.1.1 Functional requirements

This Chapter contains the functional requirements for the implementation of the consistency checking. They are presented by graphical and textual use cases taken from Siv Oma Rogdar’s Master’s Thesis [7]. Some of the use cases have been edited to clearly show their involvement in the implementation of consistency rules. Before describing the use cases of the system, the actors of the MWCF system are defined. The actors and their relationships are illustrated in Figure 14 The user actor, who is any user which is not registered in the system, is at the top level, while the characterizer is a specialisation of the user, denoted by the generalisation relationship. The administrator is at the next level as a specialisation of the characterizer. The actors are described as follows: User The user represents an anonymous person that is not registered in the MWCF system. This person has only access to view mobile scenarios previously stored in the system and cannot enter data into the system. Characterizer This actor represents a person who wants to use the MWCF to create and characterize mobile scenarios. This person is registered in the system and can access the MWCF system with a user name and a password. The characterizer has restricted access to the system. He may view all scenarios stored in the system (like the user actor), and store scenarios and characterize these but only edit scenarios he himself has created previously. Administrator The administrator represents a person who is responsible for maintaining the MWCF system. The administrator has access rights to every part of the system and administrator rights to view and edit all data in the system.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

37

Figure 14: The actors of the system and their relationship

The main use cases (as shown in the use case diagram in Figure 15) in the system are: UC1 User Registration

Any user will be able to register in the system and create a user account provided the user has an e-mail address and has access to the Internet.

UC2 Login A characterizer will be able to log in to the system using an e-mail address and a private password.

UC3 Edit User Account The characterizer may edit his user account in the following ways: change the password, change the e-mail address and change the name that is visible to other users of the system (e-mail address if not specified). The administrator may change all user accounts in the system and may also change the access level of the users.

UC4 Administer Framework The administrator can make changes to the framework. Groups, characteristics, indicators and consistency rules can be added, edited or removed.

UC5 Administer Scenarios The characterizer may do several administrative tasks concerning mobile scenarios in the system as creating a new scenario, editing an existing scenario or deleting an existing scenario.

UC6 Administer Tasks A characterizer may add tasks to a scenario, edit existing tasks in a scenario or remove tasks from a scenario. He may specify the relationship between these tasks as pre-tasks, post-tasks or subtasks. The user may save the following information on each task: name, description, responsible (one of the roles in the scenario), preconditions: location, resources and tasks, post conditions: location, resources and tasks and dependencies: roles, composite and subtasks.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

38

UC7 Characterize Scenario

After having created a scenario, a characterizer may characterize an existing scenario by assigning each task in the scenario a value for every characteristic in the framework.

UC8 View Analysis and Interpretations Any user may view the characterization done on a scenario stored in the system and its complexity indicators.

UC9 Logout A user of the system that is logged in should log out when the user has finished using the MWCF system. This is to prevent that other persons use the access rights of the person logged in. In case a user forgets to log out, the user should be automatically logged out of the system when the user has been inactive for 1 hour.

Some of the main use cases are further divided into new use cases. These use cases are not shown in the main use case diagram (Figure 15) to keep the diagram clear and easily understandable, but are shown in the use case diagrams of the respective use cases. The main use case diagram shows the three types of actors involved in the system: the user, the characterizer and the administrator. As shown also in Figure 14, the relationship between the actors is of type generalisation. This means that a characterizer inherits the behaviour of the user actor, which means e.g. that a characterizer also has an interface to the use case ”View analysis and interpretations”. Since the administrator actor inherits the behaviour of the characterizer, the administrator also has an interface to the use case ”View analysis and interpretations”. For the use cases ”User registration” and ”View analysis and interpretations” the users of the system do not have to log in. To be able to use any of the other features of the system the users first have to log in. This is shown in the use case diagram by the include relationship to the use case ”Login”. Use case ”Administer scenarios” has an extend relationship to the use case Administer tasks; i.e. use case ”Administer scenarios” can stand alone as a single use case or its behaviour may be extended by the behaviour of the Administer tasks use case.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

39

Figure 15: Main use case diagram

In the following sections, the use cases relevant to the consistency checks are described by use case diagrams and textual use cases. The textual use cases include the following items: brief description, preconditions, actors involved, flow of events, alternative paths if they exist and post-conditions. The use cases involved in the consistency checks are: UC4 Administer Framework UC7 Characterize Scenario Use case 4: Administer framework Since the MWCF framework probably will evolve, and there might be both minor updates and fundamental changes done to the framework, it should be easy to update the MWCF system to reflect these changes. The use case ”Administer framework” consists of these administrative tasks of the MWCF framework. The tasks may be categorised according to what part of the

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

40

framework they involve, hence the use case ”Administer framework” has been divided into four new use cases, namely use case 4a: ”Administer groups”, use case 4b: ”Administer characteristics”, use case 4c: ”Administer indicators” and use case 4d: ”Administer consistency rule” (see Figure 16). “Administer indicators” is not relevant to the implementation of consistency rules and is therefore not further elaborated.

Figure 16: Use case diagram for use case 4: Administer framework

Use case 4a: Administer groups Use case ”Administer groups” is depicted in Figure 17. Brief description The administrator may make changes to the groups of the framework. This includes changing the name or description of a group, removing a group from the framework and adding a new group to the framework. Actor Administrator Preconditions The administrator is logged in and has chosen to make changes to the groups of the framework. Path of flow The main flow of events should be: 1. include (Login). The administrator chooses whether he wants to add a new group to the framework, change the name of an existing group, change the description of a group or remove a group from the framework. 2. The administrator makes the changes. If he chooses to delete a group, all characteristics in the group and the consistency rules containing these characteristics will be deleted. 3. The system confirms the changes that have been done to the system. Alternative path for any of the steps The administrator chooses not to do any changes to the groups of the framework and no updates are done to the system.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

41

Postcondition The administration of the groups in the framework results in immediate visible changes to the affected parts of the system.

Figure 17: Use case diagram for use case 4a: Administer groups

Use case 4b: Administer characteristics Use case ”Administer characteristics” is depicted in Figure 18. Brief description The administrator may make changes to the characteristics of the framework. This includes changing the name of a characteristic, changing the description of a characteristic, removing a characteristic from a group (and hence from the framework), adding a new characteristic to the framework and specifying the scale used by a characteristic. Actor Administrator Preconditions The administrator is logged in and wants to make changes to the characteristics of the framework. Path of flow The main flow of events should be: 1. include (Login). The administrator chooses whether he wants to change the name or description of an existing characteristic, remove a characteristic from a group, add a new characteristic to a group or change the scale used by a characteristic. 2. The administrator makes the changes. If he chooses to delete a characteristic, all consistency rules containing this characteristic will also be deleted. 3. The system confirms the changes that have been done to the system.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

42

Alternative path for any of the steps The administrator chooses not to make any changes to the characteristics of the framework and no updates are done to the system. Postcondition The administration of the characteristics in the framework results in immediate visible changes to the affected parts of the system.

Figure 18: Use case diagram for use case 4b: Administer characteristics

Use case 4d: Administer consistency rules Use case ”Administer consistency rules” is depicted in Figure 19. Brief description The administrator may make changes to the consistency rules. The consistency rules are used by the system to check the consistency when users characterize tasks. The administration of the consistency rules includes creating a new rule, changing an existing rule, or deleting a rule. Actor Administrator Preconditions The administrator is logged in and has chosen to make changes to the consistency rules. Path of flow The main flow of events should be: 1. include (Login). The administrator chooses whether he wants to create a new consistency rule, change an existing rule or delete an existing rule.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

43

Figure 19: Use case diagram for use case 4d: Administer consistency rules

2. The administrator makes the changes. 3. The system confirms the changes that have been done to the system. Alternative path for any of the steps The administrator chooses not to do any changes to the consistency rules and no updates are done to the system. Postcondition The administration of the consistency rules results in immediate visible changes to the affected parts of the system. Use case 7: Characterize scenario A use case diagram for use case ”Characterize scenario” is depicted in Figure 20. Brief description After having created a scenario, a characterizer may characterize an existing scenario by assigning each task in the scenario a value for every characteristic in the framework. Actor Characterizer Preconditions The user is logged in and has previously created a scenario, which the user now wants to characterize. Path of flow The main flow of events should be: 1. include (Login). The user chooses the scenario to characterize. 2. The next steps are repeated for each task in the scenario that the user wants to characterize at this point: (a) The user chooses a task to characterize. (b) The user assigns the task a weight between 1 and 5, specifying the importance of the task. (c) The user assigns the task a value on every characteristic in the framework. (d) The user saves the characterization done to the task.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

44

(e) If the user has assigned values that are conflicting, i.e. not in accordance with the rules for data consistency (see Chapter 2.3), the user will be made aware of what the conflicts are and may choose to revise the characterization or leave it as it is. 3. The user finishes the characterization and may view the analysis and interpretations for this scenario if desirable. Postcondition The characterization is stored in the system, and the calculated complexity indicators may be viewed.

Figure 20: Use case diagram for use case 7: Characterize scenario

6.1.2 Non-Functional requirements

This Chapter describes the non-functional requirements to the system. The requirements are taken from Siv Oma Rogdar’s Master’s Thesis [7], some have been edited or removed to fit the context of the project. The implementation of consistency checking shall follow these requirements. Lifespan The system shall be ready for delivery on the 20th of December 2005. After this date the members of the project group will be developing the PDA part of the system. Interfaces to Web All of the features of the system must be available for use by a Web browser. Screen resolution The Web system will be optimized for personal computer screen resolutions of 1024 * 768 and for PDAs with screen resolutions of 240*320 pixels.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

45

Usability The Web system for the characterization framework will be easy to use in the sense that the user will be guided through the characterization process. The user will also be guided through the creation of a scenario. The user will be notified if he has entered any contradictory data when characterizing a scenario. For this, the rules for inconsistencies of Chapter 4.3 will be used. Modifiability of framework It should be easy to modify the system to reflect changes made in the framework. Therefore, use case 4: Administer framework has been included as one of the functional requirements to make it easy to change the framework in terms of groups, characteristics, indicators and consistency rules(see Chapter 6.1.1). Extensibility of framework In addition to allowing for modifications of the existing components of the framework, the system should allow for more fundamental changes, such as extensions to the framework by e.g. adding new components to the framework. The GUI will not take any considerations to this fact, but the system as a whole should be made such that this is possible.

6.2 Design This Chapter contains the database design and sequence diagrams for the extended MWCF system. For more information about the database design and sequence diagrams for the complete system read Siv Oma Rogdar’s Master’s Thesis [7].

6.2.1 Database design

To let the system handle different types of rules the database stores fragments of rules. A fragment consists of a characteristic id, an operator, a value and a relation. A rule is then built up by two or more rule fragments. Rule 1 from Chapter 4.3 (I3 " 4 V I4 " 4 ! I5 " 4) consists of three fragments (I3 " 4 V), (I4 " 4 !) and (I5 " 4 end). By using this design the system can handle rules with different lengths and therefore also more complex rules. The “RULE_ID” identifies the fragments of a complete rule and makes it easier to retrieve a specific rule. T_RULE Attribute name Data type Description RULEFRAGMENT_ID int The unique identifier of a rule fragment RULE_ID int The identifier of a complete rule RELATION varchar The relation with the next fragment (OR,

THEN, END) CHARACTERISTIC varchar The name of the characteristic CHARACTERISTIC_ID int The id of the characteristic VALUE int The fragment value OPERATOR varchar The operator (GE, EQ) NAME varchar The name of the rule WARNING varchar The warning to be displayed if the rule is

violated

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

46

6.2.2 Sequence diagrams

In this Chapter the sequence diagrams of use case 4d “Administer consistency rules” and the validation part of use case 7 “Characterize scenario” are presented. The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how the objects interact with others in a particular scenario of a use case [20]. Use Case 4d Administer consistency rules Use case 4d “Administer consistency rules” has been divided into 4 sequence diagrams, the first two for adding a new rule to the framework, one for editing an existing rule and one for the deletion of a rule.

Figure 21: Administer consistency rules

Figure 21 shows the sequence of events when the administrator presses the “add fragment” or “remove fragment” button. A rule consists of two or more fragments, the fragments are stored in the form until the rule is saved or the fragment is removed. In Figure 22 the sequence diagram for when the administrator presses the “save rule” button is shown. The relevant information is now transferred to the RuleBean and stored in the database.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

47

Figure 22: Add fragment

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

48

Figure 23: Getting a rule from the database

The sequence diagram for editing a rule is very similar to the sequence diagram of adding a rule and is therefore not fully shown here. The only difference is that when the administrator chooses to edit a rule, the system will get that specific rule from the database and populate the “edit rule” page with this information. When adding a new rule the page will be empty. The rest of the sequence is equal for both the adding and editing of a rule. The sequence diagram for getting a specific rule from the database and setting the information in the appropriate form is shown in Figure 23.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

49

Figure 24: Delete rule

Figure 4 shows the sequence diagram for the deletion of a rule. The “RuleBean” will remove every instance of T_RULE containing the specific “ruleID”. Use Case 7 Characterize scenario When a user has completed his characterization of a task, he gets the option to validate it against the consistency rules. Figure 25 shows the sequence of events when a user presses the validate button. The “ValidateCharAction” gets the characterization of the task and the consistency rules from the database and checks if there are any violations of the rules. If there are violations, the relevant information to be displayed to the user is stored in the “ValidateCharForm”.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

50

Figure 25: Validate

6.3 Implementation This Chapter contains the details about the implementation of expansion of the MWCF System. First a summary of the technologies used for implementing and running the system, then a description of the database implementation and finally some details about the implementation of the new functionality.

6.3.2 Technologies

This Chapter contains a short summary of the technologies relevant to the system, and a description of problems experienced with these technologies 6.3.2.1 Technologies used for the implementation The following technologies have been used to implement the new functionality to the MWCF System.

• Java Development Kit Java 2 SDK, version 1.4.2_06 has been used during the implementation.

• JDBC Database Access The JDBC 2.1 API has been used for implementing access to the database.

• Jakarta Struts Framework The Struts 1.0.2 framework has been used for implementation.

• Database The MySQL database server, version 4.1 has been used to store data in the MWCF System

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

51

All coding has been done in JCreator 3.50. 6.3.2.2 Technologies used for running the MWCF System The following software has been used for running the MWCF System.

• Servlet/JSP and Web Container Tomcat 4.1 has been used both as the Servlet/JSP container and as a stand-alone Web server.

• Internet browser Microsoft Internet Explorer, version 6.0 has been used when testing the system.

6.2.2.3 Problems with installing When installing the MWCF system we discovered some compatibility problems with the MySQL 4.1.14 server and the Java connector driver, this was resolved using the “mysql-connector-java-3.2.0-alpha”. There where also some issues with the JSP-parsing and Tomcat 5.5.9, so we had to use Tomcat 4.1.31 instead.

6.2.3 Database implementation

The design of the additions to the database compared to the old MWCF system is explained in Chapter 6.2.1 along with an explanation of the table “T_RULE”. The database was implemented on a MySQL server using SQL code. The following code is a fragment of the SQL code used to create the database tables, a complete listing of the SQL can be found in the appendix.

#---------------------------- # Table structure for T_RULE #---------------------------- drop table if exists T_RULE; create table T_RULE ( RULEFRAGMENT_ID int(11) not null auto_increment, RULE_ID int(11) not null default '0', RELATION varchar(255) not null, CHARACTERISTIC varchar(255) not null, CHARACTERISTIC_ID int(11) not null default '0', VALUE int(11) not null default '0', OPERATOR varchar(255) not null, NAME varchar(255), WARNING varchar(255), primary key (RULEFRAGMENT_ID)) type=MyISAM; #---------------------------- # Table structure for T_SCENARIO #---------------------------- drop table if exists T_SCENARIO; create table T_SCENARIO ( SCENARIO_ID int(11) not null auto_increment, NAME varchar(100) not null, DESCRIPTION varchar(255),

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

52

USER_ID int(11) not null default '0', primary key (SCENARIO_ID)) type=MyISAM; #---------------------------- # Table structure for T_TASK #---------------------------- drop table if exists T_TASK; create table T_TASK ( TASK_ID int(11) not null auto_increment, NAME varchar(255) not null, DESCRIPTION varchar(255), PRE_LOCATION varchar(255), PRE_RESOURCES varchar(255), POST_LOCATION varchar(255), POST_RESOURCES varchar(255), ROLE_ID int(11), COMPOSITE char(3), WEIGHT int(11) default '0', primary key (TASK_ID)) type=MyISAM; #----------------------------------------- # Create an administrator of the MWCF site #----------------------------------------- insert into T_USER (EMAIL, PASSWORD, NAME, ACCESSLEVEL) values ('admin@mwcf.com', 'admin', 'Default name', 'a');

6.2.4 The extended MWCF Application

This Chapter describes the new functionality implemented in the MWCF System. The main parts are the functionality to add and delete consistency rules and to validate the characterization of a task against these rules. There have also been some minor changes and additions in the user interface. 6.2.4.1 Add/delete rule When adding a new rule the user has to type the name of the rule and the warning to be displayed when the rule is violated. The logic of the rule is entered into the system fragment by fragment as explained in Chapter 7.1. For each fragment the administrator selects values from dropdown boxes. This has been done to provide flexibility as to the length of the rules, i.e. a rule can consist of two or more fragments, and to make sure the rules follow a specific format with known values to make the validation process more manageable. 6.2.4.2 Validate Characteristic The validation process compares a users’ characterization of a task to the consistency rules stored in the database. If there are any violations of the rules the user is informed and may make changes accordingly. The following code shows the how the system checks each rule fragment for violations and adds the information to be displayed to the user in the ValidateCharacteristicForm(“vform”) when a violation occurs.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

53

1. if((vform != null) && (vform.getSubmit() != null) &&(vform.getSubmit().equals("Validate"))) {

2. RuleBean rules = new RuleBean(); 3. TaskBean task = (TaskBean) session.getAttribute("task"); 4. task.getCharacterizationsOfTaskFromDB(conn, errors); 5. Vector fragments; 6. RuleBean testRule = new RuleBean(); 7. Hashtable characterization = task.getCharacterization(); 8. rules.getAllRulesFromDB(conn, errors); 9. fragments = rules.getRules(); 10. int i = 0; 11. int j = 0; 12. Integer val; 13. boolean ftest = false; 14. boolean broken = false; 15. while(i < fragments.size()) { 16. testRule = (RuleBean)fragments.elementAt(i);

17. if(!testRule.getRelation().equals("end")){ 18. if(testRule.getOperator().equals("ge")) { 19. val = (Integer)characterization.get(new

Integer(testRule.getCharacteristicID())); 20. if(val.intValue() >= testRule.getValue()) { 21. ftest = true; 22. } 23. } 24. if(testRule.getOperator().equals("eq")) { 25. val = (Integer)characterization.get(new

Integer(testRule.getCharacteristicID())); 26. if(val.intValue() == testRule.getValue()) { 27. ftest = true; 28. } 29. } 30. } 31. if(testRule.getRelation().equals("end") && ftest) { 32. if(testRule.getOperator().equals("ge")) { 33. val = (Integer)characterization.get(new

Integer(testRule.getCharacteristicID())); 34. if(val.intValue() < testRule.getValue()) { 35. broken = true; 36. } 37. } 38. if(testRule.getOperator().equals("eq")) { 39. val = (Integer)characterization.get(new

Integer(testRule.getCharacteristicID()));

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

54

40. if(val.intValue() != testRule.getValue()) { 41. broken = true; 42. } 43. } 44. if(broken) { 45. vform.addBrokenRule(testRule.getName()); 46. vform.addBrokenRule(testRule.getWarning()); 47. for(int k = j; k <= i; k++) { 48. testRule = (RuleBean)fragments.elementAt(k); 49. vform.addBrokenRule(testRule.getCharacteristic()); 50. vform.addBrokenRule(testRule.getOperator()); 51. vform.addBrokenRule(new

Integer(testRule.getValue())); 52. vform.addBrokenRule((Integer)characterization.get(new

Integer(testRule.getCharacteristicID()))); 53. vform.addBrokenRule(testRule.getRelation()); 54. } 55. returnString = "broken"; 56. broken = false; 57. } 58. j = i + 1; 59. ftest = false; 60. } 61. if(testRule.getRelation().equals("end") && !ftest) 62. j = i + 1; 63. i++; 64. } 65. }

The “if” sentence from line 17 to line 30 contains the code for checking all the fragments in a rule, except the last fragment, against the values characterized in the task. If there is a violation in one of these fragments the “ftest” variable is set “true”. When the last fragment of a rule is loaded into the “testRule” variable it will only be checked against the characterization if the “ftest” variable is “true”, line 31, otherwise the next fragment is loaded. If the last fragment is checked and one of the “if” sentences on line 34 or 40 succeeds there is a violation of the rule and all the necessary information is added to the “vform” variable.

6.4 Testing Software testing is a process to help identify the correctness, completeness and quality of developed software. This Chapter contains the test plans, test results and test methods used on the extended MWCF system.

6.4.1 Test methods

There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation, not merely a matter of creating and following rote procedure. The test methods used in this project are unit and module testing. A unit test is a procedure to verify that a particular module of source code is working properly. Ideally each test case is separate from the others. Module testing consists of testing a collection of

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

55

depended components, such as an object class or a collection of functions. The testing was carried out during and after developing the different components in the system.

6.4.2 Functional requirements test plan

These tests are based on the functional requirements in Chapter 6.1.1 6.4.2.1 Administer consistency rules T01: Test if it is possible to create a new rule fragment T02: Test if it is possible to delete a rule fragment T03: Test if it is possible to create a new rule T04: Test if it is possible to delete a rule T05: Test if it is possible to edit a rule 6.4.2.2 Characterize scenario T06: Test if the user is given a warning when assigning values to characteristics which are not

consistent according to the consistency rules.

6.4.3 Functional requirement test results

In this Chapter the test results for the functional requirements are documented. A test can either be approved or rejected. Comments are given if a test I rejected or in special cases. Test Approved Rejected Comments T01 X T02 X T03 X T04 X T05 X Edit rule not implemented T06 X

6.4.4 Non-functional requirements test plan

These tests are based on the non-functional requirements in Chapter 6.1.2 6.4.4.1 Lifespan NT01: Is the system ready for delivery December 20th 2005? 6.4.4.2 Interfaces to Web NT02: Test if all features are available for use by a Web browser

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

56

6.4.4.3 Screen resolution NT03: Test if the Web pages are viewable with a screen resolution 1024 * 768 pixels 6.4.4.4 Usability NT04: Test if the user is notified when entering contradictory data. 6.4.4.5 Extensibility of framework NT05: Is it possible to extend the system with new components of the MWCF framework?

6.4.5 Non-functional requirement test results

In this Chapter the test results for the non-functional requirements are documented. A test can either be approved or rejected. Comments are given if a test I rejected or in special cases. Test Approved Rejected Comments

NT01 X NT02 X GUI does not work as intended with Opera, some

elements get wrong colours and placement NT03 X NT04 X NT05 X

6.5 Adapting the MWCF system for PDA When developing a MWCF system for PDAs and other handheld devices, there are several factors to consider. One thing to consider is the internet connection on the PDA. The Web-based MWCF system uses sessions to authorise users and give access to the functions the user is registered for. If the system is going to keep the structure it has today the user has to be online while using the system. It is not sufficient to download the information in front or use synchronising techniques for updating the Web content. So to keep the basic structure of the MWCF system, using Struts and its Model-View-Controller design pattern, the PDA have to be able to access the internet at the time the user want to use the MWCF PDA system. Another important aspect to consider when adapting the MWCF system for PDAs is the small screen size of these devices. The current Web pages of the MWCF system should not be used because they are optimised for bigger screen resolutions. Most PDAs have a display width of 240 pixels. This sets the maximum width of Web pages viewable on a PDA without horizontal scrolling. To avoid horizontal scrolling the amount of data shown on a page have to be greatly limited. In order to make a PDA version of the MWCF system the Web page hierarchy has to be reordered, and the content has to be spread over a bigger number of pages. Some of the functionality of the current MWCF system is not needed on a PDA version of the system. First of all this include removing the administer part of the system. Administrating the system is not something that is needed on a regular basis, so it is sufficient to have this functionality only on the Web-based system. Jakub Hajduk has started planning a PDA version of the MWCF system in his Master thesis [8]. He has planned a system which has functionality for viewing scenarios that have previously been characterized. This includes

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

57

viewing characterizations and characteristic details, retrieving complexity indicator calculations and viewing complexity indicator details. This means the user only can retrieve information from the PDA-based MWCF system, and not modify them. The main advantage of this is that it limits the user input. The disadvantage of this design is that the user has no possibility of changing the characterizations. When the system is used out in the field the user might want to change the characterization based on new information gathered. By including the characterization option in the PDA system the system becomes more usable and flexible. This means the user can enter the scenario in to the Web-based MWCF system, and then do the characterization out in the field where the actual scenario takes place. As described in the previous paragraphs, the adaptation of the MWCF system for use on PDAs requires a major reconstruction of the Web pages. Since the MWCF system uses Struts and its Model-View-Controller design pattern it is however possible to keep much of the same structure of the business logic that already exist in the Web-based MWCF system. It is the presentation part of the system that has to be reconstructed to fit the demands of the limited screen sizes on PDAs.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

58

7. User guide This Chapter describes how to use the new features in the MWCF system. Chapter 7.1 explains how to add new consistency rules when the user is logged in as an administrator. In Chapter 7.2 it is explained how the user can validate the task values according to the consistency rules. A complete user guide for the MWCF system exists in Siv Oma Rogdar’s Master’s Thesis [7].

7.1 Administer consistency rules Only administrators of the MWCF system can administer consistency rules. To retrieve an overview of the consistency rules the user has to click the “framework” link in the administer menu. On the framework page all the groups, complexity indicators and consistency rules are listed, as shown in Figure 26. The user can delete a consistency rule by clicking the “remove from framework” link on the right side of the rule.

Figure 26: Framework

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

59

To add a consistency rule, the user clicks the “add new consistency rule” link. The user then enters the page shown in Figure 27. First the user must enter the name of the rule and the warning. Then the user has to enter the rule in fragments. A fragment consists of a characteristic id, an operator, a value and a relation. When a fragment is entered, the user pushes the “Add fragment” button. The fragment is then showed in the “Rule” field. The user repeats this action until the whole rule is entered. The last fragment must have “(end)” as the relation. After the last fragment is added the user must push the “save rule” button to save the rule in the framework. When the rule is saved the user will be taken back to the framework page.

Figure 27: Add new consistency rule

7.2 Validate characterization After the user has finished the characterization for a task in a scenario the user now has the choice to validate the characterization to check for consistency issues. This is done by pressing the “validate” button at the bottom of the characterization page, as illustrated in Figure 28.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

60

Figure 28: Validate characterization

If any of the consistency rules are broken they are listed in a table at the bottom of the page (Figure 29). In this table the names, warnings, rules and user values are listed. These results are not errors, but a warning that the user’s characterization may be inconsistent. If the user believes that the characterization is correct, there is no need to change it.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

61

Figure 29: Broken consistency rules

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

62

8. Results The extended MWCF system includes functionality to administer consistency rules and applying these rules to the characterization of tasks. The main difference between the old MWCF Web-system and the extended MWCF system from a normal user’s point of view is that the user now gets warnings if he/she violates the consistency rules. The user can choose to change his/her characterization values according to the warnings, or the warnings can be ignored. This makes the system more user-friendly and flexible. The add consistency rule functionality is a new feature in the MWCF system. To add a consistency rule the administrator adds the rules in fragments. By splitting up the rules in to fragments the rules can be of variable length and structure. The code that checks the consistency of characterizations is also made so it can manage rules with different length and structure. This makes the consistency rules very flexible, and it also allows them to be applied to other frameworks than the MWCF. We have also started planning of a PDA version of the MWCF framework. This will allow developers to use the MWCF tool out in the field. If the users can apply characteristics to the scenarios or view the characteristics where the scenarios actually takes place the results can be more accurate. We have used much of the time during this project for pre-study. This includes getting to know the different technologies used in the MWCF system and studying the code it self.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

63

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

64

9. Evaluation and discussion The extended MWCF system is up and running, and the consistency checking and adding consistency rules works as intended. The system is made flexible, so it can easily be applied to other frameworks. The code standard and structure used in the original MWCF system has been maintained, so the extended system has the same modifiability as the original system. We planned to use four weeks on the implementation (see Chapter 2.1), but since the task was more complicated than we could foresee we decided to use another three weeks on it. By doing this the MWCF system became more complete, and the add consistency rule feature became more flexible. Even though more time was spent on the implementation we still had to cut down on the functionality implemented, this means the edit rule feature has not implemented. The design and planning of a PDA based version of the MWCF system is not fully completed. It includes a study of the different technologies the system will run on (see Chapter 5) and an outline of the system and its functionality (see Chapter 6.5).

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

65

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

66

10. Conclusion and further work The main goals of this project were to implement consistency checks for the characterization of a task and to plan and design the development of a PDA interface for the MWCF system. During the project a large amount of the time has been spent on getting to know the MWCF system and the technologies supporting it. In addition the implementation of the consistency rules was also more time consuming than what planned for. This resulted in the need to prioritize some parts of the project in favour of other parts. The first goal of the project has been met. The MWCF system now gives the user an option to validate his characterization of a task against a set of consistency rules and an administrator of the system can administer these rules via the “administer framework” page. There are still some improvements to be made to make the validation process more user-friendly. Some work still needs to be done before the user easily can change his characterization according to the results of the validation. Functionality to make the administrator able to edit consistency rules already entered into the system also needs to be implemented. When deleting characteristics, rules related to these characteristics should also be deleted, this has not yet been implemented. Most of the improvements needed to further enhance the system can easily be implemented and should not be very time consuming. The second goal has only partially been met. Due to time constraints and a focus on implementing consistency rules, there was not spent enough time on this part of the project to make it complete. Because of this, some work still needs to be done before a satisfactory design is reached.

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

67

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

68

Appendix A - References [1] The Telework Advisory Group. Online 2005 Available from:

http://www.workingfromanywhere.org/index.htm [Accessed November, 2005] [2] George H. Forman and John Zahorjan. Challenges of mobile computing. Article 1994 [3] Mobile Wireless Network Research Group. Online 2005. Available from:

http://www.research.att.com/areas/wireless/ [Accessed November, 2005] [4] MOWAHS - Mobile Work Across Heterogenous System. Online 2001. Available from:

www.mowahs.com [Accessed September, 2005] [5] Carl-Fredrik Sørensen, Alf Inge Wang, Hien Nam Le, Heri Ramampiaro, Mads Nygård,

And Reidar Conradi. The MOWAHS characterization framework for mobile work.In Proc. IASTED International Conference on Applied Informatics 2002 (AI’2002), Innsbruck, Austria, 18-21, February, 2002.

[6] Heri Ramampiaro, Alf Inge Wang, Carl-Fredrik Sørensen, Hien Nam Le, and Mads

Nygård. Requirement Indicators for Mobile Work: The MOWAHS Approach. Technical Report, Dept. of Computer and Information Science, NTNU, 2001.

[7] Siv Oma Rogdar. A Web system for characterising mobile work. Master thesis at NTNU,

July 2003. Provided by MOWAHS project manager Alf Inge Wang. [8] Jakub Hajduk. Extension of the Web system for the Mobile Work Characterization

Framework. Master thesis at NTNU, June 2004, provided by MOWAHS project manager Alf Inge Wang.

[9] Sun Developer Network. Online 2005. Available from: http://java.sun.com [Accessed

November, 2005] [10] Dr. Bob’s Introduction to Java Beans. Online 2005 Available from:

http://www.drbob42.com/JBuilder/jb210t.htm [Accessed November, 2005] [11] Java World. Online 2005. Available from: http://www.javaworld.com [Accessed October, 2005] [12] Apache Tomcat. Online 2005. Available from: http://jakarta.apache.org/tomcat

[Accessed November, 2005] [13] The Tomcat Book Project. Online 2005. Available from:

http://tomcatbook.sourceforge.net [Accessed November, 2005] [14] Apache Struts Project. Online 2005. Available from: http://struts.apache.org [Accessed

November, 2005] [15] MySQL 5.0 Reference Manual. Online 2005. Available from:

http://dev.mysql.com/doc/refman/5.0/en [Accessed November, 2005]

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

69

[16] O’Reilly Online Catalog. Online 2005. Available from:

http://www.oreilly.com/catalog/prdindex.html [Accessed November, 2005] [17] How Stuff Work. Online 2005. Available from: http://electronics.howstuffworks.com

[Accessed October, 2005] [18] PC Magazine – Smart Phones. Online 2004. Available from:

http://www.pcmag.com/article2/0,1759,1651067,00.asp [Accessed December, 2005] [19] Canalys. Online 2005. Available from: http://www.canalys.com [Accessed December,

2005] [20] Visual Paradigm – UML 2 Diagrams. Online 2005. Available from: http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html [Accessed December, 2005]

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

70

Appendix B - SQL code This appendix contains SQL code for creating the database tables: #---------------------------- # Table structure for T_CHAR_VALUE #---------------------------- drop table if exists T_CHAR_VALUE; create table T_CHAR_VALUE ( CHARACTERISTIC_ID int(11) not null default '0', VALUE int(11) not null default '0', DESCRIPTION varchar(255) not null, primary key (CHARACTERISTIC_ID, VALUE)) type=MyISAM; #---------------------------- # Table structure for T_CHARACTERISTIC #---------------------------- drop table if exists T_CHARACTERISTIC; create table T_CHARACTERISTIC ( CHARACTERISTIC_ID int(11) not null auto_increment, NAME varchar(255) not null, DESCRIPTION varchar(255) not null, GROUP_ID int(11) not null default '0', primary key (CHARACTERISTIC_ID)) type=MyISAM; #---------------------------- # Table structure for T_DEPENDENCIES #---------------------------- drop table if exists T_DEPENDENCIES; create table T_DEPENDENCIES ( ROLE_ID int(11) not null default '0', TASK_ID int(11) not null default '0', primary key (TASK_ID, ROLE_ID)) type=MyISAM; #---------------------------- # Table structure for T_GROUP #---------------------------- drop table if exists T_GROUP; create table T_GROUP ( GROUP_ID int(11) not null auto_increment, NAME varchar(255) not null, DESCRIPTION varchar(255) not null, primary key (GROUP_ID)) type=MyISAM; #---------------------------- # Table structure for T_INDICATOR #---------------------------- drop table if exists T_INDICATOR; create table T_INDICATOR (

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

71

INDICATOR_ID int(11) not null auto_increment, NAME varchar(255) not null, DESCRIPTION blob not null, primary key (INDICATOR_ID)) type=MyISAM; #---------------------------- # Table structure for T_INVOLVEMENT #---------------------------- drop table if exists T_INVOLVEMENT; create table T_INVOLVEMENT ( KEY_CHARACTERISTIC char(1) not null, CHARACTERISTIC_ID int(11) not null default '0', INDICATOR_ID int(11) not null default '0', primary key (INDICATOR_ID, CHARACTERISTIC_ID)) type=MyISAM; #---------------------------- # Table structure for T_ROLE #---------------------------- drop table if exists T_ROLE; create table T_ROLE ( ROLE_ID int(11) not null auto_increment, NAME varchar(100) not null, SCENARIO_ID int(11) not null default '0', primary key (ROLE_ID)) type=MyISAM; #---------------------------- # Table structure for T_RULE #---------------------------- drop table if exists T_RULE; create table T_RULE ( RULEFRAGMENT_ID int(11) not null auto_increment, RULE_ID int(11) not null default '0', RELATION varchar(255) not null, CHARACTERISTIC varchar(255) not null, CHARACTERISTIC_ID int(11) not null default '0', VALUE int(11) not null default '0', OPERATOR varchar(255) not null, NAME varchar(255), WARNING varchar(255), primary key (RULEFRAGMENT_ID)) type=MyISAM; #---------------------------- # Table structure for T_SCENARIO #---------------------------- drop table if exists T_SCENARIO; create table T_SCENARIO ( SCENARIO_ID int(11) not null auto_increment, NAME varchar(100) not null, DESCRIPTION varchar(255), USER_ID int(11) not null default '0',

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

72

primary key (SCENARIO_ID)) type=MyISAM; #---------------------------- # Table structure for T_TASK #---------------------------- drop table if exists T_TASK; create table T_TASK ( TASK_ID int(11) not null auto_increment, NAME varchar(255) not null, DESCRIPTION varchar(255), PRE_LOCATION varchar(255), PRE_RESOURCES varchar(255), POST_LOCATION varchar(255), POST_RESOURCES varchar(255), ROLE_ID int(11), COMPOSITE char(3), WEIGHT int(11) default '0', primary key (TASK_ID)) type=MyISAM; #---------------------------- # Table structure for T_TASK_CHAR #---------------------------- drop table if exists T_TASK_CHAR; create table T_TASK_CHAR ( TASK_ID int(11) not null default '0', CHARACTERISTIC_ID int(11) not null default '0', VALUE int(11) not null default '0', primary key (TASK_ID, CHARACTERISTIC_ID, VALUE)) type=MyISAM; #---------------------------- # Table structure for T_TASK_DEPENDENCY #---------------------------- drop table if exists T_TASK_DEPENDENCY; create table T_TASK_DEPENDENCY ( TASK_ID int(11) not null default '0', DEPENDENT_TASK_ID int(11) not null default '0', CONDITION_TYPE varchar(20) not null, primary key (TASK_ID, DEPENDENT_TASK_ID)) type=MyISAM; #---------------------------- # Table structure for T_USER #---------------------------- drop table if exists T_USER; create table T_USER ( USER_ID int(11) not null auto_increment, EMAIL varchar(50) not null, `PASSWORD` varchar(20) not null, NAME varchar(100), ACCESSLEVEL char(1) not null, primary key (USER_ID))

!"#$%&'()*+,*+"(-&'&%."(/$()*+#"+012345+'#66&"&'/+7,'+6,8($.+#'8&(-+

73

type=MyISAM; #----------------------------------------- # Create an administrator of the MWCF site #----------------------------------------- insert into T_USER (EMAIL, PASSWORD, NAME, ACCESSLEVEL) values ('admin@mwcf.com', 'admin', 'Default name', 'a');