deliverable d1.4.2 portability & variation management ......possibilities of sharing data since...

European Project Nº: FP7-614154 Brazilian Project Nº: CNPq-490084/2013-3

Project Acronym: RESCUER

Project Title: Reliable and Smart Crowdsourcing Solution for Emergency and Crisis Management

Instrument: Collaborative Project

European Call Identifier: FP7-ICT-2013-EU-Brazil Brazilian Call Identifier: MCTI/CNPq 13/2012

Deliverable D1.4.2 Portability & Variation Management Strategy 2

Due date of deliverable: PM16

Actual submission date: January 31, 2015

Start date of the project: October 1, 2013 (Europe) | February 1, 2014 (Brazil) Duration: 30 months Organization name of lead contractor for this deliverable: Fraunhofer IESE (Fraunhofer)

Dissemination level PU Public PP Restricted to other program participants (including Commission Services) RE Restricted to a group specified by the consortium (including Commission Services) CO Confidential, only for members of the consortium (including Commission Services)

Executive Summary Portability & Variation Management Strategy 2

This document presents deliverable D1.4.2 (Portability & Variation Management Strategy 2) of

the project FP7-614154 | CNPq-490084/2013-3 (RESCUER), a Collaborative Project supported by the European Commission and MCTI/CNPq (Brazil). Full information on this project is available online at http://www.rescuer-project.org.

Deliverable D1.4.2 provides the results of the second iteration of Task 1.4 (Portability and Variation Management Strategy). In this task, we investigate how to deal with a huge diversity of mobile devices and their respective mobile platforms and communication protocols. We also investigate the need for adapting the behaviour of the RESCUER platform to several aspects such as: the emergency scenario (industrial area or large-scale event) and the specific emergency situation, the degree of danger the person is exposed to and whether s/he is part of the crowd or a formal responder, the target-audience of a communication, and possible variations between Brazilian and European regulations. The focus of the first iteration of Task 1.4 was on: 1) explicitly delimitating the scope of the RESCUER platform, 2) understanding the sources of variation within this scope and how they are expected to affect the RESCUER platform, and 3) providing an overview on variation management (VM) and mobile applications development, in order to 4) propose the first concept of a portability and VM strategy for the RESCUER platform. In this second iteration of Task 1.4, the focus was on: 1) refining the scope of the RESCUER platform, 2) updating the overview on variation management (VM) and mobile applications development with relevant or recently available information, 3) updating the portability and VM strategy for the RESCUER platform, by extending and refining the RESCUER variability models, improving the approach for specifying variability in requirements and proposing an approach for capturing variability on the architectural level.

It is relevant to notice that all deliverables of the first project iteration were only concerned with the end-to-end solution for crowdsourcing information gathering, which means the functionalities for gathering crowdsourcing information with and without user interaction, as well as the functionalities for analysing and visualising this information.

In the second project iteration, RESCUER deliverables are concerned with the end-to-end solution for group-targeted follow-up interaction, which means the functionalities for the command centre to obtain further information from people at the incident place with the purpose of better understanding the emergency situation or following up its evolution. Functionalities for supporting the coordination of the workforces are also part of the scope of the second project iteration.

2

http://www.rescuer-project.org/

List of Authors

Karina Villela – Fraunhofer Tassio Vale – UFBA (2nd version) Steffen Hess – Fraunhofer (1st version) Dominik Magin – Fraunhofer Eduardo Almeida – UFBA (1st version) Larissa Soares – UFBA (1st version)

List of Internal Reviewers

Juan Torres – UPM Gustavo Perez – MTM (1st version)

Contents 1. Introduction ..................................................................................................................................... 7

1.1. Purpose .................................................................................................................................... 7

1.2. Change Log .............................................................................................................................. 8

1.3. Partners’ Roles and Contributions........................................................................................... 9

1.4. Document Overview ................................................................................................................ 9

2. Scope of the RESCUER Platform .................................................................................................... 11

3. Sources of Variation ...................................................................................................................... 24

3.1. Mobile Devices, Mobiles Platforms and Communication Protocols ..................................... 24

3.2. Application Scenarios ............................................................................................................ 25

3.3. Specific Emergency Situation ................................................................................................ 26

3.4. Degree of Danger .................................................................................................................. 26

3.5. People Profile ........................................................................................................................ 27

3.6. Targeted Audience ................................................................................................................ 27

3.7. Differences between Brazil and Europe ................................................................................ 28

3.8. Future extensions .................................................................................................................. 28

4. Overview on Variability Management .......................................................................................... 29

4.1. Variability Modelling Approaches ......................................................................................... 29

4.1.1. Feature Modelling ......................................................................................................... 29

4.1.2. Decision Modelling ........................................................................................................ 31

4.1.3. Variation Point Modelling.............................................................................................. 32

4.1.4. Context Variability Modelling ........................................................................................ 34

4.2. Variability Realization Approaches ........................................................................................ 35

4.2.1. Parameters .................................................................................................................... 35

4.2.2. Design Patterns.............................................................................................................. 37

4.2.3. Framework..................................................................................................................... 37

4.2.4. Components and services.............................................................................................. 38

4.2.5. Version Control Systems................................................................................................ 39

4.2.6. Build Systems ................................................................................................................. 39

4

4.2.7. Pre-processors ............................................................................................................... 40

4.2.8. Feature-Oriented Programming .................................................................................... 41

4.2.9. Aspect-Oriented Programming ..................................................................................... 41

4.2.10. Virtual separation of concerns ...................................................................................... 42

4.3. Approach for Variability Management across Lifecycle Stages ............................................ 43

5. VM Strategy ................................................................................................................................... 45

5.1. Variability Modelling Approach ............................................................................................. 45

5.2. RESCUER Variability Model.................................................................................................... 45

5.3. Recommendations Regarding Variability Realization Techniques ........................................ 65

5.4. Recommendations for Capturing Variability in Requirements Specification and System Architecture ....................................................................................................................................... 68

5.4.1. Textual Representation ................................................................................................. 68

5.4.2. Graphical Representation for Variant Use Cases .......................................................... 71

5.4.3. Graphical Representation for Variant System Architecture Perspectives .................... 73

6. Overview on Mobile Applications Development .......................................................................... 75

6.1. Diversity of Mobile Devices ................................................................................................... 75

6.2. Diversity of Mobile Platforms ................................................................................................ 76

6.2.1. Android .......................................................................................................................... 76

6.2.2. iOS .................................................................................................................................. 79

6.2.3. Windows Phone ............................................................................................................. 82

6.3. Development Approaches ..................................................................................................... 85

6.3.1. Native Applications ........................................................................................................ 85

6.3.2. Mobile Web Pages ......................................................................................................... 86

6.3.3. Web Applications........................................................................................................... 87

6.3.4. Hybrid Applications ....................................................................................................... 88

6.3.5. Guidelines for Developing Mobile Applications ............................................................ 89

7. Portability Strategy ........................................................................................................................ 92

7.1. Recommendations Regarding the Mobile Application Development Approach .................. 92

7.2. Experiences with the Mobile Application Development Approach ...................................... 92

7.2.1. Overview of the Used Technology ................................................................................ 93

5

7.2.2. Advantages and Disadvantages of the Used Technology .............................................. 93

8. Conclusion ..................................................................................................................................... 96

Bibliography ........................................................................................................................................... 97

Glossary ............................................................................................................................................... 100

Appendix A: Protocol of the RESCUER Variability Elicitation Workshop ............................................. 101

A.1. Introduction ......................................................................................................................... 101

A.2. Workshop Organization ....................................................................................................... 101

A.3. Workshop Execution and Results ........................................................................................ 102

Session 1: Organizational Structures ............................................................................................... 102

Session 2: Emergency Management Process .................................................................................. 107

Session 3: Mobile Crowdsourcing Solution ..................................................................................... 108

Session 4: Emergency Response Toolkit.......................................................................................... 110

A.4. Conclusion ........................................................................................................................... 113

Appendix B: Potential Features for the Third Project Iteration .......................................................... 115

6

1. Introduction

1.1. Purpose

The RESCUER project aims at developing a smart and interoperable computer-based solution for supporting emergency and crisis management, with a special focus on incidents in industrial areas and on large-scale events. Both the concept and the objectives of the RESCUER project are described in the DoW [1], which is part of the EC Grant Agreement (Annex I). Figure 1 shows the main components of the RESCUER platform: 1) the Mobile Crowdsourcing Solution supports eyewitnesses and first responders in providing the command centre with information about an emergency situation, taking into account the different mobile devices that might be used and how people interact with those devices under stress; 2) the Data Analysis Solutions include approaches for integrating data from different operational forces as well as for combining, filtering, and analysing crowdsourcing information mashed up with open data; 3) the Emergency Response Toolkit provides the command centre with the most relevant information obtained from the crowd in appropriate format and time to support decision-making in the different phases of an emergency; and 4) the Communication Infrastructure insures the information flow between the crowd and the command centre even when the traditional communication infrastructure is overloaded.

Figure 1: Concept of the RESCUER platform

7

The purpose of this document (D1.4.2: Portability & Variation Management Strategy 2) is to analyse the RESCUER platform from the perspective of a variant-rich system. A variant-rich system is a family of similar systems that can assume the shape of a product that can be configured for different customers and/or execution platforms, a software platform that is used to implement similar systems, or a software product line infrastructure from which a family of products can be instantiated. In other words, this deliverable has the purpose of analysing the sources of variation within the RESCUER platform scope and how they may affect the set of features to be provided by the platform in the second project iteration. This deliverable is especially concerned with offering guidelines for dealing with variation during the project life cycle and finding out the best way of combining variation management techniques and mobile applications development approaches, so that project partners can use those guidelines to develop the components of the RESCUER platform.

1.2. Change Log

Table 1 summarizes the changes performed in D1.4.1 (Portability & Variation Management Strategy 1) to give rise to D1.4.2 (Portability & Variation Management Strategy 2).

Table 1: Change log from D1.4.1 to D1.4.2

Change Location Change Description Chapter 2: Scope of the RESCUER Platform

• Refinement of Table 4: List of potential features with respective relevance to the Rescuer platform (First project iteration: End-to-end solution for information gathering) to explicitly provide the relevance of each scope feature for each of the potential variants of the RESCUER platform.

• Inclusion of Table 5: List of potential features with respective relevance to the Rescuer platform (Second project iteration: Coordination and end-to-end solution for group-targeted follow-up interaction).

Chapter 3: Sources of Variation Update of the features triggered by the applicable sources of variation to take into consideration the features from the second project iteration and the better understanding of the general variability.

Section 4.1: Variability Modelling Approaches

Inclusion of Subsection 4.1.4: Context Variability Modelling.

Section 4.3: Approach for Variability Management across Lifecycle Stages

Exclusion of all contents not useful for defining the recommendations for capturing variability in requirements specification and system architecture (Section 5.4).

Section 5.2: RESCUER Variability Model

• Update of all figures and tables to add the features provided in Table 4 and other related features.

Section 5.3: Recommendations Regarding Variability Realization Techniques

Update of all tables to add recommendations for variable features included in Section 5.2 (RESCUER Variability Model) as a result of the second project iteration.

8

Change Location Change Description Section 5.4: Recommendations for Capturing Variability in Requirements Specification and System Architecture

Refinement of the recommendations for capturing variability in requirements and inclusion of recommendations for capturing variability in system architecture.

Subsection 6.2.2: iOS Update taking into consideration the new iOS devices (Table 32), possibilities of sharing data since iOS7, and new programming language called Swift.

Chapter 7: Portability Strategy Inclusion of Section 7.2: Experiences with the Mobile Application Development Approach.

Appendix A with potential features for the second and third iteration

Rename to Appendix B and exclusion of features related to the second iteration.

Inclusion of Appendix A: Protocol of the RESCUER Variability Elicitation Workshop.

1.3. Partners’ Roles and Contributions

The partners involved in this task are Fraunhofer, UFBA, and MTM. Fraunhofer contributed to this deliverable by specifying the scope of the RESCUER platform, analysing the sources of variation applicable to the project, creating the variability model of the RESCUER platform, and providing the overview on mobile applications development approaches. UFBA contributed to this deliverable with the overview on the variation management techniques, which included variability modelling techniques, variability realization techniques, as well as specific techniques for realizing variability in requirements and in architecture. MTM revised this document and will contribute more actively to its third version, by reporting their experience on using the variability realization techniques. The recommendations provided as part of the current concept of the portability and variation management strategy have been compiled by the aforementioned partners according to their respective area of contribution to this deliverable.

1.4. Document Overview

The remainder of this document is divided into three parts: the first one focuses on narrowing the scope of the RESCUER project, the second part addresses the variation management background and strategy, and the third part addresses the background and strategy on the development of mobile applications. This document is structured as follows:

PART I • Chapter 2 describes the scope of the RESCUER platform. Ideally this chapter should be

read before D1.1.2: Requirements Specification 2;

9

• Chapter 3 contains the sources of variation within the scope of the RESCUER platform and what variations they have triggered so far;

PART II • Chapter 4 provides the overview on variation management, which presents the main

techniques for variability modelling and variability realization, in addition to specific approaches for capturing variability in requirements and architecture specifications;

• Chapter 5 describes the variation management strategy to be applied in the RESCUER project, which comprises the variability model and several recommendations for guiding the project partners in the use of the variation realization techniques presented in the previous chapter;

PART III • Chapter 6 presents the overview on mobile applications development, which covers

mobile devices, mobile platforms, development approaches, and specific guidelines; • Chapter 7 contains the recommendations regarding the mobile application development

approach for the RESCUER project together with a preliminary evaluation of the adopted approach;

• Chapter 8 presents the conclusion of this document; • Appendix A describes a workshop carried out to identify variations in the emergency

management organizational structures and processes in Europe and Brazil and check whether those variations affect the RESCUER platform; and

• Appendix B contains the list of potential features for the third project iteration that have been identified so far.

10

PART I: RESCUER Scope

2. Scope of the RESCUER Platform

Software Product Line Scoping [2] is the process of identifying and describing areas of functionality and capabilities of the product line where investment in reuse is economically useful and beneficial to product development. There are several approaches for Software Product Line Scoping [3][4], but those can be generalized into three main activities:

1. Product portfolio scoping: it determines (1) the products that the product line organization should be developing, producing, marketing, and selling; (2) the common and variable features that the products should provide in order to reach the long and short term business objectives of the product line organization, and (3) a schedule for introducing products to markets [4].

2. Domain scoping: it identifies and bounds the functional areas that are important to the envisioned product line and provide sufficient reuse potential to justify the product line creation [3][4].

3. Asset scoping: it determines specific assets to be developed for reuse. All these assets are part of the reuse infrastructure [3].

Therefore the main questions to be answered during the Software Product Line Scoping are: • Which products should be included in the product line? What is their market? When will

they be released? • Which features (distinguishing characteristics) will my product line have? Which product

will have what kind of features? Which are easy, which are risky features? • Which major domains (functional areas) are necessary for engineering the products?

What are „good“ or „bad“ domains for the product line (in terms of knowledge, stability, etc.)?

• Which assets should I have in my product line? Which components, documentation etc. already exist in a reusable form, which ones should be (re-)implemented?

Despite of being a sub-process of the Software Product Line Engineering process, the scoping ideas and activities are useful for defining any variant-rich system, in other words: any portfolio of similar software systems, regardless of the specific approaches for supporting variability management.

Thus, we performed a simplified version of the scoping process proposed by [2] to scope the RESCUER platform. The twofold goal of doing so was: 1) to clearly define the products/features to be supported/provided by the platform, 2) to progress towards the identification of the variabilities to be supported by the platform. Of course, the features identified during scoping are not detailed features but the ones that are relevant for distinguishing between the different products. We

11

performed several scoping sessions that took place at different events. Table 2 provides the number of participants in the scoping sessions per iteration, where “Industry Area EU” and “Industry Area BR” refer to the representatives of industrial areas in Europe and Brazil, respectively, and “Large-scale Events EU” and “Large-scale Events BR” refer to the representatives of organizations in charge of dealing with public emergency situations in Europe and in Brazil, also respectively. A scoping expert conducted the scoping process. The results of the scoping sessions are provided in Table 3, which lists the main product variants and their characteristics, and in Table 4,Table 5 and Appendix B - Table 41, which provide the lists of features identified during scoping process.

Table 2: Number of participants from user organizations in the project scope definition

Project Iteration Industry Area EU

Industrial Area BR

Large-scale Events EU

Large-scale Events BR

First: Information gathering 5 4 4 4 Second: Follow-up interaction and coordination

2 3 2 3

As mentioned in the Table 3, it is still not completely clear how the differences in the Brazilian

and European regulations affect the RESCUER platform. We might define new product variants or address the differences in regulations in terms of customization of the two main product variants. Table 4 contains the features that were relevant in the first project iteration, whereas Table 5 provides the features added to the RESCUER scope in the second project iteration. Appendix B - Table 41 contains features to be considered in the third project iteration, but with the only purpose of documenting information that might be useful in the future. The column “Feature Type” refers to the feature classification provided in [5]. The feature types are:

• Capabilities features, which are characterized as distinct services, operations, or non-functional aspects of products in a domain. Services are end-user visible functionality of products offered to their users in order to satisfy their requirements. Operations are internal functions of products that are needed to provide services. Non-functional features include end-user visible application characteristics that cannot be addressed in terms of services or operations, such as presentation, capacity, quality attribute, usage, cost, etc.

• Operating environment features result from the fact that applications may run in different operating environments, e.g. different hardware or operating systems, or interface with different types of devices or external systems. Protocols used to communicate with external systems are also classified as operating environment features.

• Domain technology features are domain specific technologies that domain analysts or architects use to model specific problems in a domain or to “implement" service or operation features. Examples of domain technology features are domain-specific theories and methods, analysis patterns, and standards and recommendations. Note that this type of feature refers to features that are specific to a given domain and may not be useful in other domains.

12

• Implementation technique features are more generic than domain technology features and may be used in different domains. They contain key design or implementation decisions that may be used to implement other features. Communication methods, design patterns, architectural styles, ADTs, and synchronization methods are examples of implementation techniques.

We consider this classification to be really helpful to support the activity of feature identification, despite of the fact that the scoping process does not have the goal of identifying all features, but only the most important ones to distinguish between product variants and to distinguish those product variants from the competitors’ products. This is reflected in Table 4, Table 5, and Appendix B - Table 41 by the fact that most features are services, which is the most visible type of feature for the customers.

The features in light grey in Table 4, Table 5, and Appendix B - Table 41 were part of a questionnaire that was applied with the representatives of industrial areas and of organizations in charge of dealing with public emergency situations (Table 2). They were requested to inform the relevance of those features in terms of: “Must have”, “Good to have”, and “Not so relevant”. The answers were consolidated according to the identified product variants (“IP-EU”, “IP-BR”, “LE-EU”, “LE-BR”) and classified in three groups: High relevance (green, 1), medium relevance (yellow, 2), and low relevance (orange, 3). The results are presented in Table 4 and Table 5 in the columns with the name of the product variants. In addition, all project site leaders (Europe and Brazil) were requested to provide the relevance of those same features from the research perspective, by using the scale “Main research goal / Highly Interesting”, “Nice research line / Necessary underlying feature”, and “Trivial / Standard software development”. The answers were consolidated and classified in three groups, using the same scale used for representing the relevance to the product variants. The results are provided in the “Research Relevance” column. The “Project Scope” column is a free consolidation of the relevance to the product variants and the “Research Relevance” column, and the used scale is: (Y)es, it is part of the project scope; (M)aybe, it might be covered; and (N)o, it will probably not be covered.

