Using existing software to
build a virtual community for telemedicine
P.G. Hoekerd Telematics MSc. final thesis June 2013
Graduation committee University of Twente Dr. Ir. B.J.F. van Beijnum Prof. Dr. Ir. H.J. Hermens Biomedical Signals and Systems group Dr. Ir. M.J. van Sinderen
Abstract
In the recent years, the field on telemedicine has become an interesting area for research. Telemedicine is considered one of the solutions to maintain the current level of healthcare despite the aging population. Another application in the field of telemedicine is to help people to do more exercises, which will decreases chronic diseases and increase the standard of living. When doing research in the field of telemedicine, new applications will be developed. For these applications to be used optimally, they should be incorporated into a single platform. This would allow the applications to collaborate, and offer a single point of access to the user. Therefore there is the need for a platform which can be extended with applications used for research in the field of telemedicine.
In this platform, users are put into different groups, each group having a specific goal. Within each group, different users can have different roles. An online group with a specific goal and guided by policies can be considered a Virtual Community. Virtual Communities are particularly effective for telemedicine applications concerning group therapy; studies have shown that for chronic diseases requiring lifestyle changes, group therapy is an effective approach. A virtual community is typically carried out on a web based platform.
There are three distinctly different directions which can be taken to acquire a platform which can be used to extend with telemedicine functionality. The first approach is to build a platform from scratch, which has the disadvantage of requiring much work developing it. Another approach is to join an existing hosted platform, which has the disadvantage of being completely reliable on the provider of this platform. A final approach is to use an existing software platform, and host this platform ourselves. This approach has none of the disadvantages mentioned above, and this research takes this approach and investigates the possibilities, as well as the advantages and disadvantages of the existing software platform which can be used.
In this research, advice about the platform used to build a Virtual Community for telemedicine is given. This advice consists of two parts; advice is given about both which platform is most suitable to be used as a platform to be extended with telemedicine applications, as well as advice about the advantages and disadvantages of using that platform compared to building one from scratch. To be able to provide the advice about the suitability of a platform, first a set of requirements for this platform is composed by investigating previous researches. Next, research is done into existing platforms and a list of potential platforms is composed by first defining several search directions, creating a set of search terms based on these directions, and using these terms to search online. Using the requirements, the existing platforms are analyzed, and the most suitable platforms are taken. To be able to provide advice about the suitability of the remaining platforms, a case study is done. First, a typical scenario of a telemedicine application is defined. Using this scenario, a set of use cases is defined, which are implemented for the taken platforms. The required work and results are used to make a final statement about the most suitable platform, as well as a statement about how suitable the approach taken to use an existing platform is and the suitability of this most suitable platform.
ii
Table of Contents 1 Introduction ...... 1 1.1 Motivation ...... 1 1.2 Background ...... 2 1.3 Problem Statement ...... 4 1.4 Research question ...... 5 1.5 Approach ...... 7 1.6 Thesis Structure ...... 9 2 Requirements ...... 10 2.1 Introduction ...... 10 2.2 Scope & Existing papers ...... 10 2.3 Approach ...... 11 2.4 Requirements from previous research papers ...... 13 2.5 Additional requirements ...... 20 2.6 Summary ...... 22 2.7 Conclusion ...... 24 3 Platform selection and evaluation ...... 25 3.1 Introduction ...... 25 3.2 Search directions ...... 27 3.3 Platform selection ...... 28 3.4 Round 1: Quick evaluation ...... 31 3.5 Round 2: Priority A evaluation ...... 33 3.5.1 Elgg ...... 34 3.5.2 Dolphin ...... 36 3.5.3 WordPress – BuddyPress ...... 37 3.5.4 Mahara ...... 38 3.5.5 Anahita ...... 40 3.5.6 Drupal – Commons ...... 41 3.5.7 Oxwall...... 42 3.5.8 Liferay ...... 43 3.5.9 GateIn ...... 44 3.5.10 Summary ...... 45 3.5.11 Discussion...... 46 3.6 Conclusion ...... 49 4 Platform analysis ...... 50 4.1 Introduction ...... 50 4.2 Approach ...... 50 4.3 Multi Criteria Analysis ...... 52
iii
4.3.1 Priority based linear additive multi criteria analysis ...... 52 4.3.2 MCA conclusion ...... 53 4.4 Multi Criteria Analysis discussion ...... 53 4.5 Conclusion ...... 58 5 Case study ...... 59 5.1 Introduction ...... 59 5.2 Case study description ...... 59 5.2.1 Scenario ...... 59 5.2.2 Use cases ...... 60 5.2.3 Summary ...... 63 5.3 Drupal case study ...... 64 5.3.1 Development environment ...... 64 5.3.2 Use cases ...... 64 5.4 Liferay ...... 69 5.4.1 Development environment ...... 69 5.4.2 Use cases ...... 70 5.5 Summary ...... 76 5.5.1 Development environments ...... 76 5.5.2 Evaluation per use case ...... 76 5.5.3 Summary ...... 77 5.6 Conclusion ...... 78 6 Conclusion, discussion and recommendations ...... 79 6.1 Conclusion ...... 79 6.2 Discussion ...... 82 6.3 Recommendations ...... 83 7 Terminology ...... 85 8 Bibliography ...... 86 9 Appendices ...... 90 9.1 Appendix A: Primary and secondary sources ...... 90 9.2 Appendix B: Search results ...... 92 9.3 Appendix C: Requirement evaluation results ...... 94 9.4 Appendix D: Analysis results ...... 95
List of figures Figure 1: MVC platform component overview ...... 2 Figure 2: General approach ...... 7 Figure 3: Evaluation approach ...... 25 Figure 4: Search approach ...... 26
iv
Figure 5: Platform composition summary ...... 31 Figure 6: Quick evaluation summary ...... 33 Figure 7: Elgg ...... 35 Figure 8: Dolphin ...... 36 Figure 9: WordPress ...... 37 Figure 10 :Mahara ...... 39 Figure 11: Anahita ...... 40 Figure 12: Drupal ...... 41 Figure 13: Oxwall ...... 42 Figure 14: Liferay ...... 43 Figure 15: GateIn ...... 45 Figure 16: Priority A requirements evaluation summary ...... 49 Figure 17: MCA approach ...... 51 Figure 18: Priority based MCA ...... 53 Figure 19: Platform score per priority ...... 55 Figure 20: Platform analysis summary ...... 58 Figure 21: Drupal module file structure ...... 64 Figure 23: A Simple hello world use case in Drupal ...... 65 Figure 22: Drupal use case 1 implementation ...... 65 Figure 25: Drupal roles ...... 66 Figure 24: Drupal use case 2 implementation ...... 66 Figure 26: Drupal use case 4 implementation, getting group users ...... 67 Figure 27: Drupal use case 4 implementation, getting user roles ...... 67 Figure 28: Drupal use case 5 implementation ...... 67 Figure 29: Drupal use case 6 implementation ...... 68 Figure 30: Drupal use case 7 implementation ...... 69 Figure 31: File structure of a Liferay project with 1 portlet ...... 70 Figure 32: A simple Liferay portlet ...... 71 Figure 33: Liferay use case 1 implementation, view.jsp ...... 71 Figure 34: Liferay use case 4 implementation, getting group id ...... 73 Figure 35: Liferay use case 4 implementation, display users and roles ...... 73 Figure 36: Liferay use case 5 implementation, developer code ...... 74 Figure 37: Liferay use case 5 implementation, complete code ...... 74 Figure 38: Liferay use case 6 implementation, Liferay‐portlet.xml ...... 75 Figure 39: Case study evaluation summary ...... 78 Figure 40: Elimination results ...... 81
List of tables Table 1: MVC component description ...... 3 Table 2: Unmodified requirement from previous researches ...... 16 Table 3: Redefined requirement from previous researches ...... 17 Table 4: Merged requirement from previous researches ...... 18
v
Table 5: Split requirements from previous researches ...... 19 Table 6: Additional requirements ...... 22 Table 7: Base platform requirements ...... 24 Table 8: Platform selection search terms ...... 29 Table 9: Potential platforms ...... 30 Table 10: Community builders & CMS with community builder extension ...... 32 Table 11: Enterprise portals ...... 32 Table 12: Abbreviated requirements ...... 34 Table 13: Elgg priority A evaluation ...... 35 Table 14: Dolphin priority A evaluation ...... 37 Table 15: WordPress priority A evaluation ...... 38 Table 16: Mahara priority A evaluation ...... 39 Table 17: Anahita priority A evaluation ...... 40 Table 18: Drupal priority A evaluation ...... 42 Table 19: Oxwall priority A evaluation ...... 43 Table 20: Liferay priority A evaluation ...... 44 Table 21: GateIn priority A evaluation ...... 45 Table 22: Platform roles evaluation ...... 47 Table 23: Platform number of bug reports ...... 48 Table 24: Dominance analysis ...... 56 Table 25: Drupal and Liferay dominance analysis ...... 56 Table 26: Per requirement dominance analysis ...... 58 Table 27: Use case summary...... 63 Table 28: Case study use case results ...... 77
vi
1 Introduction
1.1 Motivation In the upcoming years Western Europe will have the problems of an aging population; the labor force will decrease, while the number of elderly people will increase. By 2050, for the Netherlands, the number of elderly people (69+) relative to the labor force (20‐69) is expected to have increased from 16% to 37% [1], an increase of over 125%. Since elderly people generally need more healthcare, the total amount of required healthcare will increase, whereas the labor force being able to provide this healthcare will decrease due to the decreasing workforce. Therefore if the current level of healthcare is to be maintained in the future, healthcare must be delivered more efficient. One way to potentially increase the efficiency of healthcare is by delivering it from a distance, a concept also known as telemedicine.
A possible scenario in telemedicine is to use remote monitoring to monitor patients at home where they would be monitored in a hospital at this moment. By not requiring a hospital bed, hospitals can treat more patients with the same amount of resources, thus increasing the efficiency of healthcare.
With remote monitoring, like most healthcare, multiple parties are involved. Some of the typical parties are doctors and patients, but also nurses and other healthcare personnel, as well as relatives and friends can play a role. These parties all serve a common goal, to improve a patient’s health; the exact definition of this goal depends on the situation. So there is a group of people who are interacting to achieve a common goal, each party with a certain role. This is more or less the definition of a Virtual Community (VC) as defined by [2] quoted by [3] which is defined as “An online community is ‘a group of people, who come together for a purpose online, and who are governed by norms and policies’”. Since this is a Virtual or Online community for remote monitoring, which is a part of telemedicine, this scenario can be considered a “VC for telemedicine”.
Studies have shown that for some scenarios treatment using a group approach is more effective than treatment using an individual approach [4]. One of these scenarios is when a patient has to make lifestyle changes as a result of a chronic disease, or when recovering from a disease. A VC can be used to provide support in several ways. It can be used to provide informational support by providing information, either from healthcare professionals or from other patients. It can also be used to provide emotional support via forums where one can share experiences, or via (instant) messaging services. There are several VC’s around that offer these 2 types of support [5] [6]. A more interesting type of support from a biomechanical engineering point of view is instrumental support. Instrumental support is defined in [7] as: “Instrumental support involves the provision of tangible aid and services that directly assist a person in need. It is provided by close friends, colleagues and neighbors”. These services can be in the form of ICT services, and the tangible aid in the form of ICT solutions. It is possible to have devices equipped with sensors that gather (medical) data, which can then be used to provide instrumental support. For example when used over a longer period of time, progress can be tracked, and this progress can be used to motivate a patient. In that case, the service is a progress tracking service and the tangible aid the motivation from peers. Another possible use of this data is when used in a group context, gathered data can be shared among peers, and peer pressure can be used to motivate a patient into making the required lifestyle changes. Finally, instrumental support can be used to give real time
1 of 95 feedback to a patient by a health care professional. By giving immediate feedback, possible errors can be corrected as soon as possible, thus increasing the efficiency of an exercise. 1.2 Background This section gives some background information required to understand the scope of this research. First, the different components of a MVC for telemedicine are given; the terms of these components are used later in this report. Next, the definition of mobile in Mobile Virtual Community used in this research is given.
Component overview This section describes the components of a platform for MVC for telemedicine. The terms used for these components are used later in this report, and this section explains the role of each component, and the interactions between them.
Figure 1: MVC platform component overview
Figure 1 shows the components of a MVC for telemedicine. It consists of 3 tiers; a client tier, services tier, and data access tier. It is a modified version of the 3 tier design ( [8]quoted by [9]) commonly used in software engineering. Within each tier, several components are defined. There can be multiple instances of each component within the MVC for telemedicine, unless mentioned otherwise.
2 of 95
Name Description Client tier This tier consists of the clients using the MVC for telemedicine. Service tier This tier consist of components that process and present data from the data tier to the client tier, as well as processing acquired biomedical data from the mobile devices at the client tier. Data access tier The data access tier is responsible for storing and retrieving any data used by the web tier. Fixed client A fixed client is a client on a fixed connection using a PC or laptop. A fixed client uses a browser to connect to the web tier. Generally speaking, a fixed client will not send biomedical data. Mobile Client A Mobile client is a client on a mobile connection using a mobile phone or tablet. A mobile client generally connects to the web tier using a dedicated app, but a browser can also be used. Web presentation The web presentation services consist of the MVC access platform, and any other services website related to the MVC, but not integrated in the MVC access platform. Data acquisition The data acquisition services consist of components that provide functionality to services process acquired data. It can communicate with the base platform for user authentication. MVC access The MVC access platform is the presentation component of the web service. When platform a client uses a browser to connect to the platform, this component is viewed. In a typical MVC for telemedicine, there is only MVC access platform. The research focuses on this component. Base platform The base platform will be extended with the newly developed extensions. The base platform provides functionality typical for any MVC, not functionality specific for a MVC for telemedicine. The base platform functionality includes, but is not limited to, user and community management. It can also offer functionality to offer informational support, such as a Wikipedia extension or a built in forum. In a typical MVC for telemedicine, there is only one base platform. Developed Developed extensions are newly developed applications specifically designed to extensions add telemedicine functionality to a MVC. These extensions extend the base platform, and do not work independent from the base platform. Data acquisition The data acquisition service collects biomedical data from the sensors of the service mobile devices. Not necessarily part of the MVC access platform. By not being part of the MVC access platform, better scalability and easier development can be achieved. Uses generally uses WSDL/SOAP, REST/JSON or other web services to communicate with the mobile clients. Standard The standard database is general purpose database required and used by the base database platform, and can be used by the developed extensions if required. In a typical MVC for telemedicine, there is only one standard database. Medical database A medical database is a database specifically designed to store medical data. For example, this can be a secure database, or a database with functionality for storing medical data. External data Any data source outside the scope of the project. External data sources are usually source accessed using web services. MVC website In a typical low performance environment, these elements run on one machine. Not connected from a logical point of view. Table 1: MVC component description
3 of 95
Mobility To send the acquired data from a mobile device to a VC, the VC must be reachable from this mobile device. Furthermore, a possible scenario is to have the VC platform give live feedback during exercises. Exercises are almost never done in front of a PC or laptop; whereas it is likely a person doing exercises has the possibility to carry a Smartphone. By making the platform reachable by Smartphone, live feedback can be given. Ideally, the platform must be able to be reached from anywhere, at any time. If the platform is indeed reachable from anywhere at any time, the platform becomes a Mobile Virtual Community (MVC).
It is assumed the mobile device has the ability to reach the VC platform from anywhere anytime, in other words, it has a mobile internet connection. However, while the assumption is true most of the time, it is not a strict requirement. Guaranteeing a connection 100% of the time introduces new requirements on the connection, for example automatic fallback to another type of connection, which are outside the scope of this project. 1.3 Problem Statement In the introduction several scenarios were described in which instrumental support was given. It did however not describe how this support should be given. To discover how this support should be given, research has to be done. Part of this research consists of developing new applications to extend the functionality of the MVC for telemedicine. There are various possibilities for new applications, ranging from applications that run solely on the MVC base platform, like an application to share experiences, to applications that gather (medical) data from sensors on a mobile device, and send this data to the MVC application. Since the goal of these applications is to research the options to offer support in an MVC, a research base MVC platform is required to deploy and test these newly developed applications. At this moment it is not clear what type of platform should be used to deploy these applications on. This leads to the goal of this research:
“To provide advice about the ‘base platform’ used to develop applications in the field of Mobile Virtual Communities for telemedicine to researchers interested in developing these applications”
There are several approaches for developing a “base platform”, each approach with its advantages and disadvantages.
Build a MVC from scratch Building a MVC from scratch is the most straightforward approach. Its advantages are clear, when all the code is self created, there is full control over every aspect of the developed code. With the goal of the MVC platform in mind, which is to support the development of new MVC applications, it is possible to make design choices specific for a MVC for telemedicine at the core of the MVC platform. The main disadvantage of developing a complete MVC from scratch is the amount of work required to develop a complete platform. Since this platform will only be used to develop and test new applications, the cost to build this platform would be relatively high.
Extend existing MVC software One of the main advantages of using an existing platform instead of designing one from scratch is that it has the potential to safe work in development. This existing platform can either be a generic MVC or a MVC for telemedicine. In either case, a MVC for telemedicine platform shares some features with the existing platform, like user management and grouping. If it would be possible to re‐use those features, developing a MVC will be less costly.
4 of 95
There are however some disadvantages. Since medical information is being used, which is sensitive information, security is an issue. Any security issues in the existing platform will also be in the MVC platform. Therefore, investigating the security of the existing platform will be important. Another disadvantage could be the lack of backwards compatibility. Since security is an issue, keeping the platform up‐to‐date is mandatory. When the base platform is updated, it is desirable that all developed extensions will continue to work. Thus backwards compatibility is desirable. One final thing to consider is that it is very unlikely that a platform will meet all the requirements. Therefore it will be likely that changing existing code will be mandatory. As more and more changes are being made, maintaining the platform will become more costly, up to the point where maintenance of an existing platform will become more expensive than developing one from scratch. Throughout the development of the platform this should be kept in mind, and actions be taken accordingly.
Joining an existing MVC for telemedicine A final approach can be to join an existing MVC platform or service, either one specifically designed for telemedicine, or a more generic one. This approach requires the least amount of work, since a fully working MVC will be joined. This approach however has some disadvantages which make it unsuitable to be used. Primarily, the complete reliability on the provider of this existing MVC makes it unsuitable. If the provider makes any changes, or ceases to exist, any developed extensions must be changed as well. Another disadvantage is the access of this provider to the potentially sensitive medical data stored by the developed extensions. This data can be used for data mining or sold to 3rd parties, which is undesirable. While these issues can be solved with a good contract with the service provider, this approach is still undesirable. Finally, hosted virtual communities are usually not open source, and can thus limit the development of applications.
The conclusion can be drawn based on the qualitative arguments given that joining an existing MVC service or platform is an unsuitable approach, and the disadvantages of developing a MVC from scratch most likely outweighs the advantages. Thus, the 2nd approach, extending existing MVC software is most likely the best option. The previously mentioned goal of this research will be made more specific based on this approach taken. The goal of this research is now:
“To provide advice about the most suitable existing mobile virtual community builder platforms which can be used as a base platform to be extended to develop applications in the field of MVC’s for telemedicine to researchers interested in developing these applications”
1.4 Research question The previous section defined the goal of this research. From this goal the following research question is derived: Which existing platform is most suitable to be used as a base platform for a Mobile Virtual Community for telemedicine?
Sub questions To be able to answer the main research question, ‘Which platform is most suitable to be used as a base platform for a Mobile Virtual Community for telemedicine?’, several sub questions need to be answered first. The first aspect that needs to be answered, before determining which platform is most suitable, is what makes a platform most suitable. To be able to do so, the requirements of a MVC for telemedicine need to be determined. This leads to the first question:
5 of 95
RQ1: What are the requirements of a MVC for telemedicine?
Doing a full research to find the requirements of a MVC for telemedicine –such as a case study or interviews‐ is beyond the scope of this research. Fortunately, previous researches have been done on the topic of MVC’s for telemedicine. This leads to the following question:
RQ2: What resources are available to determine these requirements?
Since it is not unlikely the scope and goal of this research differs from the resources, it is possible some requirements are more relevant or less relevant. This leads to the following question:
RQ3: How relevant are the requirements mentioned in the research literature?
To answer the question which platform is most suitable, first a list of platforms from which the most suitable platform can be chosen needs to be composed. It is possible there are several distinctly different directions to look for possible platforms for a MVC for telemedicine. These directions also depend on the requirements found earlier; platforms from some directions cannot be used to fulfill the requirements. This leads to the following question:
RQ4: What are possible directions to look for the base platform?
In each direction, several platforms will be available from which the most suitable platform can be chosen. To be able to find the most suitable platform, a list of all potentially suitable base platforms must be composed. This leads to the following question:
RQ5: Which platforms are available as a possible base platform for the MVC for telemedicine?
Once these platforms have been determined, an evaluation must be done to determine which platform is most suitable. In this research, two evaluations will be done. The first evaluation will be done by taking the previously determined requirements, and use these to evaluate the found platforms. The second evaluation will do a more thorough analysis, and do a case study to determine how well they can be used to be extended with telemedicine functionality. For the first evaluation, to be able to give a statement about which platform is most suitable, first a method must be found to objectively evaluate the platforms. For the second evaluation, first the use cases to be used need to be determined. This leads to the following two research questions:
RQ6: Which method should be used to evaluate the platforms using the requirements?
RQ7: Which use cases should be used to evaluate the platforms in the case study?
As mentioned before, the platform will be used to build extensions to provide telemedicine functionality. Earlier in the research, the advantages of the platforms are already researched. When developing new code, often limitations and problems of the platforms arise which were not clear at the beginning. To avoid giving incorrect advice based on the requirements alone, an evaluation is done to find these limitations and problems. This leads to the following research question:
RQ8: Which problems arise when developing extensions with telemedicine functionality on this platform?
6 of 95
Finally, by using the results from applying the method to be used to evaluate the platforms using the requirements and the results of the case study, the following question can be answered:
RQ9: According to the requirements and case study, which platform is most suitable to be used as a base platform?
The research questions will be addressed in this research in numerical order, with the exception of RQ1, which will be answered after the resources of RQ2 are determined. In this section the main research question and several sub questions were given. How these questions will be answered will be described in the approach in the next section. 1.5 Approach This section gives the approach used in this research. First the general approach will be described, which shows the different phases of the research. This is followed by a more detailed description about these phases of the approach. General Approach Figure 2 gives a schematic overview of the approach used in this research:
Figure 2: General approach
This research starts by composing a list of requirements (1). After this list is composed, a list of existing platforms potentially suitable to be used as base platforms is composed (2). Some of the requirements from (1) will be used in the existing platform evaluation to eliminate unsuitable platforms from the list of possible platforms (3). The platforms that were not eliminated are analyzed using all requirements at (4). A set of real life use cases is composed at the case study at (5), aimed to analyze one or more platforms in detail at (6). The number of platforms analyzed depends on the results of the existing platform analysis (4). Finally, the conclusions are drawn at (7).
The overlapping goal of steps 3, 4 and 6 is to decrease the size of the list from step 2 until there is 1 platform left. Each step will more thoroughly investigate a platform compared to the previous step. Since the time spent investigating a single platform will increase each step it is preferred to minimize the number of platforms each step. By using an elimination approach where the number of platforms investigated each step decreases, the total time required is minimized.
7 of 95
Requirements phase This research starts by composing a list of requirements to be used for the evaluation and analysis of the existing platforms. No extensive use case composition is done to determine these requirements; instead the requirements are determined by looking into papers with a similar topic. The papers used are researches conducted at this department at the University of Twente. From these papers, the requirements will be taken. However, it is unlikely these papers will have exactly the same goal and scope, so not all requirements will be relevant, and only the relevant requirements will be taken. It is also possible the scope and goal of this research will result into some requirements not mentioned in a previous research. These additional requirements will also be added to the list of requirements. Even after picking only the relevant requirements from the previous researches, not every requirement will be equally relevant. Therefore, every requirement ‐ the ones from the previous researches and the ones from our own research‐ will be prioritized on relevance. At the end of this phase, a list of requirements and their priorities is composed, which can be used in the evaluation, analysis and case study phase. At this phase, research questions 1,2 and 3 are addressed.
Evaluation phase The evaluation phase starts by composing a list of potential base platforms. During the composition the first set of platforms is already excluded if they are outside the scope of this research and these platforms will not be mentioned in this report. One or more evaluation steps will be used to decrease the size of this list, until the list only consist of platforms that can be used as a base platform. These platforms will be analyzed in the analysis phase. At this phase, research questions 4 and 5 are addressed, and research question 6 is partially addressed.
Analysis phase In the analysis phase, a Multi Criteria Analysis (MCA) will be done to determine which platform is most suitable to be used as a base platform. Each requirement will be given a grade depending on how well the platform meets this requirement. The method(s) used in the MCA will give each platform a score. Based on this score, the conclusion of the MCA will be drawn. This result will be verified by checking the values and methods used. At this phase, the remainder of research question 6 is addressed and research question 9 is partially answered. Case study phase Before drawing the final conclusion of this research, which platform is most suitable to be used as a base platform for the MVC for telemedicine, a case study will be introduced to test if the highest scoring platform from the analysis to be used as a base platform is suitable in practice. The goal of this case study is to do a more thorough analysis of the platforms, and to determine if the platforms to build extensions for telemedicine on are suitable. If two or more platforms scored equal in the analysis, the use cases of the case study will be applied to these platforms, and the results of these use cases will determine which platform is most suitable. This phase is implemented by describing a real life scenario, from which the key aspects are taken, which will then be used to derive the use cases, leading to the answer of research question 7. These use cases will then be implemented on a live platform, and the
8 of 95 required work and difficulties found are given. Based on these results, research question 8 is answered, along with the remainder of research question 9.
Conclusion Based on the results of the results of the analysis phase and case study, the conclusion of the research will be drawn and the research questions answered. Also, a small discussion is done concerning the results of the research and some recommendations are given. 1.6 Thesis Structure Chapter 2 discusses the first phase of this research, the requirements phase. In chapter 3 the list composition of potential platforms and results of the evaluation phase are described. Chapter 4 discusses the results of the analysis phase. In chapter 5, the case study composition and analysis is described. Finally, chapter 6 answers the research questions and draws the conclusion of this research. This chapter also discusses this conclusion and the research done, and provides recommendations where required.
9 of 95
2 Requirements
2.1 Introduction This chapter describes the requirements for the MVC for telemedicine and the base platform used to build it. These requirements will then be used in chapters 3 and 4 to evaluate and analyze existing platforms to find the most suitable one. First section 2.2 introduces two papers from which the requirements will be taken. This section also gives the exact scope of the research. Next, section 2.3 describes the approach used for selecting, rewriting and prioritizing these requirements. This approach is carried out and section 2.4 gives the resulting requirements and their priorities. Since the scope of this research is different from these 2 papers, some additional requirements might arise; these are given in section 2.5. Finally, section 2.6 gives a complete list of all requirements with their priorities. 2.2 Scope & Existing papers
Existing papers This section gives existing papers in the field of MVC’s for telemedicine. If a paper is considered relevant based on its goal and scope, and if the paper has a list of requirements, these requirements are used in this research. The first paper to be explored for requirements is a research done at this university by C. Dulawan [10]. This paper explores how MVC concepts can be applied in doing telemedicine. It is one of the first researches on the concept of MVC’s for telemedicine. In the paper, several use cases are introduced, from which requirements are deduced. These use cases, and therefore the requirements, focus on the remote monitoring aspect of a MVC for telemedicine, including monitoring vital signs and sending alarms based on these signs. While vital sign monitoring, being a requirement unique for a telemedicine MVC is outside the scope of this research, some requirements are still useful. The research does not address the concept of using MVC’s for group recovery therapy.
The second paper to be explored is a requirements analysis deliverable [11] done for the BraveHealth [12] project. The BraveHealth website describes its goal as follow: ‘BRAVEHEALTH proposes “a patient‐ centric vision to CVD management and treatment, providing people already diagnosed as subjects at risk with a sound solution for continuous and remote monitoring and real time prevention of malignant events”’. One of the components to be developed is a Virtual Community where data from remote monitoring is displayed and various types of support are given. Just like the first paper, a case study is done to discover the requirements. The deliverable is at this moment classified and unpublished. However, since the group where this MSc. thesis research is done is one of the participants of BraveHealth, and thus has access to the deliverable, the requirements can still be used in this research.
Especially the BraveHealth deliverable does extensive research to determine the requirements. Another aspect researched in the BraveHealth project, and discussed in [13], is the prediction of user acceptance of the MVC. A questionnaire is given to patients from several focus groups, to determine if and when they would use the MVC. The results of these questionnaires also influenced the use cases used to create the requirements. From these two sources the requirements of the MVC for telemedicine can be acquired. Both sources do a case study from which the requirements are taken, which gives a good base for the determination of
10 of 95 the requirements. While this may not result in all the requirements of an MVC for telemedicine, it is a good start. If during the derivation of the requirements it becomes clear some requirements are missing, these requirements are added in section 2.5: Additional requirements. In the next section, the method used to acquire and prioritize these requirements is given.
Scope A conclusion from section 1.3 was that extending an existing platform as a base platform is most likely the best approach. It also mentioned two possible directions for a base platform for the MVC for telemedicine; a generic MVC or a MVC specifically designed for telemedicine. MVC’s for telemedicine are not widely used at this moment, thus it is unlikely an existing MVC for telemedicine usable as a base platform will be found. Thus, this research will focus on extending a generic MVC as a base platform.
The scope on generic MVC’s also has an impact on the requirements of the existing base platform and their importance. In the next paragraph existing papers are explored for requirements. These papers are on MVC’s for telemedicine and have some requirements unique for the field of telemedicine. Since it is very unlikely requirements unique in the field of telemedicine will be met by the base platform, these requirements will be given either a low priority or removed completely and be deemed outside the scope of this research, which focuses on extending generics MVC’s. Another aspect of these papers is developing and deploying mobile applications for this MVC for telemedicine. Since these mobile applications only affect the base platform when communicating with the base platform, any requirements concerning mobile applications –besides communicating with the base platform ‐ will be considered outside the scope of this research. One final difference in scope is the scale of the project. The BraveHealth project envisioned a large scale application, which also puts requirements on the hardware and software used. This research has a smaller scale, and requirements on the hardware are no longer considered important. 2.3 Approach The previous section gave two resources containing requirements for a MVC for telemedicine. This section describes the method used acquire and prioritize these requirements. From each research, the requirements are looked up and are literally copied into this research. As mentioned in the requirements approach section in section 1.5, not all requirements are equally relevant, and a prioritizing method will be used to denote the importance of each requirement. A two step approach will be used to prioritize the requirements. The first step is to determine if the requirement is at all relevant. A requirement is not relevant if it is outside the scope of this research as defined in section 2.2. If a requirement is relevant, the second step is performed, giving a priority to the requirement. While determining if a requirement is relevant, the motivation why it would be relevant is usually the same as the motivation for the priority of a requirement. Thus, writing both down is redundant and in the report, the result of both steps will be given at the same time. A priority scheme based on the MoSCoW prioritization [14] method will be used to assign priorities to each requirement. The MoSCoW method is a method commonly used in software development for requirement prioritization. Usually, the priorities are determined in consultation with the stakeholders. In this research however, this is not the case. Instead, a motivated estimation of the priority is done for each requirement, and the motivation is given. The MoSCoW method has 4 prioritization levels that can be given to a requirement:
M ‐ MUST have this. S ‐ SHOULD have this if at all possible.
11 of 95
C ‐ COULD have this if it does not affect anything else. W ‐ WON'T have this time but would like in the future.
These 4 priorities combined with the step determining if a requirement is relevant leads to the following 5 priorities used in this research: Priority A: Must meet this requirement. These requirements will be used in chapter 3 to evaluate and chapter 4 to analyze existing platforms. Priority B: Should meet this requirement. These requirements will be used in chapter 4 to analyze existing platforms. Priority C: Could meet this requirement, but less important than priority B. These requirements will be used in chapter 4 to analyze existing platforms. Priority D: The MVC for telemedicine should meet this requirement; however, it is not important for the base platform to meet this requirement. These requirements will be used in chapter 5 to help define the scenario from which the use cases are derived. Priority E: This requirement is not relevant (anymore), and will not be adopted in the list of requirements used in this research.
Another aspect is to define when a requirement is met, or not met, and what to do if a requirement is partially met. For this research the decision was made that there are three possible options here, either a requirement is met, not met or partially met. To avoid inconsistent results, the decision was made not to further divide partially met requirements, for example into mostly met and mostly not met. Some requirements, due to their definition, can only be met or not met, not partially met. For priority D requirements, which will not be used in the evaluation and analysis but only to help define the setting for the scenario from which the use cases are derived, the decision was made not to define when a requirement is met, since this will not be used. Obviously, requirements with priority E, which are obsolete, do not require the definition when a requirement is met.
Before the priorities are given, an operation can be applied to the requirements to make them more suitable for this research. Possible operations are:
Redefinition: In some cases a small redefinition of the requirement is preferred to meet the scope of this research, by either adding, removing or rewriting parts of the original requirement. Another possibility for a redefinition is when parts of the requirement are outdated, and need to be updated. If a redefinition is the case, the motivation behind it is given.
Merge: If a requirement is present in both researches or if the scope of a previous research is more detailed than this research, multiple requirements can be merged into one more abstract requirement. If a merger is applied, the motivation behind the merger is given.
Split: If the scope of this research is more detailed than the scope of the previous researches, it is possible a requirement is split into multiple more granular requirements. Once again, the motivation behind the operation is given when it is applied.
12 of 95
2.4 Requirements from previous research papers This section lists and prioritizes the requirements from the previous researches. First the requirements which are taken without any operation are described, followed by the redefined, merged and split requirements. For each of those 4 categories, first the requirements taken from C. Dulawan are analyzed, followed by the requirements from the BraveHealth project.
Unmodified requirements This section gives the requirements that did not need a redefinition/merger or split, in other words the unmodified requirements.
The following layout is used to describe the requirements, their priority and the motivation behind the priority:
Unmodified requirements example Example requirement Motivation behind the priority Requirement fulfilled: When is a requirement fulfilled. priority Requirement partially fulfilled: When is a requirement partially fulfilled. Requirement not fulfilled: When is a requirement not fulfilled.
The next table gives the requirements that did not need a modification:
Unmodified requirements The platform should allow creation of a sub‐community. In the introduction, group therapy was mentioned as one of the possible applications for the MVC for telemedicine. To offer effective group support, it must be possible to create the groups to give this support, or sub‐communities. Without sub‐ communities, all users would be in 1 community, making it very hard to offer granular support. It is almost impossible to offer group support if the requirement is not met, thus the platform must meet this requirement, giving it priority A. A Requirement fulfilled: The platform can create sub communities Requirement partially fulfilled: Requirement not fulfilled: The platform cannot create sub communities The platform should allow creation and management of user profiles. User profiles can improve the social interaction within a (sub)‐community by allowing users to find other users with the same interests, location or illness. They can also be used to contact a user directly. This allows users to find peers to provide emotional support, which is one of the types of support of a MVC for telemedicine. If this requirement is not met, providing emotional support will difficult, so the platform must meet this requirement, giving it priority A. A Requirement fulfilled: The platform can create and manage user profiles. Requirement partially fulfilled: Requirement not fulfilled: The platform cannot create or manage user profiles. The platform should be able to identify who should be alarmed in case of an emergency. Sending an alarm in case of an emergency is one of the requirements mentioned earlier in section 2.2 that are unique for telemedicine and are beyond the scope of this research. However, for a MVC for telemedicine which can be used for remote D monitoring this requirement is still relevant. Therefore it given priority D. The platform should be able to transfer viewing session without interruption. This requirement refers to the monitoring of vital signs, and being able to view vital signs without interruption. Monitoring vital signs is one of the requirements mentioned earlier in paragraph 2.2 that are unique for telemedicine and are beyond the D scope of this research. However, for a MVC for telemedicine which can be used for remote monitoring this requirement is still relevant. Therefore it given priority D. The platform should be able to support multiple devices associated with one role. This requirement refers to the monitoring of vital signs, and being able to view vital signs without interruption. Monitoring vital signs is one of the requirements mentioned earlier in paragraph 2.1 that are unique for telemedicine and are beyond the D scope of this research. However, for a MVC for telemedicine which can be used for remote monitoring this requirement is still relevant. Therefore it given priority D. These services should at least be present: vital sign delivery service, viewing service and interaction service. It is not useful to put constraints on the minimum of required services at this moment. E It should be possible to restrict access to the sub‐community. In medicine, where information is sensitive, it must be impossible for unauthorized users to view the data shared in this sub‐ A community. Therefore the platform must be able to restrict access to sub‐communities, to avoid unauthorized users to access
13 of 95
the data, giving it priority A. Requirement fulfilled: It is possible to restrict access to the sub‐community to authorized users. Requirement partially fulfilled: Requirement not fulfilled: It is not possible to restrict access to the sub‐community to authorized users. Access: the BMVCs must be accessible using a desktop, notebook, tablet PCs and SmartPhone. Since all base platforms tested will be web based, and all the devices listed in the requirement should be able to read webpage’s, this requirement is a bit superfluous. On the other hand, if a platform does not support one of the devices listed above, it will severely lower its usability. Therefore the platform must meet this requirement, and is given priority A. A Requirement fulfilled: The platform is accessible from a desktop, notebook, tablet PCs and SmartPhone. Requirement partially fulfilled: Requirement not fulfilled: The platform is not accessible from a desktop, notebook, tablet PCs or SmartPhone. Translations: There is the need for a translation service. Further decisions are needed so as to determine if this can be done off‐ line or needs to be online (near real‐time), whether it must be human translation by an authorized translator etc. A translation service can be useful, but since the platform is only intended to be used at this university, at most 2 languages will be used (Dutch and English) and it is no longer mandatory. It could still be useful, since it saves some time in building the MVC that uses multiple languages, for example Dutch and English. However, translating the content into 1 other language is C manageable, thus it is given a low priority, priority C. Requirement fulfilled: The platform has a built in translation service Requirement partially fulfilled: Requirement not fulfilled: The platform does not have a built in translation service. Help‐functionality: users must have the possibility to get help in using the system, either through a context‐aware help function or via (context‐aware) help‐desk. This help functionality is about help in using the system only. If a user does not know how to use the platform, that user will not use all the capabilities of the platform. Having help functionality can extend the users knowledge of the platform and increase the overall usability of the platform. So this is an important requirement. However, since the amount of users will be limited, help can be given outside the platform, making built‐in help functionality not mandatory. Therefore, since this is requirement is important but not mandatory, the platform should meet it, giving it priority B. B Requirement fulfilled: The platform has help functionality services available, and help pages already implemented Requirement partially fulfilled: The platform has help functionality services available, but help pages are available externally or help functionality services are available but not implemented. Requirement not fulfilled: The platform does not have help functionality services available, and no help pages are available externally. Users, especially patients, have full understanding and insight in who is able to read what information about himself or herself, and can exercise control over who is able to see what within the context of a mobile virtual community. This requirement is important, since medical information is privacy sensitive, and a patient has the right to manage this information. Being able to view who is able to read information and exercise control over it is however optional. If the requirement is not met the platform can still be used. Therefore, since it is an important but not mandatory requirement, the platform should meet this requirement, giving it priority B. B Requirement fulfilled: Users can read and exercise control over who is able to see what information Requirement partially fulfilled: Information about who can read what information is stored in the database, but is not readily available to the end user and an extension has to be built to makes this read and exercise control over this information Requirement not fulfilled: There is no information available about who is able to see what data. Whenever required, for instance based on an in‐depth privacy and security analysis, information between endsystems (mobile devices and desktops) is exchanged in a security enhanced application protocol (such as https). Since sensitive medical data may be exchanged, a secure connection is important to guarantee this data cannot be intercepted by a 3rd party. If this requirement is not met, passwords and sensitive medical information could be intercepted by a 3rd party, leading to the leakage of privacy sensitive information. Therefore, the platform must meet this requirement, giving is priority A. A Requirement fulfilled: HTTPS is supported by the platform, and the pages to be transferred via HTTPS can be customized from the platform. Requirement partially fulfilled: HTTPS is supported, but list of pages to be transferred via HTTPS cannot be customized from the platform. Requirement not fulfilled: The platform cannot be used via HTTPS. Whenever required (again, based on an in‐depth privacy and security analysis), health related data of patients is stored in a secure manner in the MVC database. Since sensitive medical data may be used and stored, a secure database is important. However, this sensitive medical data can be stored in an external secure database, so it is not important for an existing base platform to meet this requirement. Since it is not crucial but still advantageous for a platform to meet this requirement, the platform could meet this requirement, giving C it priority C. Requirement fulfilled: The platform can store data encrypted. Requirement partially fulfilled: There are 3rd extensions available for secure storage. Requirement not fulfilled: The platform does not support secure storage. Using a mobile device(e.g. Tablets) users must be able to be connected to their virtual communities 24/7 This is a requirement on the mobile devices, not on the base platform. Therefore it is not relevant for the requirements, can E be removed and is given priority E.
14 of 95
User‐Interaction modes: the user interface must support request‐response, solicit‐response, publish‐subscribe, one‐way and notifications. In other words, all standard interaction modes need to be supported. A client will communicate with the base platform in 2 possible ways, by using a browser to view the base platform or by using a dedicated application that uses web services. A dedicated application would be custom made and would not impose any E additional requirements on the base platform, besides the availability of webservices, which is covered by another requirement. In most cases, a browser only supports request‐response, making it impossible to meet this requirement, and thus making this requirement obsolete. Therefore it is given priority E. Also, mixed (i.e. simultaneous) access must be supported. This requirement is considered to specific and therefore outside the scope of this research. Thus it is given priority E. E Various types of support must be supported, for patients the four basic types of support relevant are: informational support, instrumental support, emotional support and feedback support. Giving various types of support is one of the requirements mentioned earlier in section 2.2 that are unique for telemedicine D and are beyond the scope of this research. However, for a MVC for telemedicine which can be used for remote monitoring this requirement is still relevant. Therefore it given priority D. Mobile device: For the access and interaction with the Mobile Virtual Community Platform a dedicated mobile application needs to be deployed on the mobile device in use so as to take optimal advantage of the functionalities supported by the platform (such as timely notifications and the like). While this is an important requirement for a successful MVC for telemedicine, it is not an important requirement for the base D platform. Creating mobile applications for the MVC is outside the scope of this research, which focuses on finding a base platform to be extended. Deploying a mobile application does not depend on this base platform. Therefore, since it is outside the scope of this research, but still useful for an MVC for telemedicine, it is given priority D. Mobile device: In order to be implementation technology independents, standardized protocols for the interaction and communication between mobile device and the Virtual Community Platform are required. Web based communication between the mobile device and VC is already standardized. Any non web based communication, such as communication between a dedicated mobile application and the base platform will be completely developed by the D application developers. Therefore, since it is outside the scope of this research, but still useful for an MVC for telemedicine, it is given priority D. Mobile device: For mobile applications, the interaction / communication must be based on WSDL and SOAP. REST is considered a potential candidate for the (near) future. One of the functionalities of a MVC for telemedicine is to gather instrumental data. This data is acquired by a body area network (BAN) and collected at a mobile device. To communicate between this mobile device and the MVC platform, a SOA should be used. By using a standardized protocol, extending and managing extensions built for the MVC become easier. If the base platform would already support SOA’s, this would decrease the time required to build these extensions. It is however not mandatory to use a SOA for communication between the mobile device and the base platform. Therefore, since it is preferred, B but not required, the platform should meet this requirement, giving it priority B. Requirement fulfilled: The platform has support for SOAP/REST web services, and web service functions available for the core functionality of the platform. Requirement partially fulfilled: The platform supports custom SOAP/REST web services, but no web services are already implemented. Requirement not fulfilled: The platform does not support SOAP/REST. Mobile device: Mobile application development must be fully aligned with the requirements of the other modules in the project. E.g. It is known that running C# and Java application components on Windows mobile devices gives poor performance. As mentioned in the scope definition in chapter in section 2.2, any requirements concerning mobile applications are E considered outside the scope of this project. Therefore it is given priority E. Mobile device: Mobile Devices we use and have used in the past for development testing and Telemedicine trials are: HTC Smart Phones (various types), QTek and iPAQ. As mentioned in the scope definition in chapter in section 2.2, any requirements concerning mobile applications are E considered outside the scope of this project. Therefore it is given priority E. The Virtual Community Platform will run on multiple application / web servers. The scope of the research originally describing this requirement envisioned a large scale deployment of the MVC where scalability was an issue. This research focuses on finding a base platform to develop new extensions for research on MVC’s for E telemedicine. This research on MVC’s for telemedicine is small scale, and scalability is no longer an issue. Therefore, this requirement has become obsolete, and is given priority E. The Virtual Community Platform will be realized using J2EE technology This requirement was introduced in the original research for 2 reasons, scalability and remote management. In the motivation of the previous requirement it was described why scalability is no longer an issue. The reason to require remote management E has the same motivation; in a large scale environment it improves scalability. Since this is no longer an issue, this requirement has become obsolete, and given priority E. The preferred application servers and database This requirement is moved to the additional requirements. Servers in use for the software development This requirement was introduced to specify the hardware of the servers to host the MVC for telemedicine. Since this research E focuses on a base platform which runs on any x86 PC, this requirement is no longer relevant, and is given priority E. Software Development Environments. E
15 of 95
The base platform does not depend on a software development environment used to build new extensions, and therefore this requirement is no longer relevant and given priority E. Table 2: Unmodified requirement from previous researches
Redefined requirements This section gives the requirements that required a redefinition due to the difference in scope between the original research and this research or the fact they were outdated.
The following layout is used to describe the redefined requirements, the reason behind the redefinition, the new requirement, its priority and the motivation behind the priority:
Redefined requirements example Example requirement Motivation behind the redefinition New requirement Motivation behind the priority priority Requirement fulfilled: When is a requirement fulfilled. Requirement partially fulfilled: When is a requirement partially fulfilled. Requirement not fulfilled: When is a requirement not fulfilled.
The following table gives the results of this redefinition:
Redefined requirements The platform should provide synchronous or asynchronous communication service such as chat service and instant message for inviting community members to join sub‐community. This requirement will be made more abstract to not limit the type of communication used to invite community members. New requirement: The platform should be able to send invitations to users to join a sub community. By sending invitations to users the opportunity is given for them to decline the invitation to join a community. Furthermore, they are notified they can join a sub community. This requirement is not mandatory, since this the B platform will be used on a small scale, and other methods can be used to inform a user to join a sub community. However, meeting this requirement is still an advantage, and the platform should meet this requirement, thus giving it priority B. Requirement fulfilled: The platform can send invitations to any user to join a sub community. Requirement partially fulfilled: The platform can send invitations to users to join a sub community, but can only send them to a specific group of users, or only a specific fixed group of users can send the invite. Requirement not fulfilled: The platform does cannot send invitations to users to join a sub community. The platform should provide asynchronous communication service such as email for inviting non‐community members to join the main community. This requirement will be made more abstract to not limit the type of communication used to invite community members. New requirement: The platform should be able to send invitations to users to join the main community. By sending invitations to users the opportunity is given for them to decline the invitation to join a community. Furtermore, they are notified they are invited to join a MVC. This requirement is not mandatory, since this the platform B will be used on a small scale, and other methods can be used to inform a user to join the virtual community. However, meeting this requirement is still an advantage, and the platform should meet this requirement, thus giving it priority B. Requirement fulfilled: The platform can send invitations to any user to join the platform. Requirement partially fulfilled: The platform can send invitations to users to join the platform, but can only send them to a specific group of users, or only a specific fixed group of users can send the invite. Requirement not fulfilled: The platform does cannot send invitations to users the platform. User Roles: The following user roles must be supported by the BMVC Platform: patient, cardiologist, therapist, nurse, family member, and friend. By not limiting the user roles, flexibility will be increased, and does not impose limitations on the platform later on. Therefore, the requirement is made more abstract to not limit the user roles. New requirement: Different user roles must be supported by the BMVC platform, including, but not limited to, patient, cardiologist, therapist, nurse, family member, and friend. A Restricting access to sensitive medical data is an important requirement of the MVC for telemedicine. By introducing different roles, it becomes easier to manage access control to sensitive data. Therefore the platform must meet this requirement, and it is given priority A. Requirement fulfilled: The platform can create custom roles. Requirement partially fulfilled:
16 of 95
Requirement not fulfilled: The platform does cannot create custom roles. Ease‐of‐use / usability: The user‐interface must be intuitive and easy to use, short learning curve is required. To meet this requirement, a UI that meets this requirements must be developed. This is not a requirement on the platform by itself. However, to not be limited in the development of this UI and end up with a UI that does not meet the requirement mentioned above, the platform must have the ability to fully customize the UI. New requirement: The platform must have the ability to fully customize the UI At this moment it is not completely clear what applications will be developed in this project. By having a fully A customizable UI, extension developers will not be limited by the UI later on in the project. Requirement fulfilled: To our knowledge, every aspect of the UI of the platform is customizable Requirement partially fulfilled: The platform has some small limitations regarding the customization of the UI. Requirement not fulfilled: The platform has clear limitations regarding the customization of the UI. User role, skills, age and gender may affect the user interface requirements. Usability must be evaluated objectively and quantitatively. This requirement will be made more abstract; it is very unlikely existing platforms have the ability to change the UI according to age or skills. New requirement: : The platform must have the ability to have user specific UI’s Some of the potential users of the MVC are elderly people with decreased visual abilities. Those users require a user specific UI with for example increased font size to use the MVC platform more effective. If a platform has the ability to A create custom UI’s per user, an extension can be made to set those custom UI’s according to age/skill, meeting the original requirement. Therefore this is a requirement that must be met by the platform, and it is given priority A. Requirement fulfilled: The platform has the ability to have user specific UI’s. Requirement partially fulfilled: Requirement not fulfilled: The platform does not have the ability to have user specific UI’s. Table 3: Redefined requirement from previous researches
Merged requirements This section gives the requirements that required a merger. A merger was applied when a requirement was present in both researches or if the scope of a previous research is more detailed than this research.
The following layout is used to describe the merged requirements, the reason behind the merger, the new requirement, its priority and the motivation behind the priority:
Merged requirements example Example requirement A Example requirement B …. Priority Motivation behind merger of new New requirement Motivation behind the priority requirem Requirement fulfilled: When is a requirement fulfilled. ent Requirement partially fulfilled: When is a requirement partially fulfilled. Requirement not fulfilled: When is a requirement not fulfilled.
In the next table, the results of the mergers are given:
Merged requirements The platform should allow configuration of sub‐community such that preferences and constraints can be made regarding roles and services. The platform should be able to store the preferences and constraints imposed on the created sub‐community Since these 2 requirements are almost equal, they will be merged into the following requirement. New requirement: The platform should allow configuration of sub‐community such that preferences and constraints can be made and stored regarding roles and services. In medicine, where information is sensitive, it is very important to put constraints on information provided by services and A who is able to view and modify this information. If this requirement is not met, granular access to roles and services is impossible, and unauthorized access to these roles and services could be possible. Therefore the platform must be able to put constraints on the roles and services in a sub‐community, giving it priority A. Requirement fulfilled: The platform has the ability give custom privileges per role within a sub‐community. Requirement partially fulfilled: Requirement not fulfilled: The platform does not have the ability give custom privileges per role within a sub‐community. The platform should be capable of analyzing the vital signs in order to detect an emergency situation. The platform should be able to collect the vital signs of the patient D
17 of 95
The platform should be able to store the vital signs of the patient The platform should be able to stream vital signs of the patient These 4 requirements are all related to vital sign monitoring. They will be merged into one requirement to reduce the number of requirements. New requirement: The platform should be able to collect, store, stream and analyze the vital signs of the patient. Collecting, storing, streaming and analyzing vital signs are all requirements unique for telemedicine. As mentioned earlier in section 2.2, requirements unique for telemedicine are beyond the scope of this research. However, for a MVC for telemedicine which can be used for remote monitoring this requirement is still relevant. Therefore it given priority D. The platform should be able to have information about the patient’s location The platform should be able to detect the caregiver’s location. Both requirements are related to detecting the location of a device. For an existing platform, the role of a device is not important. Thus, they will be merged into one abstract requirement. New requirement: The platform should be able to detect the location of a mobile device. While this is an important requirement for a MVC for telemedicine, it is also a very specific requirement focused on mobility, C and unlikely to be implemented by any existing platforms. Furthermore, is can easily be implemented it when required. Thus, it is given priority C. Requirement fulfilled: The platform has the ability to detect the location of a mobile device. Requirement partially fulfilled: Requirement not fulfilled: The platform does not have the ability to detect the location of a mobile device. There should be at least one patient role in the sub‐community There should be at least one caregiver role in the sub‐community There should be at least one producer role in the sub‐community There should be at least one consumer role in the sub‐community These four requirements are all related to the minimum occurrence of a role within a community. They will be merged into E one abstract requirement. New requirement: There should be at least one patient, caregiver, producer and consumer role in the sub‐community This requirement is part of the “The platform should allow configuration of sub‐community such that preferences and constraints can be made and stored regarding roles and services.” requirement, and is thus obsolete, giving it priority E. Table 4: Merged requirement from previous researches
Split requirements This section gives the requirements that required a split. If the scope of this research is more detailed than the scope of the previous researches, it is possible a requirement is split into multiple more granular requirements. Once again, the motivation behind the operation is given when it is applied.
The following layout is used to describe the split requirements, the reason behind the split, the new requirements, their priority and the motivation behind the priorities:
Split requirements example Example requirement Motivation behind split New requirement A Priority Motivation behind the priority Requirement fulfilled: When is a requirement fulfilled. requirem Requirement partially fulfilled: When is a requirement partially fulfilled. ent A Requirement not fulfilled: When is a requirement not fulfilled. New requirement B Priority Motivation behind the priority Requirement fulfilled: When is a requirement fulfilled. requirem Requirement partially fulfilled: When is a requirement partially fulfilled. ent B Requirement not fulfilled: When is a requirement not fulfilled. New requirement … Priority Motivation behind the priority Requirement fulfilled: When is a requirement fulfilled. requirem Requirement partially fulfilled: When is a requirement partially fulfilled. ent … Requirement not fulfilled: When is a requirement not fulfilled.
The next table gives the requirements that required a split:
18 of 95
Split requirements Language: The BMVC platform must support the languages of countries where the trials will take place and the project’s language. Hence, Italian, Polish and English must be supported. The platform will now only be used in the Netherlands, so supporting Italian and Polish is no longer relevant. However, being able to set the language of the platform is still important. From this, 2 requirements are derived. New requirement: The platform must support multiple languages. Since the platform will be used in the Netherlands, the Dutch language must be supported, in the sense that it must be possible to change to interface to Dutch. Furthermore, since newly developed applications might be made by international students who do not master the Dutch language, English should also be supported. Thus, a multiple languages service is required. If this requirement is not met, it can lead to problems in the development of new extensions or the usage of the platform. Therefore this platform must be met, giving it priority A. A Requirement fulfilled: The platform supports multiple languages and these languages can be set per user. Requirement partially fulfilled: The platform supports multiple languages but these languages cannot be set per user, or are not supported at the same time. Requirement not fulfilled: The platform does not support multiple languages. New requirement: The platform should have an UI in the Dutch language It is an advantage if the platform already has an interface in the Dutch language since that will save time translating the platform. However, it is not mandatory, since it can always be added later on; assuming the requirement to support multiple languages is met. Since it is an advantage, and not mandatory to meet this requirement, it is given priority B. B Requirement fulfilled: The platform as at least 95% translated into Dutch. Requirement partially fulfilled: The platform has a Dutch translation available, but this translation is not complete. Requirement not fulfilled: The platform does not have a Dutch translation available. The human‐machine interfaces must adapt according to the capabilities of the device used (hence, for some devices only a subset of functionalities may be accessible). Depending on the capabilities of the mobile device, all or just most essential interactions are supported. User‐Interaction modes: the user interface must support request‐response, solicit‐response, publish‐subscribe, one‐ way and notifications. In other words, all standard interaction modes need to be supported. A client will communicate with the base platform in 2 possible ways, by using a browser to view the base platform or by using a dedicated application that uses web services. A dedicated application would be custom made and would not impose any additional requirements on the base platform, besides the availability of web services, which is covered by requirement MVCB3. The new requirements are specifically designed when accessing the platform by using a browser on a device with limited screen size, such as a mobile device. New requirement: The platform should be able to detect the type of device connected. It is not possible to serve a different UI to a device with limited screen size if the type of device connected is not known. However, this functionality can always be added later to the platform, so it is not given the highest priority. Requirement fulfilled: The platform has an extension available to detect the type of device connected. Requirement partially fulfilled: The platform does not have an extension available to detect the type of device connected, but B 3rd party software is available to detect the type of device connected, Requirement not fulfilled: The platform does not have any functionality, either an extension or 3rd party software, available to detect the type of device connected. New requirement: The platform must have the ability to provide a different UI for devices with a limited screen size, such as mobile devices. Serving a different UI to devices with limited screen size is an important requirement. Adding functionality to serve different UI’s to devices with limited screen size to an existing platform is complicated; therefore this requirement is given the highest priority. A Requirement fulfilled: The platform has the ability to provide a different UI. Requirement partially fulfilled: Requirement not fulfilled: The platform does not have the ability to provide a different UI. New requirement: The platform should have a UI specifically designed for devices with a limited screen size, such as mobile devices. The previous new requirement defined that a platform must have the ability to provide another UI to mobile devices. If a platform already has this UI specifically designed for mobile devices, this would safe time in development. However, it can always be designed later on, so it is not given the highest priority. B Requirement fulfilled: The platform has one or more UI’s specifically designed for mobile devices. Requirement partially fulfilled: Requirement not fulfilled: The does not have any UI’s specifically designed for mobile devices. Table 5: Split requirements from previous researches
19 of 95
Summary This section explored two researches for requirements and gave each requirement a priority. Some requirements were redefined; others were merged or split. Section 2.6 gives a summary of the requirements and their priorities. The next section introduces and prioritizes some additional requirements not mentioned in this section. 2.5 Additional requirements The previous section used the requirements from two researches to compose a list of requirements for a base platform for a MVC for telemedicine. This list does however not give a complete list of requirements for the base platform to be used for a MVC for telemedicine which this research investigates for the following reasons: The requirements from both papers focus on developing a MVC specifically for telemedicine, and thus the requirements are focused towards the telemedicine aspect of the MVC. This paper however has a scope towards extending an existing, general purpose MVC into a MVC telemedicine. This difference in scope introduces some additional requirements. Both papers assumed – at least when making the requirements‐ the MVC would be built from scratch. The fact that for this research an existing platform will be used to build the MVC means there is no longer full control over every aspect of the platform and introduces a dependence on a 3rd party that develops this platform. Being dependant on a 3rd party introduces additional requirements on that 3rd party and their software platform. Some of these requirements are technical requirements while other requirements are non technical requirements on the 3rd party itself, such as licensing.
Thus, some additional requirements are introduced to verify if an existing platform can be used as a base platform for the MVC for telemedicine. These requirements are discussed in this section. The same layout as in section 2.4 will be used.
Example additional requirement Example requirement priority Motivation behind the priority
The next table gives the 11 additional requirements:
Additional requirements The platform must be secure. Previously, this was an implicit requirement; neither paper mentions security as a requirement, possibly it was assumed that the developed code would be secure. This assumption is no longer guaranteed since some code will be developed by a 3rd party, it is now an explicit requirement on the existing platform. The platform will handle potentially sensitive medical data; therefore a platform which is as secure as possible is mandatory. The platform must meet this requirement, giving it priority A A. Requirement fulfilled: The platform is secure. Requirement partially fulfilled: Requirement not fulfilled: The platform is not secure. Any security leaks that are published must be fixed fast Only in a perfect world, software is 100% secure. Therefore, there will always be security leaks. If these leaks are fixed as fast as possible, the damage from these leaks is as minimal as possible. Therefore, the platform must meet this requirement and it is given priority A. A Requirement fulfilled: Critical security leaks are usually fixed within acceptable time. Requirement partially fulfilled: Critical security leaks are usually fixed beyond acceptable time. Requirement not fulfilled: Critical security leaks are usually not fixed at all. The platform’s code must be backwards compatible As mentioned in the previous two requirements, security is an important requirement of the base platform. To guarantee A security, security updates need to be applied. Often security updates are only released for the latest version or latest two
20 of 95
versions of a platform, so updating the platform to a new version is mandatory. The MVC platform will be used for research and development by PhD’s and master/bachelor students for their thesis. Once they finish their thesis – and thus their developed code‐ they might not be related to the MVC development anymore. However, their developed code might still be used. If due to updates at the base platform the created extensions will stop working, it can take considerable effort to fix it, since knowledge about the code is not available anymore. So, since it is mandatory to update the base platform, and it is undesired if existing code should be changed, the platform must stay backwards compatible to decrease the work required to maintain the MVC, and it is given priority A. Requirement fulfilled: The platform is completely backwards compatible. Requirement partially fulfilled: The platform is partially backwards compatible. Requirement not fulfilled: The platform does not give any guarantees about backwards compatibility, or is not backwards compatible. The platform should have recent updates If a platform has recent updates, it is more likely that new extensions will be made by 3rd parties, and security leaks will be fixed. A platform that does not have any recent updates is more likely to be discontinued, which results in security leaks not getting patched and ultimately an unsafe and unsuitable platform. Since security is an important requirement of the base platform, this requirement must be met, and it is given priority A. A Requirement fulfilled: The platform has recent updates, last updates less than 3 months ago. Requirement partially fulfilled: The platform does have updates, but not very recent. The last update was more than 3 months but less than 12 months ago. Requirement not fulfilled: The platform did not have any updates over the last 12 months. It should not be too complicated to build our own extensions. As mentioned before, the platform will be used as a development platform by students/P.H.D.’s. Since actually developing these new applications is only a small part of their research, it is not desirable for them to spend a high amount of time developing these applications. Therefore, it is preferable that making new extensions is not too complicated. Since it if preferable, and not mandatory to meet this requirement, it is given priority B. Requirement fulfilled: The platform does not have a steep learning curve, has a simple architecture and multiple tutorials are B available. Requirement partially fulfilled: The platform does not meet one of the requirements above; it has a steep learning curve, complicated architecture or has no tutorials available. Requirement not fulfilled: The platform has a steep learning curve, complicated architecture and no tutorials available. The platform must be free for non commercial use Since the platform will be used as a research platform at this university, revenues will be limited, if any at all. Therefore, the cost should be as low as possible. This motivation alone does not justify this requirement, since a small budget would be available for the base platform if required. However, some of the requirements previously mentioned in this research require a running platform to be verified. For example, it is not possible to verify the requirement “It should not be too complicated to build our own extensions” unless the extensions can be tested, which requires a running platform. Since running a platform A requires the platform to be installed, and therefore acquired, it must be free, or a free trial must be available, giving it priority A. Requirement fulfilled: The platform is free for non commercial use. Requirement partially fulfilled: Requirement not fulfilled: The platform is not free for non commercial use. The extensions useful to this project should be free Like the previous requirement, the extensions useful to this project must be free, or a free trial must be available. However, extensions are not mandatory for the base platform to be a potential base platform; they are optional to be installed. Therefore, since it is important for the base platform to have free extensions available useful to this project, but not mandatory, it is given priority B. B Requirement fulfilled: The platform has more than 10 potentially useful extensions freely available. Requirement partially fulfilled: The platform has some, but less than 10, potentially useful extensions freely available. Requirement not fulfilled: The platform has no potentially useful extensions freely available. The platform must be written in PHP or Java The extensions developed must use the same programming language as the base platform to be able to make calls to the base platform. To make the development of new extensions easier, these extensions ‐and thus the base platform‐ must be written in a programming language where the developers are skilled in. PHP is one of the most commonly used programming languages, and if a developer has skills in a programming language, PHP is most likely one of them. Thus PHP is one of the languages in which the base platform can be written. Java is also an option, since it is taught to students at this university. If A programming language would be used where the extensions developer has no experience in, this would significantly hinder the development of new extensions. Thus it is given the highest priority, priority A. Requirement fulfilled: The platform is written in PHP or Java. Requirement partially fulfilled: Requirement not fulfilled: The platform is not written in PHP or Java. The platform should support databases from multiple vendors Since it is not certain which telemedicine extensions will be developed in the future, it is preferable not to be limited to one database vendor, in case a required feature is not supported by this vendor. Extensions can still use their own custom C database, decreasing the importance of this requirement. Thus, since it is given priority C. Requirement fulfilled: The platform supports more than 2 different database vendors.
21 of 95
Requirement partially fulfilled: The platform supports 2 different database vendors. Requirement not fulfilled: The platform supports only 1 database vendor. The platform API should be well documented Having good documentation can greatly decrease the work required to develop new extensions. If this requirement is not met, developing extension can become too time consuming. Therefore, it is given priority A. Requirement fulfilled: The platform has a good API and multiple tutorials available. A Requirement partially fulfilled: The platform does have a good API or multiple tutorials available, but not both. Requirement not fulfilled: The platform does not have a good API and no multiple tutorials available. The platform should offer support to build mobile applications The scope of the project includes building mobile applications which communicate with the MVC base platform. Therefore, it is an advantage but not mandatory, to have a platform that already offers support to build mobile applications, and it is given priority C. C Requirement fulfilled: The platform offers support to build mobile applications. Requirement partially fulfilled: Requirement not fulfilled: The platform does not offer support to build mobile applications. Table 6: Additional requirements
This section introduced, motivated and prioritized an additional 11 requirements. These requirements, along with the requirements from section 2.4 will be used to evaluate and analyze existing VC platforms to be used as a base platform. The next section summarizes the requirements from both sections. 2.6 Summary The previous two sections described the requirements for a MVC for telemedicine and the base platform used to build it, the priorities of these requirements and the motivation behind these priorities. This section summarizes, orders and labels these requirements. Also some small cosmetic changes will be made. These changes include updating the requirements to MoSCoW terminology (priority A requirements use the term must, priority B the term should, etc), the term BMVC to MVC and some additional small changes to create a more uniform list.
The list on the next page will be used in the next chapters when evaluating and analyzing the existing platforms.
ID Requirement Priority A MVCA1 The platform must allow creation of a sub‐community. MVCA2 The platform must allow creation and management of profiles. MVCA3 It must be possible to restrict access to the sub‐community. MVCA4 The platform must be accessible using a desktop, notebook, tablet PCs and SmartPhone. Whenever required, for instance based on an in‐depth privacy and security analysis, MVCA5 information between endsystems (mobile devices and desktops) is exchanged in a security enhanced application protocol (such as https). The platform must have the ability to provide a different UI for devices with a limited screen MVCA6 size, such as mobile devices. MVCA7 The platform must support multiple languages. Different user roles must be supported by the MVC platform, including, but not limited to, MVCA8 patient, cardiologist, therapist, nurse, family member and friend. MVCA9 The platform must have the ability to fully customize the UI. MVCA10 The platform must have the ability to have user specific UI’s. The platform must allow configuration of sub‐community such that preferences and MVCA11 constraints can be made and stored regarding roles and services. MVCA12 The platform must be secure.
22 of 95
MVCA13 Any security leaks that are published must be fixed fast. MVCA14 The platform’s code must be backwards compatible. MVCA15 The platform must have recent updates. MVCA16 The platform must be free for non commercial use. MVCA17 The platform must be written in PHP or Java. MVCA18 The platform API must be well documented.
Priority B Users should have the possibility to get help in using the system, either through a context‐ MVCB1 aware help function or via (context‐aware) help‐desk. This help functionality is about help in using the system only. Users, especially patients, should have full understanding and insight in who is able to read MVCB2 what information about himself or herself, and can exercise control over who is able to see what within the context of a mobile virtual community. For mobile applications, the interaction / communication should be based on WSDL and MVCB3 SOAP. REST is considered a potential candidate for the (near) future. MVCB4 The platform should be able to send invitations to users to join a sub community. MVCB5 The platform should be able to send invitations to users to join the main community. MVCB6 The platform should be able to detect the type of device connected. The platform should have a UI specifically designed for devices with a limited screen size, MVCB7 such as mobile devices. MVCB8 The platform should have an UI in the Dutch language. MVCB9 The extensions useful to this project should be free. MVCB10 It should not be too complicated to build our own extensions.
Priority C There is the need for a translation service. Further decisions are needed so as to determine if MVCC1 this can be done off‐line or needs to be online (near real‐time), whether it must be human translation by an authorized translator etc. Whenever required (based on an in‐depth privacy and security analysis), health related data MVCC2 of patients should be stored in a secure manner in the MVC database. MVCC3 The platform should be able to detect the location of a mobile device. MVCC4 The platform should support databases from multiple vendors. MVCC5 The platform should offer support to build mobile applications.
Priority D MVCD1 The platform should be able to identify who should be alarmed in case of an emergency. The platform should be able to transfer viewing session without interruption. The platform should be able to support multiple devices associated with one role. Various types of support should be supported, for patients the four basic types of support MVCD2 relevant are: informational support, instrumental support, emotional support and feedback support. For the access and interaction with the Mobile Virtual Community Platform a dedicated mobile application needs to be deployed on the mobile device in use so as to take optimal MVCD3 advantage of the functionalities supported by the platform (such as timely notifications and the like).
23 of 95
In order to be implementation technology independents, standardized protocols for the MVCD4 interaction and communication between mobile device and the MVC access platform are required. The platform should be able to collect, store, stream and analyze the vital signs of the MVCD5 patient. Table 7: Base platform requirements 2.7 Conclusion This chapter started by defining the scope of this research and introduced 2 researches from which the requirements of this research were taken. The approach used to take these requirements, as well as the approach used to prioritize these requirements was also described. Next, the requirements from the researches were analyzed to determine their importance. Section 2.4 gives the results of this analysis ‐ the priority of a requirement and the motivation behind this requirement‐. Some additional requirements were introduced because they were outside the scope of the researches used for section 2.4. Section 2.5 described and prioritized these requirements Finally section 2.6 summarized, ordered and labeled all relevant requirements.
Now there is a complete set of requirements for the base platform. The priority A requirements will be used in chapter 3 to evaluate the existing platforms. In chapter 4, Priority A, B, and C requirements will be used for the score given to each platform. Finally, the Priority D requirements will be used in chapter 5 to create the scenario from which the use cases are derived.
24 of 95
3 Platform selection and evaluation
3.1 Introduction The previous chapter composed a set of requirements which will be used to evaluate existing VC builder platforms for their potential to be used as a base platform. This chapter composes and evaluates a list of potential VC base platforms using part of this set of requirements. Based on this evaluation, a set of platforms is composed to be analyzed in chapter 4.
First, section 3.2 gives the approach used to compose the list of potential base platforms and the approach used to evaluate these platforms. Section 3.3 starts the search for potential base platforms by defining 3 search directions in which to look for these platforms. Section 3.4 composes a set of search terms; First two of the 3 search directions are merged to simplify the search and for each of the two remaining directions this set is composed. Next, the search is carried out and the resulting list of primary and secondary sources is given. From these sources, a list of platforms found is composed. The next phase of the research is the evaluation of these platforms. To reduce the work required for this phase, an elimination approach of 2 rounds is used; first a quick evaluation using 5 requirements, followed by a complete evaluation. Section 3.5 evaluates the platforms using these 5 requirements which the platform must fulfill and are easily verifiable. Section 3.6 evaluates the platforms that met all 5 requirements using all priority A requirements. This section gives, besides the results of this evaluation, a small description of each platform, as well as some of its unique features. Using the results of the requirements evaluation, a list of platforms to be analyzed in chapter 4 is composed. At the end of this section, a small discussion concerning some of the requirements is done. Finally, section 3.7 gives a summary of the work done in this chapter and the results acquired. Approach This section describes the approach used for the composition of the list of potential base platforms and the evaluation of these platforms. First the approach used to compose the list of base platforms is described followed by the approach of the 2 steps of the evaluation. The following figure gives a schematic overview of the approach used:
Figure 3: Evaluation approach
Platform selection The goal of the search for potential base platforms is to find the names of potential base platforms, as well as to find a reference to the main site of that platform. In this search, two types of sources will be used. The first type of source is a primary source, in other words a source directly referring to a potential
25 of 95 base platform. The second type of source is a secondary source, in other words a source that has references to potential base platforms, but is not a base platform itself. By using these 2 types of sources, the number of potential base platforms to be investigated is maximized, and this research is made as thorough as possible.
For each type of source, a set of search terms is composed to find these sources. It is possible a search term for a primary source refers to a secondary source and vice‐versa, in which case the search approach for the latter will be used. Section 3.4 gives the search terms used.
The following figure describes the search approach used for both types of source.
Figure 4: Search approach
Primary sources The results of the search terms for primary sources contain 2 types of relevant results, platforms and secondary sources. If the result is a secondary source, the approach mentioned later in this section for the secondary sources is followed. If the result is not a secondary source, the source is checked for relevance, and if it is relevant, it is added to the set of platforms to be checked at the first round of the evaluation. A source can be considered not relevant for the following reasons: The source is not about a possible base platform. The source is already found earlier for this search term, and it is no longer relevant since it would introduce duplicate sources. This occurs most often when a source links to a sub site of a platform, not that main site. The source is outside the scope of the project, in most cases because the source is hosted and not self hosting. In section 1.3 the choice was made only to look for self hosting platforms, and hosted platforms, which can be found with the same search terms, are not considered relevant.
Secondary sources The results of the search terms for secondary sources are first checked if they were already investigated before with a different search term. If this is not the case, it is verified that the source is relevant. If this is the case, the source will be investigated and the platforms mentioned will be checked for relevance the same way the platforms mentioned for the search terms for the primary sources are checked. Once again, if the source is relevant, it is added to the set of platforms to be checked at the first step of the evaluation. A secondary source can be considered irrelevant for the following reasons: The source is not about a comparison site for a possible base platform.
26 of 95
The secondary source was already found for this search term, and it is no longer relevant since it would introduce duplicate sources.
For each type of source, each search term is entered into Google, and the first 50 results found are analyzed.
Round 1: Quick evaluation The first round consists of a quick evaluation of the platforms introduced at the platform selection that will be evaluated using a small set of requirements. The requirements were chosen because they have both mandatory and are easy to verify. All platforms will be evaluated using the following requirements: MVCA1: The platform must allow creation of a sub‐community. MVCA7: The platform must support multiple languages. MVCA15: The platform must have recent updates. MVCA16: The platform must be free for non commercial use. MVCA17: The platform must be written in PHP or java.
If a platform does not meet one of these 5 requirements, it is no longer a potential candidate and will thus not be evaluated at the priority A evaluation in section 3.6. Furthermore, if the research shows that for any reason a platform is unsuitable to be used, it will not be evaluated at the complete evaluation.
Round 2: Complete evaluation During the second evaluation round, each platform that met all 5 requirements from the first round has all the 18 priority A requirements from chapter 2 evaluated. The results of the evaluation are used to compose a list of platforms to be analyzed in chapter 4. Platforms that have a high fulfillment of the requirements are more likely to be added to the list than platform that has a low fulfillment of requirements; if a platform meets all the requirements it is likely to be added to that list. Not all requirements can be checked by researching the information given about a platform; some requirements need a working platform to be tested. In some cases there are 2 directions to get a working platform. Some platforms have a working demo on their website which can be used to evaluate the requirements. Another direction is to install the platform on a dedicated server. Installing a platform on a dedicated server has several advantages. First of all, there is full control over the platform; the demo sites often have limited control over all the administrator functionality and are reset every x minutes. Furthermore, these demo sites don’t allow new extensions to be installed. By installing the platform on a dedicated server these limitations do not exist. Also, not all platforms have a working demo on their website, and those platforms need to be installed anyway. Evaluating the requirements of some platforms on a demo site, and some on the dedicated server can lead to an unequal comparison. Therefore, every platform to be evaluated is installed on the dedicated server. 3.2 Search directions This section gives a short description of the 3 types of base platforms this research considers to be used as a base platform for developing extensions a MVC for telemedicine. The reason to not limit the search to the most obvious direction –community builders‐ is to not limit the options, and make this research as thorough and extensive as possible. This section also describes some of the advantages and disadvantages of each direction.
27 of 95
Community builder A Community builder is a piece of software designed to create online social networks. It offers services like profiles, group web pages, group blogging and friends. Usually they offer support to extend the existing functionality with new features making them the ideal potential candidates as a base platform.
Content Management Systems A Content Management Systems (CMS) is a piece of software designed for creating, publishing and modifying content on a website. A CMS is not designed to have typical online community features like profile pages and grouping. There are however several Content Management Systems that have extensions available that offer functionality to create online communities. One of the main advantages of using a CMS is that they are generally more popular than community builders, and have a more active support and developer community. Therefore, since they have a more active community, they are more extensive, more professional, and all in all more mature. One of the disadvantages is that a CMS, whose primary goal is to deliver content does not have community building as a primary goal and community building extensions are not always available. Even when extensions are available, extending those with new functionalities can be harder than extending a community builder, since you will be extending an extension, and where the CMS platforms are often designed to be extended (it is one of their features), the developed extensions often are not (they are designed to be an end product).
Enterprise portals While enterprise portals (EP) are not designed to be used as community builders, they have some interesting fundamental features. An enterprise portal page typically offers a framework that can be used to place different pieces of information on, these pieces are called portlets. A portlet is a pluggable UI software component that displays the data from a specific application. Each community can have its own portal, each portal having portlets specific for that community. This offers great flexibility for the community pages. Enterprise portals have some more interesting features. Since they are designed to be used in businesses where data is sensitive, data and user access control is one of the key features. Another feature is the provision of single sign on (SSO), which can be used by the extensions which are to be developed. If an enterprise portal can be found that also supports social networking, this portal can be used as a base platform for the MVC for telemedicine. If this social networking is offered by an extension to the enterprise portal, the disadvantage mentioned for CMS’s, extending an extension is also true for enterprise portals. 3.3 Platform selection The previous section split community builders and CMS with community builder extensions due to different features and approaches. However, due to their overlap in functionality they are often grouped in secondary sources and their search terms overlap. This research will follow this approach. Thus, the search for suitable base platforms is split into 2 directions: first community builders and CMS with community builder extensions will be researched followed by a research into enterprise portals. Both search directions will use the search approach described in section 3.2.
Search terms To find the primary sources several derivative terms for VC’s, such as “community builder” , ”social networking”, “social community”, “virtual community” and “online community” are used in combination with a term defining the requirement for a piece of software to build this virtual community such as “software” or “platform”. Enterprise portals are already pieces of software, so to find the primary sources for enterprise portals, adding the term “software” or “platform” was not required. However, there are 2 properties a typical enterprise portal does not have, which are required for the enterprise
28 of 95 portal to be suitable to be used as a base platform. First, a typical enterprise portal is not free, which is a requirement of the base platform, so the term “free” is added as a search term. Second, a typical enterprise portal does not have VC functionality, so the terms “social” and “CMS” were introduced.
To find the secondary sources, a set of search terms to specifically find secondary sources is introduced. These terms were “comparison”, “review” and “list of”. To find the platforms, these terms were combined with the terms to find the primary sources of that type.
This results in the following set of search terms for each type of base platform and source:
Primary source search terms Secondary source search terms Community community Builder community software comparison builder & community software community software review CMS with community builder platform list of community software community community builder software social networking software builder social networking platform comparison extension social network engine social networking software review social networking software list of social networking software social community builder software virtual community software social community builder platform comparison virtual community platform virtual community software review virtual community software list of virtual community software online community builder online community builder online community builder platform comparison online community builder software online community builder review list of online community builders Enterprise free enterprise portal list of free enterprise portals portal enterprise portal cms free enterprise portal comparison enterprise cms free enterprise portal review social enterprise portal list of enterprise portals enterprise portal comparison enterprise portal review
Table 8: Platform selection search terms
Each search term was entered into the Google [15] search engine separately. For each search term, the first 50 results were analyzed. While doing the research, it became clear that after 50 results the number of relevant results decreased significantly. The approach described in section 3.2 was used to find the primary and secondary sources. A total of 26 secondary sources was found, a complete list of these sources is given in appendix A. The search results can be found in appendix B.
Combining the relevant platforms found at these secondary sources and the primary sources resulted in the following platforms found:
29 of 95
Community builder & community builder Enterprise portal extension platform Around Me Exo platform Anahita GateIn Dolphin Hippo CMS Community Engine Jetspeed 2 Drupal ‐ Commons Liferay Dzoic Plone Elgg Impress CMS Inoshi Jcow Joomla lovdbyless Mahara Mugshot NetworkX Newsgator Oxwall phpFox phpibazi socialengine Telligent evolution Tiki Wiki Wordpress‐ buddypress Xoops‐Yogurt Table 9: Potential platforms
References to these primary sources can be found in appendix A.
Summary This section introduced a set of search terms used to find potential base platforms. Each search term was entered into Google, and the results were analyzed, which lead to a number of primary and secondary sources. These sources were used to compose a list of 24 Community builder & CMS with community builder extensions and 6 Enterprise portals. These platforms are the potential base platforms and will be evaluated in the next section.
Discussion In some cases, a platform was mentioned at comparison sites, but was not found in any of the Google search sources. Two possible reasons for this difference were found: A platform is a CMS with an extension for community building. Since this extension is often not as popular as a CMS or community builder platform, it is not mentioned at the first 50 Google search results. A secondary source however investigates platforms with a certain functionality, in which the CMS with the extension is found Some sources are outdated, and some platforms mentioned are no longer maintained, and have become unpopular. Google does not show these platforms at the first 50 results.
The following figure gives a schematic overview of the current position in the elimination approach. At the end of each round of the elimination, this figure will be given.
30 of 95
Figure 5: Platform composition summary 3.4 Round 1: Quick evaluation This section gives the results of the first round of the evaluation, the quick evaluation round. For every platform found in the previous section, the following table is used to describe the results of the quick evaluation of that platform: G1 G2 G3 G4 G5 To next Name Comments round
The G1 – G5 fields describe if the platform meets the 5 requirements used in the quick evaluation. These requirements are:
G1: The platform must be free for non commercial use G2: The platform must allow creation of a sub‐community. G3: The platform must support multiple languages. G4: The platform must have recent updates G5: The platform must be written in PHP or Java
If one of the requirements is not fulfilled, the investigation of that platform is terminated to reduce the work required. This leads to empty requirement fields in the table with the results. Any comments concerning a platform, or a further explanation of the outcome of the evaluation of a requirement is put in the comments field. Finally, the conclusion of the quick evaluation, whether a platform should be evaluated for priority A requirement in the next section, is put in the last field.
Community builders & CMS with community builder extension In the following table the results of the evaluation of the 5 quick evaluation requirements are given for the Community builders & CMS with community builder extension platforms:
Free/non Sub‐ Multiple Recent Next PHP / Java commercial community languages updates round No* Yes Around Me * Discontinued 2 years ago No Anahita Yes Yes Yes Yes Yes Yes Dolphin Yes Yes Yes Yes Yes Yes No* Community Engine *Ruby on Rails No Drupal ‐ Commons Yes Yes Yes Yes Yes Yes Dzoic No Yes Yes Yes No Elgg Yes Yes Yes Yes Yes Yes Yes No* Yes Yes Yes Impress CMS * With the profile addon, sub‐communities called tribes should be able to be created. However, No this did not work.
31 of 95
Free/non Sub‐ Multiple Recent Next PHP / Java commercial community languages updates round Inoshi Yes No No Jcow No No Yes No* Yes Yes Yes Joomla * Grouping is only possible with paid extensions, such as Community Builder [16]. No lovdbyless Yes No Yes No Mahara Yes Yes Yes Yes Yes Yes Mugshot Yes No No NetworkX Yes Yes No No Newsgator No Yes Yes No Oxwall Yes Yes Yes Yes Yes Yes phpFox No Yes No phpibazi Yes No Yes No socialengine No No Telligent evolution No Yes Yes No Yes No* Yes Yes Yes * It is possible to group people by adding them to a permission group, and limiting access to Tiki Wiki pages/modules to this permission group. However, this is not a straightforward approach and No will most likely lead to problems. Therefore, Tiki Wiki is given a no on the ‘creation of a sub community’ requirement. Wordpress ‐ Yes Yes Yes Yes Yes Yes buddypress Yes No Yes Yes Yes Xoops‐Yogurt No Table 10: Community builders & CMS with community builder extension
Enterprise portals
The following table gives the results of the evaluation of the 5 quick evaluation requirements for the Enterprise portals.
Free/non Sub‐ Multiple Recent PHP /
commercial community languages updates Java Exo platform No Yes Yes Yes Yes No GateIn Yes Yes Yes Yes Yes Yes Hippo CMS Yes No Yes Yes Yes No Yes Yes No* Yes Jetspeed 2 * Last update Q1 2011. Q2 and Q4 releases were never released. So no updates in over 1 year No Liferay Yes Yes Yes Yes Yes Yes Yes Yes No* Plone *Python No Table 11: Enterprise portals
32 of 95
There are 9 platforms that met all 5 requirements described earlier. These platforms are: Anahita Dolphin Drupal – Commons Elgg Mahara Oxwall Wordpress – Buddypress Liferay GateIn
Conclusion This section performed the first round of the evaluation. Using 5 requirements, the initial list of 24 community builder & CMS with community builder extension platforms at the start of this section is reduced to 7 platforms; these platforms will be investigated in the next round. From the initial list of 6 enterprise portals at the start of this section, 2 platforms will be investigated in the next round. This leads to a set of 9 platforms in total.
Figure 6: Quick evaluation summary 3.5 Round 2: Priority A evaluation The previous section did the first round of the evaluation by introducing 5 requirements all platforms must meet. This section continues the evaluation of the platforms for the 7 community builder & CMS with community builder extension platforms and 2 enterprise portals that met all requirements from the first round. For each platform, the priority A requirements are evaluated and the results of this evaluation are given. A small summary of the platform together with a screenshot of the platform and a description of the experiences with the platform are also given. The order in which platforms are evaluated is based on the number of times they were mentioned in the sources, starting with platforms mentioned most often. If a platform meets all priority A requirements it will be analyzed in the next chapter. At the end of the section a list of all platforms to be analyzed in chapter 4 is composed. Appendix C gives a summary of the fulfillment of the priority A requirements for all platforms.
33 of 95
To reduce the size of the tables describing the results of the priority A evaluation, an abbreviated version of the requirements is used. The table on the next page gives the original requirement and the abbreviated requirement:
Original requirement Abbreviated requirement MVCA1: The platform must allow creation of a sub‐community. MVCA1: Sub‐community creation MVCA2: The platform must allow creation and management of profiles. MVCA2: profile creation and management MVCA3: It must be possible to restrict access to the sub‐community. MVCA3: restrict access to sub community MVCA4: MVCs must be accessible using a desktop, notebook, tablet PCs and SmartPhone. MVCA4: Accessibility MVCA5: Whenever required, for instance based on an in‐depth privacy and security MVCA5: Https support analysis, information between endsystems (mobile devices and desktops) is exchanged in a security enhanced application protocol (such as https). MVCA6: The platform must have the ability to provide a different UI for devices with a MVCA6: Different UI for mobile devices limited screen size, such as mobile devices. MVCA7: The platform must support multiple languages. MVCA7: Multiple languages MVCA8: Different user roles must be supported by the MVC platform, including, but not MVCA8: Different roles limited to, patient, cardiologist, therapist, nurse, family member, friend. MVCA9: The platform must have the ability to fully customize the UI. MVCA9: Fully customize UI MVCA10: The platform must have the ability to have user specific UI’s. MVCA10: User specific UI MVCA11: The platform must allow configuration of sub‐community such that preferences MVCA11: Constraints on sub‐communities and constraints can be made and stored regarding roles and services. MVCA12: The platform must be secure. MVCA12: Secure platform MVCA13: Any security leaks that are published must be fixed fast. MVCA13: Security leaks fixed fast MVCA14: The platform’s code must be backwards compatible. MVCA14: Backwards compatibility MVCA15: The platform must have recent updates. MVCA15: Recent updates MVCA16: The platform must be free for non commercial use. MVCA16: Free MVCA17: The platform must be written in PHP or Java. MVCA17: PHP or Java MVCA18: The platform API must be well documented. MVCA18: Well documented API Table 12: Abbreviated requirements
3.5.1 Elgg Elgg [17] is an open source social networking engine developed by the Elgg Foundation project. Elgg is free to use under the terms of the GNU General Public licensev2 [18] and MIT License [19]. Elgg has several features which make it an interesting option as a base for the MVC for telemedicine. It has a flexible and abstract data model, which can make extending it easier. It also has the possibility to set access control on all entities in this data model, thus allowing very granular access to sensitive data. It has a web services API which allows simple communication with external data sources. Finally, it was mentioned the most at the sources.
34 of 95
Figure 7: Elgg
Out of the box, Elgg has a sleek and simple blue and white design. It has several buttons for basic functionalities like groups and members. On the front page a list with recent activities and a log in form are shown. After logging in, access restricted data, like private groups and members are shown. The administrator panel is simple – to the point where it is too simple and missing some features, at least compared to the other VC’s. One of the strengths –but also one of its possible weaknesses‐ is the fact that every extension in Elgg is a plug‐in, from the groups to the UI and from the garbage collector to the language packs. All extensions are in 1 list, which makes the plug‐in page a bit cluttered.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Partially, HTTPS login is supported, however it is not possible to customize which information is sent using HTTPS MVCA6: Different UI for mobile devices Yes MVCA7: Multiple languages Yes MVCA8: Different roles No, this might be done using access controls, but not out of the box MVCA9: Fully customize UI Yes MVCA10: User specific UI Yes MVCA11: Constraints on sub‐communities No MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Partially, No guaranteed backwards compatibility between the major releases . [20] MVCA15: Recent updates Yes, the latest release was less than 1 month old MVCA16: Free Yes, GPLv2 MVCA17: PHP or Java Yes, it is written in PHP MVCA18: Well documented API Yes, API and several tutorials available. [21] Table 13: Elgg priority A evaluation
35 of 95
3.5.2 Dolphin Dolphin [22]is a software package for building social networks developed by Boonex. It is free to use after registering. It was considered in the previous research [10]done by this C. Dulawan as a base platform for the MVC for telemedicine. The research concluded that Dolphin did not meet the requirements at the time. However, this research was done in 2008, which is 5 years ago. Since then, the platform has undergone continuous development, and the requirements might have been met now, so it was decided to take another look. One of the interesting features is that Dolphin offers mobile apps for iPhone and Android. Also, dolphin offers the usual features of a VC builder, like grouping, forums, and a selection of extensions to offer more usability.
Figure 8: Dolphin
The first thing that draws attention after installing Dolphin is a front‐page that shows a lot of items, from all members to Boonex news. These items make the front page look cluttered. Fortunately, they can be removed from the admin page. The Boonex banners however cannot be removed unless a paid subscription is acquired. Navigating the website does not feel intuitive; sometimes a great amount of time is spent finding a simple feature, like the admin page. The reviews about Dolphin are mixed. On the one hand people like the features Dolphin offers, and the fact that it is free. On the other hand people claim the code is not nicely written, and making your own extensions can be hard.
36 of 95
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Partially, it can be set per page, but only by editing the code. [23] MVCA6: Different UI for mobile devices Partially, it is possible to offer a specific UI, so once the type of device is detected, a different UI can be provided MVCA7: Multiple languages Yes MVCA8: Different roles Yes MVCA9: Fully customize UI Partially, it is not possible to remove the Boonex logo unless a paid subscription is acquired MVCA10: User specific UI Yes MVCA11: Constraints on sub‐communities No MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Partially, the new version will have a major overhaul, and will most likely not be backwards compatible, but until then it was mostly backwards compatible [24] MVCA15: Recent updates Yes, the last update was less than 1 month old MVCA16: Free Yes, but only with the Boonex logo on every page MVCA17: PHP or Java Yes, it is written in PHP MVCA18: Well documented API Partially, to our knowledge, there is no API page. A developer has to look into the source code to find it Table 14: Dolphin priority A evaluation
3.5.3 WordPress – BuddyPress WordPress [25] is one of most popular blogging tools currently available. It is distributed under the GPLv2 License. WordPress is not suitable to be used as a community builder by itself, but with the BuddyPress [26] extension it becomes a potential base platform. BuddyPress is an extension to WordPress which adds user registration, message posting and grouping.
Figure 9: WordPress
37 of 95
The default theme of WordPress shows a blue and white UI, comparable to Elgg. The top menu is easy to navigate, with just 5 buttons. Creating a new group page in WordPress is hard. Since WordPress is one of the most popular blogging tools around, a wide range of extensions and themes are available.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Yes, by using [27] MVCA6: Different UI for mobile devices Yes MVCA7: Multiple languages Partially, WordPress does support multiple languages, but not at the same time, at least not out of the box MVCA8: Different roles Yes MVCA9: Fully customize UI Yes MVCA10: User specific UI Partially, there are add‐ons to have user specific UI's, but these have no recent updates [28] [29] MVCA11: Constraints on sub‐communities No MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Partially, not always backwards compatible, as proven in [30]and [31] MVCA15: Recent updates Yes, the latest update is less than 3 months ago MVCA16: Free Yes, releases under GPLv2 MVCA17: PHP or Java Yes, written in PHP MVCA18: Well documented API Partially, documentation is available, but only inside the code Table 15: WordPress priority A evaluation
3.5.4 Mahara Mahara describes itself as follows on their website: First established in mid 2006, the Mahara project started as collaborative venture funded by New Zealand's Tertiary Education Commission's e‐learning Collaborative Development Fund (eCDF), involving Massey University, Auckland University of Technology, The Open Polytechnic of New Zealand, and Victoria University of Wellington. Since July 2007, Kineo Pacific has worked with Catalyst IT to guide the further development of Mahara. It is distributed under the GPL3 license.
Mahara [32] is a highly modular, extensible personal learning environment. It is aimed towards building virtual communities in the field of education and offers the usual features of a VC builder: profiles, groups and forums as well as some features unique in the field of education, such as institutions and student ID’s. If Mahara would be used as a base platform these features should be removed.
38 of 95
Figure 10 :Mahara
The default theme –Mahara comes with 7 themes‐ shows a clear green and white UI. The default page is the user’s dashboard, which shows an activity stream and the actions a user can take, such as joining a group. At the top of the screen a 2 layer menu is shown which is easy to navigate. New pages can be made using a drag and drop interface where blocks can be dropped onto a page. It is also possible to restrict access to these pages to users, groups or institutions.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Partially, it is possible to set https access per page via the apache configuration, but there is no extension available to do so from the platform itself MVCA6: Different UI for mobile devices Partially, default theme is compatible for mobile devices MVCA7: Multiple languages Yes MVCA8: Different roles Partially, it is possible to give custom roles by inserting them into the database MVCA9: Fully customize UI Yes MVCA10: User specific UI Yes MVCA11: Constraints on sub‐communities Per community, it is possible to set which group of users can view which page MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Partially, no guaranteed backwards compatibility between the major release MVCA15: Recent updates Yes MVCA16: Free Yes MVCA17: PHP or Java Yes, written in PHP MVCA18: Well documented API Partially, there are developer pages but no real API [33] Table 16: Mahara priority A evaluation
39 of 95
3.5.5 Anahita Anahita [34] is an open source social networking platform developed by Rmd Studio Inc and Peerglobe Technology Inc. It is distributed under the GPL3 license. Originally based on a modified version of Joomla! 1.5, it is now a standalone platform where Joomla code is being replaced by custom code. With the groups extension it is possible to create sub‐communities.
Figure 11: Anahita
The functionality of Anahita is limited. While you can make groups, you cannot add pages to this group. It is not possible to create custom roles, nor limit access to parts of the group to certain roles. Furthermore, it is not possible to invite users to join the main community, or ‐to our knowledge‐ invite users to join a sub‐community.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Partially, it is possible to set https access per page via the apache configuration, but there is no extension available to do so from the platform itself MVCA6: Different UI for mobile devices Yes MVCA7: Multiple languages Yes MVCA8: Different roles No MVCA9: Fully customize UI Yes MVCA10: User specific UI No MVCA11: Constraints on sub‐communities No MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility No MVCA15: Recent updates Yes, the latest release is less than 1 month old MVCA16: Free Yes MVCA17: PHP or Java Yes, written in PHP MVCA18: Well documented API Yes Table 17: Anahita priority A evaluation
40 of 95
3.5.6 Drupal – Commons Drupal [35] is an open source CMS distributed under the GPL. It offers the possibility to be extended by making modules. One of the modules is already developed is Commons [36], which adds profiles and groups to Drupal. Commons is open source and developed by Acquia. With thousands of extensions available, Drupal is one of the most complete platforms available.
Figure 12: Drupal
After installation multiple themes are available. The theme shown in the screenshot above is the “Commons Connect” theme. At first glance Drupal looks like any community builder, there are groups, profiles and an activity stream. However, when you start to look at the administration page, Drupal’s strength becomes more apparent. There are a lot of features available for managing users, group and other functionalities. With available extensions, Drupal has a strong User‐Access Control (UAC). Out of the box, Drupal did not meet several requirements. However, for most of them, an extension was available to fulfill the requirement.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Yes, with add‐ons it is also possible to set what information should be sent using https. [37] MVCA6: Different UI for mobile devices Yes, with [38] MVCA7: Multiple languages Yes MVCA8: Different roles Yes, With OG user roles you can set user roles per sub community. [39] MVCA9: Fully customize UI Yes, Multiple themes. Able to configure the menu/parts of the site from the UI. And finally, since
41 of 95
it is open source, anything can be edited. MVCA10: User specific UI Yes, it is possible to set the UI per user MVCA11: Constraints on sub‐communities Yes, with OG user roles you can set roles per user sub community. [39] MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Partially, no backwards compatibility between major releases. [40] MVCA15: Recent updates Yes, last update less than a month old MVCA16: Free Yes, GNU public license MVCA17: PHP or Java Yes, written in PHP MVCA18: Well documented API Yes, well documented API and reference available Table 18: Drupal priority A evaluation
3.5.7 Oxwall Oxwall [41] is a free open source software package for building social networks. It is operated by the non‐profit Oxwall foundation. It offers the usual features of a VC builder, like group pages, profiles and a newsfeed. There is support for multiple languages and themes and a simple User‐Group‐Role model. Around 150 extensions and some themes are available.
Figure 13: Oxwall
The default theme used by Oxwall has a clear and intuitive design. The built‐in drag and drop editor makes building new pages fast and easy. The default page is the user’s dashboard, it shows some links to other pages and news feed showing friend and group updates. However, when the evaluation is done,
42 of 95
the limitations of the platform become clear. Oxwall has no developer API, nor is it possible to set different UI’s per user. Furthermore, it is not clear if the code is backwards compatible.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Partially, the platform should work on https, but no functionality to add https to specific parts of the platform MVCA6: Different UI for mobile devices Partially, work in progress MVCA7: Multiple languages Yes MVCA8: Different roles Yes MVCA9: Fully customize UI Yes MVCA10: User specific UI No MVCA11: Constraints on sub‐communities No MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Unclear, no information can be found about backwards compatibility MVCA15: Recent updates Yes, the latest release was 3 months old MVCA16: Free Yes MVCA17: PHP or Java Yes, it is written in PHP MVCA18: Well documented API No API available Table 19: Oxwall priority A evaluation
3.5.8 Liferay Liferay Portal Community Edition [42] is a free, open source enterprise portal developed by Liferay Inc. It is one of the few free enterprise portals available. Even though it is an enterprise portal, it still offers the usual functionality of a Community builder like group pages, profiles and an activity stream.
Figure 14: Liferay
Installing Liferay is quite straightforward when using a bundled edition, just download, unzip and run. Making groups in Liferay is done different compared to the previous tested platforms. At the previous
43 of 95 platforms, when making a new group, a new instantiation of the group webpage template was made. At Liferay, when creating a new group, the developer creates a whole new set of web pages, and gives users access to these web pages. An advantage of this approach is the increased flexibility since you can now change all the features of a group page. A disadvantage of this approach is the additional overhead when creating a new group. Liferay offers a very strong UAC. For each element on a group page, you can set which user or group can do what action with that element. Another advantage of Liferay is its extensive admin panel.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Partially, best solution seems to be to use an apache server and then forward it using virtual servers. An out‐of‐the‐box solution is not available. [43] MVCA6: Different UI for mobile devices Yes. It is possible to set mobile themes. It is possible to limit access to certain functionalities to mobile/fixed. It is possible to set mobile device rules MVCA7: Multiple languages Yes MVCA8: Different roles Yes, globally and per community MVCA9: Fully customize UI Yes, multiple themes and multiple layouts offer flexibility regarding the UI. 100% customization could not be verified nor invalidated MVCA10: User specific UI Yes MVCA11: Constraints on sub‐communities Yes MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Partially, no backwards compatibility between the major releases, deprecation process between them. [44] MVCA15: Recent updates Yes, latest release less than 3 months old MVCA16: Free Yes MVCA17: PHP or Java Yes, written in Java MVCA18: Well documented API Partially, there is a generated javadoc, but the actual documentation about what the classes/functions do is limited Table 20: Liferay priority A evaluation
3.5.9 GateIn GateIn UXP [45] is an open source enterprise portal based on the GateIn Portal and provides additional applications to build social intranets. GateIn Portal itself is an open source website framework sponsored by eXo and Red Hat. Like Liferay, communities are made by creating a new set of websites called a portal, and giving a user access to these websites. The same advantages and disadvantages of this approach as mentioned in section 3.6.8. still apply. GateIn portal offers the usual features for an enterprise portal, such as SSO, user and group management and multiple templates. The UXP extension converts the enterprise portal into a VC, by adding functionality like a social activity stream.
44 of 95
Figure 15: GateIn
GateIn, like Liferay, comes with a sample community to show its capabilities. Creating a new community is straightforward. One aspect where GateIn differs from the other platforms is the lack of an administration panel. The administration is done via a menu which is accessible for administrators on any page. The options available in this menu are limited.
Priority A requirement Requirement met MVCA1: Sub‐community creation Yes MVCA2: profile creation and management Yes MVCA3: restrict access to sub community Yes MVCA4: Accessibility Yes MVCA5: Https support Partially, Https is supported, but only for the complete platform, not per page MVCA6: Different UI for mobile devices Partially, work in progress https://community.jboss.org/wiki/GateInMobileSpecifications MVCA7: Multiple languages Yes MVCA8: Different roles Yes MVCA9: Fully customize UI Yes MVCA10: User specific UI Maybe. The reference guides claims it is possible, and refers to the user guide on how it should be done. The user guide contains no information about user specific UI's. So this requirement could neither be confirmed not invalidated MVCA11: Constraints on sub‐communities No MVCA12: Secure platform MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility Partially, Backwards compatible within every major release, no guarantees between major releases MVCA15: Recent updates Yes MVCA16: Free Yes MVCA17: PHP or Java Yes, written in Java MVCA18: Well documented API Yes, API [46]and reference guides available Table 21: GateIn priority A evaluation
3.5.10 Summary This section started with 9 potential base platforms. A small summary of each platform was given, together with a screenshot of the platform and a description of the experiences with the platform. Each platform was evaluated using priority A requirements. Based on the results of this evaluation, the platforms can be put into 3 groups: Platforms meeting all requirements. Platforms meeting all requirements, except the requirements concerning roles and privileges. Platforms not meeting one or more requirements besides the requirements concerning roles and privileges.
45 of 95
For each group, a small summary of that group and the platforms belonging to that group are given.
Platforms meeting all requirements. These platforms met all priority A requirements, and will therefore be analyzed in chapter 4. The following platforms belong to this group: Drupal Liferay
Platforms meeting all requirements except the requirements concerning roles and privileges. These platforms met all requirements except 2 requirements concerning roles and privileges. The requirements concerned are “MVCA8: Different user roles must be supported by the MVC platform, including, but not limited to, patient, cardiologist, therapist, nurse, family member, friend.“ and “MVCA11: The platform must allow configuration of sub‐community such that preferences and constraints can be made and stored regarding roles and services.”. Based on the requirements these platforms should not be further investigated, since all priority A requirements are mandatory and must be met as defined in chapter 2. But since the majority of the platforms are in this group, the amount of platforms to be analyzed in the next chapter would be too limited. Excluding these platforms now might exclude a platform that has other ‐greater‐ advantages and should not be excluded. This issue is further discussed in section 3.6.11.
The following platforms belong to this group: Elgg Dolphin Mahara WordPress GateIn
Platforms not meeting one or more requirements besides the requirements concerning roles and privileges. These platforms did not meet some priority A requirements besides MVCA8 and MVCA11 and are considered unsuitable and will thus not be analyzed in chapter 4. There are 7 platforms that are more suitable according to the requirements and the impact of the exclusion of these platforms is acceptable. The following platforms belong to this group: Anahita Oxwall
Another aspect to be discussed is the fact that MVC12 and MVC13 are not answered for any of the platforms. No approach could be found to objectively answer these requirements, and they are therefore excluded from the evaluation. This issue is further discussed in the next section.
3.5.11 Discussion This section discusses the two issues concerning the evaluation of the priority A requirements in the previous section. The first issue to be discussed was mentioned in the previous section concerning roles and privileges. The second issue to be discussed is about the requirements concerning security.
46 of 95
Roles and privileges The previous section mentioned 5 platforms that met all requirements except 1 or 2 requirements concerning roles and privileges, MVCA8 and MVCA11. If the requirements definition from section 2.3 would be taken as given, these platforms should be excluded, since these requirements were defined as requirements the platform must meet. These are several reasons that led to the decision to include these platforms nonetheless. The goal of this research is to find the most suitable base platform. To find the most suitable platform, some requirements were introduced. To be able to objectively exclude platforms from the analysis from chapter 4, the decision was made to require that all priority A requirements must be met. However, it is possible a platform does not meet one of the priority A requirements, but scores significantly better on the other requirements. This platform would then be more suitable, but would still be removed from the analysis. In this case, there are 5 platforms that do not meet one specific (and in the case of Elgg, 2, where the other requirement, MVCA8, is related) requirement, MVCA11. Therefore, it was decided to exclude these 2 requirements from the requirements that eliminate a platform for further investigation. In the analysis in the next chapter, these 2 requirements will still be included in the score. By using this approach, more platforms are still potential candidates, but the platforms not meeting these two requirements do receive a disadvantage in the score of the analysis of chapter 4. If a platform does have other advantages that would make it a more suitable platform, this will also manifest in the score of this analysis.
The following table summarizes for each platform which feature related to roles and privileges is implemented and which feature isn’t. Also for MVCA8 and MVCA11 the corresponding feature is given.
Anahita Elgg Dolphin Mahara Oxwall Drupal WordPress Liferay GateIn Yes, Yes, Admin, Multiple roles Yes Admin Yes staff and Yes Yes Yes Yes Yes
and user user Via insertion Custom roles MVCA8 No No Yes into the Yes Yes Yes Yes Yes database Yes, Yes, user Roles per sub Yes, user Member, No No and No Yes Yes Yes community and admin Mod and admin admin Custom roles Via insertion Yes, with per sub No No No into the No OG_user_roles No Yes Yes community database extension Privileges per Yes, Yes, with role per sub No No some No No OG_user_roles No Yes Yes community privileges extension Custom Yes, with privileges per No No No No No nodeaccess Yes Yes Yes role extension It is possible Yes, with Custom to restrict nodeaccess privileges per MVCA11 No No No access to No and No Yes No role per sub pages to OG_user_roles community groups/users extensions Table 22: Platform roles evaluation
Security In the set of requirements, two requirement concerning security are listed: “MVCA12: The platform must be secure.” and “MVCA13: Any security leaks that are published must be fixed fast.”. Security is an important issue, but for several reasons, it was impossible to give an objective score to each platform. These requirements were therefore excluded from the round 2 evaluation, and will not be analyzed in
47 of 95 the next chapter. In this section, two possible approaches to give an objective score are given, and a discussion is done why these approaches cannot be used.
Approach 1: count number of bugs The most straightforward approach to determine if a platform is safe is to count the number of bugs reported. Most security issues come from unresolved bugs in the code. Especially when a bug is reported in public and therefore known to a bug abuser, but not yet fixed, the risk of that being exploited is great. Therefore, the number of reported and unresolved bugs could be used to determine the number of security issues, and thus the security of the platform.
Elgg, Mahara, Drupal, WordPress, Liferay and GateIn have a bug tracker. The reported bugs from the bug tracker could be counted to get a result. The table on the next page shows the number of open and closed issues for each platform, both for the critical, major and the less important bugs (minor and trivial). A bug is considered open when it is unresolved, not yet fixed or not yet closed otherwise.
Anahita Elgg Dolphin Mahara Oxwall Drupal WordPress Liferay GateIn [47] [48] [49] [50] [51] [52] [53] [54] Number of major bugs 863 330 1050 1661 3571 Number of open major bugs 73 36 300 143 379 Number of closed major bugs 790 294 750 1518 3192 Number of critical bugs 193 22 3850 386 896 Number of open critical bugs 9 2 98 18 52 Number of closed critical bugs 184 20 3752 368 844 Table 23: Platform number of bug reports
Anahita, Dolphin and Oxwall did not have a bug tracker available. We could not get the GateIn bug tracker to accept custom queries, so it was impossible to determine the number of open and closed bugs.
There are several reasons why this table cannot be accurately used to determine how secure a platform is: 1. There is no automated functionality to verify if a bug is exploitable or concerning security at all. Analyzing all bug reports for all platforms would require too much work. 2. Some platforms are more extensive than others, and will therefore have more bug reports. 3. Some platforms are more popular than others, and will therefore be used more often, and bugs will be reported more often. 4. The time between the first bug report and now might differ per platform; therefore some platforms will have more bugs because they are older. This problem could be solved by only taking the bug reports after a certain date which is the same for all platforms. This date has to be chosen such that every platform is already using the bug reporting system at this date.
These 4 reasons lead to the conclusion that it is impossible to create an objective result based on the results of table 23.
Approach 2: research the effort put into security Another approach is to research how much effort each platform puts into security. But once again, due to the difference in scope and popularity, the results will be hard to compare. Reason 2 and 3 from the previous paragraph also apply here, if a platform is more poplar and more people use it, hackers have more potential gain from hacking these platforms. Also, if a platform is more extensive, the chance of finding a potential exploit is larger. Therefore, a large popular CMS like Drupal or WordPress is forced to
48 of 95 put more effort into security than a less popular platform like Elgg or Mahara. How much more effort these platforms should put into security is hard to give an objective statement about. All of the 9 platforms put at least some effort into security.
To be able to give an objective statement about the requirement, an extensive research would have to be done which considers all the aspects mentioned earlier in this section. The work required for this research would be disproportional to its importance; it influences only two requirements. Therefore, doing a thorough research on the security of the platforms is considered outside the scope of this research. Since an approach to get an objective verdict about the security of a platform could not be found, the requirements concerning security, MVCA12 and MVCA13 have been excluded from the evaluation in section 3.6. Nor will these 2 requirements be taken into account in chapter 4, despite the fact these two requirements are priority A requirements. 3.6 Conclusion This chapter started by describing the approach used to find and evaluate potential base platforms. Three directions to look for potential platforms were defined, followed by search terms used to find these platforms and resources mentioning these platforms. The resulting primary and secondary sources were listed, from which a list of potential base platforms was composed. Next, a 2 round evaluation of the found platforms was done to reduce the list of platforms to be analyzed in the next chapter. In the first round, 30 platforms were evaluated using 5 requirements. 21 of the 30 platforms were eliminated for further investigation in the next round. In the second round, the 9 remaining platforms were evaluated using all priority A requirements. From these 9 possible platforms, 2 platforms initially passed this second round of the evaluation, and another 5 platforms passed the evaluation after some consideration. These 7 platforms will be analyzed using all requirements in the next chapter: Elgg Dolphin Mahara Drupal WordPress GateIn Liferay
Figure 16: Priority A requirements evaluation summary
49 of 95
4 Platform analysis
4.1 Introduction The previous chapter composed a list of potential base platforms, and by using the priority A requirements from chapter 2, this list was reduced to 7 platforms. This chapter attempts to reduce the list of potential platforms to 1 platform, which would be the most suitable platform to be used as a base platform.
The chapter starts by describing the approach to find this most suitable platform using a Multi Criteria Analysis (MCA) [55]. Section 4.2 gives the motivation to use a MCA, as well as the approach used for this MCA. Section 4.3 executes this approach, and gives the results of this analysis. This analysis will give one or more suitable platforms. A MCA only gives an indication and not a final result, so the results have to be verified. This verification is done, and the results are given in section 4.4. Section 4.5 gives the conclusion of this verification, and thereby the conclusion of chapter 4. 4.2 Approach Chapter 2 composed a set of requirements and grouped these requirements into 5 groups, priorities A‐ E. From these 5 groups, priority D and E are not relevant in the analysis of the base platforms, either because they are specific for a MVC for telemedicine and not relevant for a base platform or are obsolete. The requirements of remaining three groups, priorities A,B and C will be used in the analysis of the platforms done in this chapter using a Multi Criteria Analysis. A Multi Criteria Analysis can be used to solve problems involving multiple criteria; in the case of this research, each requirement is a criterion. Solving is in this case interpreted as finding the best candidate, or best platform. A MCA can use multiple methods to get an objective and verifiable result. The goal of this MCA is to give each platform a score, from which a conclusion concerning the most suitable platform(s) can be drawn.
Grading First, for each platform, each requirement is given a grade on a three point scale depending on how well that requirement is met. If a requirement is completely met, it receives a grade of 2. If a requirement is not met, it receives a grade of 0. There are three occasions for a requirement to receive a grade of 1.First; if a requirement is partially met it will receive a grade of 1. Next, if a requirement will most likely be met in the future (when there is work is progress) it will also receive a grade of 1. Finally, if a requirement is met now but is expected not to be met in the future (functionality supporting the requirement no longer maintained) it will also receive a grade of 1. These grades will be used in the comparison methods of the MCA.
Dominance analysis A logical first method would be to do a dominance analysis. The goal of a dominance analysis is to find candidates –in this case platforms‐ that perform equal or better on all criteria –in this case requirements‐. If platform A would score at least equal on all requirements compared to platform B, and has at least 1 requirement where it scores higher than platform B, the logical conclusion is to exclude platform B. Platform B has no advantage over platform A and Platform A would dominate platform B. This is a straightforward way to exclude platforms to reduce the platforms to be analyzed. This approach however has some drawbacks. The main drawback is that a dominance analysis might exclude platforms that should not be excluded because the difference is small. If platform A would be the most suitable platform, and a platform B would score equal to platform A on all requirements except for one, then the dominance analysis would exclude platform B from the conclusion of the MCA, while the
50 of 95 difference between these platforms is so small they are still both potential base platforms. The requirements are not the only factors that determine if a platform is most suitable, they provide a good indication and are verifiable, but there are other factors, for example the use cases investigated in chapter 5. The goal of the MCA is to find the most suitable platform, or if the difference between multiple platforms is too small, find the most suitable platforms. The case study from chapter 5 would then give the final conclusion which platform is most suitable. So if only a dominance analysis is done, the conclusion of the MCA would be different from the expected conclusion drawn. Nevertheless, a dominance analysis is a powerful method, and will still be done, since its results are independent of any weights used by the methods mentioned later, which might not be reliable. The results of this analysis however will not be used to exclude platforms, but as a tool to help with the verification of the conclusion achieved by using other methods.
Linear additive method The goal of the MCA is to give one or more scores to each platform, and use these scores to draw a conclusion about the most suitable platform. To acquire these scores, a calculation must be done based on the grades given to the requirements. A simple summation of the grades would be the most straightforward. However, not all requirements are equally important and to take this difference into account, each requirement, or group of requirements is given a weight, and this weight is multiplied by the score. In a MCA, this is called a linear additive model. The comparison method used in this research is a linear additive model on each priority group of requirements. In this case each priority group, priority A, B and C is given a certain weight and the score is calculated. The resulting single score can be used to objectively compare the platforms.
Based on these scores the most suitable platform(s) to be used as a base platform are selected according to the MCA. This conclusion however only gives an indication which platform(s) is/are most suitable, different methods and weights can give different outcomes and the conclusion of the MCA must therefore be verified. This verification is done by doing an evaluation of certain requirements; the requirements where the most suitable platform(s) score lower than every other platform. If this evaluation does not raise any objections to why this/these platforms should not be the most suitable base platforms, the conclusion of the analysis is that this/these platforms are indeed the most suitable platform(s) to be used as a base platform for the MVC for telemedicine. Another aspect that will be verified is the impact of the weights and 3 point grading scale used.
Figure 17: MCA approach
51 of 95
4.3 Multi Criteria Analysis This section does the Multi Criteria Analysis by following the approach mentioned in the previous section. First, each requirement is given a score depending on how well a requirement is met. A complete list of scores can be found in appendix D. Section 4.3.1 gives the results of method used for this MCA, the priority based linear additive method.
4.3.1 Priority based linear additive multi criteria analysis The method used in this MCA is the linear additive model grouped by the priorities of the requirement. First the summarized scores for each priority for each platform are calculated:
: ∑ , where PlatformX is {Elgg, Dolphin, Mahara, Drupal, WordPress, Liferay, GateIn}, Y = {A,B,C} and m is the number of requirements for priority Y. These scores are given in figure 20. Since Priority A requirements are more important than Priority B requirements, and Priority B requirements are more important than priority C requirements, each priority is given a certain weight multiplication factor. Priority A requirements receive a multiplication factor of 4, priority B requirements 2, and priority C requirements a multiplication factor of 1. This leads to the following abstract formula:
4 ∗ ∑ 2 ∗ ∑ 1 ∗ ∑ .
To calculate the score of each platform the following formula is used:
4 ∗ 2 ∗ 1 ∗
Combining this formula with the formula to calculate the score for each priority leads to the following formula to calculate the score for PlatformX:
4 ∗ 2 ∗
1 ∗
Applying this formula leads to the following scores:
52 of 95
180 160 160 151 140 123 125 128 127 115 120 100 80 60 40 20 0 Elgg Dolphin Mahara Drupal Wordpress Liferay GateIn
Figure 18: Priority based MCA
Several conclusions can be drawn from these scores:
1. Drupal has the highest score, with a score 9 points higher than the 2nd best. 2. Liferay has the second highest score, scoring 9 points lower than the best platform, but 23 points higher than the 3rd best platform, WordPress. 3. Dolphin has the lowest score, 8 points lower than the 2nd lowest, Elgg 4. The remaining 4 platforms have a score that is relatively close to each other, all within a 5 point margin.
4.3.2 MCA conclusion Based on the results of the MCA, a conclusion about the most suitable platform can be drawn. Drupal has the highest score; Liferay was 2nd, with a lower score than Drupal, but also a significantly higher score than the other 5 platforms. Since Drupal and Liferay both scored significantly higher than the other 5 platforms, but have a score that is relatively close to the other, the conclusion is that based on the MCA Drupal and Liferay are the most suitable platforms to be used as a base platform for a MVC for telemedicine. In the next section, this conclusion will be discussed. 4.4 Multi Criteria Analysis discussion This section discusses the conclusion of the MCA, and attempts to invalidate the results of the MCA. If this attempt is not successful, the conclusion of chapter 4 will be the same as the conclusion of the MCA: Drupal and Liferay are the most suitable platforms to be used as a base platform for a MVC for telemedicine. If this invalidation attempt is successful, further investigation will be required. The discussion starts at the method used in the verification, more specifically the effects of the weights used and the 3 point scale grading. After these effects are discussed and the method used is verified, the first verification of the results is done. This is a dominance analysis of Drupal and Liferay over every platform. Earlier, an argument was made why a dominance analysis was unsuitable for as a method in the MCA; it could exclude platforms that were only slightly worse than another platform. However, at this point, it has already been determined that the difference between the Drupal & Liferay and the other platforms is significant. If Drupal or Liferay dominates another platform, it means that there is no
53 of 95 advantage to use that other platform based on the dominance analysis and since the difference is significant based on the linear additive analysis, Drupal or Liferay will in all cases be more suitable than that platform. The second verification is a more thorough per requirement analysis on all requirements where Drupal or Liferay is dominated by another platform. If these dominances are considered to not be a crucial issue, in other words, if it is no problem that Drupal or Liferay gets dominated these requirements, then the result of the MCA is still valid. If Drupal or Liferay is dominated and the dominance is crucial, the conclusion that Drupal or Liferay is most suitable must be reconsidered.
If the method verification shows the method is correct, and the result verification does not invalidate the result, then the conclusion of the MCA holds.
Method verification This section discusses two elements of the method used in the MCA. The first element discussed is the 3 point grading system used to assign scores to requirements, which might be too limited. The second element discussed is the weights used for the priorities in the linear additive methods. Since no in depth research was done to compose these weights, an analysis on the impact of the relative difference between these weights in the MCA is done to determine the accuracy of the total sore.
3point scaling The 3 point scaling method might be too limited to get an accurate result. However, as described in chapter 2, for 13 of the 31 requirements a 2 point scale would already be sufficient, since they can only be completely met or not met at all, not partially met. For most of the other requirements ‐the requirements that can be partially met‐ an accurate 5, 10 or 100 point scaling is hard to define due to the lack of quantitative results. Therefore, while it might not give the most accurate result, the 3 point scale is likely to be the most suitable approach.
Different weights for the priority based linear MCA This section investigates the effect of the different weights used by looking at the scores of each individual priority. The following graph gives the scores of the platforms on each priority using the following formula:
:
These scores were also used for the weighed total score in section 4.3.1.
54 of 95
35 31 30 29 26 26 25 25 Elgg 25 24 Dolphin 20 17 Mahara 16 Drupal 15 12 12 11 10 Wordpress 9 10 Liferay
5 3 3 GateIn 2 1 1 1 0 0 Priority APriority BPriority C
Figure 19: Platform score per priority
From this chart, several conclusions can be drawn 1. For each priority, Drupal and Liferay score higher than all other platforms, with the exception of Drupal versus GateIn at priority C. This means, no matter what weights will be used; Drupal and Liferay will always score higher than the other platforms, except when priority C will receive a high weight. For GateIn to score higher than Drupal, the priority C requirement weight would have to be at least (31‐26)/(3‐2) = 5 times as high as the priority A requirements. Since priority A requirements are more important than priority C requirements, it is illogical for this to happen. 2. For priority A and B, Drupal scores higher than Liferay. This means, no matter what weights will be used, Drupal will always score higher than Liferay unless priority C requirements are given a higher weight than A or B, which would once again be illogical. 3. The difference between Liferay and the other platforms on Priority A requirement is ((29/26)‐1) *100% = 11% and on Priority B requirements ((16/12)‐1)*100% = 33%. These differences are significant enough to not have another platform have a score close to Liferay independent of the weights used. For Drupal, these differences are more significant with respectively 19% and 41%.
From (1) the conclusion is drawn that no platform can ever perform better than Drupal and Liferay based on these results. In fact, from (3) the conclusion can be drawn that Drupal and Liferay always score significantly better than the other platforms assuming priority B requirements receive a higher weight then priority C. So Drupal and Liferay will always be the most suitable platforms according to the priority based linear MCA, independent of the weights used for the priorities. The choice was made that weights could only be given to priorities, not on individual requirements. If weights were given to individual requirements, the outcome of the MCA could be different, especially when heavy weights are given to requirements where Drupal and Liferay have a low score. To remove this uncertainty, an analysis of these requirements is addressed in the next two sections.
Dominance analysis verification As mentioned in the approach, first a dominance analysis will be done. If the results of this analysis are that either Drupal or Liferay dominates another platform, this would strengthen the conclusion that Drupal and Liferay are indeed the most suitable platforms, since they would score equal or better than
55 of 95 that platform on every requirement. For each row on the following table, it shows the percentage of requirements where that platform scores equal or higher (dominates) than the platform at the column:
Average Elgg Dolphin Mahara Drupal Wordpress Liferay GateIn 1 Elgg 80% 88% 82% 70% 88% 70% 82% 2 Dolphin 73% 79% 82% 64% 76% 64% 76% 3 Mahara 81% 88% 91% 67% 82% 76% 85% 4 Drupal 96% 97% 97% 97% 100% 94% 94% 5 Wordpress 78% 85% 85% 79% 70% 100% 70% 79% 6 Liferay 94% 91% 97% 100% 88% 94% 100% 97% 7 GateIn 82% 85% 88% 91% 70% 82% 76% 100% Table 24: Dominance analysis
Several conclusions can be drawn from the table: 1. From the average column of rows 4 and 6 can be concluded that no platform dominates all other platforms. 2. From the average column of rows 4 and 6 can be concluded that Drupal and Liferay both have a high domination compared to the other platforms, but have a percentage that is close to the other. 3. From the WordPress column of row 4 can be concluded that WordPress is dominated by Drupal. 4. From the Mahara column of row 6 can be concluded that Mahara is dominated by Liferay.
Based on the dominance analysis several conclusions can be made. From (3) it can be concluded that WordPress is no longer a potential candidate, since it is dominated by Drupal, and had a lower score in the linear additive analysis. The same conclusion can be drawn for Mahara, since it is dominated by Liferay (4). From (1) the conclusion can be made that further investigation is required. Another conclusion can be drawn from (2): Since the dominance of Drupal and Liferay is high, it is not much work to further investigate the requirements where these platforms are dominated by another platform. This verification will be done next.
The next table shows a more detailed version the dominance analysis for Drupal and Liferay. Each entry has several possible results; if a platform dominates the other platform the result is dominates. If there are one or two requirements on which is platform is not dominated then those requirements are given. This highlights the importance of these requirements. If a platform does not dominate another platform on more than two requirements, the result is given as ‘*’.
Elgg Dolphin Mahara Drupal WordPress Liferay GateIn Drupal MVCC1 MVCC5 MVCB8 Dominates MVCB8, MVCB8, MVCC2 MVCC2 Liferay * MVCC5 Dominates * MVCA5, MVCA18 MVCB9 Table 25: Drupal and Liferay dominance analysis
Several conclusions can be drawn from table 25:
56 of 95
1. The only requirement that prevents dolphin from being dominated is MVCC5, the support to build mobile applications. 2. MVCC1, the built in translation service is most important requirement that prevents Elgg to be dominated 3. MVCB8 and MVCC2, the Dutch UI and Secure storage are the most important requirements that prevent Drupal from dominating other platforms. 4. MVCB9 and MVCA18, the number of available free extensions and the API documentation are the most important requirements that prevent Liferay from dominating other platforms.
In the next verification these requirements will be more thoroughly analyzed. If the dominance of another platform over Drupal or Liferay is considered not to be an issue, the conclusion of the MCA will not change.
Per requirement verification The previous section recommends 6 requirements for a more thorough analysis to verify if the dominance of another platform over Drupal or Liferay was relevant enough to change the conclusion of the MCA. This list of 6 requirements is extended by all requirements where either Drupal is dominated by Liferay or Liferay is dominated by Drupal. As can be seen in the table in Appendix D, for Liferay these requirements are MVCA5 and MVCB10; Drupal has no additional requirements. Combining these two lists gives 8 requirements that require a more thorough analysis: MVCA5, MVCA18, MVCB8, MVCB9, MVCB10, MVCC1, MVCC2 and MVCC5. The following table gives the result of this analysis:
Requirement Analysis MVCA5: Whenever required, for Drupal offers an extension which allows configuration of https per page. Dolphin requires the developer to instance based on an in‐depth add a piece of code at a page to allow https for that page. Elgg and Mahara only support https for a privacy and security analysis, predefined set of pages. Liferay suggest using virtual apache servers for https support. information between endsystems Setting up a virtual apache server takes some time initially, but after it has been set up, adding a page to be (mobile devices and desktops) is exchanged via https can be done by adding 2 lines of code to the configuration page. The lack of https exchanged in a security support is not enough to choose Drupal or WordPress over Liferay. enhanced application protocol (such as https).
MVCA18: The platform API must Elgg and Drupal have a well documented API available. Liferay does have an API that shows a list of be well documented. classes/functions available, but no documentation is available on what these classes/functions do and how they should be called. Mahara has some examples available. GateIn has some reference guides available. To our knowledge, Dolphin does not have an API available. The lack of a well documented API for Liferay could become an issue when developing new extensions. However, the class and function names are clear, and once the patterns used are clear to the developer, the lack of a well documented API becomes less of an issue. The lack of a well documented API is not enough to choose Elgg or Drupal over Liferay. MVCB8: The platform should Liferay has a fully translated Dutch UI. Elgg, Drupal, GateIn and Mahara have a partially translated Dutch have an UI in the Dutch UI. Dolphin also has a Dutch UI available, but it is not free. language. If required, the missing parts of the Dutch translation can be added by the developer since all platforms support multiple languages. This would require some work, but the amount of work is not enough to choose Liferay over Drupal. MVCB9: The extensions useful to Drupal offers thousands extensions, most of them free. Elgg offers up to 1000 free extensions. Mahara and this project should be free Liferay have some extensions available. To our knowledge, GateIn does not have extensions readily available. Most of the extensions of Dolphin are not free. Having thousands of extensions available is a clear advantage for any platform. However it is not crucial for the platform to be used. Furthermore, Liferay is already an extensive platform without any extensions installed. The lack of extensions is not enough to choose Drupal or Elgg over Liferay. MVCB10: It should not be too Since Elgg uses built‐in functions to process and display information, its learning curve is steep. Liferay and complicated to build our own GateIn, being J2EE applications will thus have a steep learning curve if the developer has no experience extensions. with J2EE programming. Dolphin offers only 1 example on how to develop extensions. Drupal however does not have any of the disadvantages listed above; its learning curve is not as steep as Elgg, it is written in PHP and has a wide range of examples available. Since the steeper learning curve will become less of a problem the longer a developer is working with the
57 of 95
code, this problem is not insurmountable, and the more complicated extension building is not enough to choose Drupal over Liferay. MVCC1: There is the need for a Only Elgg dominates the other platforms on this requirement, and even Elgg does not offer a translation translation service. Further service at this moment, the translation service is still in development. Furthermore, this is not a very decisions are needed so as to important requirement (priority C), so the lack of a translation service is not enough to choose Elgg over determine if this can be done off‐ Drupal or Liferay. line or needs to be online (near real‐time), whether it must be human translation by an authorized translator etc. MVCC2: Whenever required None of the platforms offer functionality to store data securely, in other words encrypted, in a database (again, based on an in‐depth transparent to the developer storing this data. Liferay and GateIn however can use hibernate, and privacy and security analysis), hibernate offers transparent encryption of stored data. Using an xml configuration file, the algorithm and health related data of patients password used for encryption can be defined. This configuration also defines the fields of each table that should stored in a secure manner require encryption. in the MVC database. When required an external secure data storage, or custom made functionality to encrypt data can be used, so the lack of secure storage is not enough to choose Liferay or GateIn over Drupal. MVCC5: The platform should Only Dolphin scores higher than the other platforms on this requirement, and even for Dolphin this offer support to build mobile extension is not free. So it is unlikely this feature will be used. Furthermore, this is not a very important applications. requirement (priority C), so the improved support to build mobile applications is not enough to choose Dolphin over Drupal or Liferay. Table 26: Per requirement dominance analysis
For none of the requirements an argument was given why the domination of Platform X over Drupal or Liferay was sufficient to choose Platform X over Drupal or Liferay and thereby change the conclusion of the MCA. Therefore, the conclusion of the MCA, and thus the conclusion of this chapter is that either Drupal or Liferay is the most suitable platform. 4.5 Conclusion This chapter did a MCA to find the most suitable platform. Section 4.2 gave the approach used for the MCA as given. This approach was carried out and section 4.3 did a linear additive analysis to give each platform a score. Drupal had the highest score, followed by Liferay. The conclusion was therefore that either Drupal or Liferay would be the most suitable platform, but further research was required to verify this conclusion. Section 4.4 verified this conclusion by attempting to invalidate this conclusion of section 4.3. This attempt was unsuccessful, so the conclusion of this chapter is that either Drupal or Liferay is the most suitable platform to be used as a base platform, and further investigation is required to find the one most suitable platform to be used as a base platform. The next chapter will do this investigation with a case study.
Priority A Quick evaluation Analysis Case study Evaluation 30 platforms 7 platforms 2 platforms 9 platforms
Eliminated by not meeting G1: 7 Eliminated by not meeting G2: 5 Eliminated by not Eliminated by Eliminated by not meeting G3: 0 meeting Priority A having a lower Eliminated by not meeting G4: 7 requirements: 2 score: 5 Eliminated by not meeting G5: 2 Figure 20: Platform analysis summary
58 of 95
5 Case study
5.1 Introduction The previous 2 chapters investigated the most suitable base platform for the MVC for telemedicine. This investigation consisted of relatively shallow requirements analysis with the goal to find the most suitable platform; the goal was not to investigate how suitable this most suitable base platform would be to be used to build a MVC for telemedicine. The results of the requirements analysis could ‐to some extend‐ be used to draw conclusions about how suitable a platform would be; however a more in‐depth analysis of the platforms must be conducted to come to a final conclusion. The platforms were only investigated on how they could be used as a base platform for a MVC for telemedicine in theory without making a practical application. The analysis of this chapter will test how suitable the base platforms found are in practice. Therefore, the chapter develops extensions to the base platform that are similar to MVC for telemedicine extensions and analyzes the required work and results. This analysis was not done for all platforms found in chapter 3 to reduce the work required. The creation of these extensions also serves another purpose. The conclusion of the analysis from chapter 4 was that there was no single most suitable platform; Drupal and Liferay both scored almost equal in the analysis. To answer the question which platform is most suitable, another test must be composed, and the use cases of this chapter can be used to answer this question. The in‐depth analysis of this chapter now has two goals: To answer the question “which problems arise when using these platforms to build extensions with telemedicine functionality on” and to answer “which platform is the most suitable base platform, Drupal or Liferay?”.
This practical in‐depth analysis is done by first defining a typical scenario for an extension for a MVC for telemedicine. From this scenario, several aspects will be taken. Key elements of these aspects will be used to derive several use cases which will be implemented for both Drupal and Liferay. Section 5.2 describes the scenario, the aspects, their key elements, a list of use cases derived from these key elements, and why these uses cases were chosen. Sections 5.3 and 5.4 implement these use cases for respectively Drupal and Liferay the results of the case study are given. Section 5.5 gives the conclusion of these analyses. 5.2 Case study description This section introduces the use cases to be used for the case study. It starts by describing a real‐life scenario for an extension for a MVC for telemedicine. This scenario is based on the scenario used by C. Dulawan and the priority D requirements found in chapter 2. The extension would be deployed on the base platform, and could therefore be used to test how suitable the base platform would be. From this scenario, several key aspects will be taken, and from these aspects use cases will be derived. Not the whole scenario will be implemented, only the relevant aspects derived from this scenario. By not implementing the whole scenario, the work required for the implementation is reduced, while the results are still relevant. Furthermore, by dividing the scenario into multiple smaller use cases, it is easier to highlight the relevant issues.
5.2.1 Scenario The following scenario is considered a typical scenario for a MVC for telemedicine: “A patient is recovering from an illness which requires him to do daily exercises. This patient has problems motivating to do these daily exercises, so he joins a Virtual Community to receive support. This support is given in three forms: emotional support, appraisal support and instrumental support. The
59 of 95 emotional support is given from peers with the same illness by sharing experiences and giving positive feedback. The appraisal support is given by a physiotherapist who analyzes the results of the daily exercises and gives constructive feedback based on these results. The instrumental support is given by a BAN that tracks daily movements using a pedometer and GPS. The data collected by the BAN is sent to an external server once per day, where it is processed and stored. The base platform collects this processed data once per day. This data about daily exercise is shared among the users of a group. Only the physiotherapist can see a detailed overview of all the users of a group, each normal user can see a detailed overview of its own information and a summary of the exercises done by his peers. The physiotherapist can configure which information is displayed at the summary” At this moment the potential base platforms for the MVC for telemedicine do not support this functionality, so the decision was made to develop an extension to this base platform to add this functionality.
From this scenario the following five aspects relevant for the base platform are taken: 1. ‘The decision was made to develop an extension to the base platform to add this functionality’ 2. ‘Each normal user can see a detailed overview of its own information and a summary of the exercises done by his peers.’ 3. ‘Only the physiotherapist can see a detailed overview of all the users of a group,’ 4. ‘The base platform collects this processed data once per day’ 5. ‘The physiotherapist can configure which information is displayed at the summary’
Using these five aspects, a set of use cases will be composed. The remainder this section will describe these use cases. For each of the use cases created a short description of the use case, the goal of this use case, a more detailed motivation of the use case and how this use case will be implemented will be given. Finally, a summary of all the created use cases is given.
5.2.2 Use cases Aspect 1: The decision was made to make an extension to the base platform to add this functionality This section gives the use case derived from the first aspect, “The decision was made to develop an extension to the base platform to add this functionality”. The use cases of this aspect will focus on the creation of a generic extension, but the elements researched will also be relevant for extensions for telemedicine. There is one key element in this aspect that requires more research, “make an extension”. How an extension is created is researched in use case 1: “Create an extension”.
Use case 1: Create an extension
Goal: Determine how to build an extension and to discover any problems when developing new extensions. Motivation: As shown in the scenario in section 5.2.1 the platform will be used to develop extensions. These extensions will be developed by students and PhD’s. Since they will only make extensions in the scope of their research, it is likely the number of extensions they each make will be low. Thus the learning curve to build a new extension should be as low as possible. This use case is designed to test how difficult it is to make a basic extension in terms of lines of code and time required to make this extension. Implementation: Create a simple “hello world” extension. This use case does not test anything beyond displaying unformatted static content.
60 of 95
Aspect 2: Each normal user can see a detailed overview of its own information and a summary of the exercises done by his peers. The key element to be researched from this aspect is “its own information”. To be able to show a user its own information, first the identity of the logged in user has to be determined. This is researched in use case 2: “Underlying platform functionality“.
Use case 2: Underlying platform functionality
Goal: Determine how to use the functions of the underlying base platform concerning the currently logged in user. While determining how to use the base platform functionality for the currently logged in user, also some research into the general base platform functionality will be done. Motivation: Since the platform will be used to build extensions where information about currently logged in user is required to give personalized information, the identity of the currently logged in user needs to be able to be determined. This identity information can then be used to offer user specific information. To do so, the identity of the currently logged in user must be known. This use case is designed to test how much work it is to access the functionality of the underlying platform, in this case to access user information. Implementation: Display the username of the current user.
Aspect 3: Only the physiotherapist can see a detailed overview of all the users of a group, each normal user can only see a summary of the exercises done by his peers This section gives the use cases derived from the third aspect, “Only the physiotherapist can see a detailed overview of all the users of a group, each normal user can only see a summary of the exercises done by his peers“. The first element to be researched is “Only the physiotherapist can see”. This means the platform has to be able to restrict access to certain parts of the platform. This is researched in use case 3: “Access restriction”. The second aspect to be researched is “of all the users of a group”. To be able to show a summary of all the users in a group to these users, first a list of all these users must be available. How this is done is researched in use case4: “Group data”.
Use case 3: Access restriction
Goal: Determine how to restrict access to an extension and its content. Motivation: Within a virtual community, different people can have different roles, for example patients and doctors. As mentioned in the scenario, each role can have different privileges that define what a user is allowed to access. This use case is designed to test the ability to restrict access to the content of an extension. Implementation: Limit view permissions to an extension to a user with role “use_case_viewer”. If during the implementation is becomes clear that creating view permissions are different from other permissions, creating these other permissions will also be investigated.
Use case 4: Group data Goal: Determine how to display data about members of a community. Motivation: As described in the scenario, a possible extension could be one where data about community members is shared to other community members, for example when sharing exercise results. To do so, it must be possible to know which members are in a community. Once this is known,
61 of 95 data of these users can be retrieved and displayed. The implementation of this use case aims to display the usernames and roles of all the users in a community. Once the members are known, the data retrieval is considered trivial to the underlying platform. Implementation: Create an extension that shows the members of the current community, and the roles they have in this community.
Aspect 4: The base platform collects this processed data once per day This section gives the use cases derived from the fourth aspect, “The base platform collects this processed data once per day”. This aspect contains two key elements, “collects this processed data” and “once per day”. The first key element is researched in use case 5: “External data consumption”. This use case investigates how to consume data from an external data source. The second key element, “once per day” is researched in use case 6: “Automated tasks”. This use case investigates how to create automated tasks, such as calling a function to collect data once per day.
Use case 5: External data consumption
Goal: Determine how to consume data from an external source. Motivation: As mentioned in the scenario, one of the uses of a MVC is to collect and display medical data. This data is not necessarily stored on the same server as the MVC – in other words it is stored at a remote resource. This use case is designed to determine how to consume data from a remote resource using web services. Displaying the retrieved data is only relevant to check if the data was indeed retrieved from the remote source. Implementation: Get data from a remote source and display it. In this case, a WSDL/SOAP web service is used that shows the current date and time for a US zip code. This web service was chosen for two reasons: 1) It was publicly available and 2) The data retrieved changes over time, and it can easily be checked if the retrieved data has indeed changed and is up to date. The decision was made to use a SOAP/WSDL web service since requirement MVCB3 prefers SOAP/WSDL over REST.
Use case 6: Automated tasks
Goal: Determine how to perform a task without user interaction on the platform. Motivation: In some cases it is preferred to be able to perform certain tasks without user interaction to trigger them. For example, if processing data takes a relatively long time, or, like in the scenario, the data should only be collected only once per day. This task should be performed before a user requires this data, to decrease loading time and increase usability. Another example is when data is live monitored and triggers set to get this data must be activated without user interaction. Implementation: Create a Cron‐like job which gets data from use case 5 and processes this data. This data processing does not have to be complex to make this use case relevant, and in the processing done is limited to storing the data in a database.
Unimplemented use case: External data production
Goal: Determine if the platform can be used to produce web services. Motivation: Where use case 5 pulls data from an external source and processes it, this use case aims to test if the platform can be used as a web service consumer where data is pushed to. One of the major disadvantages of pulling data for monitoring is the fact that the external data source has to be polled the check if new data is available. Setting this polling interval too short can cause useless overhead when no
62 of 95 new data is available. Setting this polling interval too high can cause triggers to activate too late. With data pushing these disadvantages are nonexistent. Data pushing however requires changes at the external data source – the source has to know when to push data and to where‐ and this is not always possible. Implementation: Create an extension that is a web service consumer, send data to this consumer, store this data, and make another extension to display this data.
When the MVC platform will be used as a web service consumer, in this case the producer of a service where medical data can be posted, this web service does not require close integration with Drupal or Liferay. In most cases, the web service can run independent from Drupal or Liferay. In fact, running the web service independently provides several advantages. It provides better scalability since the web services can be run on a different server. It reduces code complexity due to the loose coupling with the base platform. Therefore, since this use case will not test any capabilities of a base platform, the decision was made not to implement it.
Aspect 5: The physiotherapist can configure what information is displayed at the summary This section gives the use case derived from the final aspect, “The physiotherapist can configure what the information is displayed the summary “. The key element from this aspect is “configure”. To be able to configure which information is shown, a configuration page needs to be created. From this requirement, use case 7: “Configuration page” was derived.
Use case 7: Configuration page
Goal: Determine how to make a configuration page for a developed extension. Motivation: There are several scenarios conceivable where an end user can change some of the settings of the extension, like the zip code from use case 5. To do so, it should be possible to create a configuration page. This use case is designed to figure out how to make this configuration page. Implementation: Make a configuration page where the zip code for the time zone from use case 5 can be changed.
5.2.3 Summary The following table gives a summary of the use cases created. It shows the use case number, along with a short description of the use case and the aspect from which the use case was derived.
Use case Short description Aspect Use case 1 Create an extension Aspect 1 Use case 2 Underlying platform functionality Aspect 2 Use case 3 Access restriction Aspect 3 Use case 4 Group data Aspect 3 Use case 5 External data consumption Aspect 4 Use case 6 Automated tasks Aspect 4 Use case 7 Configuration page Aspect 5 Table 27: Use case summary
63 of 95
This section introduced a typical scenario for a MVC for telemedicine extension. From this scenario, several aspects were taken. The key elements of these aspects were used to create 7 use cases. In the next two sections, these use cases will be implemented. Section 5.3 describes and discusses the results of the implementation of the use cases for Drupal. In section 5.4, the results of the implementation of the use cases in Liferay are given and discussed. 5.3 Drupal case study The previous section gave 7 use cases which will be used to discover problems that might arise when using Drupal or Liferay in practice, as well as to determine which platform is most suitable. This section implements these use cases and gives the results, as well any problems discovered while implementing for the first platform, Drupal. First the development environment used to implement the use cases for Drupal is discussed, followed by a section about the use cases.
5.3.1 Development environment Drupal does not have an IDE specifically designed to develop new code for Drupal, therefore any IDE capable of developing PHP code can be used. For the use cases in this research, the choice was made to use Eclipse with the PHP development tools extension [56], since there was previous positive experience with developing in Eclipse. Extending Drupal is done by making extensions called modules. All that has to be done to make a new Drupal module is to create a folder containing two files, a .info with information about the module, like its name and description, and a .module file with the actual code. The folder containing the files must be uploaded to the server in order to be used.
Figure 21: Drupal module file structure
The following setup was used to implement the use cases for Drupal: Pentium D 2x3Ghz, 2G Ram, Linux Debian 2.6.32‐5‐amd64, Apache 2.2.16, PHP 5.3.3.7, MySQL 5.1.61, Drupal Commons 6.x‐2.4.
5.3.2 Use cases This section implements the use cases described in section 5.2 implemented in Drupal. The work required implementing these use cases, and the results of the implementation are given.
Use case 1: Create an extension This use case gives some basic static information to the user. The goal of this use case is to determine how to make a module and to discover any problems when developing new modules. To show content at a page in Drupal using a module, a predefined function has to be implemented to display this content. This function expects the developer to return an array containing the content to be displayed by this module. The line “Hello world” is added to this array, and the array is returned. The code from the file usecase1.module used to implement use case 1 is shown below. The $block array is used to return the output of this module. The variable $op contains the operation, in this case there are 2 options: ‘list’ and any operation that is not ‘list’ . The code inside the if($op==”list”) is used by Drupal to display the name of a module when displaying the list of available modules for a block. Inside the $block[‘content’] is the actual content of the module.
64 of 95
function usecase1_block($op = 'list', $delta = 0, $edit = array()) { $block = array(); if ($op == "list") { $block[0]["info"] = t('Use Case 1'); }else{ $block['subject'] = 'Use case 1'; $block['content'] = 'Hello world'; } return $block; }
Figure 22: Drupal use case 1 implementation
After the module is uploaded to the server, it needs to be enabled at the module configuration page. Finally, after the module is enabled, it needs to be placed in a block on the website. Each Drupal page is divided into multiple blocks, for example header, sidebar and content. For each page, the content of a block can be specified. A block can contain static information, but also modules. There are 2 ways to add modules to the blocks. At the blocks page, /admin/build/block, modules can be added to blocks that need to be displayed on every page, for example in the menu. Adding a module to a single page can be done by creating a custom context for that page that contains the module, and use this context to add the module to that page. Custom contexts can be used to trigger certain actions on certain conditions. In this case an action is triggered to add the use case 1 module to the sidebar last block when the node type is group. This adds the module to the group pages.
Figure 23: A Simple hello world use case in Drupal
Creating a new module in Drupal was straightforward with the available tutorials. The amount of code required to only display one line is relatively high, 10 lines of code just to echo one line. Adding a module to a single page using custom contexts was relatively complex.
65 of 95
Use case 2: Underlying platform functionality The goal of this use case is determining how to use the functions of the underlying platform concerning the currently logged in user. To achieve this goal, a module will be made which displays the username of the currently logged in user. In this section, the steps required to achieve the goal are given. A global variable containing information about the currently logged in user is available to the developer. One piece of information is the username. The username is displayed in the same way as use case 1. The following piece of code displays the username of the currently logged in user:
function usecase2_block($op = 'list', $delta = 0, $edit = array()) { global $user; $username = $user->name; $block = array(); if ($op == "list") { $block[0]["info"] = t('Use Case 2'); }else{ $block['subject'] = 'Use Case 2'; $blockcontent = 'Hello '.$username; $block['content'] = $blockcontent; } return $block; }
Figure 24: Drupal use case 2 implementation
Implementing this use case was simple for Drupal, the username was available from the global object $user. Drupal has a set of global variables and functions available, ranging from user information to configuration variables, which makes accessing underlying platform functionality simple. Use case 3: Access restriction The goal of this use case is to restrict access to an extension to a certain role. To achieve this goal, only a user with the role “usecase_viewer” is able to see the content of the module “usecase3”. Drupal offers the possibility to create custom permissions, and an API function to check if a user has a role that contains that permission. By calling this function with the required role as a parameter the platform checks if the user has the required role, and if this is the case, access is granted. This allows access restriction to the module. Once the custom permission is created at the administrator panel and the check is added to the code, the next step that needs to be done is to create a role that contains that permission, and assign this role to the user, which can be done from the configuration menu. In this case the permission “view use case” was given, which grants permission to view the module. This permission was given to the role “usecase_viewer”. Finally, the role “usecase_viewer” was given to the user.
Figure 25: Drupal roles
66 of 95
It is not possible to give different permissions per instantiation of the module. It is however possible to create a custom role for a user for a community, and assign permissions for a module to this role. This way, since the role is only relevant for the instantiation of the module, permissions can be given to a user per instantiation of the module, unless of course when there are multiple instances of a module within community. So restricting access to a module is relatively easy, but limited. Use case 4: Group data The goal of this use case is to display the name of the community, the users and their roles for the community the module is used in. After retrieving the group node id, which is a unique identifier for a group, a query can be used to determine the group members. Displaying the group members and their roles is done the same way as use case 1. The code below shows a query to get the usernames from a certain group, and the code required to get the current group id.
$groupid =og_get_group_context()->nid; $query = "SELECT users.name,users.uid FROM {users} users, {og_uid} og WHERE og.nid='%d' AND og.uid=users.uid"; $query_result = db_query($query,$groupid);
Figure 26: Drupal use case 4 implementation, getting group users
After the users from a group are known, the next step is to get the roles for the users for that group. For each user this is done with a query:
$query2 = "SELECT roles.name FROM {role} roles, {og_users_roles} our WHERE our.gid='%d' AND our.uid='%d' AND our.rid=roles.rid"; $query_result2 = db_query($query2,$groupid,$users->uid);
Summary Figure 27: Drupal use case 4 implementation, getting user roles Once the underlying functionality to retrieve the current group was known, implementing this use case was straightforward.
Use case 5: External data consumption The goal of this use case is to consume data from an external source using web services. To achieve this goal, a SOAP client has to be implemented and integrated into a module. This SOAP client gets the local time provided by a web service. The most straightforward to consume web services with Drupal is to use the SOAP client from PHP [57]. This client takes the WSDL file from the web service, and creates a class with the same functions as defined in this WSDL file.
$zipcode = "10001"; $soapclient = @new SoapClient( "http://www.ripedevelopment.com/webservices/LocalTime.asmx?wsdl=0" ,array("cache_wsdl"=>WSDL_CACHE_NONE)); $result = $soapclient->LocalTimeByZipCode( array("ZipCode"=>$zipcode)); $time = $result->LocalTimeByZipCodeResult;
Figure 28: Drupal use case 5 implementation
67 of 95
The syntax of the functions which should be called was not always clear due to bad documentation and code complexity of the web service specification, so implementing this use case proved more challenging than expected. After the correct syntax was determined, the information could be retrieved from the SOAP call and this information was displayed the same way as use case 1. The code used to acquire data from the web service called functions from the PHP API, not from the Drupal API. Therefore, the difficulties that arose while implementing this use case do not give any indication about the development in Drupal.
Use case 6: Automated tasks The goal of this use case is to create an automated task that runs at a fixed time without user interaction. This goal is achieved by creating CRON like functionality, in other words to assign some scheduling functionality to call a predefined job at certain times. To create a CRON like function in Drupal, the modulename_cron hook can be implemented. This function is called every time cron.php is run. Running cron.php is up to the developer, by either using system crontabs, or by using a module that calls cron.php on access. The code shown below retrieves the local time from the web service from use case 4 and stores this time in the database:
function usecase6_cron(){ $zipcode = variable_get("usecase5_greeting", "10001"); $soapclient = @new SoapClient( "http://www.ripedevelopment.com/webservices/LocalTime.asmx?wsdl=0" ,array("cache_wsdl"=>WSDL_CACHE_NONE)); $result = $soapclient->LocalTimeByZipCode( array("ZipCode"=>$zipcode)); $time = $result->LocalTimeByZipCodeResult; $query = "INSERT INTO {hoekie_usecase6}(time,adddate) VALUES('%d',NOW())"; db_query($query,$time); }
Figure 29: Drupal use case 6 implementation
To our current knowledge, there is only 1 function which calls the hook_cron functions on all modules. There is a function to check when the hook_cron was last called. It is up to the module developer to determine if interval between the last function call and this function call was large enough and if any action should be taken Another thing to consider is the following: If – for some reason‐ a Cron job with a very short interval is required, then cron.php must be called at a very short interval. The Cron functions of all the modules will be called often; even when this might not be required since their interval is large, thereby creating significant overhead.
Use case 7: Configuration page The goal of this use case is to store settings for module. To achieve this goal, a configuration page where these settings can be created and stored will be made. In Drupal, there are two places to place a configuration page: As a subpage of the extension or at the configuration menu. The configuration menu allows centralized access to all configuration pages, allowing easier management of the platform. However, it does require that the user wanting to access to this administration page to have access to the configuration menu. This configuration page should only be used to store settings relevant to every instance of the module.
68 of 95
To add a configuration page to the configuration menu in Drupal, the modulename_admin() hook has to be implemented to create a configuration page. Also, the modulename_menu() hook has to be implemented to create a menu item linking to the configuration page. This configuration page can be used to set global settings for the module, not user/group specific settings. When storing configurations per instance of the module/per group that uses the module, a subpage of the module should be created. In this case, storing the information set in the configuration page is up to the developer. The creation of this configuration page and creation of a link to this page is up to the developer. The code below shows a simple form with 1 field where you can set a zip code:
function usecase7_admin() { $form = array();
$form['usecase7_greeting'] = array( '#type' => 'textfield', '#title' => t('Zipcode'), '#default_value' => variable_get('usecase7_zipcode','10001'), '#size' => 20, '#maxlength' => 20, '#description' => t("The zipcode"), '#required' => TRUE, );
return system_settings_form($form); }
Figure 30: Drupal use case 7 implementation
Implementing a configuration page is easy in Drupal, there is functionality to retrieve and store the information entered, as well as put restrictions on the values entered.
Summary In this section, the results of the use case evaluation for Drupal were discussed. For each use case, the implementation of that use case was given, along with some code examples. When the implementation was not straightforward, or when limitations of the platform arose, these were also given in the report. A summary of the results can be found in the evaluation per use case in section 5.5.2.
In the next section, the same use cases will be evaluated for Liferay. 5.4 Liferay The previous section implemented the use cases created in section 5.2 using Drupal, and gave the results. This section does the same for Liferay. First it discusses the development environment used to implement the use cases for Liferay, followed by the results of the implementation of the use cases.
5.4.1 Development environment Liferay Inc has created an IDE to develop new functionality for the Liferay portal, Liferay IDE. Liferay IDE is an extension to the Eclipse IDE in the form of a set of Eclipse plug‐ins and offers functionality to create Liferay extensions such as portlets and themes. For every use case in this chapter a new portlet will be created, a more detailed description about creating portlets will be given later. Before a portlet can be created, a project to contain the portlets must be created. When creating a new Liferay project, several files will be generated. Among these files are several XML files containing project settings and properties. Several folders are created where the files generated
69 of 95 when creating a new portlet will be placed. Finally, multiple libraries containing support functionality, such as logging, axis and WSDL are included. When creating a new portlet using the Liferay API, several things happen. Information about the portlet is added to the projects settings XML files. A java class is created where the implementation of the functionality of the portlet should be placed. The file view.jsp is created where the code to display the content of a portlet should be placed.
Figure 31: File structure of a Liferay project with 1 portlet
The Liferay IDE has several ant scripts to deploy the created portlet on the server. Using these scripts requires the server to be able to remotely deploy new portlets, or for the server to run locally.
To deploy the portlets containing the code for the use cases, the following server setup was used: AMD Phenom 2x 3Ghz, 4GB Ram, Windows 7 64 bit, Tomcat 7.0.23, MySQL 5.5.22, Liferay Portal Community Edition 6.1.0 CE
5.4.2 Use cases This section implements the use cases described in section 5.2 in Liferay. It gives the work required implementing these use cases, and the results of the implementation. Use case 1: Create an extension This use case gives some simple static information to the user. The goal of this use case is to determine how to make a portlet and to discover any problems while developing a new portlet. To develop a portlet, the steps from section 5.4.1 describing the creation of a new portlet must be followed. After the portlet is created, the line “Hello World” to the can be added to the file that is displayed when calling the portlet. The file that needs to be called on portal initialization can be changed at the portlets configuration file, portlet.xml. By default when using the Liferay IDE to create portlets this file is view.jsp. After adding the “Hello world” line the portlet is finished and can be deployed to the server. To show this portlet to a user, a new page designated to contain the portlet should be created at the control panel and the deployed portlet must be drag‐and‐dropped to this page.
70 of 95
Figure 32: A simple Liferay portlet
For this use case, the data to be shown was “Hello world” and to achieve this, the line “Hello world” was added to the file view.jsp. Implementing this use case was straightforward.
Use case 2: Underlying platform functionality The goal of this use case is figuring out how to use the functions of the underlying platform concerning the currently logged in user. To achieve this goal, a portlet will be made which displays the username of the currently logged in user. In this section, the steps required to achieve the goal are given. To find the username of the currently logged in user, several steps are required. First, the id of the currently logged in user must be retrieved. This user id can be retrieved from the renderRequest object, which represents the request sent to the portlet to handle a render. This id can then be used to get a User object from the Liferay class providing user information. This User object contains information about the user, including its name. Displaying the name was done the same way as displaying hello world from use case 1. The jsp code to be created by the developer to display the username of the currently logged in user is shown below:
<%@ page import="com.liferay.portal.model.User" %> <%@ page import="com.liferay.portal.service.UserLocalServiceUtil" %>
This is the UseCase2 portlet in View mode. <% Long userid = Long.parseLong(renderRequest.getRemoteUser()); User user = UserLocalServiceUtil.getUserById(userid); String username = user.getFullName(); %> Hello, <%= username %>
Figure 33: Liferay use case 1 implementation, view.jsp
Implementing this use case proved more challenging than expected. Using the renderRequest to get the user id was not straightforward, and this solution was only found after doing some research on the Liferay forums. This is a typical issue when developing with Liferay and only using the API, for every class the functions are given, but can be hard to find to correct class. The classes used concerning User and
71 of 95
UserLocalServiceUtil follow a fixed pattern, which should be easy to understand for someone with experience in programming with J2EE, remote calls and persistence.
Use case 3: Access restriction The goal of this use case is to restrict access to an extension to a certain role. To achieve this goal, only a user with the role “usecase_viewer” is able to see the content of the portlet “usecase3”. In Liferay, restrictions can be put on a portlet from the portal, no additional coding is required. Therefore, for this use case, the portlet created in use case 2 will be re‐used. Liferay offers multiple approaches to assign permissions to roles, and roles to users. For more information about users and roles in Liferay, see [58].This use case describes how to give permissions to a certain portlet, but giving permissions to ‐for example‐ a certain page can be done the same way. Permissions can be put on portlets on 2 different scopes; for every instance of a portlet on the portal or for every instance of a portlet per community. Some roles cannot be used on certain scopes. In this use case view permissions can be given to a user, this can be done from the portal. Other permissions that can be given from the portal are “Add to page”, “Configuration” and “Permissions”. Custom permissions can also be created for portlets, but these do require code changes in the portlet. User and Organizations are created portal wide at the “Users and Organizations menu item. An organization is a portal wide hierarchical group independent of any created communities, for example portal administrators. Roles are created portal wide at the “Roles” menu item. Permissions given to every instantiation of a portlet are added from the actions ‐> define permissions on the roles pages. Permissions per instantiation of a portlet are given by clicking on the options button on this portlet ‐> configuration. Users can be given regular roles at the roles page by clicking actions ‐> assign users. Users can be given organizational roles at the “Users and organizations” page, actions ‐> assign organization roles. Users can be given site roles at the site memberships page. The most straightforward approach to assign permissions of a certain portlet to a user is to create a new regular role. A regular role is a portal‐scoped role. After the role is created, permissions to view the portlet are given to this role. Finally, the user is assigned this role. The advantage of this approach is its simplicity; In 3 steps, the user has permissions to view every instance of the portlet on every community. This is also the main disadvantage of this approach. Users can have different roles per community, and giving them roles for the whole portal leads to them having roles in certain communities that are not desired. For example, giving a user the regular role “patient” leads to that user having the patient role in every community, even the communities where he might be an informal caregiver. Regular roles should therefore only be used for site wide roles, such as, for example, portal administrator. A second approach is to create a new organization and create an organizational role which has view permissions to the portlet. After the organization is created, a user is added to this organization and assigned an organizational role. Finally, the organization is added to the community. Now the user has view permissions to the portlet through the organization it belongs to. The main advantage of this approach is that the organization can be used again for another community. A possible scenario is a group of doctors and nurses managing several communities with the same goal. The portlets and web pages will be the same, only different patients will be in these communities. Once an organization containing these doctors and nurses is added to the community, no additional steps have to be taken to give permissions to specific users, since they inherit these permissions from the organization. This approach has several disadvantages. It is not possible to give additional roles/permissions to a specific user from a organization in a community, making this an inflexible approach. Another disadvantage is the lack of possibilities to give instance based permissions to organizations.
72 of 95
The third approach is to create a site role which will be given permissions to view the portlet. This role can be assigned to users and user groups per community. Permissions to view a portlet can be given to every instantiation of this portlet or per instantiation. Since this role is given on to a user per community, site roles can be used to give permissions to a portlet per community. The main advantage of this approach is its flexibility; you can give permissions to users per user per portlet or portlet instantiation. The main disadvantage is the overhead when creating a new community, for every community that is created, for each user one or more roles have to be assigned. When giving permissions to portlets per instance, these roles have to be added to each portlet instantiation every time. The 3 different approaches give great flexibility to assigning roles in Liferay. After figuring out the different approaches, their advantages and disadvantages, implementing this use case was easy.
Use case 4: Group data The goal of this use case is to display the name of the community, the users and their roles for the community the portlet is deployed in. To do so, first the community has to be determined. This can be done by getting the themedisplay attribute from the request, and use this object to determine the layout, which contains the community groupid from the current community. The code below shows the required code. ThemeDisplay themeDisplay= (ThemeDisplay) request.getAttribute(com.liferay.portal.kernel.util.WebKeys.THEME_DISPLAY); long portletGroupId= themeDisplay.getLayout().getGroupId();
Figure 34: Liferay use case 4 implementation, getting group id
Using the groupid, the User factory UserLocalServiceUtil can retrieve a list of users of that group.
For each user, its roles in this community can be retrieved from the Role factory. The code shown below is the implementation of the retrieval and display of the users and their roles.
List
<% }
Figure 35: Liferay use case 4 implementation, display users and roles
Retrieving the group id was not straightforward, the approach to first call the themeDisplay to retrieve the layout to get the groupid is not intuitive, and this approach was only discovered after a search on the Liferay forums. Retrieving the group, user and roles on the other hand was straightforward, since it followed the same pattern as retrieving the user object from use case 2.
73 of 95
Use case 5: External data consumption The goal of this use case is to consume data from an external source using web services. To achieve this goal, a SOAP client has to be implemented and integrated into a portlet. This SOAP client gets the local time from a web service. The Eclipse J2EE IDE has built in functionality to convert WSDL files into java classes and functions. These functions can then be used to get data from a remote source. After the java code is generated from the WSDL file, this code can be moved to the correct folder in the portlets code. To use the generated code, the developer has to create the following 3 lines of code.
LocalTimeLocator locator = new LocalTimeLocator(); LocalTimeSoap localtimesoap = locator.getLocalTimeSoap(); return localtimesoap.localTimeByZipCode(zipcode);
Figure 36: Liferay use case 5 implementation, developer code
The complete function is show below, including some auto‐generated catches for thrown exceptions. public String getTime(String zipcode){ LocalTimeLocator locator = new LocalTimeLocator(); try { LocalTimeSoap localtimesoap = locator.getLocalTimeSoap(); return localtimesoap.localTimeByZipCode(zipcode); } catch (ServiceException e) { // TODO Auto-generated catch block e.printStackTrace(); return e.toString(); } catch (RemoteException e) { // TODO Auto-generated catch block e.printStackTrace(); return e.toString(); } }
Figure 37: Liferay use case 5 implementation, complete code
Using the generated code should not be too difficult for a developer familiar with WSDL and SOAP web services; the generated code follows default patterns for web service development. The locator returns a SOAP object, which has all the functions of this object defined in the WSDL. The last line of code calls the –in this case only‐ available function on this SOAP object, localTimeByZipCode, which returns the time for a certain zip code. Since the code is auto‐generated, a developer does not have to be familiar with web services, only the generated java code has to be used to call this web service. Use case 6: Automated tasks The goal of this use case is to create an automated task that runs at a fixed time without user interaction. This goal is achieved by creating a CRON like functionality, in other words to assign some scheduling functionality to call a predefined job at certain times. Creating an automated task is done by creating a Cron‐like job in Liferay. This job consists of 2 steps. The first step is to schedule the job. This can be done by adding a
74 of 95
The code shown below is an example where the com.rmt.UseCase6Sheduler class is called at an interval of 10 minutes. This code is part of the Liferay‐portlet.xml configuration file.
Figure 38: Liferay use case 6 implementation, Liferay‐portlet.xml
As mentioned above, it is easy to create automated jobs in Liferay. Multiple scheduler entries can be defined for each portlet, each running at a certain interval or at fixed times, creating great flexibility.
Use case 7: Configuration page The goal of this use case is to create a page to store settings for portlet. To achieve this goal, a configuration page where these settings can be created and stored will be made. When creating a new portlet, several additional modes besides the “view” mode can be added. In this case the “edit” mode is added. By adding this mode, the portlet knows there will be an edit page and an empty edit page, edit.jsp, will be created. At this page, the developer can create a form to set the configuration. After creating this settings page, the javax.portlet.PortletPreferences, class can be used to store these settings. The developer has the choice to make preferences unique per group or per user and unique per instantiation or not. They can also be set globally. By adding 2 lines to the xml configuration file of the portlet, portlet.xml, the portlet is displayed in the control panel. Once again, the default page view.jsp is shown. It is up to the developer to detect whether the portlet is viewed at the control panel or at the community page, and to change to page accordingly. At the control panel page, the developer can create a configuration page, and use the PortletPreferences class to store preferences relevant to every instance of the portlet.
Summary This section discusses the results of the use case evaluation for Liferay. For each use case, the implementation of that use case was given, along with some code examples. When the implementation was not straightforward, or when limitations of the platform arose, these were also given in the report. The next section gives a summary of the differences and similarities between Drupal and Liferay.
75 of 95
5.5 Summary
5.5.1 Development environments Eclipse IDE was used for both Drupal and Liferay to develop the use cases, so neither one has an advantage over the other based on the IDE alone. Liferay however has a small advantage over Drupal, since the Liferay Eclipse IDE has extensions that make the creation of new code easier. One thing to consider is the fact that Liferay extensions are more extensive than Drupal extensions. A Liferay extension consists of at least 7 files, where Drupal modules only consist of 2 files. However, since these files are automatically generated, this does not make developing a new extension in Liferay harder, nor does it require more work. On the contrary, creating a new extension in Liferay is easier and faster due to these files being generated by the IDE. Another thing to consider with Liferay is that for the use cases, both the IDE and the actual server ran on the same machine. If this is not the case, for example with a dedicated server, direct deployment of new modules becomes more complex. The tomcat server used to run Liferay on does not support remote deployment. If remote deployment is required, another application server, like glassfish [59], that supports remote deployment should be used. The easiest way to directly deploy modules in Drupal is to use windows sharing to share the Drupal modules folder, and directly edit the files.
5.5.2 Evaluation per use case Use case 1: Create an extension Displaying “hello world” in Drupal required several lines of code, while in Liferay it only took 1 line of code to be added by the developer. Adding the use case to a webpage was also easier in Liferay, since it can be dragged‐and‐dropped to a page, compared to the more complex custom context from Drupal. Therefore Liferay performs better at use case 1 Use case 2: Underlying platform functionality Retrieving the username of the currently logged in user was slightly easier in Drupal since all user information was readily available in an array. In Liferay retrieving the user id was not straightforward, and additional functions needed to be called to retrieve the username belonging to this user id. Therefore, Drupal performs better at use case2. Use case 3: Access restriction Both Liferay and Drupal require an equal number of steps to grant view permissions to a user to a developed extension. However, since Liferay has more extensive and flexible roles and permissions, it performs better at use case 3. Use case 4: Group data Determining the current community was not straightforward in Drupal nor Liferay, so neither one perform better than the other. Once the community was retrieved, both in Drupal and Liferay it is easy to determine its members and roles. So Drupal and Liferay perform equally well for use case 4. Use case 5: External data consumption using web services With the help of the Eclipse J2EE IDE, consuming web services in Liferay becomes relatively simple. When consuming web services in Drupal, the PHP web services API was used. Using this API was more complex than using the J2EE IDE; therefore it is easier to consume web services in Liferay than in Drupal.
76 of 95
Use case 6: Automated tasks Creating a new Cron like job in Liferay or Drupal requires roughly the same amount of work, and has the same complexity. Liferay however has a more flexible way to set when a job needs to be run, and does not require any user/developer input to run its CRON jobs, so Liferay performs better in use case 6. Use case 7: Configuration page Liferay can store preferences unique per user, per instantiation or on a global scope. Drupal itself can only store preferences on a global scope; it is up to the developer to be able to store settings on another scope. Being able to store preferences per user or instance creates greater flexibility since settings specific for this user/group can be stored. Therefore Liferay performs better than Drupal for use case 7.
5.5.3 Summary The difference in scope between the enterprise portal Liferay and CMS Drupal manifests itself while implementing the use cases. The use of portlets in Liferay makes integration of developed extensions into the base platform relatively easy, where integrating a developed extension into a page in Drupal is more complicated. The difference between Liferay and Drupal becomes clearest in ‘use case 5 external data consumption using web services’ and ‘use case 6, automated tasks’. A CMS like Drupal is commonly not used to perform these functions, and implementing them was therefore more difficult than in Liferay.
The following table describes which platform performs best for each use case. When both platforms perform equally, both platforms are selected.
Use case Summary Drupal Liferay Use case 1 Create an extension X Use case 2 Underlying platform functionality X Use case 3 Access restriction X Use case 4 Group data X X Use case 5 External data consumption X Use case 6 Automated tasks X Use case 7 Configuration page X Table 28: Case study use case results
77 of 95
5.6 Conclusion This chapter started by describing a real‐life scenario for a MVC for telemedicine. From this scenario, several key aspects were taken from which 7 use cases were acquired. These use cases were implemented for the two remaining potential platforms to be used as a base platform, Drupal and Liferay. The results of this implementation were given in sections 5.3 and 5.4. Since Liferay performed better than Drupal at 5 of the 7 use cases, the conclusion was drawn that Liferay is the most suitable platform to be used as a base platform.
Another goal of this chapter was to find hidden problems and limitations of the platforms. The conclusion of the previous section was that Liferay was to most suitable platform to be used as a base platform. In the remainder of this section the limitations and problems of Liferay are summarized.
The main problem when developing with Liferay is its complexity due to the fact it is so extensive. Sometimes multiple approaches are possible. If the developer is not familiar with Liferay, this can lead to confusion leading to increased development times, since it is not always clear which approach to use. For example, this is the case when using roles/permissions or the user/group class pattern. Another problem is the lack of a good API already mentioned in section 3.6.8. While implementing the use cases, it was often not clear which functions or classes to use. The number of tutorials explaining how to use these classes was also limited. A more thorough analysis of the advantages and disadvantages of Liferay can be found in the discussion of this research in section 6.2.
This concludes the research for the most suitable base platform for a MVC for telemedicine. The next chapter gives the final conclusion and answers to the research questions.
Figure 39: Case study evaluation summary
78 of 95
6 Conclusion, discussion and recommendations
This chapter gives and discusses the results of this research. Section 6.1 first answers the sub questions, followed by the main research question. Section 6.2 discusses the results, followed by the recommendations of this research in section 6.3. 6.1 Conclusion
The goal of this research was “To provide advice about the most suitable existing base platforms which can be extended to develop applications for MVC’s for telemedicine to researchers interested in developing these applications”. From this goal the following main research question was derived: ”Which platform is most suitable to be used as a base platform for a Mobile Virtual Community for telemedicine?”. To answer this question, multiple sub‐questions were composed. In this section, the answers to these sub‐questions and the main question are given.
RQ2: What resources are available to determine these requirements? This research uses two resources to determine its requirements. The first resource is a research done at this university by C. Dulawan in 2007 which explores how MVC concepts can be applied in doing telemedicine. Since this research focuses on MVC’s for telemedicine, the scope and goal are roughly the same, and the requirements from the research done by C. Dulawan could also be used in this research. The second resource is a deliverable for the BraveHealth project. One of the components to be developed in this project is a virtual community, and the requirements of this virtual community will also be used in this research. Both researches employ use cases to determine the requirements.
RQ1&3: How relevant are the requirements mentioned in the researches and what are the resulting requirements of a MVC for telemedicine? The two researches have a total of 50 requirements which could be used for this research. If required these requirements were redefined, split or merged. Another 11 additional requirements are introduced due to the difference in scope between the 2 researches and this research. These requirements can be found in Table 6: Additional requirements. As mentioned in chapter 1, not all requirements are equally important. The requirements are prioritized using a 5 point prioritizing scheme, priorities A‐E, based on the MoSCoW method. The first 3 priorities are requirements the platform respectively must, should or could meet. In this research, the fourth priority consists of requirements a complete MVC for telemedicine must meet, but the base platform won’t have to meet. The final priority consists of requirements that are no longer relevant but are mentioned for completeness. Applying this scheme on the requirements leads to a list of 38 priority A‐D requirements; 18 priority A requirements, 10 priority B requirements, 5 priority C and 5 priority D requirements. (Section 2.6)
RQ4: What are possible directions to look for the base platform? This research explorers several directions for base platforms. The initial direction explored consists of “community builder” platforms, which is the most straightforward approach for building virtual communities. However, the number of platforms found and the platforms themselves were limited, therefore the search was extended. The first additional direction consists of content management systems (CMS). These platforms are often more popular and therefore more extensive than community builder platforms. Often these platforms have extensions with community builder like functionality available, making them a suitable alternative to “community builders”. A second additional direction to
79 of 95 be explored are enterprise portals, which offer interesting features to start a MVC for telemedicine such as good data access control, web service support and single sign on. If a portal also has some community builder functionality, it could be a suitable alternative. This gives three directions to look for possible base platforms: Community builders, CMS with community builder extension platforms and enterprise portals.
RQ5: Which platforms are available as a possible base platform for the MVC for telemedicine? To make the search for platforms as thorough as possible, two types of sources were used to find suitable platforms; primary sources which are possible base platforms, and secondary sources containing a list of possible base platforms, but which are not base platforms themselves. For both types of sources and for each direction a set of search terms was composed. These search terms were entered into Google and the first 50 results were analyzed. The platforms found as primary sources were listed, and the 24 secondary sources were analyzed for potential platforms, which lead to 30 possible platforms to be used as a base platform. (Section 3.3)
RQ6: Which method should be used to evaluate the platforms using the requirements? Some requirements are not easy to verify, which makes evaluating the platforms take considerable effort. To reduce to overall time required for evaluation and analysis an elimination approach was used. This elimination consists of 3 rounds. The first round aims to do a quick elimination of unsuitable platforms. To achieve this, a set of 5 requirements is chosen from the list of the priority A requirements. These requirements have the property that they do not require much effort to verify and are mandatory for a platform to meet. Since a platform must meet all mandatory ‐priority A‐ requirements, the logical approach for the next round is to use these requirements to evaluate the remaining platforms. Based on this evaluation, a list of suitable platforms to be analyzed in the final round is composed. Since all remaining platforms are now suitable as base platforms based on the requirements chosen, another distinction between the platforms needs to be made. In the third and final round this is done by using a Multi criteria analysis (MCA) to give each platform a score. Based on the score, the most suitable platform(s) can be selected. The advantage of using a MCA is that it gives a verifiable result.
RQ7: Which use cases should be used to evaluate the platforms in the case study? To determine the use cases to be used for the case study, first a typical scenario for a MVC for telemedicine was introduced. This scenario was based on the scenario used by C. Dulawan, combined with the priority D requirements from chapter 2. The choice was made not to implement the full scenario; instead, 5 aspects were taken which were relevant to the base platform. By implementing only parts of the scenario, the work required for the implementation, and focus can be put on the relevant aspects. From these 5 aspects, a set of 7 use cases was composed.
RQ9: According to the requirements and case study, which platform is most suitable to be used as a base platform? The first round of the evaluation checked all 30 platforms if they met the set of 5 requirements. Nine platforms met these 5 requirements and went through to the next round. In this round, all platforms not meeting one or more of the mandatory requirements would be eliminated. This would however eliminate 5 platforms based on 2 requirements –concerning roles and privileges‐. These platforms might still be good options; if required these requirements could be met by implementing them afterwards. To avoid eliminating suitable platforms, these 2 requirements were no longer considered mandatory and these 5 platforms could now go through to the next round. Since 2 platforms did meet all priority A requirements, a total of 7 platforms went through to the next round. It is possible to implement other
80 of 95 missing requirements; however the costs will be relatively high to implement several requirements to let one platform go through. In this final round, the MCA was done. The requirements from a certain priority were given a weight factor, which was multiplied by a number defining how well a requirement was met. These results were added for each platform, resulting in a single score. Two platforms –Drupal and Liferay‐ scored significantly higher than the other five. Since a MCA only gives an indication which platform would be best, the results were verified. This verification was done using multiple methods: first the impact of the weights used was analyzed, followed by a dominance analysis and a deeper investigation of the requirements where Drupal and Liferay did not dominate. This verified that Drupal and Liferay were indeed the most suitable platforms and should be used in the case study.
The following diagram shows a summary of the elimination:
Figure 40: Elimination results
A case study consisting of the 7 use cases was conducted to determine which platform is most suitable to be used as a base platform for a MVC for telemedicine, Drupal or Liferay. In this case study, Liferay scored better than Drupal at 5 of the 7 use cases, and therefore the conclusion of this case study is that Liferay is the most suitable platform to be used as a base platform.
RQ8: Which problems arise when developing extensions with telemedicine functionality on this platform? The main problem when developing with Liferay is its complexity due to the fact it is so extensive. Sometimes multiple approaches are possible. If the developer is not familiar with Liferay, this can lead to increased development times, since it is not always clear which approach to use. For example, this is the case with roles/permissions and the user/group class pattern. This usability problem could not be checked in the requirements analysis since it takes significant effort to verify; it only became clear after the use cases were implemented. Another problem is the lack of a good API. While implementing the use cases, it was often not clear which functions or classes to use. The number of tutorials explaining how to use these classes was also limited.
Main RQ: Which platform is most suitable to be used as a base platform for a Mobile Virtual Community for telemedicine? The conclusion from the requirements and case study was that Liferay is that most suitable platform to be used as a base platform. Therefore, using the given requirements and case study, for the platforms found, this research draws the following conclusion:
In the context of this research, the most suitable base platform to be used for a MVC for telemedicine is Liferay.
81 of 95
6.2 Discussion The previous section gave the conclusion of this research: Liferay is the most suitable base platform. This section discusses these results. First, the approach chosen in section 1.3 to extend an existing platform is discussed. This discussion checks if the most suitable platform, Liferay, is more suitable than building one from scratch. If using Liferay is not more suitable than building one from scratch then the advice given will change accordingly. Second, the conclusion of this research is that Liferay is the most suitable platform, however being the most suitable platform however does not imply this platform is suitable to be used as a base platform. How suitable Liferay is a base platform is discussed in this discussion.
Was the decision to use the approach to extend existing MVC software correct? The amount of work required to build a base platform from scratch with the same features as Liferay would be large. Since the scope of the MVC for telemedicine is a small scale research platform, only limited resources are available, building a base platform from scratch an infeasible option. In chapter 1.3, several disadvantages of using an existing platform were mentioned. The first disadvantage was a possible lack of security. Liferay has some reported bugs and leaks, but they are fixed fast. Furthermore, being an enterprise portal, being used in commercial environments, having good security is an important requirement for Liferay, thus possible leaks must be fixed fast, in order for customers to keep using it. Another disadvantage was a possible lack of backwards compatibility. Liferay stays backward compatible within each major version release, which on average stays the major version for 2 years. When changes are made that affect backwards compatibility, a deprecation process is introduced. Since both possible disadvantages are small for Liferay, he following conclusion can be drawn from this section:
The work reduction advantage outweighs the disadvantages, so the approach mentioned in chapter 1.3 to extend an existing platform is indeed the best approach.
During the implementation of the use cases, already some small problems occurred. In these cases the problems could easily be fixed. However, the use cases were simplified versions of real extensions. The fear that if simple use cases would give small problems, large extensions would give larger problems could not be lost. These larger problems might be too complex, or require too much work to solve or work around. Verifying if these problems would really occur would require building one or more real extensions, which is outside the scope of this research. So based on the results of this research, using Liferay as a base platform is most likely the best approach, but not completely certain. Verifying if extending Liferay is indeed absolutely the best choice is outside the scope of this research.
Is Liferay suitable to be used as a base platform? The conclusion of this research is that Liferay is the most suitable platform found to be used as a base platform. Being the most suitable platform however does not imply this platform is suitable to be used as a base platform. In this section, a small discussion is done concerning the suitability of Liferay as a base platform for a MVC for telemedicine. Multiple factors played a role in determining how suitable Liferay is as a base platform. First, the results of the requirements analysis and case study were used to get an objective view on how suitable the platform would be. Next, a list of features of Liferay was composed to determine the advantages of Liferay as a base platform.
The first verification introduced to checks how suitable Liferay is, is done using the fulfillment of the requirements. If Liferay would not meet one or more important requirements, the result could be that it
82 of 95 is not a suitable platform. Liferay completely fulfilled 19 of the 26 priority A and B requirements, the 7 remaining requirements were partially fulfilled. The requirements that were not fulfilled were 4 priority C requirements. From the fact that all priority A and B requirements were at least partially fulfilled, the conclusion can be drawn that Liferay is not unsuitable to be used as a base platform.
The second verification introduced tries to find strengths of Liferay which would make it a suitable platform to be used as a base platform. Liferay offers several features required for a MVC for telemedicine. These features include: Profile management. Liferay offers profiles where information relevant to the site can be stored, edited and viewed such as passwords and roles. These profiles also store user specific information such as address, phone number, etc. Finally, custom fields can be added if required. Community creation and management. Liferay support communities in the form of a set of web pages for a community. These web pages can be used to offer community specific content. Use of portlets to create extensions. The use of portlets gives results integration with newly developed extensions. Drag and drop developed extensions to a webpage. The community specific content can be offered in the form of portlets, which are small pieces of static or dynamic content. These portlets can be dragged onto a page for easy page design. User access control. Liferay has a strong user access control. Users can be put into different groups and organizations. Access can be given to groups and individual users. This access can be used to grant access to communities, web sites within a community and specific portlets on a web site. Different types of access can be granted, such as view, create and edit. Finally, these permissions can be granted on a global scope, or per community. Different user interfaces using themes. Liferay supports different themes to fulfill UI requirements Eclipse IDE for portlet development. Liferay has a custom IDE which can be used to develop and deploy new extensions. This IDE also generates some of the required code, thus the development of these extensions requires less work. Web services support. For most of the commonly used API functions of Liferay, a web service is already available. If the decision is made to create an extension not integrated in Liferay ‐for example a data acquisition service‐ some of the platforms functionality can still be used by using these web services. For example, a user can be authenticated.
These features, combined with the –at least partial‐ fulfillment of all priority A and B requirements make Liferay suitable to be used as a base platform for a MVC for telemedicine. 6.3 Recommendations This section gives several recommendations based on work and results of this research:
No extensive survey was done on the requirements; instead they were taken from papers with a slightly different goal and scope. It is reasonable to assume these requirements are accurate enough, but a survey would provide more accurate and possibly different results. Only free platforms were considered. The results of this research can differ if a budget is available to spend on non free platforms so that a larger set of platforms can be investigated. Different additional methods can be considered to compare different platforms. One of these methods is to compare user experiences. However, due to the difference in platform usage, the user experiences also differ, and it is hard to give an objective and relevant conclusion.
83 of 95
In the first discussion of section 6.2, a conclusion was made that Liferay is most likely the most suitable approach, but some full scale extensions should be developed to verify this. This leads to the following recommendation: Before a final decision to use Liferay as a base platform is made, one or more real full‐scale extensions should be made. If the development of these extensions is not problematic and fulfills the requirements of this extension, the conclusion made is more solid. In section 3.6.11 the decision was made to exclude the requirements concerning security from the evaluation since no approach could be found to give an objective statement. The requirements are however still relevant. To be able to give an objective statement about security, a thorough research has to be conducted. There are several scenarios where Drupal is the most suitable platform as base platform, especially when a PHP platform is preferred. A more detailed report is given in section 4.5. If for some reason Liferay is not suitable to be used as a base platform, Drupal should be considered first as an alternative.
84 of 95
7 Terminology API Application An API is a library that contains a specification of the classes, variables and functions of a Programming software component. Interface Ant “Apache Ant is a Java library and command‐line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other….. Ant supplies a number of built‐in tasks allowing to compile, assemble, test and run Java applications.” [60] Axis An implementation of the SOAP protocol. BAN Body Area Network A network of low power devices on, in or around the human body (but not limited to humans) to serve a variety of applications including medical, consumer electronics / personal entertainment and others. CMS Content Management A software tool, usually web based that allows creating, editing and publishing content. System CVD CardioVascular A disease involving the heart or blood vessels Disease Cron Time based job scheduler originating from Unix‐like operating systems. EP Enterprise portal An enterprise portal provides a single access point to different pages designed to offer personalized information using portlets. GPS Global Position “A navigational system using satellite signals to fix the location of a radio receiver on or System above the earth's surface”. [61] HTTP HypertText Transfer “The Hypertext Transfer Protocol (HTTP) is an application‐level protocol for distributed, Protocol collaborative, hypermedia information systems.” [62]. It is the foundation of communication on the World Wide Web. HTTPS HypertText Transfer Protocol for secure communication on the internet, effectively done by layering HTTP Protocol Secure over SSL/TLS. IDE Integrated A software component used for software development. Usually contains a code editor, Development and components to build and run the code as well as make development of the code Environment easier. J2EE The enterprise edition of the java computing platform containing additional functionality like multi‐tier technologies and web services. JSON JavaScript Object A standard for human readable data interchange, most commonly used in combination Notation with REST. JSP Java Server Pages A technology for dynamic html page generation using Java. MCA Multi Criteria Analysis A method to objectively and verifiable compare different options using multiple criteria. MoSCoW A technique used in software engineering to assign importance to requirements. MVC Mobile Virtual A form of virtual community that can be used from a mobile device from anywhere at Community any time. MySQL An open source relational database management system PHP “PHP is a widely‐used general‐purpose scripting language that is especially suited for Web development and can be embedded into HTML” [63] REST REpresentational A client‐server architecture used to transfer resources. The JSON/REST combination can State Transfer be used for webservice and the HTTP protocol is built using the REST architecture SOAP Simple Object Access A lightweight protocol for exchanging structured information in a decentralized, Protocol distributed environment, achieved by transferring XML files, most commonly using the HTTP protocol. SSO Single Sign On A technology where multiple components can use a signle authority for user identification and verification. UAC User Access Control A technology that limits resource access to users that have privileges to these resources. UI User Interface The system by which users interact with an application, in this case the MVC platform. VC Virtual Community “An online community is ‘a group of people, who come together for a purpose online, and who are governed by norms and policies’” [2] quoted by [3] WSDL Web Services An XML‐based interface description language that is used for describing the functionality Description Language offered by a web service. XML eXtensible Markup A human‐ and machine‐readable markup language most commonly used to transfer Language information between applications.
85 of 95
8 Bibliography
[1] "World Population Prospects, the 2010 Revision," [Online]. Available: http://esa.un.org/wpp/Excel‐ Data/population.htm.
[2] J. Preece, Online Communities: Designing Usability, Supporting Sociability, Chichester: Wiley, 2000.
[3] J. P. Clarisse Sieckenius de Souza, "A framework for analyzing and understanding online communities," Interacting with Computers, vol. 16, no. 3, pp. 579‐610, 2004.
[4] M. P. Buman and P. R. Giacobbi Jr, "Peer Volunteers Improve Long‐term Maintenance of Physical Activity with Older Adults: A Randomized Controlled Trial," J Phys Act Health, no. September (8), pp. 257‐266, 2011.
[5] "Live better, together! | PatientsLikeMe," [Online]. Available: http://www.patientslikeme.com/.
[6] "Health Information, Resources, Tools & News Online ‐ Everydayhealth.com," [Online]. Available: http://www.revolutionhealth.com.
[7] J. House, Work Stress and Social Support., Addison ‐ Wesley, 1981.
[8] W. W. Eckerson, "Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client Server Applications," Open Information Systems, vol. 10, 1995.
[9] "Multitier architecture," [Online]. Available: http://en.wikipedia.org/wiki/Multitier_architecture.
[10] C. Dulawan, B. van Beijnum, H. Hermens and L. Nieuwenhuis, "Analysis and applications of mobile virtual communities for telemedicine".
[11] L. Ellouimi, B. J. van Beijnum and P. Pawar, "Deliverable 1.3.7 – MVC Specification," 2011.
[12] "Consortium for research in automation and telecommunications ‐ Bravehealth," [Online]. Available: http://infocom.uniroma1.it/crat/index.php?option=com_content&task=view&id=32&Itemid=49.
[13] BraveHealth partners, "Deliverable 1.2 ‐ User requirements".
[14] "MoSCoW prioritisation method," [Online]. Available: http://www.coleyconsulting.co.uk/moscow.htm.
[15] "Google," Google, [Online]. Available: http://www.google.com.
[16] "Community Builder ‐ Joomla Social Networking Solution," [Online]. Available:
86 of 95
https://www.joomlapolis.com/community‐builder.
[17] "Elgg," [Online]. Available: http://elgg.org.
[18] "GNU General Public License v2.0," [Online]. Available: http://www.gnu.org/licenses/gpl‐2.0.html.
[19] "The MIT License (MIT)," [Online]. Available: http://www.opensource.org/licenses/mit‐license.php.
[20] "Elgg backwards compatibility," [Online]. Available: http://docs.elgg.org/wiki/Release_Policy.
[21] "Elgg API," [Online]. Available: http://docs.elgg.org/wiki/Main_Page#Introduction_3.
[22] "Dolphin," [Online]. Available: http://www.boonex.com/dolphin.
[23] "Dolphin https support," [Online]. Available: http://www.boonex.com/forums/topic/SSL‐Dolphin‐ .htm.
[24] "Dolphin backwards compatibility," [Online]. Available: http://www.boonex.com/trac/dolphin/milestone/Dolphin%208.0%20%28Sundance%29.
[25] "Wordpress," [Online]. Available: http://wordpress.org.
[26] "Buddypress," [Online]. Available: http://wordpress.org/extend/plugins/buddypress/.
[27] "Wordpress https support," [Online]. Available: http://wordpress.org/extend/plugins/wordpress‐ https/faq/.
[28] "Wordpress themeswitcher," [Online]. Available: http://wordpress.org/extend/plugins/theme‐ switcher/ .
[29] "Wordpress user‐theme," [Online]. Available: http://wordpress.org/extend/plugins/user‐theme/.
[30] "Wordpress backwards compatibility 1," [Online]. Available: http://wpshout.com/backwards‐ compatible‐wordpress‐3‐0‐functions/.
[31] "Wordpress backwards compatibility 2," [Online]. Available: http://wpshout.com/backwards‐ compatible‐wordpress‐3‐0‐functions/.
[32] "Mahara," [Online]. Available: https://mahara.org/.
[33] "Mahara API," [Online]. Available: https://wiki.mahara.org/index.php/Developer_Area.
[34] "Anahita," [Online]. Available: http://www.anahitapolis.com/.
87 of 95
[35] "Drupal ‐ Open Source CMS," [Online]. Available: http://www.drupal.org.
[36] "Drupal Commons Social Business Software," [Online]. Available: http://www.acquia.com/products‐ services/acquia‐commons‐social‐business‐software.
[37] "Drupal https," [Online]. Available: http://drupal.org/https‐information.
[38] "Drupal mobile theme," [Online]. Available: http://drupal.org/node/1008582.
[39] "Drupal user roles," [Online]. Available: http://drupal.org/project/og_user_roles.
[40] "Drupal backwards compatibility," [Online]. Available: http://drupal.org/node/65922.
[41] "Oxwall," [Online]. Available: http://www.oxwall.org.
[42] "Liferay," [Online]. Available: http://www.liferay.com/products/liferay‐portal/overview.
[43] "HTTPS ‐ Wiki ‐ Liferay.com," [Online]. Available: http://www.liferay.com/community/wiki/‐ /wiki/Main/How+to+configure+https+feature.
[44] "Versioning Policy ‐ Wiki ‐ Liferay.com," [Online]. Available: http://www.liferay.com/community/wiki/‐/wiki/Main/Liferay+Versioning+Policy.
[45] "GateIn ‐ JBoss Community," [Online]. Available: https://www.jboss.org/gatein.
[46] "gatein/gatein‐api‐java ‐ GitHub," [Online]. Available: https://github.com/gatein/gatein‐api‐java.
[47] "Elgg Trac," [Online]. Available: http://trac.elgg.org.
[48] "Dolphin bugs," [Online]. Available: http://www.boonex.com/forums/forum/Dolphin‐Bug‐Reports‐ 0.htm.
[49] "Mahara launchpad," [Online]. Available: https://bugs.launchpad.net/mahara/.
[50] "Oxwall bug reports," [Online]. Available: http://www.oxwall.org/forum/5.
[51] "Drupal issues," [Online]. Available: http://drupal.org/project/issues.
[52] "Wordpress trac," [Online]. Available: http://core.trac.wordpress.org/.
[53] "Liferay JIRA," [Online]. Available: http://issues.liferay.com/secure/Dashboard.jspa.
[54] "GateIn JIRA," [Online]. Available: https://issues.jboss.org/browse/.
88 of 95
[55] London, Department for Communities and Local Government:, "Multi‐criteria analysis: a manual," London, 2009.
[56] "Eclipse PDT," [Online]. Available: http://www.eclipse.org/projects/project.php?id=tools.pdt.
[57] "PHP: SoapClient," [Online]. Available: http://php.net/manual/en/class.soapclient.php.
[58] "Using Liferay Portal 6.1 ‐ User Guide," [Online]. Available: http://www.liferay.com/documentation/liferay‐portal/6.1/user‐guide/‐/ai/portal‐architectu‐5.
[59] "GlassFish ‐ Open Source Application Server," [Online]. Available: http://glassfish.java.net/.
[60] "Apache ant," Apache, [Online]. Available: http://ant.apache.org/.
[61] "GPS ‐ Definition," Merriam‐Webster, [Online]. Available: http://www.merriam‐ webster.com/dictionary/gps.
[62] "RFC 2616 ‐ Hypertext Transfer Protocol," IETF, [Online]. Available: http://tools.ietf.org/html/rfc2616.
[63] "PHP: Hypertext Preprocessor," The PHP Group, [Online]. Available: http://php.net/.
89 of 95
9 Appendices
9.1 Appendix A: Primary and secondary sources In this appendix, the primary and secondary sources of section 3.4 are given. The following table gives the names and references to the main page of the primary sources. Name Address Around Me http://www.barnraiser.org/aroundme Anahita http://www.anahitapolis.com Dolphin http://www.boonex.com/dolphin Community Engine http://communityengine.org Drupal http://www.drupal.org Drupal Commons http://www.acquia.com/products‐services/acquia‐commons‐social‐business‐software Dzoic http://www.dzoic.com Elgg http://elgg.org Exo http://www.exoplatform.com/company/en/home GateIn https://www.jboss.org/gatein Hippo CMS http://www.onehippo.com Impress CMS http://www.impresscms.org/index.php Inoshi https://github.com/insoshi/insoshi Jcow http://www.jcow.net Jetspeed 2 http://portals.apache.org/jetspeed‐2 Joomla http://joomla.org LifeRay http://www.liferay.com/products/liferay‐portal/overview Lovdbyless http://lovdbyless.com Mahara https://mahara.org Mugshot No primary source could be found Network X http://www.socialabc.com Newsgator http://www.newsgator.com Oxwall http://www.oxwall.org PhpFox http://www.phpfox.com Phpibazi http://sourceforge.net/projects/phpizabi Plone http://plone.org Socialengine http://www.socialengine.com Telligent evolution http://telligent.com/products/p/evolution.aspx Tiki Wiki CMS groupware http://info.tiki.org/Tiki+Wiki+CMS+Groupware Wordpress http://wordpress.org Wordpress ‐ Buddypress http://wordpress.org/extend/plugins/buddypress Xoops http://xoops.org Xoops – Yoghurt http://xoops.org/modules/repository/singlefile.php?cid=97&lid=1668
The following table gives the names and references to the main page of these secondary sources. ID Title Address 1 12 Best Open‐Source Social Networking http://technologytosoftware.com/best‐open‐source‐social‐networking‐software‐boost‐ Software social‐network.html 2 2012 Content Technology Vendor Map http://www.realstorygroup.com/images/subway_Graphic_5.23.jpg 3 25 Best Social Networking Platforms to Start http://www.tripwiremagazine.com/2010/07/25‐best‐social‐networking‐platforms‐to‐ your own Service start‐your‐own‐service.html 4 6 Open Source Social Networking Projects ‐ http://www.linuxplanet.com/linuxplanet/reviews/7199/1 Flock, Elgg, Jcow ‐ Reviews ‐ LinuxPlanet 5 6 Promising And Open Source Social http://www.webresourcesdepot.com/6‐promising‐and‐open‐source‐social‐networking‐ Networking Softwares To Create Your Own softwares‐to‐create‐your‐own 6 Alternatives To Ning: Guide To The Best Social Available: http://www.masternewmedia.org/ning‐alternatives‐guide‐to‐the‐best‐social‐ Networking Platforms And Online Group networking‐platforms‐and‐online‐group‐services Services 7 Anjaan: Top 10 Open Source PHP Scripts for http://anjaanblog.blogspot.nl/2012/01/top‐10‐open‐source‐php‐scripts‐for.html Social Networking
90 of 95
8 Best 5 Open Source Social Networking http://www.techihawk.com/2012/01/best‐5‐open‐source‐social‐networking.html Software ~ Tech i Hawk 9 Comparison of social networking software ‐ http://en.wikipedia.org/wiki/Comparison_of_social_networking_software Wikipedia, the free encyclopedia 10 IDEA; Software options for niche social http://www.idea.org/blog/2011/07/20/software‐options‐for‐niche‐social‐networks/ networks 11 List of enterprise portal vendors ‐ Wikipedia, http://en.wikipedia.org/wiki/List_of_enterprise_portal_vendors the free encyclopedia 12 Open Source Social Platforms: 10 of the Best http://mashable.com/2007/07/25/open‐source‐social‐platforms 13 Open Source, social networking software http://geofftop.com/DISCUSSION.php?ID=54 14 Social Networking http://www.softaculous.com/apps/socialnetworking 14 Social Networking Comparison Chart | Best http://www.mybestratedwebhosting.com/best‐web‐hosting‐tips/social‐networking‐ Web Hosting comparison‐chart.html 16 Social Networking Scripts ‐ User Reviews ‐ http://www.topcommunitysoftware.com/ Social Network Script 17 Social Networking Software | Start your own http://social‐networking‐software.org Social Network today! 18 Tags: community software Powered by the http://www.virtualedgedirectory.com/tag/community%20software Virtual Edge Institute 19 The 5 Best Open‐Source Social Networking http://www.makeuseof.com/tag/the‐5‐best‐open‐source‐social‐networking‐software/ Software 20 Top 10 Free Open‐source Social Networking http://savedelete.com/best‐free‐open‐source‐social‐networking‐ Software To Make Your Network More software.html#.UFx1yFGuqVt Powerful 21 TOP 10 Open‐Source Social Networking http://visionwidget.com/social‐networking‐apps.html Applications TO Run Your Own 22 Top 10 Open‐Source Social Networking http://feedgrowth.com/idea‐categories/social‐networking/top‐10‐open‐source‐social‐ Platforms and Tools | feed growth! networking‐platforms‐and‐tools 23 Top 20 Free Open Source Social Networking http://www.honeytechblog.com/top‐20‐free‐open‐source‐social‐networking‐software Software 24 Top 50 Community Software, Social Network http://www.vivalogo.com/vl‐resources/best‐community‐software‐social‐network‐ Scripts and Platforms | Vivalogo Resources scripts‐platforms.htm 25 Top 7 Open Source Social Networking http://blackboxsocialmedia.com/social‐networking/top‐7‐open‐source‐social‐ Applications | Social Media Marketing And networking‐applications SEO For Business 26 Top five open source social networking http://linux‐news.org/index.php/2012/01/27/top‐five‐open‐source‐social‐networking‐ platforms available in the market platforms‐available‐in‐the‐market/
91 of 95
9.2 Appendix B: Search results This appendix shows the search results for the primary and secondary resource search terms. An ‘1’ indicates the platform was mentioned at the source. Community builder & CMS with community builder extension primary source search results:
engine
Me
CMS
evolution Search term Elgg Pligg Jcow Total Dzoic Inoshi Xoops Drupal Oxwall phpfox Joomla Anahita Dolphin Mahara phpizabi Networx Mugshot Lovdbyless Newsgator Around Buddypress SocialEngine Impress Telligent Community
Community Builder 3 1 1 1
community software 7 1 1 1 1 1 1 1
Community builder 2 1 1 platform Community builder 2 1 1 software social networking platform 8 1 1 1 1 1 1 1 1
social network engine 3 1 1 1
social networking 11 1 1 1 1 1 1 1 1 1 1 1 software social community builder 2 1 1 software social community builder 2 1 1 platform virtual community 0 platform virtual community 0 software online community builder 2 1 1 online community builder 1 1 platform online community builder 1 1 software 1 Total 0 3 2 0 2 1 3 0 1 1 9 0 1 0 0 2 3 0 1 0 3 2 0 0
Community builder & CMS with community builder extension secondary source search results:
Secondar
engine
Me
CMS y source
evolution ID from Elgg Pligg Jcow Total Dzoic Inoshi Xoops Drupal Oxwall phpfox Joomla Anahita Dolphin Mahara phpizabi appendix Networx Mugshot Lovdbyless Newsgator Around Buddypress SocialEngine A: Impress Telligent Community
1 9 1 1 1 1 1 1 1 1 1
2 6 1 1 1 1 1 1
3 9 1 1 1 1 1 1 1 1 1
4 5 1 1 1 1 1
5 4 1 1 1 1
6 3 1 1 1
7 10 1 1 1 1 1 1 1 1 1 1
8 5 1 1 1 1 1
9 13 1 1 1 1 1 1 1 1 1 1 1 1 1
10 5 1 1 1 1 1
12 10 1 1 1 1 1 1 1 1 1 1
13 7 1 1 1 1 1 1 1
14 4 1 1 1 1
92 of 95
15 4 1 1 1 1
16 5 1 1 1 1 1
17 4 1 1 1 1
18 7 1 1 1 1 1 1 1
19 5 1 1 1 1 1
20 10 1 1 1 1 1 1 1 1 1 1
21 10 1 1 1 1 1 1 1 1 1 1
22 7 1 1 1 1 1 1 1
23 6 1 1 1 1 1 1
23 12 1 1 1 1 1 1 1 1 1 1 1 1
24 6 1 1 1 1 1 1
25 7 1 1 1 1 1 1 1
26 5 1 1 1 1 1
Total 7 6 15 4 15 6 4 23 1 6 4 6 11 12 6 2 2 3 6 4 5 8 4 13
Community builder & CMS with community builder extension search results:
engine
Me
CMS
evolution
Elgg Pligg Jcow
Dzoic Inoshi Xoops Drupal Oxwall phpfox Joomla Anahita Dolphin Mahara phpizabi Networx Mugshot Lovdbyless Newsgator Around Buddypress SocialEngine Impress Telligent Community
Primary 0 3 2 0 10 2 1 3 0 1 1 9 0 1 0 0 2 3 0 1 0 3 2 0 sources Secondary 7 6 15 4 15 6 4 23 1 6 4 6 11 12 6 2 2 3 6 4 5 8 4 13 sources Total 7 9 17 4 25 8 5 26 1 7 5 15 11 13 6 2 4 6 6 5 5 11 6 13
Enterprise portal primary source search results: Search term Exo platform GateIn Hippo CMS JetSpeed 2 Liferay Plone free enterprise portal 1 enterprise portal cms 1 1 1 enterprise cms 1 1 social enterprise portal 1 1
Total 2 1 1 4
Enterprise portal secondary search results: Appendix A resource ID Exo platform GateIn Hippo CMS JetSpeed 2 Liferay Plone 2 1 1 1 1 1
11 1 1 1 1 1 Total 2 2 2 1 2 Enterprise portal search results: Exo platform GateIn Hippo CMS JetSpeed 2 Liferay Plone Primary sources 2 1 1 0 4 0 Secondary sources 2 2 2 1 2 1 Total 4 3 3 1 6 1
93 of 95
9.3 Appendix C: Requirement evaluation results In this appendix, the requirement evaluation results of section 3.6 are summarized. For each platform and each requirement, it is given if the requirement is fulfilled, not fulfilled or partially fulfilled.
Elgg Drupal GateIn Liferay Oxwall Anahita Mahara Dolphin WordPress
MVCA1: Sub‐community creation Yes Yes Yes Yes Yes Yes Yes Yes Yes MVCA2: profile creation and Yes Yes Yes Yes Yes Yes Yes Yes Yes management MVCA3: restrict access to sub Yes Yes Yes Yes Yes Yes Yes Yes Yes community MVCA4: Accessibility Yes Yes Yes Yes Yes Yes Yes Yes Yes MVCA5: Https support Partial Partial Partial Partial Partial Yes Yes Partial Partial MVCA6: Different UI for mobile Yes Yes Partial Partial Partial Yes Yes Yes Partial devices MVCA7: Multiple languages Yes Yes Yes Yes Yes Yes Partial Yes Yes MVCA8: Different roles No No Yes Partial Yes Yes Yes Yes Yes MVCA9: Fully customize UI Yes Yes Partial Yes Yes Yes Yes Yes Yes MVCA10: User specific UI No Yes Yes Yes No Yes Partial Yes Partial MVCA11: Constraints on sub‐ No No No No No Yes No Yes No communities MVCA12: Secure platform No objective result could be given. See section 3.6.11 for more information. MVCA13: Security leaks fixed fast MVCA14: Backwards compatibility No Partial Partial Partial No Partial Partial Partial Partial MVCA15: Recent updates Yes Yes Yes Yes Yes Yes Yes Yes Yes MVCA16: Free Yes Yes Yes Yes Yes Yes Yes Yes Yes MVCA17: PHP or Java Yes Yes Yes Yes Yes Yes Yes Yes Yes MVCA18: Well documented API Partial Yes Partial Partial No Yes Partial Partial Yes
94 of 95
9.4 Appendix D: Analysis results In this section, the values used for the scores of the analysis in section 4.3 are given.
Elgg Drupal GateIn Liferay Mahara Dolphin WordPress
Priority A: MVCA1: The platform must allow creation of a sub‐community. 2 2 2 2 2 2 2 MVCA2: The platform must allow creation and management of profiles. 2 2 2 2 2 2 2 MVCA3: It must be possible to restrict access to the sub‐community. 2 2 2 2 2 2 2 MVCA4: MVCs must be accessible using a desktop, notebook, tablet PCs and SmartPhone. 2 2 2 2 2 2 2 MVCA5: Whenever required, for instance based on an in‐depth privacy and security analysis, information between endsystems (mobile devices and desktops) is exchanged in a security 1 1 1 2 2 1 1 enhanced application protocol (such as https). MVCA6: The platform must have the ability to provide a different UI for devices with a limited 1 1 1 2 2 2 1 screen size, such as mobile devices. MVCA7: The platform must support multiple languages. 2 2 2 2 1 2 2 MVCA8: Different user roles must be supported by the MVC platform, including, but not limited 0 1 1 2 2 2 2 to, patient, cardiologist, therapist, nurse, family member, friend. MVCA9: The platform must have the ability to fully customize the UI. 2 1 2 2 2 2 2 MVCA10: The platform must have the ability to have user specific UI’s. 2 2 2 2 1 2 1 MVCA11: The platform must allow configuration of sub‐community such that preferences and 0 0 0 2 0 2 0 constraints can be made and stored regarding roles and services. MVCA12: The platform must be secure. No objective result could be given. MVCA13: Any security leaks that are published must be fixed fast. See section 3.6.11 for more information. MVCA14: The platform’s code must be backwards compatible. 1 1 1 1 1 1 1 MVCA15: The platform must have recent updates. 2 2 2 2 2 2 2 MVCA16: The platform must be free for non commercial use. 2 2 2 2 2 2 2 MVCA17: The platform must be written in PHP or Java. 2 2 2 2 2 2 2 MVCA18: The platform API must be well documented. 2 1 1 2 1 1 2 Priority B: MVCB1: Users should have the possibility to get help in using the system, either through a context‐aware help function or via (context‐aware) help‐desk. This help functionality is about help 1 1 1 1 1 1 1 in using the system only. MVCB2: Users, especially patients, should have full understanding and insight in who is able to read what information about himself or herself, and can exercise control over who is able to see 1 1 1 1 0 1 1 what within the context of a mobile virtual community. MVCB3: For mobile applications, the interaction / communication must be based on WSDL and 1 0 2 2 1 2 2 SOAP. REST is considered a potential candidate for the (near) future. MVCB4: The platform must be able to send invitations to users to join a sub community. 1 2 2 2 1 2 0 MVCB5: The platform must be able to send invitations to users to join the main community. 0 2 1 2 2 2 1 MVCB6: The platform should be able to detect the type of device connected. 1 1 1 2 1 2 1 MVCB7: The platform should have a UI specifically designed for devices with a limited screen size, 2 1 0 2 2 2 1 such as mobile devices. MVCB8: The platform should have an UI in the Dutch language. 1 1 2 1 1 2 2 MVCB9: The extensions useful to this project should be free 2 0 1 2 2 1 0 MVCB10: It should not be too complicated to build our own extensions. 1 0 1 2 1 1 1 Priority C: MVCC1: There is the need for a translation service. Further decisions are needed so as to determine if this can be done off‐line or needs to be online (near real‐time), whether it must be 1 0 0 0 0 0 0 human translation by an authorized translator etc. MVCC2: Whenever required (again, based on an in‐depth privacy and security analysis), health 0 0 0 0 0 1 1 related data of patients should stored in a secure manner in the MVC database. MVCC3: The platform should be able to detect the location of a mobile device. 0 0 0 0 0 0 0 MVCC4: The platform should support multiple database vendors. 0 0 1 2 0 2 2 MVCC5: The platform should offer support to build mobile applications. 0 1 0 0 0 0 0
95 of 95