13

Table 3: Potential product variants from the RESCUER platform

Product ID

Product Name Product Description Market Segment Customizations Environmental Constraints

IP RESCUER Industry Focus on fire/explosion, gas leak, and environmental incident

Industrial parks in Europe and Brazil.

As differences in regulations have not been deeply investigated, it is still not completely clear whether there is need for customizations of this product variant to the European market and to Brazilian the market. The determination of the relevance of the identified features to the combination of product variant and market/region (IP-EU and IP-BR in Table 4 and Table 5) is a sound step towards the final decision.

Operational forces can only use explosion-safe equipment.

LE RESCUER Large-Scale Event

Focus on disturbance in the crowd and fire/explosion

Organizations involved in ensuring security and safety in large-scale events.

Same explanation as for IP, but the combination of product variant and market/region is represented by LE-EU and LE-BR in Table 4 and Table 5. For this product, there is the need for allowing independent download of the Mobile Crowdsourcing Solution and probably also for having it as a (suit of) add-on(s) to be integrated in the large-scale-event mobile application.

Operational forces can only use explosion-safe equipment.

14

Table 4: List of potential features with respective relevance to the Rescuer platform (First project iteration: End-to-end solution for information gathering)

Feature ID

Feature Name Feature Type Feature Description IP-EU IP-BR LE-EU LE-BR Research Scope

SF1 Monitoring of crowd behaviour

Service Monitoring of a specific area during a specific period of time in order to detect too high density, turbulence, and pressure.

2 1 2 2 1 Y

SF2.1 Sensor data gathering: position

Operation Gathering of position (direct sensing) using one of the available mechanisms: e.g. Wifi signal or GPS.

SF2.2 Sensor data gathering: movement speed

Operation Gathering of movement speed through direct sensing of GPS raw data.

SF2.3 Sensor data gathering: movement direction

Operation Gathering of movement direction through direct sensing of GPS raw data.

SF2.4 Sensor data gathering: altitude

Operation Gathering of altitude data from a specific sensor or using GPS coordinates (direct sensing). It is not relevant to SF1, but it is relevant for supporting multimedia data analysis.

SF3 Sensor data annotation

Operation Annotation of content explicitly generated by the user (multimedia data, incident notifications or reports) with sensor data

SF4 Sensor data streaming Operation Streaming of sensor data for crowd sensing. SF5 Incident notification Service Notification of an incident by someone at the place

of the incident.

SF5.1 Very quick incident notification

Operational Environment Feature

Notification of an incident by someone at the place of the incident using a smart phone or tablet. 3 3 3 3 1 Y

15

Feature ID


SF5.2 Incident notification via SMS

Operational Environment Feature

Notification of an incident by someone at the place of the incident using a standard cell phone. 1 2 1 2 3 M

SF6.1.1

Incident report: Crowd Service Report of incident that ask for information that can be provided by anyone in the crowd. 2 3 2 2 1 Y

SF6.1.2

Incident report: Expert Service Report of incident that ask for information that can only be provided by people with experience in dealing with emergency situations.

2 1 3 2 1 Y

SF6.2.1

Incident report: Gas leakage

Domain Technology Feature

Report of incident that ask specific information regarding gas leak. 1 1 1 2 2 Y

SF6.2.2

Incident report: Explosion/Fire


Report of incident that ask specific information regarding explosion/fire. 1 1 1 2 1 Y

SF6.2.3

Incident report: Traffic Accident


Report of incident that ask specific information regarding traffic accident. 3 2 1 3 2 N

SF6.2.4

Incident report: Blackout


Report of incident that ask specific information regarding blackout. 2 1 1 3 2 N

SF6.2.5

Incident report: Environment


Report of incident that ask specific information regarding chemical spills or other similar environmental incidents.

1 1 1 2 2 Y

16

Feature ID


SF7 Multimedia attachment

Operation Attachment of an image or video to an incident notification or report.

SF8 Integration with existing large-scale events apps (Alias: Integration2UpperLevelApp)

Non-functional

Integration of the Mobile Crowdsourcing Solution into the mobile applications of the large-scale event organization in order to maximize the possibility of people in the crowd having the Mobile Crowdsourcing Solution ready for instant use in their smart mobile devices.

SF9 Integration with existing procedures of the workforces

Non-functional

Integration of the Mobile Crowdsourcing Solution into an everyday procedure of the workforces to promote its smoothly use in emergency situations. It should also be investigated the possibility of people partially using it in their everyday life.

2 1 2 2 2 M

SF10 Crowd density analysis Service Analysis of position sensor data or videos to allow the detection of places with potentially dangerous crowd density.

SF11 Crowd turbulence analysis

Service Analysis of position sensor data to allow the detection of places with crowd turbulence, which means the detection of a part of the crowd moving against another part of the crowd.

SF12 Crowd pressure analysis

Service Analysis of position sensor data or videos to allow the detection of places with crowd pressure, which means the detection of a crowd of certain size going to places that are suddenly narrower than the place of origin.

17

Feature ID


SF13.1 Crisis mapping: Incident location

Service Information layer that displays the location of the emergency situation or the several incidents of an emergency situation in a map of the area.

1 1 1 1 1 Y

SF13.2 Crisis mapping: Places of concern

Service Information layer that displays the places of concern in the surrounding area, such as factories with hazard material, schools or hospitals.

1 1 1 3 2 M

SF13.3 Crisis mapping: Safety & security areas

Service Information layer that displays the safety & security areas, which are pre-defined areas in the chemical parks or large-scale events where people should go in case of an incident.

1 1 2 1 2 M

SF13.4 Crisis mapping: Crowd behaviour

Service Information layer that displays the crowd density in the map of the area using e.g. heat map.

SF13.5 Crisis mapping: Crowdsourcing information

Service Information layer that displays selected data (after data analysis) coming from the crowd or operational forces with its reliability indicator having as a starting point for the user interaction the position of the data in the map of the area.

2 1 1 3 1 Y

SF13.6 Crisis mapping: Free drawing

Service Possibility of free drawing over the map of the area and any visualization layer over it. 1 1 3 3 3 N

SF14.1 User registration: Workforce

Service User registration for workforces (police, firefighters, rescue service). The user will inform the workforce he works for and his/her role on the emergency management process (e.g. evacuation coordinator, emergency brigade leader).

18

Feature ID


SF14.5 User registration: Supporting force

Service User registration for the supporting forces (volunteers, security staff, emergency staff). The user will at least inform the specific supporting force s/he belongs to. Additional necessary information needs to be elicited.

SF14.3 User registration: Volunteer

Service Special user registration for volunteers in industrial areas. The user will at least inform the community around the industrial area in which s/he lives.

SF14.4 User registration: General civilian

Service User registration for any general civilian, who might be a visitor or an employee of a large-scale event or industrial area.

SF14.2 User registration: Employee

Service Special user registration for employees in industrial areas. The user will at least inform the company in the industrial area s/he works for.

19

Table 5: List of potential features with respective relevance to the Rescuer platform (Second project iteration: Coordination and end-to-end solution for group-targeted follow-up interaction)

Feature ID


SF16.1 Follow-up interaction: Civilians

Service Follow-up interaction with people who are at the incident place, to ask for missing information (only if they have already interacted with RESCUER and are in safety areas) and to know about their personal status (only if they are not moving). It represents a request of information.

3 3 3 2 1 Y

SF16.2 Follow-up interaction: Supporting forces on-site

Service Follow-up interaction with supporting forces on-site to obtain missing information or investigate potential problems. It represents a request of information.

3 1 3 1 1 Y

SF16.3 Follow-up Interaction: Workforces on-site

Service Follow-up interaction with workforces on-site to increase information reliability, obtain missing information, clarify contradictory information, or investigate potential problems. It represents a request of information.

1 1 1 1 1 Y

SF34 Friends Follower Service Mechanism that allows someone in the crowd to send his/her position and status to friends as well as to know his/her friends’ position and status. Ideally it should support communication to the outside through automatic publication in social media and/or sending of SMS/E-mail.

3 3 3 3 3 N

20

Feature ID


SF35 W Questions Analysis Service Analysis of text, images or videos to extract information about what type of incident is, when it happened, and who was involved.

SF36 Fire/Smoke Expansion Speed

Service Analysis of videos to estimate the expansion speed of fire or smoke.

SF17.1 Emergency mapping: Placement of workforces

Service Visualization layer that displays the workforces' placement/distribution in a certain area. Ideally it should provide the position of police, firefighters, and rescue service.

1 1 1 1 2 Y

SF17.2 Emergency mapping: Placement of supporting forces

Service Visualization layer that displays the supporting forces' placement/distribution in a certain area. Ideally it should provide the position of security staff, emergency staff, and volunteers.

2 1 1 1 3 M

SF17.3 Emergency mapping: Evacuation and approach routes

Service Map of the emergency situation area in which people from the command and control centre can draw the evacuation and/or approach routes together with the respective visualization layer that displays those routes.

1 1 1 2 3 M

SF19.1 Contact information: Emergency/crisis committee

Service Organogram of the emergency/crisis committees with the respective contact information. 3 1 2 N/A1 3 N

1 The relevance of this feature was not evaluated for incidents in large-scale events in Brazil due to a misunderstanding during the questionnaire application. 21

Feature ID


SF19.2 Contact information: Other organizations involved in emergency management

Service Communication flow between the organizations involved in an emergency situation with the respective contact information. 3 1 1 1 3 N

SF20 Emergency dashboard: Classification of severity

Service Possibility of informing the classification of the emergency in terms of severity in the emergency situation overview. Ideally the classification of the emergency should be suggested by the Emergency Response Toolkit based on the received reports.

2 1 1 1 2 Y

SF21 Virtual meeting room Service Virtual meeting room to support meetings of the emergency and/or crisis committees when a face-to-face meeting is not possible.

3 3 3 3 3 N

SF25 Operation plan Service Coordination mechanism that allows assigning tasks to operational forces. Each workforce has its own operation plan and the view of all operation plans merged in an integrated operation plan is desired by the workforces.

3 1 2 3 2 M

SF26 Actual dispatch Service Coordination mechanism that allows the actual dispatch of workforces. Through this mechanism the tasks are sent to the people in charge of performing them.

2 2 3 3 2 N

SF23.1 Human resource management: Workforces

Service Coordination mechanism that informs available man power and special skills per workforces (police, firefighters, rescue service).

1 1 1 1 3 M

22

Feature ID


SF23.2 Human resource management: Supporting forces

Service Coordination mechanism that informs available man power and special skills per supporting forces (volunteers, security staff, emergency staff).

3 1 1 1 3 N

SF23.3 Coordination: Request of task

Service Coordination mechanism that is used to request the execution of tasks, e.g.: 1) Evacuation of company(ies), whole industrial park, neighbourhood(s) 2) Road Blockage 3) Damage Evaluation

1 1 3 3 2 M

SF24.1 Material & equipment management: Workforces

Service Coordination mechanism that informs equipment and other available resources per workforces (police, firefighters, rescue service)

1 2 1 1 3 M

SF24.2 Material & equipment management: Supporting forces

Service Coordination mechanism that informs equipment and other available resources per supporting forces (volunteers, security staff, emergency staff).

2 2 2 1 3 N

SF24.3 Coordination: Request of resource

Service Coordination mechanism that is used to request resources, e.g. medical support, emergency brigades, helicopter (extern), firefighters (extern), security (extern), and rescue services (extern).

1 1 2 3 2 Y

SF31 Ad-hoc communication

Service Peer-to-peer communication in the crowd by alternating smart devices acting as access points. 3 1 2 3 1 Y

23

3. Sources of Variation The purpose of this chapter is to analyse the potential sources of variation of the RESCUER

platform that were presented in the DoW [1] in order to better understand how they affected the definition of the platform scope, but especially to understand how those sources of variation will affect the refinement of the product variants and features presented in the previous chapter. As mentioned in the DoW [1], variations in the RESCUER platform are expected due to:

1) The different mobile devices, mobile platforms and communication protocols, 2) The two application scenarios: incidents in large-scale events and incidents in industrial

areas, 3) The specific emergency situation, such as fire, explosion or gas leakage, 4) The degree of danger the person is exposed to, 5) The profile and specific role of the person in the emergency situation, e.g. whether the

person is part of the crowd or a member of the workforces, 6) The targeted audience of a communication, e.g. whether the target audience is the

company where the incident took place, the whole industrial area or public authorities, 7) Possible differences between Brazilian and European regulations and markets, 8) Future extensions, e.g. the addressing of a further type of emergency situation or the

inclusion of new role in the emergency situation.

3.1. Mobile Devices, Mobiles Platforms and Communication Protocols

Figure 2 represents the key features of a mobile device, which include the most popular operating systems or mobile platforms, and the most relevant communication protocols. It makes use of the feature diagram notation to illustrate standard features (represented as mandatory), alternative features (represented as alternative) and features that are not present in every mobile device (represented as optional). The features of special concern when developing a mobile application that should run in several different mobile devices are the screen size and resolution, and the operating system.

Regarding the first, while the space occupied by some interface elements scaled down and up according to the screen size, other interface elements must be carefully planned according to the expected screen size. In regards to the second, the platform used to develop the mobile application strongly depends on the mobile operating system (native development) or on the fact that the mobile application is intended to run in several operating systems (cross-platform development). When choosing a development approach, the development of some features will be easier or more difficult than when choosing another development approach. The performance of the application later on may also be affected by this choice. As the Mobile Crowdsourcing Solution component of the RESCUER platform should run in several different mobile devices, Chapter 6 of this deliverable

24

investigates the advantages and disadvantages of the current mobile applications development approaches.

Figure 2: Key features of a mobile device

3.2. Application Scenarios

An incident in an industrial area is classified according its severity following the guidelines defined in [6]. The guidelines are specific for industrial areas. On the other hand, large-scale events are usually classified according to the security risk they represent. The Maurer scheme is one of the approaches for risk assessment of large-scale events [7]. As a consequence, feature Emergency dashboard: Classification of severity (SF20), considered relevant to both application scenarios (see Table 5), will have different implementations in the two application scenarios.

The types of incident supported by the RESCUER platform are also expected to vary according to the specific application scenario. For example, Incident report: Gas leakage (SF6.2.1) and Incident

25

report: Environment (SF6.2.5) are only relevant to the application scenario of incidents in industrial areas. Another set of features only relevant to the application scenario of incidents in industrial areas is: User registration: Volunteer (SF14.3) and User registration: Employee (SF14.2). The first one was proposed by the Brazilian user organization of the consortium: COFIC. COFIC has a set of volunteers (normal citizens) who lives in the communities surrounding the open industrial area. Nowadays they have special radios in order to directly communicate problems to the industrial area or receive instructions. Using the RESCUER platform, they would have smart phones. Similarly, User registration: Employee (SF14.2) was proposed by COFIC to support the evacuation of people from specific companies in an industrial area.

Feature Integration with existing large-scale events apps (SF8) is obviously only applicable to the scenario of incidents in large-scale events. In this application scenario, features related to the supporting forces, such as SF17.1 - Emergency mapping: Placement of supporting forces and SF23.2 - Human resource management: Supporting forces, have high relevance.

Furthermore, it should be investigated the reason for the consistent good evaluation of the relevance of Crisis mapping: Free drawing (SF13.6) by the representatives of industrial areas in contrast to the not so good evaluation of this feature by the representatives of large-scale events (Table 4).

Finally, some coordination features like Coordination: Request of task (SF23.3) and Coordination: Request of resource (SF24.3) are more relevant in the application scenario of incidents in industrial areas than in the application scenario of incidents in large-scale events.

3.3. Specific Emergency Situation

The specific emergency situation influences the feature Very quick incident notification (SF5.1). Using this feature, the user of the Mobile Crowdsourcing Solution selects the type of incident s/he is witnessing. Furthermore, several features regarding incident report have been included in the scope of the RESCUER project to address the particularities of the incident report for the specific emergency situation: Incident report: Gas leakage (SF6.2.1), Incident report: Explosion/Fire (SF6.2.2), Incident report: Environment (SF6.2.5). The variation represented by these three features is realized by having questions in the incident report that are specifically related to the type of incident.

3.4. Degree of Danger

Deliverable D2.1.1 (Conceptual Model of Mobile User Interaction in Emergencies 1)2 stated that the human cognitive capabilities available to interact with a mobile application are strongly reduced

2 D2.1.2 (Conceptual Model of Mobile User Interaction in Emergencies 2) consolidates the results of the two iterations of task T2.1 (Mobile User Interaction in Emergency Situations) and, therefore, substitutes D2.1.1.

26

when people face an emergency situation. They concentrate on their main tasks at the moment, which are identifying and assessing the risks that the emergency situation brings and taking the necessary protective actions. Distance from the epicentre of the incident and timespan since the moment null of its occurrence play a crucial role on the level of stress of the witnesses and consequently on their human cognitive capabilities. Therefore, deliverable D2.1.1 proposed a strategy for collecting crowdsourcing information at the place of the incident based on three steps, depending on the distance from the epicentre of the incident and timespan since the moment null, namely one-click information gathering, guided information gathering, and chat-like information gathering. The feature Very quick incident notification (SF5.1) and the features regarding Incident report (SF6.1.x and SF6.2.x) correspond to the two first steps, one-click information gathering and guided information gathering, respectively. The user of the Mobile Crowdsourcing Solution starts with the Very quick incident notification (SF5.1), can go on with the Incident report (SF6.1.x and SF6.2.x) when s/he feels ready for it, and finally can engage himself/herself in a chat-like interaction when s/he is in a safety area. The user interface will not make him/her aware of the three steps, but just inform that information has been sent to the command and control centre and allow him/her to provide more information, if s/he can and wants to do it. As the functionalities regarding the three steps will always be available, the scoping features SF5.1 and SF6.1.x are mapped to the same feature of the variability model presented in Section 5.2.

3.5. People Profile

We have identified three main profiles for the people involved in an emergency situation: 1) people from workforces, 2) people from supporting forces, 3) and general civilians. People profile affects the way that they report incidents (SF6.1.1 - Incident report: Crowd and SF6.1.2 - Incident report: Expert), and both the conditions under they are selected to participate in follow-up interactions and the questions that they get to answer (SF16.x - Follow-up interaction). While civilians will get questions that anyone in the crowd can answer (SF6.1.1 - Incident report: Crowd), workforces and supporting forces will get questions that require a certain level of knowledge and experience with emergency situations (SF6.1.2 - Incident report: Expert).

It should be investigated whether the current features already cover the need for information from volunteers, which is a relevant sub-profile of supporting forces (see Section 3.2).

3.6. Targeted Audience

The targeted audience of a communication is only relevant for the third project iteration.

27

3.7. Differences between Brazil and Europe

No features have been identified so far as a consequence of differences in the European and Brazilian regulations, or de-facto standards related to emergency handling and crisis management or related to the use of crowdsourcing information to this end. The consortia will further investigate differences between the applicable regulations in the two regions. However, Table 5 indicates interesting differences: features related to supporting forces (SF16.2 - Follow-up interaction: Supporting forces on-site, SF17.2 - Emergency mapping: Placement of supporting forces, SF23.2 - Human resource management: Supporting forces) are more relevant to Brazilian industrial areas than to European industrial areas, probably due to the relevant role of the volunteers in the Brazilian industrial areas. Furthermore, User registration: Volunteer (SF14.3) and User registration: Employee (SF14.2), as explained in Section 3.2, are very important features for Brazilian industrial areas, but not relevant to European industrial areas. This results from the facts that the Chemical Park of Linz does not have volunteers and the organizational units of its companies are dispersed in the industrial area, which decreases the need for sending messages to all employees of a certain company. Features related to contact information (SF19.1 - Contact information: Emergency/crisis committee and SF19.2 Contact information: Other organizations involved in emergency management), Integration with existing procedures of the workforces (SF9), and Operation plan (SF25) are very important for Brazilian industrial areas and not so relevant to European industrial areas. This might also be a consequence of the size of the industrial area (in terms of physical area and in terms of number of companies), and the consequent complexity and need for negotiation and coordination. Therefore, this source of variation should be further investigated to find out whether the Industrial Park of Camacari and the Chemical Park of Linz are good representatives of the industrial areas in their respective geographic regions. Another interesting finding regarding this source of variation was the high relevance of Incident notification via SMS (SF5.2) for both application scenarios in Europe, in contrast to the moderate relevance assigned in Brazil.

3.8. Future extensions

Two types of extensions are expected and, therefore, should be carefully planned in the portability and variation management strategy: 1) new types of incident, and maybe 2) new specific roles that people can play in an emergency situation (e.g. evacuation coordinator and emergency brigade leader).

28

PART II: Variability Management

4. Overview on Variability Management

Similarly to the Software Product Line Scoping process (Chapter 2), the techniques used for modelling and realizing variability in software product line engineering can be useful for other types of variant-rich systems too. These techniques are used in domain engineering [8], the process of developing the common assets for a set of similar product variants. Such assets can be reused when developing/deriving the customized products, which constitutes the process of application engineering.

4.1. Variability Modelling Approaches

Variability modelling is essential for defining and managing the commonalities and variabilities in software product lines. Nowadays, several variability modelling approaches exist to support domain and application engineering activities [9], each with slightly different focus and goal. Next, we present the most popular approaches: feature modelling, decision modelling, and variation point modelling. Context variability modelling, which is an approach for dealing with complex variability models, is s briefly explained in Subsection 4.1.4, because several variabilities in RESCUER features are consequence of variabilities in the environment of the RESCUER platform.

4.1.1. Feature Modelling

Feature modelling is the activity of identifying externally visible characteristics of products in a domain and organizing them into a model called feature model [5]. Lee et al. [5] proposes a feature classification in terms of capabilities (services, operations, or non-functional properties), operating environments, domain technologies, and implementation techniques, as already presented in Chapter 2, to support the identification and modelling of features.

In a feature model, common features among different products are modelled as mandatory features, while different features among them may be optional or alternative. Optional features represent selectable features for products of a given domain and alternative features indicate that no more than one feature can be selected for a product. Features are not always freely combinable. Not all features may be compatible, and some features may require the presence of other features (for example, “B implies C”). Therefore, a feature model describes relationships between features and defines which feature selections are valid [10].

A feature diagram uses a graphical notation to specify a feature model in terms of an AND/OR hierarchy of features and constraints among them [5][10]. A tree whose nodes are labelled with

29

feature names represents the feature model and the semantics is specified by a translation into propositional logic. Different notations convey various parent-child relationships between features and their constraints [5]. The composed-of relationship is used if there is a whole-part relationship between a feature and its sub-features. In cases where features are generalization of sub-features, they are organized using the generalization/specialization relationship. The implemented-by relationship is used when a feature (i.e., a feature of an implementation technique) is necessary to implement the other feature. Figure 3 shows a simplified feature model of a Private Branch Exchange (PBX) system.

Figure 3: An example of feature model: PBX product line [5]

Table 6 summarizes the strengths and weaknesses of modelling variability with feature models.

30

Table 6: Strengths and weaknesses of feature models

Strengths Weaknesses o Supports the understanding of variability

[5][10] o Simple [5][10] o Feature diagram is widely used in practice [5] o Dependencies can be clearly visualized in

feature diagrams [10] o Some textual representation (e.g. µTVL) [11]

can be formally verified o Availability of tools [10]

o Relationship to others artifacts (such as components, interfaces) is not usually addressed [5]

4.1.2. Decision Modelling

The Software Productivity Consortium Services Corporation [12] defines decision model as a set of decisions that are adequate to distinguish among the members of a product family and to guide the adaptation work products.

According to [9], most decision model approaches were either inspired by industrial applications or developed in close collaboration with industry. Several of them are discussed in a recent comparative analysis [13]. In VManage [14] and the approach by Weiss and Lai [15], a decision model is a document defining the decisions that must be made to specify a member of a domain [16]. The tool-supported DOPLER approach [17] has been developed to guide the derivation of customer-specific products. The work of Schmid and John [18] provides a common modelling foundation that can be mapped to a wide range of notations. Figure 4 depicts a partial decision model for the example of a mobile phone in a tabular representation, whereas Figure 5 shows a partial decision model of bottle sorting automation system.

Figure 4: Decision model in a tabular notation [18]

31

Figure 5: Decision model in a graphical representation [17]

Table 7 summarizes the strengths and weaknesses of modelling variability with decision models, which are non-hierarchical models.

Table 7: Strengths and weaknesses of decision models

Strengths Weaknesses o Focus on supporting product derivation

[9][19] o Simple o Relationship to artifacts is usually addressed

[19]

o Used by a group of people o Dependencies are not so clearly visualized in

the tabular representation o DOPLER [17] is the only robust tool

4.1.3. Variation Point Modelling

In COVAMOF [20], variation points represent choices provided by the product family and the related dependencies that represent the constraints on these choices. There are five different types of variation points, namely Value, Optional (zero or one variant), Alternative (exactly one variant), Optional Variant (zero or more variants), and Variant (one or more variants) variation points. A variation point entity has a number of properties, for example, the abstraction layer the choice is located in, its binding time, and the reason why a choice is provided.

The Variability Specification Language (VSL) [20] is a technique for modelling variability that distinguishes between variability on the specification and on the realization level. The variability on

32

the specification level refers to choices demanded by customers and is expressed by Variabilities. On the realization level, Variation Points indicate the places in the asset base that implement these required choices. They describe the actions that should be taken when a particular option is chosen. Implements relations between Static Variation Points and Variabilities describe how the Variation Points should be configured based on the decisions for the Variabilities. The Variation Points are separated into two sets: Dynamic Variation Points (referring to runtime variability) and Static Variation Points (referring to pre-runtime variability).

Figure 6 shows how a product family mobile parking applications can be modelled using the concepts in the meta-model of VSL. The top-right box (specification level) contains the user-visible choices, the left box contains the software application structure, and the bottom-right box (realization level) specifies the variability in these assets that implement the user-visible choices on the specification level. The legend in Figure 6 shows how the graphical elements map onto the concepts in the VSL.

Figure 6: A parking product family modelled in VSL [20]

Table 8 summarizes the strengths and weaknesses of modelling variability with variation point models, which are non-hierarchical models.

33

Table 8: Strengths and weaknesses of variation point models

Strengths Weaknesses o Focus on the link to / representation of

architecture o Provision of levels of abstraction o Dependencies can be formal or informal o More concepts/elements

o Dependencies are not so clearly represented in VSL

o Used by a group of people

4.1.4. Context Variability Modelling

There are several approaches for dealing with complex variability models (e.g. multi criteria product lines [21], multi-level feature modelling [22], context variability modelling [23], and view based feature modelling [24]). As mentioned before, context variability modelling is described here due to its relevance for modelling variability in the RESCUER project.

Hartmann and Trew [23] propose to model context variability, which is the variability of the environment in which a product resides. The context variability model contains the primary drivers for variation, e.g. different geographic regions. It can be defined using a feature diagram notation but does not define features in the traditional sense, but general classifiers of the context. The dependencies between features and context are modelled as dependencies between feature model and context variability model. An example is shown in Figure 7.

Figure 7: Feature diagram of an infotainment multiple product line [23] 34

Table 9 summarizes the strengths and weaknesses of modelling context variability.

Table 9: Strengths and weaknesses of context variability models

Strengths Weaknesses o Intuitive way to capture variability and

commonality that originate from different contexts [23]

o Definition of feature variability according to different criteria [25]

o Reduction of redundancy [25]

o Maintenance of a big number of dependencies between the two models [25]

4.2. Variability Realization Approaches

Apel et al. [10] introduced three dimensions for classifying variability realization or implementation techniques: (i) Binding Time, (ii) Technology, and (iii) Representation. The former can be distinguished between compile-time binding, load-time binding, and run-time binding. Compile-time variability is decided before or at compile time; load-time variability is decided after compilation when the program is started; with run-time variability, decisions can be made and changed during program execution. Regarding Technology, it is possible distinguish the variability implementation techniques that are based on mechanisms provided by a programming language, called language-based approaches, from those that are based on tools that operate on software artifacts to derive products, called tool-based approaches. In terms of Representation, there are annotation-based and composition-based approaches, which differ in the way they represent variability in the code base and the way they generate products.

Table 10 classifies different variability implementation techniques according to the dimensions aforementioned. Some approaches have multiple instances with different properties, such that the classifications are not disjoint. For example, some component systems support both static and dynamic composition; others are both language-based and tool-based. Each technique has advantages and disadvantages, as it will be explained in the following subsections [10].

4.2.1. Parameters

A simple way to implement variability is to use conditional statements (such as “if” and “switch”) to alter the control flow of a program at run-time. Conditional statements are typically controlled by configuration parameters passed to a method or a module, or set as global variables in a system. Different parameter assignments lead to different program executions. Table 11 summarizes the strengths and weaknesses of implementing variability with parameters [10].

35

Table 10: Classification of variability implementation techniques [10]

Table 11: Strengths and weaknesses of implementing variability with parameters [10]

Strengths Weaknesses o Easy to use, well-known o Flexible and fine grained o First-class programming-language support o Different configurations within the same

program possible

o All code is deployed, no compile-time configuration

o Often used in ad-hoc or undisciplined fashion o Boilerplate code to propagate method

arguments or non-modular solutions o Scattering and tangling of configuration

knowledge o Separation of feature code and information

hiding possible, but left to the discipline of developers

o Extensions typically require invasive changes, but little preplanning though

o No support for non-code artifacts o Nontrivial tracing between features and code,

and thus difficult to analyse statically

36

Boilerplate code is the sections of code that have to be included in many places with little or no alteration. Feature code means the code that implements a feature. It might be scattered across multiple files and modules, which makes tracing a feature to all code fragments implementing it a nontrivial task. Furthermore, feature code might be tangled with the base code and code of other features. Due to its crosscutting nature, it is difficult to encapsulate a feature’s code behind an interface and to place all feature code in one cohesive structure.

4.2.2. Design Patterns

A problem of the parameter approach is that variability is scattered and hard-wired in the source code, often in an undisciplined fashion. Consequently, many patterns have evolved on how variability can be separated and decoupled, among them many well-known design patterns for object-oriented programming, such as observer, template method, strategy, and decorator. The strengths and weaknesses of design patterns are presented in Table 12 [10].

Table 12: Strengths and weaknesses of implementing variability with design patterns [10]

Strengths Weaknesses o Well established, ease communication

between developers o Guidelines for disciplined design o First-class programming-language support o Different configurations within the same

program possible o Separate feature code from base code,

possibly with clear interfaces o Non-invasive extensions without modifying

the base code, given a preplanning effort

o Boilerplate code and architectural overhead o Preplanning of extension points necessary

4.2.3. Framework

A framework is an incomplete set of collaborating classes that can be extended and tailored for a specific use case. It represents a reusable base implementation for a related set of problems, and thus perfectly fits the needs of product line development. Frameworks, especially, black-box frameworks, are a suitable way to implement variability in product lines. Using typical plug-in loaders, individual products are created by composing plug-ins at load-time, but in principle run-time changes are possible [10].

Like the parameter approach, frameworks are language-based. However, frameworks differ from parameters in that they are primarily composition-based, not annotation-based, and in that variability is usually decided at load-time, not run-time. Table 13 summarizes the strengths and weaknesses of implementing variability with frameworks [10].

37

Table 13: Strengths and weaknesses of implementing variability with frameworks [10]

Strengths Weaknesses o Well-suited for implementing variability o Automated product derivation by plug-in

loading o Static tailoring, deploying only selected

features o Modularity by separating features, hiding

feature internals, and enabling feature traceability (especially in black-box frameworks)

o Suitable for open-world development (black-box frameworks only)

o Disciplined implementation, well-known

o High upfront design effort o Difficult evolution o Potential development, run-time, and size

overhead o No reuse outside the framework o Unsuited for fine-grained and crosscutting

features o No support for non-code artifacts

4.2.4. Components and services

Components and services (including web service) are a classic kind of language-based implementation approach. A class can be seen as a small component that can be reused in many applications; a library of graph algorithms is an example of a larger component, consisting of many classes. Services are a special form of software components. Services typically emphasize standardization, interoperability, and distribution. Especially in the popular form of web services, a service is reachable over a standardized Internet protocol and may run on remote servers [10].

Although component-based implementations are common in product line practice, they lack the automation potential of feature orientation. In contrast to plug-ins in frameworks, components are generally not designed to be composed automatically. In a component-based approach, there is no generator that would automatically build a product for a given feature selection; manual developer intervention is required. However, components can be integrated to some degree with other implementation approaches. Table 14 summarizes the strengths and weaknesses of implementing variability with components/services [10].

Table 14: Strengths and weaknesses of implementing variability with components/services [10]

Strengths Weaknesses o Well-known and established implementation

technique o Static tailoring, deploying selected features

only o Separation of concerns, information hiding,

and feature traceability o Reuse within and beyond the product line o Reuse of third-party implementations

o No automated product derivation, glue code is necessary

o Difficult evolution o Potential development, run-time, and size

overhead o Preplanning necessary to size components o Unsuited for fine-grained and crosscutting

features

38

Strengths Weaknesses o Reuse in distributed environments, even with

features maintained and run by third parties (especially services)

o Uniformly applicable to many languages

4.2.5. Version Control Systems

Version control systems are best known for tracking revisions of source code, that is, variation over time. Each revision gets an identifier and possibly a comment explaining the changes. Developers can go back in time to retrieve earlier revisions of the source code and investigate changes. Revisions are ordered and newer revisions supersede previous ones.

Since developers use version control systems routinely, it seems tempting to use the well-known branching and merging techniques and mature tools for feature variability. In contrast to language-based variability, branching can be used uniformly for code and non-code artifacts, and changes can be applied at arbitrary granularity (from removing directories to changing individual characters). Table 15 summarizes the strengths and weaknesses of implementing variability with version control systems [10].

Table 15: Strengths and weaknesses of implementing variability with version control systems [10]

Strengths Weaknesses o Well-known, established, and mature tools o External infrastructure o Arbitrary compile-time customization

independent of granularity and crosscutting o Uniform application to source code and non-

code artifacts o Only minor effort for preplanning

o Mixture of revisions and variants o Encourages development of variants, not

features. No feature traceability, no separation of feature code, and no information hiding

o No structured reuse (copy and edit of plain text)

o Relies on merging, prone to conflicts and errors

o Hard to maintain with many branches. Almost all practical tools are text based

4.2.6. Build Systems

A build system is responsible for scheduling and executing all build-related tasks, which may include running generators, compiling source code, running tests, and creating and copying deliverable units. With a build system, developers document and automate the build process. Especially in large projects, a build process is not trivial, since many different build tools (compilers, linkers, parser generators, testing frameworks, documentation generators) and dependencies (libraries, tools) are involved. As a build system can control which files are compiled and how, it is

39

natural to use it for variability at compile time. Typically, build systems use a parameter-based approach when they are executed at compile time. Table 16 summarizes the strengths and weaknesses of implementing variability with build systems [10].

Table 16: Strengths and weaknesses of implementing variability with build systems [10]

Strengths Weaknesses o Well-known and established tools o Suitable for conditional compilation at file

level o Orchestration of other variability mechanisms o Arbitrary compile-time customization o Uniform application to source code and non-

code artifacts o No extensive preplanning necessary

o Limitation to file-level variability and discouragement of systematic preplanning leads to code replication

o Largely unsuitable for feature-oriented programming at a fine grain

o No notion of modularity o Feature traceability at the file level only o Undisciplined and complex scripts can

become hard to maintain and analyse

4.2.7. Pre-processors

A pre-processor is a tool that manipulates source code before compilation. A popular pre-processor is the C pre-processor cpp, which is used in almost every C and C++ project. It provides directives to inline files, to define macros, and to remove code fragments based on user-defined conditions. In addition to cpp, many other pre-processors exist and are used for specific purposes. Most important for variation management, pre-processors typically provide facilities for conditional compilation, where marked code fragments in the source code are conditionally removed before compilation— #ifdef and #endif in cpp. Conditional compilation is probably the most common mechanism for implementing variability in industrial practice [10].

Pre-processors are controversial (Table 17). On the one hand, they are widely used in practice. On the other, numerous studies discuss the negative effect of pre-processor usage on code quality and maintainability [10].

Table 17: Strengths and weaknesses of implementing variability with pre-processors [10]

Strengths Weaknesses o Easy to use, well-known o Simple programming model: annotate and

conditionally remove o Compile-time customization of the source

code. No boilerplate code o Flexible and support of arbitrary granularity o Little preplanning required o Features usually traceable to (several) code

locations

o Scattering and tangling of feature code and configuration knowledge. No clear separation of concerns

o No support for information hiding o May obfuscate source code o Often used in ad hoc or undisciplined fashion o Prone to simple errors o Difficult to analyse and to write tool support

for the underlying language

40

Strengths Weaknesses o Lightweight mechanism for extractive product

line adoption o Uniform application to source code and non-

code artifacts

4.2.8. Feature-Oriented Programming

Feature-oriented programming (FOP) is a composition-based approach for building software product lines that relies directly on the notion of features. The idea is to decompose a system’s design and code into the features it provides. This way, the structure of a system aligns with its features, ideally, one module or component per feature. To this end, new language constructs are needed to express which parts of a program contribute to which features and to encapsulate the feature’s code in composable, modular units. Table 18 summarizes the strengths and weaknesses of implementing variability with FOP [10].

Table 18: Strengths and weaknesses of implementing variability with FOP [10]

Strengths Weaknesses o Easy to use language-based mechanism,

requires only minimal language extensions o Compile-time customization of source code

without run-time overhead o Separation of (possibly crosscutting) feature

code into distinct feature modules o Direct feature traceability from a feature to

its implementation in a feature module o Conceptually uniformly applicable to code

and non-code artifacts, tools already cover many languages

o Little preplanning required due to mixing-based extension mechanism

o Requires adoption of a language extension or unfamiliar composition tools as part of the development process

o Granularity at the level of methods (or other named structural entities)

o Composition is syntax-directed and does not offer enforced interfaces between feature modules

o Tools need to be constructed for every language, but these may be generated

o Only academic tools so far, little experience in practice

4.2.9. Aspect-Oriented Programming

Aspect-oriented programming (AOP) aims at the modularization of crosscutting concerns. During the discussion of FOP in [10], they have already considered a kind of crosscutting concern: A collaboration extends a program at different places, thus it cuts across the module boundaries introduced by classes. While FOP has been developed as a feature implementation (collaboration implementation) technique, AOP targets crosscutting concerns from a different perspective: AOP aims at reducing code scattering, tangling, and replication induced by crosscutting concerns that are not well-separated [10].

41

AOP is a language-based and composition-based approach for product-line implementation, where selected aspects and classes are woven to form the desired product. Different weaving technologies support different binding times including compile-time binding (such in AspectJ) and load-time binding. Table 19 summarizes the strengths and weaknesses of implementing variability with AOP [10].

Table 19: Strengths and weaknesses of implementing variability with AOP [10]

Strengths Weaknesses o Compile-time variability without run-time

overhead; load-time variability possible as well

o Separation of (possibly crosscutting) feature code into distinct aspects

o Direct feature traceability from feature to its implementation in an aspect

o Fine granularity based on events during the program execution, depending on the join point model

o Little or no preplanning effort required

o Requires adoption of a sophisticated language extension, including a novel programming paradigm

o Different aspect-oriented extensions for different code and non-code languages, only experimental uniform models so far

o Composition is syntax-directed and does not offer enforced interfaces between feature modules

o Though conceptually uniform, tools need to be constructed for every language

o Only academic tools so far, little application in practice

4.2.10. Virtual separation of concerns

Virtual separation of concerns (VSC) is a tool-based approach for product line development. Based on a combination of tracing information, visualization facilities, source-code views, and the integration of feature models, code that belongs to individual features can be displayed, edited, and understood in separation. For example, one can view the code only of a certain feature or feature combination, whereas the remaining code is hidden. Additionally, a developer can get a view on the combined code of multiple features (thus seeing the interacting code fragments in place), which is not easily possible in language-based approaches [10].

According to Apel et al. [10], VSC is an improvement over the limitations of classic tool-driven approaches and it is a full-fledged alternative to advanced, language-based approaches. Compared to advanced language-based approaches, virtual separation of concerns provides a simpler underlying mechanism based on annotations. It remains limited regarding information hiding, but excels, especially, at fine-grained extensions, where composition-based approaches are limited. Table 20 summarizes the strengths and weaknesses of implementing variability with VSC.

42

Table 20: Strengths and weaknesses of implementing variability with VSC [10]

Strengths Weaknesses o Simple programming model: annotate and

conditionally remove o Structured tracing of features o Compile-time customization of source code;

no boilerplate code o Flexible and support of arbitrary granularity o Little preplanning required o Virtual separation of concerns, despite

physical scattering and tangling of feature code

o Lightweight mechanism for extractive product-line adoption

o Uniform application to source code and non-code artifacts

o Easy to use and analyse

o No support for information hiding o Mostly academic tools so far, little experience

in practice o Many fined-grained and interleaved

annotation hinder program comprehension

4.3. Approach for Variability Management across Lifecycle Stages

Schmid and John [18] presented an approach that enables homogenous variability management across the different lifecycle stages, independent of the specific notation. The approach in [18] distinguishes among variation points, i.e. the “points” in a generic artefact where variation occur, the specific possible instantiations, and the logic for selecting among the instantiations. The latter is called a selector.

The following types of variability selectors are considered relevant in [18]: • Optionality: A property either exists in a product or not. • Alternative: Two possible resolutions for the variability exist and for a specific product only

one of them can be chosen. • Set alternative: Only a single instance may be selected out of a range of possible

alternatives. • Set selection: Several variabilities may be simultaneously selected for inclusion in a product. • Value reference: The value of the decision variable can be directly included in the product

line model. This, of course, only makes sense with decision variables that only assume a single value in application engineering.

The concepts discussed so far are representation independent. In order to represent variation points in diverse software engineering artifacts (domain model, code, etc.), which employ a specific representation technique, it is necessary to map the different types of variability selectors to the target notation [18]. In order to derive a context-specific representation of variability mechanisms, their approach perform the following steps:

43

1. Determine the required level of granularity Prior to determining a specific approach to variability representation, it is necessary to identify

the kind of structures in the target notation, which we need to make variable. This particularly implies to identify the granularity of constructs that can be variable.

2. Identify approach for representing variability selectors In order to represent variability based on existing representation formalism, we must extend it in

a homogenous way, so that the variability representation is well integrated. This requires a basic approach that is well compatible with the underlying notation. In particular, for formally defined representation formalisms, this requires an extension of their underlying meta-model. The most simple extension is possible in the context of text-based representations.

3. Determine supported selector types In spite of the fact that there are different types of selector, in the context of a specific modelling

situation, only a subset of these types is usually necessary.

4. Map selector types to target notation The next step is to identify a notation for each of the identified selectors. This is already mainly

determined by the decisions that have been made in the previous steps. For example, in the case of a text-based notation, one must determine a specific keyword for the different selectors and one must define the specific notation for selecting individual alternatives.

5. Analyse for special representation mechanisms Finally, there might be some special notational elements that do particularly apply in the context

of the target notation. An example can be the optional variant decision.

Schmid and John [18] applied their variability management approach in a case study with an embedded systems company to capture variability in text-based requirements. They decided to use textual constructs framed with “<<” “>>” and they introduced a keyword for each of the selected selector types. Figure 8 shows an excerpt of a product line model document, which includes optional, alternative, and value variability.

Figure 8: An example using the textual notation

44

5. VM Strategy This chapter is concerned with providing the guidelines for dealing with variability in the

RESCUER project. It decides on the variability modelling approach to be used in the project and provides recommendations regarding the most suitable realization techniques for the already identified variabilities. The RESCUER variability model is also presented in this chapter, as it is crucial to base the recommendations about the most suitable realization techniques. Furthermore, this chapter provides guidelines for capturing variability in the project’s requirements specification and system architecture.

5.1. Variability Modelling Approach

Section 4.1 presented different approaches for variability modelling and discussed their strengths and weaknesses. Feature modes and its particular representation using feature diagrams is the approach selected to be used in the RESCUER project for several reasons:

• Feature diagrams support the elicitation and understanding of commonalities and variabilities with customers and/or end-users [9]. Dependencies are better visualized in feature diagrams, especially if constraints (dependencies beyond the parent relationship) are included.

• There is free software for feature modelling. • Feature diagrams can be used for modelling variability and for supporting the specification of

product variants [13]. The selection of features for a product variant can be translated into propositions and formally verified against the feature model [26].

• Several authors have proposed complementary models to the feature model in order to capture the relationships between features and the other development artifacts [11].

• Feature models are the most popular form of variability models. There is a trend towards feature-oriented software product lines engineering that can be observed in [10] and [11], for example.

• Feature diagrams are the most familiar approach for the RESCUER stakeholders and partners.

5.2. RESCUER Variability Model

This section presents the current status of the RESCUER variability model, which is represented with feature diagrams. The first diagram (Figure 9) provides an overview of the main features of the RESCUER platform as well as the classifiers of its context, as proposed in Subsection 4.1.4. The context classifiers are described in Table 21. The feature diagrams for the Mobile Crowdsourcing Solution, Emergency Response Toolkit, and Data Analysis Solutions are provided in Figure 10, Figure 11, and Figure 12, respectively, whereas their respective feature specifications are provided in Table

45

22, Table 23, and Table 24. Figure 13 provides the feature diagram for the remaining RESCUER features, while Table 25 contains the respective feature specifications.

Figure 9: RESCUER platform overview (Iteration 2)

46

Table 21: Feature specification of the RESCUER context (Iteration 2)

Feature ID

Feature Name Feature Type

Feature Description Binding Time

C1 Geographic Region Structure It captures the geographic region where the RESCUER platform will be installed. Mandatory C1.1 Geographic Region:

Europe Context Classifier

The RESCUER platform might be installed in Europe. Platform Installation

C1.2 Geographic Region: Brazil

Context Classifier

The RESCUER platform might be installed in Brazil. Platform Installation

C2 Application Scenario Structure It captures the scenario which the RESCUER platform will be applied to, so that it can be used to handle emergencies and manage crises in this scenario.

Mandatory

C2.1 Application Scenario: Industrial Area

Context Classifier

The RESCUER platform might be applied to handle emergencies and manage crises in the scenario of incidents in industrial areas.

Platform Installation

C2.2 Application Scenario: Large-Scale Event

Context Classifier

The RESCUER platform might be applied to handle emergencies and manage crises in the scenario of incidents in large-scale events.

Platform Installation

C3 Mobile Device Structure Group of features regarding the mobile device profile that influence the Mobile Crowdsourcing Solution.

App Installation

C3.1 Mobile Device: Screen Size

Context Classifier

It captures the size of the mobile device screen. It is a variability defined in terms of a value reference.

Same as Parent Feature

C3.2 Mobile Device: Screen Resolution

Context Classifier

It captures the resolution of the mobile device screen. It is a variability defined in terms of a value reference.


C3.4 Mobile Device: Operating System

Structure It captures the operating system on which the Mobile Crowdsourcing Solution should be capable of running on.


C3.4.1 Mobile Device: Google_Android

Context Classifier

It indicates that the operating system of a specific mobile device is Android. App Installation

C3.4.2 Mobile Device: Apple_iOS

Context Classifier

It indicates that the operating system of a specific mobile device is IOS. App Installation

47

Feature ID

Feature Name Feature Type

Feature Description Binding Time

C3.5 Mobile Device: GPS Structure It captures whether GPS is active or not at runtime. Same as Parent Feature

C3.5.1 Mobile Device: Active GPS

Context Classifier

It indicates that GPS is active in a specific mobile device running the Mobile Crowdsourcing Solution.

Runtime

C3.5.2 Mobile Device: Inactive GPS

Context Classifier

It indicates that GPS is not active in a specific mobile device running the Mobile Crowdsourcing Solution.

Runtime

C3.6 Mobile Device: Position Service

Structure It captures the runtime status of the position service of the mobile device. This service collects position information from multiple sources (GPS, Wifi, etc.).


C3.6.1 Mobile Device: Available Position Service

Context Classifier

It indicates that the position service can deliver the position of a specific mobile device.

Runtime

C3.6.2 Mobile Device: Unavailable Position Service

Context Classifier

It indicates that the position service cannot deliver the position of a specific mobile device.

Runtime

48

Figure 10: Feature model of the Mobile Crowdsourcing Solution (Iteration 2) 49

Table 22: Feature specification of the Mobile Crowdsourcing Solution (Iteration 2)

Feature ID Feature Name Feature Type Feature Description Binding Time Requires/ Excludes

F1 Mobile Crowdsourcing

Structure It represents the Mobile Crowdsourcing Solution component. Mandatory

F1.1 Information Gathering

Structure Grouping of features concerned with the gathering of information from people at the place of an incident (unidirectional communication).


F1.1.1 Sensor Data Gathering

Service Gathering of data without user interaction, by automatically collecting them from mobile device sensors.

App Installation

F1.1.1.1 Sensing Modus Domain Technology

Operating modus for sensor data gathering. For monitoring of crowd behaviour, it has to be continuous. For annotation of user generated contents, the discrete modus is enough.


F1.1.1.1.1 Sensing Modus: Discrete

Domain Technology

Gathering of sensor data at a certain time (discrete time). Runtime

F1.1.1.1.2 Sensing Modus: Continuous

Domain Technology

Gathering of sensor data within a certain timeframe. It correspondents to the sensor data monitoring (continuous time).

Runtime

F1.1.1.2 Direct Sensing Operation Group of features concerned with the gathering of raw sensor data, which means data that are directly extracted from sensors.


F1.1.1.2.1 Direct Sensing: Position

Environment Technology

Description in Table 4, SF2.1. Ideally it should include the precision of the position service.

Runtime Requires C3.6.1

F1.1.1.2.2 Direct Sensing: Movement Speed


Description in Table 4, SF2.2. Runtime Requires C3.5.1

50


F1.1.1.2.3 Direct Sensing: Movement Direction


Description in Table 4, SF2.3. Runtime Requires C3.5.1

F1.1.1.2.5 Direct Sensing: Device Acceleration


Gathering of data from the accelerometer. Same as Parent Feature

F1.1.1.2.6 Direct Sensing: Gyroscope Orientation


Gathering of data from the gyroscope. Same as Parent Feature

F1.1.1.2.7 Direct Sensing: Compass Orientation


Gathering of data from the compass. Same as Parent Feature

F1.1.1.2.8 Direct Sensing: Display Orientation


Gathering of display orientation data. Same as Parent Feature

F1.1.1.5 Sensor Data Streaming

Operation Sensor data streaming with the purpose of crowdsensing. Runtime Requires F1.1.1.1.2

F1.1.2 User Generated Data Gathering

Service It follows the three steps of the RESCUER information gathering strategy explained in Section 3.4, which means it jointly addresses SF5.1 and SF6.1.x from Table 4.


F1.1.2.2 User Generated Data Source

Structure Group of features that indicate the level of detail of the user generated data, taking into consideration the user profile (workforce, supporting force or civilian).


F1.1.2.2.1 User Generated Data Source: Crowd

Domain Technology

Description in Table 4, SF6.1.1. App Installation Requires F5.2.4

F1.1.2.2.2 User Generated Data Source: Expert

Domain Technology

Description in Table 4, SF6.1.2. App Installation Requires F5.2.1 or F5.2.5

51


F1.1.5 Report Type Structure Group of features that indicate the set of information to be provided when reporting a certain type of incident.


F1.1.5.1 Report Type: Fire Domain Technology

It defines the set of specific information to be provided when reporting fire.

Runtime

F1.1.5.2 Report Type: Explosion

Domain Technology

It defines the set of specific information to be provided when reporting explosion.

Runtime

F1.1.5.3 Report Type: Gas Leakage

Domain Technology

Description in Table 4, SF6.2.1. Runtime Requires C2.1

F1.1.5.4 Report Type: Environmental Incident

Domain Technology

Description in Table 4, SF6.2.5. Runtime Requires C2.1

F1.1.3 Multimedia Attachment

Operation Description in Table 4, SF7. Same as Parent Feature

F1.1.1.4 Sensor Data Annotation

Operation Annotation of content explicitly generated by the user with sensor data collected from his/her mobile device.

App Installation Requires F1.1.1

F1.1.4 Soft Data Annotation Operation Annotation of sensor data or content explicitly generated by the user with device ID and timestamp.


F1.1.6 Follow-up Request Answering

Service Group of features that provide alternatives for answering follow-up requests.

Runtime Requires F2.4

F1.1.6.1 Follow-up Request Answering: Open Answer

Follow-up answering form that contains a question to be answered with free text (open answer). It should be used for answering open questions or catalogue questions that do not have pre-defined answer options.

52


F1.1.6.2 Follow-up Request Answering: Closed Answer

Follow-up answering form that contains a set of questions to be answered by selecting the provided options (closed answer). It should be used for answering catalogue questions for which answer options have been pre-defined.

Requires F8

53

Figure 11: Feature model of the Emergency Response Toolkit (Iteration 2)

54

Table 23: Feature specification of the Emergency Response Toolkit (Iteration 2)


F2 Emergency Response Toolkit

Structure It represents the Emergency Response Toolkit component. Ideally should support highlighting of contents manually and/or automatically.

Mandatory

F2.1 Emergency Mapping Service Group of features that provide static or dynamic information about the emergency situation over a map of the area.


F2.1.1 Area Map Operation Display of the area map. Same as Parent Feature

F2.1.5 Crowd Behaviour Operation Description in Table 4, SF13.4. Platform Configuration

Requires F3.1.1

F2.1.2 Incident Location Operation Description in Table 4, SF13.1. Same as Parent Feature

F2.1.6 Crowdsourcing Information

Operation Description in Table 4, SF13.5. Same as Parent Feature

F2.1.9 Enriched Map View Operation Display of information drawn by the user over a map of the area using the attached labels for selection of the view.

Platform Configuration

Requires F2.1.8

F2.1.10 Placement Of Forces Operation Group of features that provide the position of members of different forces over a map of the area.


F2.1.10.1 Placement Of Workforces

Domain Technology

Description in Table 5, SF17.1 Same as Parent Feature

F2.1.10.2 Placement Of Supporting Forces

Domain Technology

Description in Table 5, SF17.2 Platform Configuration

F2.1.7 Free drawing Service Description in Table 4, SF13.6. Platform Configuration

55


F2.1.8 User Based Map Enrichment

Service Association of labels to drawings made by the user over a map of the area.


Requires F2.1.7

F2.1.8.1 User Based Map Enrichment: Approach Routes

Operation Use of the label “Approach Routes” Platform Configuration

F2.1.8.2 User Based Map Enrichment: Evacuation Routes

Operation Use of the label “Evacuation Routes” Platform Configuration

F2.1.4 User Based Map Enrichment: Safety Areas

Operation Use of the label “Safety Areas” Same as Parent Feature

F2.1.3 User Based Map Enrichment: Places of Concern

Operation Use of the label “Places of Concerns” Platform Configuration

F2.2 Emergency Dashboard

Service It summarizes key information about the overall emergency situation, the reported incidents, and the affected people. It includes incident counting, counting of affected people (injured, dead, trapped), and potential impact of the emergency situation on the surroundings and on the environment. It should provide summarized report information on demand.


F2.2.1 Classification of Severity

Operation It presents the classification of the severity of the emergency situation.


Requires C2.1 (see Section 3.2)

56


F2.3 Emergency Browser Service Browser of contents generated by the users of the Mobile Crowdsourcing Solution. It offers filtering capabilities.


F2.3.1 Incident Browser Domain Technology

Browser that lists the incidents clustered by the Emergency Response Toolkit.


F2.3.1.1 Incident Merging Operation Possibility of the user of the Emergency Response Toolkit to merge incidents.

Platform configuration

F2.3.2 Report Browser Domain Technology

Browser that list the raw reports sent by the users of the Mobile Crowdsourcing Solution.


F2.4 Follow-up Request Service Follow-up interaction triggered by the command centre. Platform Configuration

F2.4.1 Follow-up Request Formulation

Operation Formulation of the follow-up request by the command centre.


F2.4.1.1 Follow-up Request Formulation: Catalogue Question

Domain Technology

Request of information using questions from a catalogue. Runtime Requires F8

F2.4.1.2 Follow-up Request Formulation: Open Question

Domain Technology

Request of information using open question, which means a free-text question that can only be answered with free-text.

Runtime

F2.4.2 Target Group Criteria Operation Definition of the criteria for determining the people who should receive the request of follow-up interaction.


F2.4.2.1 Profile Based Structure Usage of user profile as criteria for defining the target group of a request of information.

F2.4.2.1.1 Workforce Target Domain Technology

It is related to SF16.3 in Table 5. Same as Parent Feature

57


F2.4.2.1.2 Supporting Force Target

Domain Technology

It is related to SF16.2 in Table 5. Platform configuration

F2.4.2.1.3 Civilian Target Domain Technology

It is related to SF16.1 in Table 5. Platform configuration

Requires F2.4.2.4 or F2.4.2.5

F2.4.2.2 Role Based Domain Technology

Usage of emergency management role(s) as criteria for defining the target group of a request of information. Ex: evacuation coordinators, emergency brigade leader, etc.


F2.4.2.3 Location Based Implementation Technique

Usage of location as criteria for defining the target group of a request of information.


F2.4.2.4 Movement Based Implementation Technique

Usage of the fact that people are moving or not as criteria for defining the target group of a request of information.


F2.4.2.5 Previous Interaction Based

Implementation Technique

Usage of the fact that people have already interacted with the Mobile Crowdsourcing Solution as criteria for defining the target group of a request of information.


F2.4.2.6 Affiliation Based Implementation Technique

Usage of the affiliation of the employees, which means the company in which they work, as criteria for defining the target group of a request of information.


Requires F5.2.2

F2.5 Coordination Structure Coordination represents the request and monitoring of something. Ideally it should include request, status monitoring and graphical overview.


F2.5.1 Resource Coordination

Service The subject of the coordination is resources. It mainly refers to SF24.3 in Table 5.


58


F2.5.2 Task Coordination Service The subject of the coordination is tasks. It mainly refers to SF23.3 in Table 5.


F2.2.4 Weather Conditions Service It presents information about the weather at the place of incident, as e.g. temperature and wind speed. It should include information that allows the estimate of air pressure.


Requires F6.1

Figure 12: Feature model for data processing (It includes Data Analysis Solutions.) 59

Table 24: Feature specification for data processing (It includes Data Analysis Solutions.)


F3 Data Processing Structure It includes the Data Analysis Solutions component, but it will probably go beyond it in the next project iteration.


F3.3 Incident Clustering Operation Feature that clusters incident reports based on time, keyword, and location.


F3.4 Data Analysis Structure Group of features that represent the Data Analysis Solutions provided by the RESCUER platform.


F3.4.1 Analysis Aspect Structure Group of features that represent the several aspects of an incident that can be analysed.


F3.1.1 Crowd Aspect Structure Group of features that gives the crowd behaviour aspects that the RESCUER platform should be able to analyse.


F3.1.1.1 Crowd Density Service Description in Table 4, SF10. Platform Configuration


F3.1.1.2 Crowd Turbulence Service Description in Table 4, SF11. Platform Configuration


F3.1.1.3 Crowd Pressure Service Description in Table 4, SF12. Platform Configuration

Requires F3.1.2.1

F3.4.1.1 W Questions Aspect Service Description in Table 5, SF35. Platform Configuration

Requires F3.1.2.3 or F3.1.2.4 or F3.1.2.2

60


F3.2 Fire/Smoke Expansion Aspect

Service Description in Table 5, SF36. Platform Configuration

Requires F3.1.2.2

F3.1.2 Analysis Technology Structure Group of features that gives the technologies used to analyse the several aspects of an incident.


F3.1.2.1 Device Based Analysis

Domain Technology Crowd behaviour threat analysis based on the number of smart phones or other mobile devices in the area of interest.


Requires F1.1.1.2.1, F1.1.1.2.2, and F1.1.1.2.3

F3.1.2.3 Text Based Analysis Domain Technology Analysis of free texts provided as part of incident reports and follow-up answers.


F3.1.2.3.1 English Text Analysis Domain Technology Analysis of texts in English. Platform Configuration

F3.1.2.3.2 Portuguese Text Analysis

Domain Technology Analysis of texts in Portuguese. Platform Configuration

F3.1.2.4 Image Based Analysis Domain Technology Analysis of the images sent by the users of the Mobile Crowdsourcing Solution.


Requires F1.1.1.4

F3.1.2.2 Video Based Analysis Domain Technology Analysis of the videos sent by users of the Mobile Crowdsourcing Solution.


Requires F1.1.1.4

61

Figure 13: Feature model for the support infrastructure

62

Table 25: Feature specification for the support infrastructure


F8 Incident Question Catalogue

Service It provides a set of pre-defined questions to be used to request relevant information in incident reports or follow-up interactions. Questions to be used in follow-up interactions might have open answer.


F5 User Registration Service It requests registration information that will set up the registration scope, the user profile, and the user language.


F5.1 User Language Implementation Technique

Language to be used in the interface of the platform components. This information will be directly obtained from the operating system of the mobile device for the users of the Mobile Crowdsourcing Solution.

For mobile RESCUER users

F5.1.1 Portuguese Option The language for the user interface is Portuguese. App Installation F5.1.2 German Option The language for the user interface is German. App Installation F5.1.3 English Option The language for the user interface is English. App Installation F5.2 User Profile Operation It specifies the person profile when in emergency

situations in the application scenario. The need for different user profiles or roles in the registration scope of the ERTK has not been investigated yet.


F5.2.1 Workforce Domain Technology Description in Table 4, SF14.1. App Installation F5.2.5 Supporting Force Domain Technology Description in Table 4, SF14.5. App Installation Excludes F5.3.2 F5.2.3 Volunteer Domain Technology Description in Table 4, SF14.3. App Installation F5.2.4 Civilian Domain Technology Description in Table 4, SF14.4. App Installation Excludes F5.3.2 F5.2.2 Employee Domain Technology Description in Table 4, SF14.2. App Installation

63


F5.3 Registration Scope Operation It defines the scope of the registration. Same as Parent Feature

F5.3.1 Mobile Option Registration for using the Mobile Crowdsourcing Solution. It is done when installing the application.

Runtime

F5.3.2 ERTK Option Registration for using the Emergency Response Toolkit. Runtime Excludes F5.2.4 and F5.2.5

F6 External Services Structure Group of features to access external services. Same as Parent Feature

F6.1 Weather Service Service It obtains from external services information about the weather conditions.


F6.2 Map Service Service It obtains from external services the map of the area of interest.


F7. Quality Mechanisms

Structure Group of features concerned with quality mechanisms. Same as Parent Feature

F7.1 Integration 2 Upper Level App

Service Description in Table 4, SF8. Platform Configuration (LE in Table 3)

F7.2 Incident Log Concrete / Service Log of all actions executed in the RESCUER platform with regards to a certain emergency situation.


F3.4 Reliability Indicator Operation Feature that cluster incident notification or reports based on time, keyword, and location.


F4.1.2 Adhoc Communication

Domain Technology Network connection to be used in case of overloaded internet connection.


64

5.3. Recommendations Regarding Variability Realization Techniques

As presented in Section 4.2, there are many variability realization techniques and the most suitable technique for a specific variability depends on several aspects, such as binding time, developers’ experience, and learning curve. Table 26, Table 27, Table 28, and Table 29 indicate proper variability realization techniques for the variable features described in Section 5.2. In the recommendations provided in this section, child features should follow the same variability realization technique of their parent features. In general, the adopted rationale was:

• For features with platform configuration binding time, the techniques can be parameters and version control.

• For features with binding time at app installation, recommended techniques are parameters and design patterns.

• For features with runtime binding time, we would expect the use of parameters and design patterns or services.

Table 26: Realization techniques for the Mobile Crowdsourcing Solution features (Iteration 2)

Feature ID Variability Technique F1.1.1.1 Sensing Modus

• F1.1.1.1.1 Discrete • F1.1.1.1.2 Continuous

Parameters, design patterns

F1.1.1.2 Direct Sensing • F1.1.1.2.1 Position • F1.1.1.2.2 Movement Speed • F1.1.1.2.3 Movement Direction

Parameters, design patterns, services

F1.1.1.5 Sensor Data Streaming Parameters, design patterns, services

F1.1.2.2 User Generated Data Source • F1.1.2.2.1 Crowd • F1.1.2.2.2 Expert

Parameters, version control

F1.1.5 Report Type • F1.1.5.1 Fire • F1.1.5.2 Explosion • F1.1.5.3 Gas Leakage • F1.1.5.4 Environmental Incident


F1.1.1.4 Sensor Data Annotation Parameters, version control F1.1.6 Follow-up Request Answering

• F1.1.6.1 Open Answer • F1.1.6.2 Closed Answer


65

Table 27: Realization techniques for the Emergency Response Toolkit features (Iteration 2)

Feature ID Variability Technique F2.1.5 Crowd Behaviour Parameters, version control F2.1.9 Enriched Map View Parameters, version control F2.1.10.2 Placement Of Supporting Forces Parameters, version control F2.1.7 Free Drawing Parameters, version control F2.1.8 User Based Map Enrichment

• F2.1.8.1 Approach Routes • F2.1.8.2 Evacuation Routes • F2.1.3 Places of Concern


F2.2.1 Classification of Severity Parameters, version control F2.3 Emergency Browser

• F2.3.1 Incident Browser • F2.3.2 Report Browser


F2.4.1 Follow-up Request Formulation • F2.4.1.1 Catalogue Question • F2.4.1.2 Open Question


F2.4.2 Target Group Criteria • F2.4.2.1 Profile Based • F2.4.2.2 Role Based • F2.4.2.3 Location Based • F2.4.2.4 Movement Based • F2.4.2.5 Previous Interaction Based • F2.4.2.6 Affiliation Based


F2.5 Coordination Parameters, version control F2.2.4 Weather Conditions Parameters, version control

Table 28: Realization techniques for data processing (It includes Data Analysis Solutions.)

Feature ID Variability Technique F3.4.1 Analysis Aspect

• F3.1.1 Crowd Aspect • F3.4.1.1 W Questions Aspect • F3.2 Fire Smoke Expansion Aspect


F3.1.1 Crowd Aspect • F3.1.1.1 Crowd Density • F3.1.1.2 Crowd Turbulence • F3.1.1.3 Crowd Pressure

Parameters, services

F3.1.2 Analysis Technology • F3.1.2.1 Device Based Analysis • F3.1.2.3 Text Based Analysis • F3.1.2.4 Image Based Analysis • F3.1.2.2 Video Based Analysis


66

Table 29: Realization techniques for the support infrastructure features

Feature ID Variability Technique F5.1 User Language

• F5.1.1 Portuguese • F5.1.2 German • F5.1.3 English


F5.2 User Profile • F5.2.1 Workforce • F5.2.5 Supporting Force • F5.2.4 Civilian


F5.3 Registration Scope • F5.3.1 Mobile • F5.3.2 ERTK

Services in different platforms

F6.1 Weather Service Pre-processors, Version control

F7.1 Integration 2 Upper Level App Pre-processors, Version control

F4.1.2 Ad-hoc Communication Parameters, version control In any case, the development team should make the final decision on which techniques to use

taking into consideration their experience and the fact that the chosen techniques must not violate architectures decisions. In fact, they should support the architectures decisions. For example, the team can decide to use services rather than design patterns, in order to have a good coupling and interoperability.

For instance, during the development of the Mobile Crowdsourcing Solution, the developers underwent the decision making process of how variability should be realized. In order to provide multiple-language support, they adopted a combination of parameterization and configuration files, since it allows registering product configuration within files in a dynamic way. For multi-language support, every time the user selects his/her preferred language, the configuration file is changed with the respective parameter value of such language. This concrete example highlights the importance of analysing which realization technique is suitable for a specific scenario and adapting the provided recommendations when necessary, since they are not ultimate statements for choosing realization techniques.

67

5.4. Recommendations for Capturing Variability in Requirements Specification and System Architecture

The specification approach for capturing variability in the RESCUER project followed the approach described in Section 4.3. This approach is neither expected to be used nor read by people with background in variability management. Therefore, the goal was to define a specification approach for variation management that is easy to learn and use, but also easy to read and understand. It should address variability in requirements (free text and use case diagrams) and in architecture.

We adopted for the textual representation and for the graphical representation the following selectors:

• Optional: a property either exists in a context or not • Alternative: two or more possible resolutions for the variability exist and for a specific

context only one of them can be chosen; • Multiple selection: several variants may be simultaneously selected for inclusion in a context; • Value reference: the value of a variable can be directly included in the application context.

5.4.1. Textual Representation

For the textual representation of the variability selectors, we chose the representation presented in Figure 14. This representation can be used in any textual specification of the RESCUER project (e.g. deliverables of Task 1.1 and Task 1.2) according the guidelines provided in this subsection3.

Figure 14: Illustration example of variation point and variants [27]

Optional selectors should be represented by a two-column frame with just one row. The first column identifies the property that can be included or not and it should be preceded by an “Opt:” tag. The second column describes the property itself. One example with “Community volunteer”, a

3 All examples in this subsection are intended to illustrate the usage of the templates and not to be real examples of variation in the requirements specification of the RESCUER project.

68

user sub-profile that is only relevant to Brazilian industrial areas, is provided below to show how to include optional contents in a requirements text.

Template

Opt: [Variant name] [Variant description]

Example

Opt: User Registration for Community volunteer

The user registration for community volunteer requests from the user the indication of the community which s/he belongs to.

Alternative selectors are represented in a two-column frame with multiple rows (at least three rows in total). As presented in the template below, possible variants are identified in the light grey cells and described in the white cells. The variation point name is preceded by an “Alt:” tag and is also described. The example below indicates that specific emergency handling procedures are applied in industrial areas and large-scale events.

Template

Alt: [Variation point name] [Variation point description]

[Variant name] [Variant description] [Variant name] [Variant description]

Example

Alt: Emergency Handling Procedure

The emergency handling procedures are different in industrial area and large-scale event.

Industrial Area Describe here the specific procedures for industrial areas Large Event Describe here the Specific procedures for large-scale events

A two-column frame with multiple row (at least three rows in total) can also be used to represent the multiple selection selectors (see template below). As expected, the guidelines are the same as for alternative selectors, but the variation point name is preceded by a “Mult:” tag. The example below describes possible types of incident reports in RESCUER. Each instance of the RESCUER platform can support a different set of incidents.

69

Template

Mult: [Variation point name] [Variation point description]

[Variant name] [Variant description] [Variant name] [Variant description]

[Variant name] [Variant description]

Example

Mult: Incident Report The RESCUER system should provide incident report templates for one or more types of incidents.

Gas Leakage Gas leakage in an industrial park.

Fire Fire resulting from explosions or other triggers in industrial areas or large-scale events.

Flooding Flooding close to industrial areas.

Value reference selectors are applied to the description of a behaviour that vary depending on the value assigned to a parameter. The template below shows how it should be represented. The variation point name is preceded by a “Val:” tag.

Template

[Text], followed by Val: [Variation point name], followed by [more text], if necessary.

Example

Chat-like information gathering should only be allowed when the person is Val: DistanceEpicentre km distant from the epicentre of the incident place.

Finally, the textual representation for the case that an entire section is used to describe a variant should be:

Template

[Section name] ([selector tag] [Variation point name]→[Variant name])

Example

2.1 Incident Report (Mult: Information Gathering Step→Guided Information Gathering)

70

5.4.2. Graphical Representation for Variant Use Cases

For the graphical representation of the variability selectors in use case diagrams, we chose the following annotations. Both use cases and actors can be made variable. The value reference selector was considered not relevant to this graphical representation.

• Variants are annotated with the <<variant>> stereotype; • Variation points are marked with their respective types and names:

o Optional: <<Opt:variation point name>> o Alternative: <<Olt:variation point name>> o Multiple selection: <<Mult:variation point name>>

Figure 15 illustrates the graphical representation of optional variation points, which in this case involves three variant use cases and one variant actor.

Figure 15: Optional use cases

Figure 16 illustrates the graphical representation of alternative variation points, whereas Figure 17 illustrates the graphical representation of multiple selection variation points.

71

Figure 16: Alternative use cases

Figure 17: Multiple selection use cases

72

5.4.3. Graphical Representation for Variant System Architecture Perspectives

Similar to use case diagrams, component diagrams can also capture variability. The constructors or structures of interest are components and interfaces. The notation to be used to capture variability is the same as the one used for use case diagrams, but it is relevant to point out that interaction among variant components must be represented (as shown in Figure 20).

Figure 18, Figure 19, and Figure 20 provide examples of the graphical representation of the three different types of variation points that are relevant in components diagrams.

Figure 18: Optional components

Figure 19: Alternative components

73

Figure 20: Multiple selection components

74

PART III: Portability

6. Overview on Mobile Applications Development

6.1. Diversity of Mobile Devices

Since the introduction of the iPhone in 2007, the term “Smart Device” has become more and more evident. Smart devices are small, mobile computers usually consisting of touchscreens and cameras. They are connected to the GSM-network and the internet to enable speech and data communication. In addition, they are equipped with several environmental sensors like gyroscope, GPS, temperature, NFC, among others. Smart devices include smartphones and tablets, mini-tablets, as well as phablets (smartphones with display size between 5 and 7 inch). Nowadays smart watches and glasses are also included in this category. Key features of smart devices are:

• Mobility (battery-powered, always available), • Network connection (speech as well as data), • Intelligence (through embedded sensors), • Extendible (through Apps), • Operable (via touchscreen, gestures, and/or speech), • Localizable (e.g., through sensors).

The device characteristics need to be considered when deciding for a certain device or a set of devices to run an application. The more diversity factors need to be considered when developing the application, the larger is the effort to be spent developing and testing it. For example, to support smartphones and tablets the graphical user interface (GUI) must be adapted to the hardware (screen size and resolution) as well as tests need to be performed on each of those devices.

In order to better distinguish and evaluate the characteristics of smart devices, they can be divided into categories (Table 30). In each device category there are several types of devices taking into consideration screen size and resolution. Table 30 presents screen sizes and resolutions that are common nowadays.

In addition, the following performance characteristics need to be considered when making decisions about the suitable hardware:

• CPU performance, • RAM, • Flash memory (internal, external), • Battery capacity, • Size and weight.

75

Table 30: Different mobile device categories

Category Screen size Screen resolution (approx.)

Smartphones 3‘‘ – 5‘‘ 960 x 540

to Full HD 1920 × 1080

Phablets 5“-7“ 960 x 540

to Full HD 1920 × 1080

Mini-Tablets 7‘‘ – 8‘‘ 1.280 x 800

to 2560 x 1600

Tablets 10‘‘

1.280 x 720 to

Full HD 1920 × 1080 to

Quad HD 3840 × 2160

Each of the aforementioned device categories has advantages and disadvantages. Smartphones

have in contrast to tablets smaller screen sizes and lower screen resolutions. Due to the form factor they have smaller batteries, which results in less running time. Tablets have a larger screen and a higher resolution, but also a bigger form factor. However, smartphones and tablets have similar hardware (CPU, RAM, flash memory, GPS, gyroscope, compass, among others.). Thus, the distinction among devices needs to be established based only on the screen size and resolution.

6.2. Diversity of Mobile Platforms

There exist several mobile platforms and development techniques. According to IDC, the three main mobile operating systems are Android (79.3%), iOS (13.2%), and Windows Phone (3.7%) (August 2013) [28]. Each of these operating systems provides a different mobile platform for the development of mobile applications. Developing native mobile applications for each of the mobile platform requires knowledge of a certain programming language and knowledge of platform specific interaction elements. Each platform supports developers differently and has different requirements.

6.2.1. Android

With 79.3% market share, Android is the most widespread operating system for mobile devices. It is an open-source operating system which has been published under the Apache-license. Initially

76

developed by Andy Rubin, Android has been bought in 2005 by Google. There is a huge diversity of mobile devices with this operating system, ranging from 1.6 inch smart watches to 12 inch tablets. Table 31 gives an exemplary overview of different Android devices.

Table 31: Diversity of Android devices

Device Screen size Resolution

Samsung Galaxy Gear (Smartwatch) 1.6 inch 320 x 320

Samsung Galaxy Fame Lite 3.5 inch 320x480

HTC one m8 5 inch 1080x1920

Samsung Galaxy Mega 6.3inch 1.280x720

Samsung GALAXY Tab 3 7.0 7 inch 1024x600

Samsung GALAXY TabPro 8.4 inch 2.560x1.600

Samsung GALAXY NotePRO 12.2 inch 2560x1600

Based on the huge amount of screen sizes and resolutions as well as the resulting pixels per inch,

it is time consuming to develop a universal application that fits all sizes and resolutions or at least all smartphones and tablets. The Android operating system is licensed to several hardware vendors such as HTC or Samsung. These vendors often modify or extend the basic operating system with device specific features. The main development language used for Android is Java.

The Android architecture is based on the Linux-kernel and the Dalvik Virtual Machine (Dalvik VM), as illustrated in Figure 21.

The Linux-kernel takes care of the basic functionality, i.e., memory management, process management, network-communication and the interface for multimedia. It acts as an abstraction layer between the underlying hardware and the rest of the software. The Dalvik VM is a reduced Java Virtual Machine (JVM). Applications are written in a Java-like language and compiled to byte code. The JVM-compatible .class files are converted to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The Dalvik Executable format is more compact and especially designed for systems with low memory and processor speed such as mobile devices. Furthermore, the Dalvik VM uses a register-based architecture instead of JVM’s stack machine architecture. This reduces the number of instructions to load data on the stack, but it increases the length of the instructions, because source and destination registers need to be encoded within them. The debate about which architecture is faster has not been finished yet. According to Google, the Dalvik VM is designed so that multiple instances of it can run efficiently on one device. This way, each executed application runs in its own VM.

77

Figure 21: Dalvik Virtual Machine and Android architecture [29]

The architecture base is extended by a large set of C/C++ libraries to make the implementation for including media files, using 2D and 3D graphics, using web views, accessing SQLite databases, among others, as easy as possible.

On top of all this lies the application framework. It provides central services to the above lying applications such as the Activity Manager, the Window Manager, the Content Providers, the View System, the Notification Manager, the Package Manager, the Telephony Manager, the Resource Manager, and the Location Manager. The Activity Manager, as the name suggests, manages the lifecycle of applications and also provides a stack for the back navigation. The Window Manager, as the name implies, takes care of the windows. The Content Providers enable applications to share their own data with other applications or to access data of other applications that use the Content Providers to share their data. The View System provides a rich and extensible set of views and UI-components available for application implementation while the Notification Manager enables

78

developers to display custom alerts of their application in the status bar. The Package Manager provides methods for querying and manipulating installed packages and related permissions. The Telephony Manager provides a complete environment for developers to use phone-calls and messaging. The Resource Manager grants access to non-code resources such as localized (language specific) strings, graphics, and layout files. Finally, the Location Manager gives the developer access to the GPS module. The roof of the whole architecture is formed by the core applications shipped with Android, e.g. email client, SMS program, calendar, maps, browser, contacts, among others. The architecture of Android is designed so that every new application can make use of every core application and even replace them totally [30].

The Android SDK (software development kit) comes along with Eclipse and the Android Developer Tools Plugin, as well as the Android System Emulator. For development based on the Android platform, Google provides a huge amount of API guides, references, tools, sample code, style guides, among others.

In order to extend the smartphones functionality, apps can be downloaded from Google’s own app store, the Play Store, or app stores from different 3rd party vendors such as amazon or directly from the web.

Furthermore, Android has security features built into the operating system that significantly reduce the frequency and impact of application security issues. The system is designed to allow building apps with default system and file permissions and avoid difficult decisions about security. The Android Application Sandbox isolates app data and code execution from other apps [31]. In addition to running applications in the Sandbox, it is also possible to give root access to applications in order to bypass these security aspects. This leads to less constraints and more freedom, but also implies in security risks from the user’s perspective.

6.2.2. iOS

Firstly known as iPhone OS, iOS is a mobile operating system developed by Apple for the iPhone, iPad, iPod touch and AppleTV. Although the first iOS was released one year upfront Android, its market share is only 13.2%. In contrast to Android, Apple does not license iOS to hardware vendors, which results in the fact that there is a very limited amount of different devices on the market running iOS. Table 32 summarizes all available iOS devices currently sold by Apple.

From the development perspective, there are three different screen sizes/resolutions for smartphones to take into consideration and three different screen sizes/resolutions for tablets. This implies in less effort for UI adjustment.

79

Table 32: All available iOS devices

Device Screen size Resolution

iPhone 5s/5c, iPod touch 4 inch 1136 x 640

iPhone 6 4.7 inch 1334 x 750

iPhone 6 Plus 5.5 inch 1920 x 1080

iPad mini 7.9 inch 1024 x 768

iPad mini 2/3 7.9 inch 2048 x 1536

iPad air/air 2 9.7 inch 2048 x 1536

iOS is derived from Mac OS X and therefore is also a UNIX-based operating system. The

architecture of iOS (Figure 22) consists of four layers, namely Cocoa Touch, Media Services, Core Services, and Core OS [32].

Figure 22: iOS architecture [32]

The Core OS layer builds the abstraction from the hardware and is realized through a modified mach-kernel. The functionality of this layer reaches from network functionality with the CFNetwork Framework, over access to external accessories with the External Accessory Framework, to common, fundamental operating system functionalities, such as security, memory management, file system management, and threads. The Core Services layer is the next abstraction level. It delivers important functionality to the layers above, such as database functionality with the SQLite library (respective CoreData), transactions between applications with the Store Kit Framework, database management with the Core Data Framework, among others. The next layer is the Media Services layer. It provides

80

audio through the AV Foundation Framework, video through the Media Player Framework, and graphics functionality through the OpenGL ES Framework, in addition to two-dimensional drawing through the Core Graphics Framework and the animation of such drawings through the Quartz Core Framework. The Cocoa Touch layer is the top layer and therewith the most important one for software developers. It is mostly written in Objective-C and based on the Cocoa API of Mac OS X with specializations for the iPhone. It offers many of the core frameworks needed by developers, such as the UIKit Framework, the Map Kit Framework, the Push Notification Service, the Message UI Framework, the Address Book UI Framework, and the Game Kit Framework. The UIKit Framework is a big, functionality-rich, Objective-C based API which contains the majority of the functionalities most commonly used by iOS developers. The most important functions are: creation and management of UI elements, handling of program-cycles and events, data handling, inter process communication (IPC), and usage of data from hardware like accelerometer, battery, gyroscope, camera, and others. The Map Kit Framework delivers the functionality for map-based applications, such as the scrolling of a map, the overlaying of a map with additional information, the presentation of a map in accordance to the actual geographical position of the device. The Push Notification Service gives the opportunity to inform the user about an event without the need for the respective application to be active. In iOS, messages take an extra tour over an Apple server and are sent by the Push Notification Service. This way only one process has to run in the background, instead of having all applications running in the background and listening for their push notifications like in Android. The Message UI Framework gives the possibility to send e-mails from any arbitrary application and even provides the UI elements needed for this task. The Address Book UI Framework contains the functionalities to access the address book, and to show and edit both address and contact information. The Game Kit Framework allows peer-to-peer connections between several different devices. Its name derives from the fact that it was meant for the implementation of multiplayer games [30].

Each iOS application runs in its own sandbox resulting in the fact there is no direct access to the hardware (file system, network, etc.). Hardware and software can only be accessed via designated APIs, which gives the user the control to manually decide which application may have access to which features (GPS, Push, Calendar, Contacts, etc.). Applications cannot access the data of other applications. Since iOS 7 there is the possibility to share a small amount of data among apps in the same App-Group (e.g. username, passwords, settings, etc.). With the introduction of iOS 8, it is also possible to share larger data in so-called App-Group folders. These are directories where applications in the same App-Group can access the data (like e.g. databases, images, etc.).

Apple provides its own integrated development kit (IDE) XCode to natively develop iOS applications. Xcode comes along with a code editor, iOS simulator, tools to analyse the app and to submit it to the app store. In contrast to Android, the only possibility to download apps is through Apple’s app store. Every app undergoes Apples’s own review process before being released in the app store. By doing so, Apple ensures a certain level of quality of the apps released in its app store but, on the other hand, limits the freedom of developers and the applications. For example, it is not

81

possible to run huge tasks in the background, extensively track/use sensor data, or continuously perform certain actions.

At Apple’s WWDC 2014 a new programming language called Swift was introduced. It was created by Apple for iOS and OS X development and is designed to work with Apple’s Cocoa and Cocoa Touch frameworks. The usage of the Objective-C Runtime allows using C, Objective-C, C++ and Swift code in a single program. Swift is intended to be more precise (to offer the same functionality, but with less code than in Objective-C) and more resilient to errors. In contrast to the Smalltalk like syntax of Objective-C, the Swift language’s name spacing system is aligned with other modern languages derived from C, like Java or C#. This enables fast-learning of the Swift language if developers are used to common-languages like Java, C#, PHP, etc.

6.2.3. Windows Phone

Windows Phone is a mobile operating system developed by Microsoft for smartphones (market share 3.7%). The equivalent tablet operating system is called Windows RT. Like Windows 8, both systems are based on the Windows-NT kernel. In 2015, Microsoft plans to merge the smartphone and tablet platforms. Similar to Google, Microsoft licenses its operating system to hardware vendors which sell their devices with Windows Phone/RT. Table 33 gives an overview of several devices available for Windows Phone and Windows RT.

Table 33: Windows Phone/RT device diversity

Device Screen size Resolution Operating System

HTC 8XT 4.3 inch 800 x 480 Windows Phone

Nokia Lumia 930 5 inch 1920 x 1080 Windows Phone

Nokia Lumia 1520 6 inch 1920 x 1080 Windows Phone

Acer Iconia W4-820 8 inch 1280 x 800 Windows RT 8.1

Nokia Lumia 2520 10.1 inch 1920 x 1080 Windows RT 8.1

Microsoft wanted to have similar functionality as iOS and Android in Windows Phone, but also

wanted to avoid the risk of getting mixed up with them. Therefore, they decided for a completely different look, as all other mobile operating systems looked quite alike. The home screen, called start screen, of Windows Phone consists of so called tiles. Tiles are rectangular, clickable areas that represent links to applications, features, functions, and individual items. The users are free to add, rearrange, or remove these tiles. They are dynamic and are updated in real time. The main architecture of Windows Phone 8 is built up of four layers (Figure 23).

82

The lowest layer is the Hardware Foundation layer. Similarly to Android and iOS, it abstracts from the hardware and provides access to it for the above lying layers. The second lowest layer is the Kernel layer. It consists of a Windows kernel which takes care of security, networking, and storage issues. It also manages the device resources and grants the above lying layers access through drivers to the hardware abstractions delivered by the Hardware Foundation layer. The layer on top of these two contains the three pillars: App Model, UI Model, and Cloud Integration. The App Model is responsible for the management, the licensing, the run-time isolation, and the updating of the applications. The UI Model takes care of visualization tasks, such as session management, rendering of the different UI layers onto the screen with Direct3D, and switching between windows. It also provides the possibility to open an application from another application to allow a fluent navigation between the applications. The third pillar – Cloud Integration – attends to the services supplied by the internet, which includes Xbox Live, Bing, push notifications, Windows Live, among others. The layer over these three important pillars is the Application platform. It builds the platform for application developers to develop three different types of applications, namely Silverlight, XNA, and HTML/JavaScript. Silverlight applications are meant for business purposes. XNA is the basis for games. These two application types built on the Common Language Run-Time (CLR). The last application type consists of web applications that run inside the web browser. All three application types make use of frameworks to deliver access to hardware and services [30].

Figure 23: Windows Phone architecture [33]

83

There exist several ways to develop native apps for Windows Phone. Based on a specialized .NET API, it is possible to develop apps in C# or Visual Basic and Silverlight. Windows Phone Runtime (WinPRT) provides the basic functionalities of Windows RT based on native COM-components. Wrappers provide the functionality to call the runtime environment with .NET C#/VB and native C++. For developing the apps, Microsoft provides Visual Studio 2013, Blend for Visual Studio, the Windows Phone 8 SDK as well as a Windows Phone Emulator.

Windows Phone apps run in a sandboxed process. This means that they are isolated from each other, and will interact with phone features in a strictly structured way. If an app needs to save data or configuration information, it will do so using isolated storage, which is designed to be protected from access by other apps. Apps can only communicate with each other through controlled mechanisms. Apps run under the supervision of an execution manager. The execution manager measures whether apps behave as required by certain defined conventions. For example, the execution manager monitors the use of resources by apps that are not in the foreground, and terminates non-foreground apps as needed to make the foreground app more responsive to the user [34]. The sandboxed process within which a particular app runs has a customized set of security capabilities. The Windows Phone app platform is designed to minimize the attack surface area of each app by only granting it the capabilities that it needs in order to run. For example, if an app does not require the use of the Media Library, the Windows Phone app platform will seek to execute it in a sandboxed process that does not have access to the Media Library.

Similar to iOS, the only way to download Windows Phone apps is through Microsoft’s Windows Phone Store.

Table 34 presents a comparison of the three aforementioned mobile platforms.

Table 34: Comparison of mobile operating systems

Android iOS Windows Phone/RT

Possibility to run apps outside sandbox Yes No No

Development language Java Objective-C, Swift C#, .NET/VB

Required OS for development Any Mac OSX Windows 8

Application distribution Anywhere Proprietary app store Proprietary app store

Developer program fee (individual) $25 once $99/year $19/year

Device diversity High Low Medium

Existing app diversity (Q1/2014) 1.2 millions >1 million 0.2 million

84

6.3. Development Approaches

Several approaches for developing mobile applications exist. There is a distinction between native, hybrid and web approaches. Each approach has specific benefits and drawbacks that must be evaluated based on the specific use case.

6.3.1. Native Applications

Native apps are applications completely adapted to the underlying operating system. They are written in the programming language instructed by the operating system and can therefore make use of the operating system specific APIs and libraries to access the device’s hardware. Native apps are developed in the following programming languages:

• Java for Google’s Android • Objective-C/Swift for iOS • C# and Visual Basic for Window Phone

Native apps are distributed over the platform-specific app stores (Google’s Play Store, Apple’s App Store, and Microsoft’s Windows Phone Store) or can be downloaded from any 3rd party source (Google’s Android). End-users download those applications and they are automatically installed on the device. Typically most of the needed data are downloaded and stored on the device during the installation. Some applications require web services for updating the application’s content. There might occur obstacles when submitting an app to an app store (like review process and guidelines) There are also benefits when deploying apps through an app store. They can easily be found in the respective app store and simply installed on the device. App stores facilitate monetization as developers can use the app store’s specific billing systems. However, the operator of those stores often requests a certain percentage of the earnings and it takes several days from submitting the app to the approval (or disapproval).

When developing an app by using platform-specific technologies, a high degree of user experience can be achieved. In addition to the access to all provided hardware functionalities and input gestures, platform specific interaction patterns and UI elements can be used to enable the best user experience. Furthermore, native apps support complete offline functionalities. Finally, performance and responsiveness of native applications cannot be reached by cross-platform and web applications.

On the other hand, native apps have one major drawback: For each platform, one native app needs to be developed. Even though the same backend and communication interfaces can be used by each native app, the frontend needs to be developed for each platform. For a great user experience, platform specific adaptations of the user interface must be performed.

In order to support a very broad-range of end-users, an app needs to be developed for each platform. Thus this approach limits the amount of end-users.

Table 35 summarizes the benefits and drawbacks of native apps.

85

Table 35: Benefits and drawbacks of native apps

Benefits Drawbacks

• Responsiveness & performance • Offline capability • Access to hardware (gyroscope, compass, etc.) • Easy usage of platform specific interaction

patterns and UI elements

• Development effort to reach broad range of end-users

• App store constraints (review process, guidelines)

• Time to submit/update software to the app store

• Can only be developed within designated IDEs

6.3.2. Mobile Web Pages

Mobile web pages are websites that are accessible through the browser of the specific smartphone and tablet. Mobile web pages display requested information optimized for the devices screen size and resolution. Based on responsive web design techniques, the website is developed once and automatically adjusts to the characteristics of the device. An alternative is to develop different websites for each device class such as smartphones, tablets, and desktops, which is done when the goal is to have completely different look-and-feels on the corresponding devices. Apart from supporting different device classes, mobile websites can also support platform specific characteristics such as button appearances, screen transition behaviour, among others.

When developing mobile websites common internet standards such as HTML, PHP, CSS, and JavaScript are used. The website is then deployed on a webserver and is accessible via every browser. This way they do not undergo the review process in app stores which increases time to market as well as updateability.

However, in contrast to native applications, this approach lowers user experience. Websites and their performance strongly depend on the available internet connection. Especially in the mobile domain, working and fast internet connections cannot be assumed and therefore long loading times may happen. Furthermore, it is not possible to have access to all hardware features provided by the smartphone. Web-languages do not support hardware-sensors like the gyroscope, NFC, or temperature. In addition, native input modalities like swipe gestures or multi touch are not supported, as browsers on smartphones mainly support scrolling and pan&zoom.

Thus the strengths of mobile web pages are mainly to support a very broad range of end-users using heterogeneous devices. Despite the user experience of such web pages being very low in contrast to other approaches, the results are still acceptable and are improving more and more due to continuous enhancements in the web domain.

Table 36 summarizes the benefits and drawbacks of mobile web pages.

86

Table 36: Benefits and drawbacks of mobile web pages

Benefits Drawbacks

• Usage of open web standards • Independent of app stores • Cross platform • Shorter time to market • Easier maintenance • UI responsiveness & performance

• Lowered/bad user experience • Slow due to huge data transmissions • Only available with working internet

connection • Very limited access to hardware sensors • No access to software APIs (contacts,

calendar, etc.)

6.3.3. Web Applications

As mobile web pages, web apps also display information in a system-specific web browser. Mobile web pages can be reached via a normal web browser whereas web apps are websites embedded in a native, operating system specific application frame and need to be downloaded from the operating system’s specific app store.

Web apps download and save at the initial start-up all required files (HTML, CSS, images, and JavaScript) on the device. During later start-ups, only the necessary content needs to be downloaded which increases network performance. However, the cross-platform aspect is kept. Furthermore, only the native frame needs to be developed for each operating system, the displayed webpages are universal. Similar to web pages, updates can be provided independent of the specific app-store’s review process as only the webpages on the internet need to be changed. Similar to mobile web pages, it is not possible to access all hardware features as well as use all gestures provided by the operating system, as it is still a web browser that displays the content. The main aspect that differentiates web apps from mobile web pages is the natively developed application frame. If it has been developed, a similar broad ranged amount of end users can be supported.

Table 37 summarizes the benefits and drawbacks of web apps.

Table 37: Benefits and drawbacks of web apps

Benefits Drawbacks

• Offline availability of parts of the application • Independent of app stores • Cross platform • Shorter time to market • Easier maintenance

• Lowered/bad user experience • Limited access to hardware sensors • No access to software APIs (contacts,

calendar, etc.)

87

6.3.4. Hybrid Applications

Hybrid apps are a mixture of native and web apps and try to equalize the advantages and disadvantages of both application types. While web apps can be written without a framework using HTML5, hybrid apps need a framework for implementation. These frameworks are mostly based on web technologies and provide the possibility of developing cross-platform apps that do not noticeably differ from native apps. They compile the hybrid apps to the native packages of the targeted mobile operating system and therewith the hybrid apps can be distributed through the central application stores just like native apps. Furthermore, they deliver access to native hard- and software functions and build a sort of container for web apps. The supported platforms differ from framework to framework, but most of them support at least iOS and Android [30].

Hybrid or web-to-native wrapper frameworks build an appendix for the existing web apps. The web app is bound to a web view in a native app. In this way a web app can be compiled to a native app without any changes in the code (see Subsection 6.3.3).

On the other hand, apps of cross-compiled or source code translator frameworks are written in a common used programming language. The written code is then cross-compiled to native code with a code generator, which is a cross-platform compiler. This provides an abstraction from the programming language of the mobile operating system. There exist several vendors of such frameworks that support cross platform development. Hybrid apps in general have access to many available hardware sensors and provide device specific gestures to interact with the application. However, the more hardware sensors and platform specific APIs are used, the more native components need to be used and thus the less hybrid the apps are.

Another aspect to consider is that, after major operating system updates, it often takes time until vendors have updated their wrapper frameworks to make them compatible to the new version of the operating system. Furthermore, Xcode is still needed to submit iOS applications to the app store.

Hybrid apps are deployed via the specific app stores, which has its advantages and disadvantages (review process, monetization, and guidelines, among others).

Table 38 summarizes the benefits and drawbacks of hybrid apps.

Table 38: Benefits and drawbacks of hybrid apps

Benefits Drawbacks

• Offline capability • (limited) Access to hardware features • Usage of platform specific interaction

patterns and UI elements (depending on the framework)

• Cross platform

• Another language/framework to get used to • Less responsive than native apps • App store constraints (review process,

guidelines, time to submit/update an app) • Time to adapt frameworks to new operating

system updates

88

6.3.5. Guidelines for Developing Mobile Applications

There is not one right way to develop mobile applications. The selection of the development approach strongly depends on the context within the application is intend to be used, its users, the development effort to be spent, the concrete requirements (e.g. whether it is necessary to have access to hardware sensors and/or software APIs, among others.) and other factors. Table 39 provides decision support for selecting the appropriate development approach. There are mainly seven decision categories to be considered, namely user experience, usage of device features, multi-platform support, required tools/skills, speed, costs, and delivery method.

From the user experience perspective, the native approach is obviously the way to go. Native UI elements, gestures, offline capability, and performance satisfy the user in the best possible way. Hybrid approaches support all these features to a certain degree, whereas web approaches have deficits in performance, offline capability, gestures, and look&feel. When developing native app, the UI design and screen flow might be developed for each operating system individually, which results in the best possible UX, but also in the most development effort. Hybrid apps support different UI designs or can share the same design. It is up to the used framework and user interface design techniques how this is taken into account. Web apps mainly share the same UI design and screen flow whereas it is already possible to make adaptive, operating system specific web apps.

Taking the usage of device features into account, hybrid approaches support most of the device features available natively. In contrast, web apps access to device specific functions is very limited (Table 39). If access to device features respectively sensor data is needed, a hybrid or native approach must be used.

Native apps support only their respective operating system, whereas hybrid and web apps support a wide range of mobile operating systems. Taking multiple screen sizes into account, even native apps need to be adapted to support e.g. tablets and smartphones. iOS applications can share a same code-base, whereas the UI is developed separately for iPhones and iPads. It is also possible to scale iPhone apps to an iPad, resulting in a magnification of the iPhone app. Web apps and hybrid frameworks like PhoneGap also support upscaling. However, it is often not feasible to only upscale applications as a larger screen may result in a different UI design and screen flow. Thus, at least the UI of smartphone and tablet applications need to be developed separately.

Available developers/required tools also have an impact on the development strategy. For going for native apps, developers must have knowledge in the concrete development languages (Java, C#, Objective-C, among others). This means that several developers are necessary, each one skilled in a specific language, or it is necessary to have available developers with a broader ranged knowledge. In addition, Windows 8 computers are necessary for Windows Phone development, whereas Macs are required for iOS development.

The development for different platforms (native) takes much longer, as for each platform an application needs to be developed separately. Hybrid and web apps are developed for all target platforms, where some adjustments need to be done for hybrid apps. This has impact on effort and respective costs. Developing one application for different operating systems costs much more than

89

developing a hybrid or web app. If there is a very limited budget, it gets very difficult to develop several apps natively.

The delivery method depends on the approach. Native and hybrid applications can be sold through the app store. The provider takes care of the accounting and also of the quality of the app. Users can be sure that apps downloaded from the app store do not harm them or their privacy. Web apps are not managed by app stores, they are simple websites accessible via browser. Thus they can be updated instantly, without a review process. Native and hybrid applications must undergo the operating system specific app store’s review process, which takes some days. After an update has passed the review process, it cannot be ensured that users will download the latest version of the application.

Table 39: Decision support for mobile application development [35]

Native Hybrid Web User experience Performance Fast Slower Slower UX/UI Best Similar to native app Like a website Gestures Best Possible Limited Connectivity Online and offline Online and offline Online and limited

offline Quality control High (through app

store policies) High (through app store policies)

Up to developer

Browser variability Not an issue Not an issue Can be an issue Use of device features Local storage Best Possible Limited Accelerometer Yes Yes No NFC Yes Yes No Camera integration Yes Yes Yes Calendar Yes Yes No GPS Yes Yes Yes Multi-platform support Multiple operating systems No Yes Yes Multiple screen sizes Custom Custom Automatic Tools/Skills required Dev Tools Native Platform

SDKs Frameworks, e.g. PhoneGap, Appcelerator

Frameworks, e.g. jQuery Mobile, Sencha

Developer Skills Specialized – Objective-C, Java, C#

Framework dependent plus HTML5, CSS, JS

HTML5, CSS, JS

Developer Availability Most limited Training is required Easiest transition Cost Development time Slow Faster Fastest Effort for updates/new versions Slow (iOS & Faster Fastest

90

Native Hybrid Web Windows), Fast (Android)

Testing Testing on each platform

Testing on each platform

Testing with multiple browsers

Code reuse Limited Better Best Delivery method Marketing/Discovery/Download App store App store Web Updates App store App store None required Flexibility Limited Limited High Other considerations Security High High Weaker Data management High High Depending on the

used technology

91

7. Portability Strategy This chapter is concerned with providing the guidelines for dealing with portability in the

RESCUER project. It provides recommendations regarding the mobile application development approach to be used.

7.1. Recommendations Regarding the Mobile Application Development Approach

Taking the features and requirements for the Mobile Crowdsourcing Solution into account, this app or set of apps must be developed in a native or hybrid way. Web apps do not provide access to sensor data which are strictly needed. Both native and hybrid approaches provide access to desired sensor data. From the performance perspective, hybrid approaches still provide sufficient performance, whereas the user experience of a native application is much better. The Mobile Crowdsourcing Solution must contain offline functionality to store reports of an emergency situation and send them when internet is available. An important aspect to consider when deciding for a hybrid approach is how to integrate libraries. On the one hand, the RESCUER app(s) will make use of custom (native) libraries provided by DFKI to access sensor data. On the other hand, its integration into large scale event apps developed by 3rd party vendors should be possible. Thus, a library must be created that can be used in native applications.

7.2. Experiences with the Mobile Application Development Approach

All the required system and device features have been implemented using native (Android/iOS) libraries provided by the specific operating system. Figure 24 shows the architecture of the RESCUER Mobile Crowdsourcing Solution. When compiling the application for iOS only the light blue box containing the RESCUER native iOS Library ( in Figure 24), the JavaScript Plugin for PhoneGap ( in Figure 24) and the application itself is included in the application. The same holds for the Android application.

Native system libraries/packages provide access to specific device sensor data like GPS, accelerometer, gyroscope, and compass ( in Figure 24). The required system libraries are wrapped in one native library per platform that provides access to them through one interface ( in Figure 24). This interface may vary between the different operating systems as they have a different syntax to call methods or provide callback functions.

A JavaScript plugin ( in Figure 24) maps the native interfaces to a unified interface, which is the same for every operating system. The application itself calls the libraries through the JavaScript plugin und receives messages and answers in the same way.

Each RESCUER native library is included in the implementation project when developing an application.

92

The advantage of using native libraries is having access to all kind of functions provided by the operating system’s platform and not only to the ones supported by PhoneGap. The disadvantage is that the “one code for all” approach is not possible. The PhoneGap application itself is compatible to all operating systems supported by PhoneGap, but the RESCUER native library still needs to be developed and compiled for a certain operating system.

Figure 24: Architecture of the PhoneGap application. The light blue box contains the RESCUER native iOS Library, the JavaScript plugin for PhoneGap, and the PhoneGap application for iOS

7.2.1. Overview of the Used Technology

Each PhoneGap based application need to consider several architectural different aspects. PhoneGap enables web-based applications in form of a native app on the device and not running as traditional website. Further it allows the web-based solution to interact with native components of the platform through the use of plugins. PhoneGap does not provide any mechanisms for UI Design or application logic. This is totally up to the developer. Therefore, usually further third party libraries based on web technologies are required. In the case of RESCUER, the used library is Ionic, which is a GUI Framework based on the MVC capabilities of AngularJS.

7.2.2. Advantages and Disadvantages of the Used Technology

PhoneGap Application Architecture Model

The separation into device connection, application management and user interface has some positive as well as negative consequences. The fact that the UI and application logic is written in HTML, CSS and JavaScript allows using experienced web developers for frontend and application development. Furthermore, depending on the project setting, it might also be easy to integrate parts

93

of JavaScript APIs used for an existing website without having the need for change. It might also be possible to reuse existing HTML and CSS for a mobile optimized website.

The drawback of this separation is that all choices regarding how to build a navigation logic or GUI are totally up to developers or to third party libraries. This results in the existence of various frameworks of different capabilities and focus, which has some important implications on the reuse of code between different projects. The degree of possible reuse totally depends on the same choice of frameworks due to the hard dependency on the used frameworks. Furthermore, besides code that uses multiple frameworks, there are also important dependencies between them, as frameworks that require and exclude others. Therefore, it can be stated that apps developed with PhoneGap provide a high level of reuse as long as you stick to the chosen frameworks. In the RESCUER project the level of reuse between Android and iOS outbalances the possible drawback of additional effort for switching the framework in future app development. In addition, a possible reuse of the source code in future projects is not in the immediate scope of the project.

Web Based User Interfaces

The fact that PhoneGap uses web based UIs leads to the possibility of developing one single UI for all required target platforms. Due to the ease of use of html and css it is also possible to build, modify or extend the UI in a short period of time. Here, especially the choice of using Ionic for RESCUER helps a lot, since it is a modern framework without a huge amount of legacy being developed for the purpose of HTML 5 mobile apps.

It is very important to design a neutral looking, but intuitive application and not trying to imitate some features of a certain platform, since it will just behave “unnatural” for end-users when running the application.

Documentation of the Used Technologies

Ionic is very well documented and the documentation is full of examples of how to use the framework. Therefore Ionic has a good learnability.

This positive judgment cannot be made for PhoneGap. Even though it has a history of being developed for years, its documentation is poor and only shortly covers topics on a very abstract level. Furthermore, there are no deeper tutorials available on their website that are compatible to its current version. When searching for guidance on the Internet, it is difficult to find appropriate information because a lot of available information is not valid anymore, since PhoneGap underwent big structural changes in autumn 2013.

94

Handling and Development of Native Plugins

A very critical part of PhoneGap is the need for plugins to access device features or native system functions. These plugins can be official plugins, third party’s plugins or self-made, project specific plugins.

Even very basic functionality like getting information about the device or the software version needs to be gathered by plugins and even this kind of plugins are not loaded in the application by default. The documentation issue of PhoneGap gets even worse with regards to plugins. The official core plugins are not documented on the PhoneGap website and are only explained on their github repository. The documentation of these plugins varies from nearly no documentation to a small set of well-documented plugins. In addition, the plugin architecture works well if you find the right plugins or the web development team is able to write their own custom plugins.

If there is a need for a custom plugin, like the RESCUER crowd sensing library, the official documentation only gives is a short explanation of the architecture of such a plugin and some short information about how to develop plugins for the different target platforms. This is not sufficient to learn how to develop a plugin and developers can easily stumble over a lot of problems. These might be some issues with the PhoneGap command line interface on different development platforms or the lack of an update command for plugins (it is necessary to remove and add them to trigger an update). Furthermore, there is the need to write JavaScript code, a plugin, and a platform description file in the form of xml, as well as platform specific code, which makes it hard to ensure that the plugin delivers the desired quality. In addition, it is barely possible to debug a plugin without embedding it into an application project.

This leads to the conclusion that developing this kind of plugins is very difficult if the development team does not have experience with developing PhoneGap plugins. In an ideal world, choosing a native development approach to realize the complete functionality provided by the Mobile Crowdsourcing Solution would be more beneficial, if the resources for realization were available. Nevertheless, in the RESCUER context, we decided to use PhoneGap based on the benefits of having a shared UI component, reuse of at least parts of the Mobile Crowdsourcing Solution across platforms and not least the availability of experienced web developers. This outbalanced the option of building native solutions, as there was no access to experienced native iOS and Android developers.

95

8. Conclusion This document provides a clear definition of the RESCUER platform scope for the second project

iteration (Chapter 2), which was very useful for establishing a common understanding of the project goals for this iteration and for guiding other active tasks in this period. In addition, it provides relevant information about the sources of variation in the project and how they affect the RESCUER platform (Chapter 3). A variability model, which is presented in Section 5.2, characterises the relevant variations in the features provided by the main RESCUER components. Our decision of modelling variability with feature diagrams is justified in Section 5.1. The recommendations provided in Sections 5.3 (variability realization techniques for the identified features), 5.4 (how to capture variability in textual requirements, use case diagrams and architectural diagrams), and 7.1 (which mobile application development approaches are best suitable to the project) are expected to support project members in achieving efficient software reuse in each specific case. They were based on our practical experience and best knowledge of the state-of-the-art in the areas of variation management (Chapter 4) and mobile applications development (Chapter 6). It is relevant for the developers of the Mobile Crowdsourcing Solution to be able to benefit from the advantages of the adopted technologies, while dealing with their disadvantages (Section 7.2).

Refinements of the models and especially of recommendations presented in this document may still occur in the next project iteration. For example, project members are going to use the recommendations in practice and provide their feedback. Moreover, several issues are going to be further investigated, as e.g. whether and how the differences in processes and organizational structures in Brazil and Europe (Appendix A) affect the RESCUER platform. .

96

Bibliography [1] EC Grant Agreement No 614154 (2013). Annex 1: Description of Work. [2] I. John, J. Knodel, T. Lehner, and Muthig (2006). A practical guide to product line scoping. In The

10thInternational Dirk Software Product Line Conference. [3] I. John and M. Eisenbarth (2009). A decade of scoping: a survey. In Proceedings of the 13th

International Software Product Line Conference (SPLC '09). Carnegie Mellon University, Pittsburgh, PA, USA, pages 31-40.

[4] J. Lee, S. Kang, and D. Lee (2010). A Comparison of Software Product Line Scoping Approaches. In International Journal of Software Engineering and Knowledge Engineering, Vol. 20., N. 5, pages 637-663.

[5] K. Lee, K. C. Kang, and J. Lee (2002). Concepts and Guidelines of Feature Modelling for Product Line Software Engineering, Software Reuse: Methods, Techniques, and Tools. In Proceedings of the Seventh Reuse Conference (ICSR7), pages 62-77. Springer-Verlag .

[6] Vereinbarung zwischen Land Oberösterreich – Landeshauptstadt Linz – Stadtgemeinde Steyregg und den Unternehmen am Chemiepark Linz über die Zusammenarbeit bei Schadensereignissen (2014). 48p.

[7] Maurer Scheme in Wikipedia. Date of Access:10.06.2014 http://de.wikipedia.org/wiki/Maurer-Schema

[8] F. van der Linden, K. Schmid, and E. Rommes (2007). Software Product Lines in Action, 333p. Springer-Verlag.

[9] K. Czarnecki, P. Grünbacher, R. Rabiser, K. Schmid, and A. Wąsowski (2012). Cool Features and Tough Decisions: A Comparison of Variability Modeling Approaches. In Proceedings 6th Int'l Workshop on Variability Modelling of Software-Intensive Systems, Leipzig, Germany, pages 173-182.

[10] S. Apel, D. Batory, C. Kästner, and G. Saake (2013). Feature-Oriented Software Product Lines: Concepts and Implementation. 308p., Berlin/Heidelberg. Springer-Verlag. ISBN 978-3-642-37520-0.

[11] Hats Project Public Deliverable, µTVL in Final Report on Feature Selection and Integration. Date of Access: 28.05.2014 http://www.hats-project.eu/node/97

[12] Software Productivity Consortium Services Corporation (1993). Reuse-Driven Software Processes Guidebook. Version 02.00.03, Technical Report SPC-92019-CMC.

[13] P.Y. Schobbens, P. Heymans, J.C. Trigaux, and Y. Bontemps (2006). Feature Diagrams: A Survey and a Formal Semantics. In Proceeding of the 14th IEEE International Conference on Requirements Engineering, Minneapolis, USA, pages 139–148. IEEE.

[14] European Software Institute Spain and IKV++ Technologies AG Germany (2002). MASTER: Model-driven Architecture inSTrumentation, Enhancement and Refinement.

[15] D. Weiss and C. Lai (1999). Software Product-Line Eng.: A Family-Based Software Development Process. Addison-Wesley.

97

http://de.wikipedia.org/wiki/Maurer-Schema

http://www.hats-project.eu/node/97

[16] J. Mansell and D. Sellier (2003). Decision Model and Flexible Component Definition Based on XML Technology. In Proceedings of the 5th International Workshop on Software Product Family Engineering, pages 466–472. Springer-Verlag.

[17] D. Dhungana, P. Grünbacher, and R. Rabiser. The DOPLER Meta-Tool for Decision-Oriented Variability Modeling: A Multiple Case Study. Automated Software Engineering 18(1), pages 77–114.

[18] K. Schmid and I. John (2004). A customizable approach to full lifecycle variability management. Science of Computer Programming, Vol. 59, pages 259–284.

[19] K. Schmid, R. Rabiser, and P. Grünbacher (2011). A comparison of decision modeling approaches in product lines. In Proceedings Int. Workshop on Variability Modelling of Software-intensive Systems (VaMoS), pages 119-126. ACM Press.

[20] M. Sinnema and S. Deelstra (2007). Classifying Variability Modeling Techniques. Elsevier Journal on Information and Software Technology 49(7), pages 717–739.

[21] S. Buhne, K. Lauenroth, K. Pohl, and M. Weber (2004). Modeling features for multi-criteria product-lines in the automotive industry. In: 26th International Conference on Software Engineering - Workshop W14S “Software Engineering for Automotive Systems”, pages 9–16.

[22] M.-O. Reiser and M. Weber (2006). Managing Highly Complex Product Families with Multi- Level Feature Trees. In: 14th IEEE Requirements Engineering International Conference, pages 149–158.

[23] H. Hartmann and T. Trew (2008). Using Feature Diagrams with Context Variability to Model Multiple Product Lines for Software Supply Chains. In 12th International Software Product Line Conference, pages 12-21.

[24] H. Gomaa and M. Shin (2002). Multiple-view meta-modeling of software product lines. In: 8th IEEE International Conference on Engineering of Complex Computer Systems, pages 238–246.

[25] O. Oliinyk (2012). Applying Hierarchical Feature Modeling in Automotive Industry. Master Thesis on Software Engineering, MSE-2012:111, School of Engineering at Blekinge Institute of Technology.

[26] J. White, D. Schmidt, D. Benavides, P. Trinidad, and A. Ruiz-Cortés (2008). Automated Diagnosis of Product-line Configuration Errors in Feature Models. In 12th International Software Product Line Conference, pages 225-234.

[27] K. Pohl, G. Böckle, F. van der L (2005). Software Product Line Engineering: Foundations, Principles and Techniques, 467p. Springer-Verlag.

[28] IDC Worldwide Mobile Phone Tracker (August 2013). Date of Access: 09.05.2014 http://www.idc.com/getdoc.jsp?containerId=prUS24257413

[29] Android System Architecture. Date of Access: 09.05.2014 http://de.wikipedia.org/wiki/Android_%28Betriebssystem%29

[30] S. Erhart (Mai 2012). Scalable Mobile Cross-Platform Development. Masterthesis. [31] Android Developers – Security Tips. Date of Access: 09.05.2014

http://developer.android.com/training/articles/security-tips.html [32] Apple Inc., iOS Developer Library – iOS Technology Overview. Date of Access: 09.05.2014

https://developer.apple.com/library/ios/documentation/miscellaneous/conceptual/iphoneostechoverview/Introduction/Introduction.html

98

http://www.idc.com/getdoc.jsp?containerId=prUS24257413

http://de.wikipedia.org/wiki/Android_%28Betriebssystem%29

http://developer.android.com/training/articles/security-tips.html



[33] Windows Phone 7 Architecture. Date of Access: 09.05.2014 http://windowsphone.interoperabilitybridges.com/articles/android-to-wp7-chapter-1-introducing-windows-phone-platform-to-android-application-developers#h2Section0

[34] Microsoft, Security for Windows Phone 8. Date of Access: 12.05.2014 http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402533%28v=vs.105%29.aspx

[35] BayTech Services. Native, Hybrid or Web - What’s Best for your Mobile Apps? Whitepaper.

99

http://windowsphone.interoperabilitybridges.com/articles/android-to-wp7-chapter-1-introducing-windows-phone-platform-to-android-application-developers%23h2Section0

http://windowsphone.interoperabilitybridges.com/articles/android-to-wp7-chapter-1-introducing-windows-phone-platform-to-android-application-developers%23h2Section0

http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402533%28v=vs.105%29.aspx

http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402533%28v=vs.105%29.aspx

Glossary

Terms

Incident Natural or man-made occurrence that interrupts the normal procedure or behavior in a certain situation. It causes a critical situation or emergency situation that requires measures to be taken immediately to reduce adverse consequences to life and property. In terms of the Emergency Response Toolkit, a collection of reports that are closely related in terms of type of incident, position of incident and approximate time of occurrence will be considered as reports of the same incident.

Emergency situation Several (similar or different types of) incidents, reported in different positions and time may occur in an industrial area or large-scale event and require the reaction of the command centre. In terms of the Emergency Response Toolkit, they belong to the same emergency situation.

Abbreviations

AOP Aspect-oriented Programming

DoW Description of Work

EC European Commission

FOP Feature-oriented Programming

IDC International Data Corporation

UI User Interface

UX User Experience

ERTK Emergency Response Toolkit

100

Appendix A: Protocol of the RESCUER Variability Elicitation Workshop

A.1. Introduction

The RESCUER Variability Elicitation Workshop had the goal of: • Identifying commonalities and differences between the organizational structures dealing

with emergency situations in industrial areas in Europe and Brazil, • Identifying commonalities and differences between the processes used for dealing with

emergency situations in industrial areas in Europe and Brazil, • Identifying different requirements for the Mobile Crowdsourcing Solution and the Emergency

Response Toolkit from the viewpoint of the industrial areas in Europe and Brazil.

The workshop took place on 25th November 2014 and was complemented by one working session during the Rescuer Annual Project Meeting held in the period of 26-28th November 2014. Table 40 provides the list of participants in the workshop with their respective roles.

Table 40: List of participants in the variability elicitation workshop

Participant Organization Role Colin Geyer Fireserv Representative of European

Industrial Areas Érico Oliveira COFIC Representative of Brazilian

Industrial Areas Karina Villela Fraunhofer Moderator Manuella Silva Fraunhofer Moderator Assistant Vaninha Vieira UFBA Observer Paulo Simões Jr UFBA Observer Ivy Michelle MTM Observer Laia Pedraza Vomatec Observer

A.2. Workshop Organization

The workshop was organized in the following sessions and activities: • Session 1: Organizational Structures

o Activity 1.1: Identification of on-site organisations and actors o Activity 1.2: Identification of off-site organizations and actors o Activity 1.3: Indication of specificities in the organizational structures o Activity 1.4: Indication of commonalities in the organizational structures

101

o Activity 1.5: Mapping of different terms with similar/equivalent meaning • Session 2: Emergency Management Process

o Activity 2.1: Identification of activities and respective actors o Activity 2.2: Indication of specificities in the processes o Activity 2.3: Indication of commonalities in the processes o Activity 2.4: Mapping of different terms with similar/equivalent meaning

• Session 3: Mobile Crowdsourcing Solution o Activity 3.1: Feedback on the current functionality and interface o Activity 3.2: Indication of specific requirements

• Session 4: Emergency Response Toolkit o Activity 4.1: Feedback on the current functionality and interface o Activity 4.2: Indication of specific requirements

The workshop participants were informed of the goals of the workshop and divided into two

groups: Europe and Brazil, each one headed by the representative of industrial areas in the respective geographic region. They were provided with material previously prepared based on the deliverables and models of the first project iteration and asked not to use specific names and abbreviations, but to extract the essential nature of the organizations, actors, and activities.

During the activities the moderator and moderator assistant helped the participants to complete the activities by clarifying doubts and keeping the focus of the participants in the activities to be performed.

A.3. Workshop Execution and Results

Session 1: Organizational Structures Activity 1.1: Identification of on-site organizations and actors

This activity consisted of drawing a model placing the on-site actors in their acting area in an emergency situation. The term “on-site actors” is defined as actors who move to the place of the incident when notified of the incident. “Acting area” is the place where the on-site actors perform their activities in the emergency situation, which was divided in three zones: hot (red circle), warm (orange circle) and cold (green circle), respectively the most dangerous location because it is very near the incident; the intermediate location, which is still near, but not so dangerous; and the nearest location where people can stay without running risks.

Each representative of industrial parks received a panel paper drawn with the acting zones and an envelope. The envelope contained a set of colour bubbles with names of potential actors, which were extracted from models that had been created by the representatives of the industrial areas before the workshop. They also received extra colour bubbles in blank, in case there were actors not included in the set of previously prepared bubbles. The set of prepared bubbles consisted of all

102

actors provided by the European representative or the Brazilian representative in their previous models, in order to maximize the changes of the selection of the same actors by the two groups during the workshop. They also received their respective previously created models. The envelope received by the European representative contained blue bubbles, whereas the envelope received by the Brazilian representative contained green bubbles.

The results of this activity are represented by the bubbles in Figure 25 and Figure 26. The white bubbles used by the European representative were to emphasize that those actors are only involved in very specific or very big incidents.

Activity 1.2: Identification of off-site organizations and actors

This activity consisted of drawing a model to describe the organizational structures involved in

managing an emergency off-site. The term “off-site actors” refer to actors that are stationary in rooms or buildings during the emergency. They may stay at the usual workplace or go to other buildings in order to perform their dispatch-related activities.

Each representative of industrial areas received a panel paper with the names of the three main off-site organizational structures according to the previous requirements elicitation work, namely medical support, emergency committee, and crisis committee. They also received an envelope with the same contents as in activity 1.1. They were asked to put the pertinent actor bubbles in the off-site organizational structures which they belong to, or outside them in case they do not belong to any of the three structures.

The results of this activity are represented by the bubbles and connecting lines in Figure 27 and Figure 28. The connecting lines represent the hierarchy in the organizational structures. In Figure 27, the European representative informed that the organizational structure “Emergency Committee” is called “Command and Control Centre” in Europe and that there is no “Medical Support Area” in European industrial areas. The Brazilian representative used arrows to the bubble “Civil Defence” to represent that the Civil Defence informs all connected actors of the incident and of the need for taking actions.

Activity 1.3: Indication of specificities in the organizational structures

In this activity, each representative of industrial areas was invited to look at their respective

models of on-site and off-site organizations and actors, and indicate the actors that they believed to be specific to their geographic region (Europe or Brazil). For doing so, they should put red circle adhesives on the bubbles representing the actors.

The results of this activity are represented in Figure 25 and Figure 26, and in Figure 27 and Figure 28 by the biggest red circle adhesives put on the bubbles. There are two sizes of red circle adhesives in those figures. The smallest ones have the same meaning but were included in activity 1.5.

103

Activity 1.4: Indication of commonalities in the organizational structures In this activity, each representative of industrial areas was invited to look at the panels of on-site

and off-site organizations and actors created by the other representative, and indicate the actors that they believed to be common between the two regions (Europe and Brazil). For doing so, they should put green circle adhesives on the bubbles representing the actors.

The results of this activity are represented in Figure 25 and Figure 26, and in Figure 27 and Figure 28 by the green circle adhesives put on the bubbles. There are green circle adhesives in those figures that are over red circle adhesives. They were put in activity 1.5. Activity 1.5: Mapping of different terns with similar/equivalent meaning

In this activity, each representative of industrial areas was invited to explain his respective

models of on-site and off-site organizations and actors. During the explanation, the other representative of industrial areas should check whether specificities were real specificities (if not, he should put a green circle adhesive over the previous red circle adhesive), check whether commonalities were real commonalities (if not, he should put a red circle adhesive over the previous green circle adhesive), and classify the remaining activities in specificities (using red circle adhesives) or commonalities (using green circle adhesives). Representative of industrial parks were asked to use yellow strip adhesives to indicate when actors did not have the same name in the model of the other geographic region as in his own model, but had very similar responsibilities. The yellow strips were numbered to make each mapping uniquely identified.

The results of this activity are represented in Figure 25 and Figure 26, and in Figure 27 and Figure 28 by small red circles, by green circles over red circles and vice-versa, and by numbered yellow strip adhesives put on the bubbles. It is not possible to differentiate between green circle adhesives put in in this activity or in activity 1.4. A blue circle adhesive was used in Figure 28 to indicate a so far unknown and very specific actor in emergencies in industrial areas in Brazil: the community leaders. In fact, this actor is a council of community leaders which includes e.g. religious and commercial representatives.

104

Figure 25: On-site actors in European industrial areas

Figure 26: On-site actors in Brazilian industrial areas

105

Figure 27: Organization structures off-site in European industrial areas

Figure 28: Organization structures off-site in Brazilian industrial areas

106

Session 2: Emergency Management Process Activity 2.1: Identification of activities and respective actors

This activity consisted of drawing the model of the emergency handling process in the two regions: Brazil and Europe. The process model should contain the process activities, actors and workflow starting from the detection/notification of the incident until the end of the emergency situation.

Each representative of industrial areas received a panel paper and an envelope. The envelope contained a set of colour rectangles with names of potential activities and a set of colour bubbles with the name of potential actors. Both sets were prepared based on the process models that had been created by the representatives of the industrial areas before the workshop. In addition, they received extra colour bubbles and rectangles in blank for the case there were activities or actors not included in the set of previously prepared rectangles and bubbles. The set of prepared colour rectangles consisted of all activities, provided either by the European representative or by the Brazilian representative in their previous models, in order to maximize the changes of the selection of the same activities by the two groups during the workshop. The set of prepared colour bubbles consisted of all actors and were prepared in the same way. The representative of industrial areas also received their respective previously created process models. The envelope received by the European representative contained blue rectangles and red bubbles, whereas the envelope received by the Brazilian representative contained green rectangles and yellow bubbles.

The results of this activity are represented by the bubbles in Figure 29 and Figure 30.

Activity 2.2: Indication of specificities in the processes In this activity, each representative of industrial areas was invited to look at their respective

process model and indicate the activities that they believed to be specific to their geographic region (Europe or Brazil). For doing so, they should put red circle adhesives on the rectangles representing the activities.

The results of this activity are represented in Figure 29 and Figure 30 by the biggest red circle adhesives put on the rectangles. There are two sizes of red circle adhesives in Figure 30. The smallest ones have the same meaning but were included in activity 2.4.

Activity 2.3: Indication of commonalities in the processes

In this activity, each representative of industrial areas was invited to look at the panel with the

process model created by the other representative and indicate the activities that they believed to be common between their geographic regions (Europe and Brazil). For doing so, they should put green circle adhesives on the bubbles representing the activities.

107

The results of this activity are represented in Figure 29 and Figure 30 by the green circle adhesives put on the rectangles.

Activity 2.4: Mapping of different terms with similar/equivalent meaning

In this activity, each representative of industrial areas was invited to explain the process model

for his region. During the explanation, the other representative of industrial areas should check whether specificities were real specificities (if not, he should put a green circle adhesive over the previous red circle adhesive), check whether commonalities were real commonalities (if not, he should put a red circle adhesive over the previous green circle adhesive), and classify the remaining activities in specificities (using red circle adhesives) or commonalities (using green circle adhesives). Representative of industrial parks were asked to use yellow strip adhesives to indicate when activities did not have the same name in the model of the other geographic region as in his own model, but had very similar purposes. The yellow strips were numbered to make each mapping uniquely identified.

The results of this activity are represented in in Figure 29 and Figure 30 by small red circles, by green circles over red circles and vice-versa, and by numbered yellow strip adhesives put on the rectangles. It is not possible to differentiate between green circle adhesives put in in this activity or in activity 2.3.

Session 3: Mobile Crowdsourcing Solution Activity 3.1: Feedback on the current functionality and interface

The activity consisted on providing feedback on the current functionality and interface of the

Mobile Crowdsourcing Solution. All screens of the Mobile Crowdsourcing Solution and the interaction flow between them were captured on two panel papers with the same contents: one for the European group and another for the Brazilian group. The screens were organized according to the respective user profile. First the workshop moderator explained the three user profiles: workforces, supporting forces, and civilians (at this time, called operational forces, specialists and visitors, respectively). This was necessary because the purpose of this activity was also to check whether the set of screens for each specific user profile were adequate. After the explanation about the profiles, the moderator explained all screens and the interaction flow between them.

Figure 31 contains the feedback provided by the EU representative, whereas Figure 32 contains the feedback provided by the Brazilian representative. However, as this activity could not be performed in parallel with the two groups, at some point all workshop participants gathered around the panel initially delivered to the Brazilian group and provided feedback together. All feedbacks were captured in yellow post-it with the identification of the organization providing the feedback.

108

Activity 3.2: Indication of specific requirements In this activity, the representatives of industrial areas were explicitly asked to indicate

requirements on the Mobile Crowdsourcing Solution that were specific for his geographic region: Europe or Brazil.

The European representative had no specific requirements on the Mobile Crowdsourcing Solution. The Brazilian representative mentioned the need to support the community volunteers and the evacuation coordinator. There is an evacuation coordinator per company in Brazilian industrial areas.

Figure 29: Emergency handling process in European industrial areas

109

Figure 30: Emergency handling process in European industrial areas

Session 4: Emergency Response Toolkit Activity 4.1: Feedback on the current functionality and interface

The activity consisted on providing feedback on the current functionality and interface of the Emergency Response Toolkit. The main screens of the Emergency Response Toolkit and the interaction flow between them were captured on two panel papers with the same contents: one for the European group and another for the Brazilian group. However, in order to save time, it was decided that the developer of the Emergency Response Toolkit would explain all screens and the interaction flow between screens to all workshop participants by running the application directly and the feedback session would be performed with the two groups together.

110

Figure 33 contains the feedback provided by the workshop participants by putting yellow post-it on one of the Emergency Response Toolkit panels.

Figure 31: Feedback on the Mobile Crowdsourcing Solution from the European group

111

Figure 32: Feedback on the Mobile Crowdsourcing Solution from the Brazilian group

112

Activity 4.2: Indication of specific requirements In this activity, the representatives of industrial areas were explicitly asked to indicate

requirements on the Emergency Response Toolkit that were specific for his geographic region: Europe or Brazil.

Neither the European representative nor the Brazilian representative had specific requirements on the Emergency Response Toolkit in terms of functionality or interface. This might have happened due to the lack of time for the workshop moderator to investigate this matter more deeply during the workshop.

Figure 33: Feedback on the Emergency Response Toolkit

A.4. Conclusion

The workshop succeeded in capturing the differences and similarities between industrial areas in Europe and Brazil in terms of organizational structures and emergency handling processes. The workshop participants were very active and motivated to explain the organizational structures and processes, to answer questions about their models, and to provide valuable feedback on the ongoing

113

system solutions. After the workshop it is possible to use a common set of terms that abstract from the specific terms used in each geographic region without losing the information about the specificities between industrial areas in those two regions. As a result of the workshop, there is also a clear indication of what should be investigated in terms of specificities of the Mobile Crowdsourcing Solution for Brazilian industrial areas. However, it is necessary to organize further workshops to deeper exploit the specificities and commonalities in the Mobile Crowdsourcing Solution for the two regions, and especially to investigate the specificities and commonalities regarding the Emergency Response Toolkit.

114

Appendix B: Potential Features for the Third Project Iteration

Table 41: List of potential features for the third project iteration

Feature ID Feature Name Feature Type Feature Description SF15 Automatic publication in

social media Service Automatic publication of incident notification or report in social media defined by the user.

SF37 Coordination: Referring of patient

Coordination mechanism that is used to request health care in hospital (This request includes the product type, antidote, safety information of the chemical product, and victims characteristics)

SF18 Semantic Annotation Operation Annotation of multimedia data with semantic information. SF22 Data transfer among

operational forces Service Transfer of data among operational forces

SF22.1 Data transfer: Operational force to RESCUER

Operation Transfer of data from operational forces to Rescuer. Rescuer will be the platform for the operational forces to exchange data.

SF22.2 Data transfer: RESCUER to operational force

Operation Transfer of data from operational forces to Rescuer. Rescuer will be the platform for the operational forces to exchange data.

SF27.1 Crowd steering: Crowd Service Sending of instructions on how to get out of the place or how to help people depending on the profile of the user (willing to help). It is necessary to investigate whether the steering of employees of the industrial area is included here or their steering would have specific characteristics.

SF27.2 Crowd steering: Expert Service Sending instructions to expert from the operational forces or any other trained first responder. It is necessary to investigate whether the steering of operational forces is necessary.

SF27.3 Crowd steering: Volunteer Service Sending instructions to volunteers who leave around the industrial area and contribute to safety around the industrial area in a regular basis. It is necessary to investigate whether their steering would have specific characteristics. The communication mechanisms will probably be different..

115

Feature ID Feature Name Feature Type Feature Description SF27.4 Crowd steering: Affected

community Service Sending instructions to the affected surrounding community. It is necessary to investigate

whether their steering would have specific characteristics. SF28.1 Incident Communication:

Company Service Communication of the incident to the employees of the company where the incident took

place. SF28.2 Incident Communication:

Industrial Area Service Communication of the incident to the employees of the industrial area where the incident took

place. SF28.3 Incident Communication:

Surrounding communities Service Communication of the incident to the surrounding communities of an industrial area.

SF28.4 Incident Communication: Public authorities

Service Communication of the incident to public authorities.

SF28.5 Incident Communication: Press

Service Communication of the incident to the press.

SF28.6 Incident Communication: General public

Service Communication of the incident to the general public. It is necessary to investigate whether their steering would have specific characteristics. The communication mechanisms will probably be different.

SF29 Message composition Operation Composition of messages from templates and specific incident information to a certain target audience.

SF30.1 Message Sending: Broadcast Domain Technology Feature

Broadcast of messages

SF32 Data usage control Service Management of policies that define who can use which data with which purpose.

116

deliverable d1.4.2 portability & variation management ......possibilities of sharing data since...

Documents