Software integration between external game APIs and theGameBus repositoryCitation for published version (APA):Naseeb, C., & Technische Universiteit Eindhoven (TUE). Stan Ackermans Instituut. Software Technology (ST)(2015). Software integration between external game APIs and the GameBus repository. Eindhoven: TechnischeUniversiteit Eindhoven.

Document status and date:Published: 25/09/2015

Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:openaccess@tue.nlproviding details and we will investigate your claim.

Download date: 29. May. 2020

Software Integration between external Game APIs and the GameBus repository

Eindhoven University of Technology

Stan Ackermans Institute / Software Technology

Chan Naseeb December 2015

SOFTWARE INTEGRATION BETWEEN EXTERNAL GAME APIs AND THE GAME BUS REPOSITORY

Eindhoven University of Technology Stan Ackermans Institute / Software Technology

The design described in this report has been carried out in accordance with the TU/e Code of Scien-tific Conduct

Partners

Information Systems Group

Synergetics

Eindhoven University of Technology

Steering Group

Pieter Van Gorp (Project Owner / Project manager) Luk Vervenne (Project Mentor) Pieter Van Gorp, Ad Aerts (Supervisors)

Date Document Status

December 2015 Public

Contact Address

Eindhoven University of Technology Department of Mathematics and Computer Science MF 7.090, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands +31402474334

Published by Eindhoven University of Technology

Stan Ackermans Institute Printed by Eindhoven University of Technology

UniversiteitsDrukkerij ISBN 978-90-444-1373-1

(Eindverslagen Stan Ackermans Instituut ; 2015/035) A catalogue record is available from the Eindhoven University of Technolo-gy Library

Abstract Many games exist to serve a unique purpose for different domains, so is the case with healthcare. However, when it comes to integrating such games to achieve healthcare benefits, and an integrated, enjoyable experience, not enough has been done due to factors such as shortage of resources, time to market and others. This report describes the design and implementation of the GameBus data model to realize such an integrated platform. This model is the technology independent core of the solution. Moreover, the model is a common language for different de-velopers and partners, which contributes to bringing the functional design closer to the software design. This report encompasses and explains all the different as-pects of the development throughout this project. These include problem analysis, system architecture, design and its implementation.

Keywords GameBus, healthcare, software integration, OOTI, layered design, Model View Controller, health and wellbeing

Preferred reference

Chan Naseeb, Software Integration between external Game APIs and the GameBus repository, SAI Technical Report, September 2015. (978-90-444-1373-1)

Partnership This project was supported by Eindhoven University of Technology and the information systems group at the Industrial Engineering department of TU/e.

Disclaimer Endorsement

Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily con-stitute or imply its endorsement, recommendation, or favoring by the Eind-hoven University of Technology or the information systems group at the In-dustrial Engineering department of TU/e . The views and opinions of authors expressed herein do not necessarily state or reflect those of the Eindhoven University of Technology or the information systems group at the Industrial Engineering department of TU/e , and shall not be used for advertising or product endorsement purposes.

Disclaimer Liability

While every effort will be made to ensure that the information contained within this report is accurate and up to date, Eindhoven University of Tech-nology makes no warranty, representation or undertaking whether expressed or implied, nor does it assume any legal liability, whether direct or indirect, or responsibility for the accuracy, completeness, or usefulness of any infor-mation.

Trademarks Product and company names mentioned herein may be trademarks and/or

service marks of their respective owners. We use these names without any particular endorsement or with the intent to infringe the copyright of the re-spective owners.

Copyright Copyright © 2015. Eindhoven University of Technology. All rights reserved. No part of the material protected by this copyright notice may be reproduced,

modified, or redistributed in any form or by any means, electronic or me-chanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the Eindhoven Uni-versity of Technology and the information systems group at the Industrial Engineering department of TU/e.

vii | P a g e

Preface This technical report presents the results of the GameBus project. This project was carried out as a final assignment for the Profes-sional Doctorate in Engineering (PDEng in Software Technology) degree program at the Eindhoven University of Technology (TU/e). This assignment was part of the EIT funded large project “Game-Bus” in the EIT’s action line “Health and wellbeing”. GameBus is a joint project involving different partners around Europe, centered on gamification of healthcare with TU/e as its leader. In this report the development of the GameBus backend is elaborat-ed, which is the basis for the integration of different game APIs to the GameBus repository. For readers not familiar with the problem domain Chapter 3 is a good starting point. For the readers interested in design and implementation aspects, Chapter 5, 6 and 7 should be useful. For those interested in the context, goals and the results of the project Chapter 1, 2 and 10 provide a sufficient understanding. Chan Naseeb, December 2, 2015

ix | P a g e

Acknowledgements A project can never be done independently. This project is yet an-other proof of that statement. This project would have never been a success story without the help and guidance of several people. First, I would like to thank my supervisors, Ad Aerts and Pieter Van Gorp for their guidance, feedback and discussions throughout the project. They helped me in considering also different perspectives, which could have been missed otherwise, and gave me some good tips off and on. I would also like to thank Synergetics staff who provided useful in-puts to the project. I would like to express my special gratitude to Ad Aerts for all his valuable inputs and especially during this project and in general for two years during the PDEng program and Maggy de Wert for all her support. It would be unjust not to express a very special gratitude to all my PDEng colleagues for making the past two years an amazing and incredible experience. Last but not least, I would like to thank my parents (best teachers in the world) Muhammad Ismail and Jamila Akhtar for their uncondi-tional support, love, affection and continuous support for all my family members. Finally, I would like to thank my friends and all others who have contributed, helped me in one way or the other. Thank you all, Chan Naseeb December 2, 2015

xi | P a g e

Executive Summary There are many apps going around independently that basically fo-cus on one particular aspect, be it fun, social or physical activities. They fail to give us a unique and combined experience in terms of

a. Social, physical and cognitive wellbeing b. Integrated or joint gaming experience encouraging staying

together c. Seamless integration

This report describes a project to design and develop the system that will help to achieve an integrated gaming experience for games aimed at social, physical and cognitive wellbeing. This system pro-vides further the possibility for game providers to integrate their games into GameBus platform as well. This project aims specifically to achieve a modular design with characteristics of extensibility and loose coupling, integrating three different games and leveraging their data for enrichment of the GameBus platform and further utilizing it for creation of gaming challenges. This is realized with the help of RESTful service end-points such that others could also integrate to the GameBus plat-form. In order to let them do the integration without any further support, a usable and easily understandable documentation was also written. The GameBus integrates the games Strava, Griddlers, CAMEO and cognitive games from Telecom Italia. Strava is integrated through the Tapiriik (via DropBox) service, which lets the platform collect all user’s activities and store them into the platform. (2) Griddlers game is connected to the platform through its REST endpoint. (3) CAMEO a social togetherness measurement middleware developed by CNR Italy is also connected through the REST endpoint of GameBus. (4) It also integrates through REST endpoint the cogni-tive games developed by Telecom Italia. All these integrations are based on the domain model, which was developed at the early stag-es of this project. This project brings the following values: the isolated games can now be hooked together for a common purpose, and that can be eas-ily achieved. The platform is extensible to suit upcoming needs of the users. The system has a modular design based on modern tech-nologies, which would help for further extensibility. The compo-nents are loosely coupled to enable both flexibility and separation of concerns. We recommend using and deploying this system on a trial basis in both Italian and Dutch community because of the collaboration and available local support. This would not only prove its success and usefulness, but would also provide further feedback and dimensions

for its future development. Last but not least, there is a huge poten-tial for big data analysis opportunities in the near future.

xiii | P a g e

Table of Contents

Preface ..................................................................................................... vii

Acknowledgements .................................................................................. ix

Executive Summary ................................................................................. xi

Table of Contents ................................................................................... xiii

List of Figures ....................................................................................... xvii

List of Tables .......................................................................................... xix

1. Introduction ....................................................................................... 1

1.1 Context ......................................................................................... 1

1.2 The Information Systems Group TU/e .......................................... 2

1.3. Assignment Goals ......................................................................... 3

1.4. Outline .......................................................................................... 4

2. Stakeholder Analysis ......................................................................... 5

2.1 Stakeholder Analysis .................................................................... 8

2.2 Collaboration & Communication Model: .................................... 8

2.3 Requirements .............................................................................. 11

2.4 Non-Functional or Quality requirements ................................... 12

3. Problem Analysis ............................................................................. 13

3.1 Software integration .................................................................... 13 3.2 Software integration issues.......................................................... 13 3.3 Main challenges and the approach ............................................. 14 3.4 Design opportunities ................................................................... 14 3.5. Data Model: ............................................................................... 16 3.6. Detailed problem description: .................................................... 16 3.7. The characteristics of the API .................................................... 17 3.8. Challenges .................................................................................. 17 3.9. Dependencies: ............................................................................ 17 3.10. Societal perspective .................................................................. 18

4 System Architecture ........................................................................ 19

4.1 Introduction ............................................................................ 19

4.2 Architecture Overview ............................................................ 19

4.2.1 Logical View ........................................................................... 20

4.2.2 Development View .................................................................. 21

4.2.3. Process View .......................................................................... 23

4.2.4. Deployment View .................................................................... 24

4.2.5. Use Case ................................................................................. 25

5. System Design .................................................................................. 27

5.1. Introduction .................................................................................... 27

5.2. GameBus Data Model .................................................................... 27

5.3 Patterns applied .............................................................................. 29

5.4. Usage Scenarios ............................................................................. 35

5.5. Packaging components ................................................................... 36

5.6. CRUD API ...................................................................................... 36

5.7. DropBox-Connector ....................................................................... 37

5.8. DropBox-Web hook ........................................................................ 37

5.9. Jaxb ................................................................................................ 38

5.10. Integration .................................................................................... 38

5.11.Integration of games ...................................................................... 39

5.12 Conclusion: ................................................................................... 41

6. Implementation ................................................................................ 42

6.1. Introduction .................................................................................... 42

6.2. Individual Scope ............................................................................. 42

6.3. Technological choices for the implementation efforts ................... 43

7. Verification & Validation ............................................................... 45

7.1. Verification ..................................................................................... 45 7.1.1. System Testing ........................................................................ 45 7.1.2. Unit Testing ............................................................................. 45

7.2. Validation ....................................................................................... 45 7.2.1. Object Diagrams ...................................................................... 45 7.2.2. Prototyping .............................................................................. 45

8. Deployment ...................................................................................... 47

8.1. Deployment at Islab Server ........................................................ 47

8.2. Deployment at WSO2 ................................................................. 48 8.2.1. Synergetics Enterprise Service Bus (ESB).......................... 48

9. Conclusions ...................................................................................... 49

9.1. Project results ................................................................................ 49

9.2. Domain Model as central point of contact ..................................... 50

9.3. Next Generation GameBus ............................................................. 50

9.4. Other results ................................................................................... 50

9.5. Future work .................................................................................... 50

10. Project Management .................................................................... 51

10.1 Project Planning and scheduling .................................................. 51

xv | P a g e

10.2. Work Breakdown Structure (WBS) ............................................... 53

11. Project Retrospective ................................................................... 56

11.1. Introduction .................................................................................. 56

11.2. Design opportunities revisited ..................................................... 56

Glossary ................................................................................................... 58

Bibliography ............................................................................................ 59

References ............................................................................................. 59

Appendix A ............................................................................................ 60

Appendix B ............................................................................................ 60

Appendix C ............................................................................................ 60

Appendix D ............................................................................................ 60

Appendix E ............................................................................................ 60

Appendix F ............................................................................................ 60

About the Author .................................................................................... 61

xvii | P a g e

List of Figures Figure 1- Information System group’s research clusters .................................... 2 Figure 2- Stakeholders involved in the GameBus project ................................ 10 Figure 3- A different view of stakeholders involved ....................................... 10 Figure 4- Package Decomposition at the top level with reference to figure 4 above

.......................................................................................................... 22 Figure 5- Package Decomposition of src.main.java ......................................... 23 Figure 6- Sequence in the Process View ........................................................ 24 Figure 7- Deployment perspective ................................................................. 25 Figure 8- GameBus Use cases....................................................................... 26 Figure 9- DAO applied in GameBus context (Adapter) ................................... 30 Figure 10- Interaction between participants in DAO pattern [7] ....................... 31 Figure 11- DAO Pattern with MySQL ........................................................... 32 Figure 12- DAO with MySQL and Sqrrl ........................................................ 33 Figure 13- Business logic layer ..................................................................... 37 Figure 14- integration scenario for End users .......................................... 39 Figure 15- integration scenario for external games having a REST API .. 40 Figure 16- Integration scenario for trusted apps with REST API .............. 41 Figure 17- Data model with operations .......................................................... 42 Figure 18- Deployment option 1 Islab server .................................................. 47 Figure 19- Deployment option 2 WSO2 server ............................................... 48 Figure 20- Four step project management strategy .......................................... 51 Figure 21- Project Plan w.r.t Documentation .................................................. 54 Figure 22- Overall Plan A- Tasks w.r.t Deadlines ........................................... 54 Figure 23- LogBook- Daily Tasks Tracking ................................................... 55

xix | P a g e

List of Tables Table 1- Components in the logical View ...................................................... 20 Table 2- Use Case 1: Play a Game ................................................................ 26 Table 3: Project results ............................................................................. 49

1

1. Introduction The project is introduced briefly here, along with the introduction to the information systems (IS) group at the Industrial Engineering de-partment of the TU/e. The main activities performed by the IS group are outlined. In particular, the GameBus project is elaborated along with its work packages and its goals. GameBus is an externally funded project within the EIT ICTLabs ac-tion line Health and Wellbeing. The project aims to deliver a novel app that could make monitoring various activities of life an enjoyable gam-ing experience. The main focus is to let people play games in such a way that it becomes a part of a socially integrated interaction with their environment, friends, family, and neighbors. This report focuses on the part of the project that lies under “Software Integration and testing” with the title “Software Integration between external Game APIs and the GameBus repository”.

1.1 Context The “Software integration between external game APIs and the GameBus repository” project was conducted by the author as part of the fulfillment of his Professional Doctorate in Engineering (PDEng) in Software Technology (ST) degree program. This program is a two year, Doctoral level, technological designer program, which focuses on design skills, and prepares the candidates as technological designers. This paves the way for them to become System (or Software) Archi-tects later on in their professional career. The PDEng program spans two parts, the first (fifteen months) being in-house, intensive training and projects, while the second has a task to challenge the candidate about his design competencies along with oth-er technical and non-technical competencies in an industrial and opera-tional setting. In the second part, a nine month period, the candidate has to take on challenges such as project management expectations and risk management, as well as the architectural, design and (of course) implementation aspects of the project. He is expected to deliv-er a quality solution based on the criteria identified in the initial phase of the project. This project lies under the final part of the program. Throughout the report, for convenience purposes, I will use the name GameBus or ‘this project’ to refer to the project “Software Integration between external Game APIs and the GameBus repository”. This project was initiated by Pieter Van Gorp (TU/e) in collaboration with Synergetics. One of the project goals was to support the partners involved in the GameBus project under the EIT ICTLabs action line “Health and wellbeing”. The more specific goal from the software per-spective is to realize the integration of different game components in such a way that in the future, other users or companies can also inte-grate their games using a well-documented standard procedure.

Synergetics[2] Synergetics is focusing on a personal data ecosystem. At present, they are mainly working in the healthcare and retail sectors to give the user more control over his data. Others areas of their focus include mobility and talent management. Synergetics acted in this project as a Storage layer provider.

1.2 The Information Systems Group TU/e The Information Systems Group [1] is part of the Industrial Engineer-ing and Innovation Sciences department at Eindhoven University of Technology. The group conducts research in Business Process Engi-neering by focusing on two application domains (smart mobility and healthcare) and two technological domains (Business Process Intelli-gence and Business Process Management) as shown in figure 1 [1]. This division of the application domain and the technology domain re-sults in four clusters given below. The GameBus project lies in the domain of the healthcare cluster.

Figure 1- Information System group’s research clusters

1.3. The Mission of the healthcare cluster is: “To analyze, design, improve, and support operational processes in healthcare by adapting methods, techniques and tools developed in the Business Process Man-agement and Intelligence (BPM and BPI) research” [1]. GameBus [2] is a one year externally funded project (for the PDEng trainee it is for nine months only) by EIT ICTLabs. The project aims to turn prevalently isolated gaming into an integrated interaction to pro-vide an enjoyable gaming experience. The key focus was to integrate a social dimension into the gaming experience that still can be enjoyed individually. In game playing situations, players stimulate each other.

GameBus

3 | P a g e

This positively affects their health [3]. Several advantages could be obtained through such gaming environments. For example, non-intrusively monitoring the elderly about their health decay and second, monitoring their cognitive capability. Another advantage, in the longer term, would be the big data emerging after deployment, which has a huge scientific and commercial benefit to offer in the near future. As a follow-on project, TU/e and Synergetics aim to extend this project with AasS (Analytics as a Service) in the coming years.

1.3. Assignment Goals The goals and responsibilities for this project (and trainee) as formulat-ed in the EIT ICTLabs proposal are

1. Design a data model for the centralized GameBus repository, which could encompass and leverage the domain concepts.

2. Integrate the RaPIDO app (game) with the repository 3. Integrate the Griddlers.net app (Game) with the GameBus re-

pository. 4. Integrate the Strava app to the GameBus repository. 5. Demonstrate the correctness (tests), security (OAuth) and per-

formance (optimization where applicable) of these three inte-grations.

6. Document how third parties (any game integrators such as Ital-ian National Research Centre (CNR, Italy) can connect their app “Context Aware MiddlewarE for Opportunistic mobile so-cial networks” (CAMEO) to the repository in an independent manner.

7. Mediate between the other human-centric and computer-centric project stakeholders.

The concrete assignment for this project consists of various game integrations, their tests, and documentation. This comes under software integration and testing activities. Briefly, the project is aimed at performing execution tasks for the following three GameBus packages: WP2: Design a GameBus specific data model, which supports the storage of game results based on the entities user/player and circle of friends. It should also be capable of providing the possibility for the repository to store the relationships between those entities. WP5: (i). Handle the integration of the external games such as cognitive games and the others by collaborating with Telecom Ita-lia, Griddlers.net, and Italian National Research Centre (CNR). (ii). Document the integration of an external game with the Game-Bus repository. This should enable third parties like Medisana1 to connect to GameBus without any support from Synergetics. WP6: Integrate two more games, namely RaPIDO and Strava.

1 http://www.medisana.com/

1.4. Outline This report describes the development of the GameBus platform for the support of social, physical, and mental well-being. The report’s organi-zation is as follows: Chapter 2 provides the stakeholders analysis. It elucidates the require-ments based on their interests. Chapter 3 presents the problem and the domain analysis, where the problem addressed during the course of this project is defined. It fur-ther identifies the design opportunities and the goals. Chapter 4 presents the GameBus system architecture. Various architec-tural diagrams are provided in order to explain the system from differ-ent views. This focuses on realization of the 4+1 view Model in the GameBus context. Chapter 5 explains the design opportunities, the design decisions made, and their rationales respectively. The details such as how to design such systems are addressed. A number of alternatives are examined and evaluated to make essential technological and design choices. Chapter 6 mentions important implementation details for the project. Chapter 7 discusses verification and validation methods and their re-sults accordingly. The focus in this chapter is on testing. Chapter 8 focuses on deployment of the project. Chapter 9 concludes the project report about the opportunities identi-fied and addressed and discusses the future prospects. Chapter 10 gives insights into the management that was executed throughout the project. It discusses the project schedule, the plan, the work break down structure (WBS), and the risk management. Chapter 11 reflects upon the entire process of the project. It also revis-its the design criteria to check whether they were applied / considered successfully.

5 | P a g e

2. Stakeholder Analysis This chapter presents the stakeholders, with their interests in the GameBus project. It further details the functional requirements based on their interests. The relevant/important non-functional requirements conclude this chapter. In order to realize the aims and goals stated in the previous chapter and in alignment with the mission of the healthcare cluster, it is of para-mount importance to understand and analyze the different types of people who are involved in this project or who (could) have an influ-ence on this project. Thus, at least, the following points needed to be considered:

1. The key stakeholders in this project.

2. The different roles they are expected to have.

3. In what capacity they influence this project

4. Their expectations in regard to the GameBus project.

Interests of Stakeholders List1 lists the stakeholders, their interests, the deliverables and where relevant, their roles. List 1- Stakeholders with their interests.

1. Stakeholder: TU/e. Pieter Van Gorp

Role: Project Manager Interests:

Apps Integrations (backend), Documentation

Deliverables expected: GameBus baseline product, with the integrations as mentioned in requirements.

2. Stakeholder: TU/e. Ad Aerts

Role: University supervisor Interests: PDEng requirements are met. Well-documented de-

sign with validated quality attributes.

Demonstration of the required integration Deliverables expected:

Design report, including design criteria and derived documents

(for instance a page in the 2015 graduation project overview

booklet)

3. Stakeholder: TU/e Carolina Gomez

Role: UI designer

Interests: Collaboration

Using mockups to check the tests Deliverables expected:

Realization of the backend services for the front end data

presentation

4. Stakeholder: Synergetics

Role: Storage Layer provider Interests:

Collaboration

API platform usage

Share & document knowledge about Sqrrl2 Deliverables expected:

Data Model

Communication

5. Stakeholder: Sagiton

Role: Developers of the Front end app Interests:

Implement services needed for the app.

API deployed Deliverables expected:

Data Model

API (interfaces)

Communication

6. Stakeholder: CNR

Role: GameBus Partner Interests:

Connect to GameBus.

CNR will provide the CAMEO middleware. This middleware

focuses on opportunistic social networks and provides the con-

text by utilizing them as described in [6].

API Documentation Deliverables expected:

Data Model

API (adapt or revise) 2 See http://sqrrl.com/

7 | P a g e

Documentation

Communication

7. Stakeholder: Telecom Italia

Role: GameBus Partner Interests:

Connect their games to GameBus

API Documentation Deliverables expected:

Data Model

API (adapt or revise)

8. Stakeholder: Griddlers

Role: GameBus Partner Interests:

Connect their game to GameBus

API Documentation Deliverables expected:

Data Model

API (adapt or revise)

9. Stakeholder: Sqrrl Staff

Role: Synergetics Partner Interests:

Use their platform in GameBus Deliverables expected:

Communication and feedback

10. Stakeholder: Yenlo (WSO2)

Role: Synergetic’ s partner and ESB provider for Synergetics Interests:

Use their platform for API deployment Deliverables expected:

Communication and feedback

10. Stakeholder: Yenlo (WSO2)

Role: Integration service Interests:

Integrate to GameBus

Deliverables expected:

-NA-

2.1 Stakeholder Analysis The stakeholders listed in Table 1 can be categorized into four types. The stakeholder types or groups are depicted in figure 2. Each of the stakeholders is unique in having its interest and influence on the pro-ject. The types of stakeholders are categorized based on their interests, simi-larity of the nature of their contribution in this project and alike. This categorization helps to see the bigger picture of their interests, the col-laboration and to see the extent of closeness and differences. The four types are

1. Developers 2. Sponsors or Customers 3. Partners 4. GameBus Users

Their collaboration and further details are given in the next section.

2.2 Collaboration & Communication Model: The stakeholders types of the GameBus project and their communica-tion and collaboration as illustrated in Figure 2 and 3, is described be-low. In Figure 2 the size of the circle indicates the importance of the contribution.

1. Developers They are responsible for creation of the GameBus infrastruc-ture, which would ultimately enable integration of other games or apps to it. All the developers have different kinds of respon-sibilities. As employee from TU/e, I am responsible for the core development and realization of the backend for this project. I collaborated and communicated with my colleague from Indus-trial Design on user interface aspects. In addition to this, both my supervisors were kept informed by me about the progress and I attained their feedback as well. Synergetics is a storage layer provider for the GameBus pro-ject. I needed to collaborate with them and also with Sagiton programmers since they developed the front end. I was also re-sponsible to communicate with Sqrrl, Yenlo and CNR to keep them updated about the progress and what features from them we could use in this project. The arrows show that since they were having some features, which could be utilized in Game-Bus, they were contributors as well. Besides close collaboration within TU/e and Synergetics (Sagi-ton), I was mainly communicating with CNR as they were

9 | P a g e

committed to integrate CAMEO into GameBus. For this they needed documentation and workshops for comprehension of the API and the Data Model.

2. Sponsors or Customers They are the ones who would provide challenges and rewards. For example ZuidZorg is a care organization interested in the Health and wellbeing of the people. With this category of stakeholders I had very occasional communications but these were helpful in having a broader overview of the project.

3. Partners The main partners were Telecom Italia, Griddlers and Tapiriik (Strava). I had to keep in touch with Telecom Italia and Grid-dlers about the progress, modes for integration, providing them the corresponding API specifications, holding workshops and providing support throughout the project. After the first four months, collaboration with them became more frequent. However, with Strava (Tapiriik) it was rather more integrating their app to our platform, so no frequent communication was needed as their documentation was quite good and the service, called Tapiriik, through which we needed to integrate made it even simple and easy.

4. GameBus Users Initially this project is focused to be launched in the Italian and Dutch community, so for that reason most of the initial tests were conducted with Italian and Dutch? users in mind. These tests were conducted in collaboration with my colleague Caro-lina (PDEng in USI trainee) but I was regularly getting the up-dates and communication.

Figure 2- Stakeholders involved in the GameBus project

Figure 3- A different view of stakeholders involved Figure 3 just gives a different view on the stakeholders of this project. On the top (level 1) is the project itself, and all the stakeholders men-tioned at level 3 belong to the stakeholders. The last (level 4), mentions about their role, which signifies how they would contribute to the pro-ject.

11 | P a g e

2.3 Requirements The requirements are deduced from list1, the stakeholder analysis and the collaboration and communication model. They are given below

1. Design a GameBus specific data model that supports the stor-

age of game results per game modality, per user, and per circle

of friends.

The data model will be input for the model-based development

of a repository for storing the physical, cognitive, and social ac-

tivity data.

This data model should enable the definition and evaluation of

cross game challenges.

2. Develop a web based data repository based on the data model

using Sqrrl Enterprise.

3. Initialize repository

4. Develop the first integrations of external (three) Game APIs

and the centralized repository.

a. Integrate Strava (through the Tapiriik service using Drop-

Box), which would enable connecting GameBus app with

multiple millions of users. The data will be pulled from

third party APIs (e.g., Strava) while in step (3) integration

is provided between APIs that are under full control of the

project partners (and TU/e in particular)

b. Handle the integration of the external cognitive game in

close collaboration with the programmers from Grid-

dlers.net. (e.g., based on the open source Open Sudoku pro-

ject of the popular Griddlers.net platform).

c. RaPIDO: a game for kids to perform more physical activi-

ties outside and in teams.

5. Provide API specification for plugging in game components.

6. Provide technical support during integrated experimentation

a. Integration and testing of Cog Games by Telecom Italia.

b. Integration and testing of CAMEO by CNR Italy.

7. Document for other programmers how to integrate an external

game with the GameBus repository. Thus enabling a third party

(e.g., Medisana) to connect to GameBus without direct support

from Synergetics.

8. Software Integration and Testing (Unit & Regression Tests)

9. API Development (REST based)

10. API documentation should be independently usable by third

parties for any further integration with GameBus.

11. A well-documented design with validated quality attributes.

2.4 Non-Functional or Quality requirements Qualities of the API (Extracted from stakeholders’ expectations):

1. Tested and the tests well documented: Test coverage and justi-fications for omissions and failures

2. Extensible 3. Usable and fully implemented API 4. Easy to integrate with for a third party app 5. Consistent 6. Validated against above listed quality attributes.

13 | P a g e

3. Problem Analysis This chapter presents a detailed problem analysis, design opportunities and design criteria in the GameBus project. It further mentions the challenges, and the dependencies. To conclude the chapter, it men-tions, which societal challenges this project would address at the global level of this project. 3.1 Software integration “Software integration between external game APIs and the GameBus repository” is not only an interesting but also a challenging software problem. The integration of commonly used and usable functions from different software applications (games/apps in this context) makes it interesting, while integrating third party software apps/games makes it challenging. The latter apps have (1) a different purpose for which they were designed, and (2) different interfaces through which they talk to other applications. Since the apps/games are external to the project, their interfaces are not under control in this project; they cannot be re-designed for the purpose of integration. In short, software integration is like system integration in the sense that in system integration we put together the system components (sub-systems) and ensure that they all work together as a system. In a simi-lar way and with the same aim, in software integration we link together different software components / modules. For software integration, it is quite possible that the integration prob-lems have not been solved earlier except in its broadest sense, like two games might have been integrated to some extent but not specifically for what we aim to do in this project. Therefore, the skill set needed is oriented towards breadth of knowledge, as we would need to cover dif-ferent aspects in the designed solution. According to Grady, “integration” is among one of the most “misun-derstood” concepts within system engineering. [7/18] 3.2 Software integration issues The software integration issues are 1. Mismatch between provided interfaces and required interfaces 2. In system integration we have access to all parts, which allows us to replace parts but in software integration we don’t have access at sys-tem level 3. The software is written by engineers with different level of expertise 4. To integrate well, you need to know the software behavior, which part does what? But mostly it has poor or no documentation. 5. Assumptions or technology choices made are not communicated/ or documented The aforementioned issues make software integration relatively hard if not impossible. This is exactly what the GameBus project tries to solve: create a com-mon communication infrastructure (bus) and collaborate with the crea-

tors of the games to have them provide the proper interface. When this is successful, GameBus may become a de facto standard. 3.3 Main challenges and the approach The main challenge in this project was to provide prospective game integrators with a generic domain model, which would not only enable integrations from different game vendors but which could also address and capture a set of game specific features. Another challenge was to cope with the diversified knowledge of the “health and wellbeing” domain and the way the different software ven-dors represent it in their games (or apps). As per my knowledge, there is no standardized way to represent such data, although we hope that, this will change. There are standards such as HL7 [18] for the transport of health related data that are widely used, but this probably does not include gaming data. Since it seems unrealistic to cover the entire domain knowledge within the timespan of this project, the focus was to model a stable core in such a way that it remains extendible. It is preferred to model the core (smaller part of the domain) in a best possible way rather than to have a huge part modeled but not in a proper way. Additionally, the system should be maintainable and extendible with any possible future inte-gration that is compliant with the domain and the concept this project focuses on. This was done by identifying the backbone of the model, to which later it is easy to attach independent feature(s) or purpose specif-ic extensions. It would be problematic to modify this core, once it has been published, since this would imply migration of the already im-plemented and populated databases. This is the sort of maintenance that we would never want to do. Due to the nature of the project and the challenges that it brought, an iterative and prototypical methodology was applied. The first month was focused on developing the understanding of the domain, scoping the project, and other such foundational tasks. After that, the realiza-tion of the concepts was performed in weekly iterations (see. chapter 13). Due to a number of uncertainties, varying expectations, starting from scratch, and abstractions that needed to be concretized, the iterative approach proved useful. Prototyping, instantiating, refining, and apply-ing design-for-change principles were the key elements that substanti-ated the iterative approach in realization of this project. 3.4 Design opportunities At the beginning of this project, at least three design criteria were deemed as appropriately applicable, out of nine as defined by K.Van Hee and K. Van Overveld[4]. Besides the criteria chosen as applicable, two design criteria items were selected as not applicable in this con-text. They are presented with the analysis hereunder.

15 | P a g e

The Design Criteria that may apply: 1. Complexity (handling the complexity of software integration,

Does it acquire a complex structure?) 2. Realizability

a. Technical realizability (Can it be made technologically?) 3. Documentation: Documented API 4. Verification & validation: Test coverage. 5. Impact: What does this (artifact) mean for the environment? What

impact would it have on the software community? a. Education or instructional b. Prospects for Synergetics

I have chosen Complexity, Realizability and Documentation as my top three for this project. Although, each of the above is explained below, only first three would be considered and applied in this project. Complexity is the first among the three chosen criteria items. The de-sign was aimed to handle (address) the software integration complexi-ty, by capturing the domain concepts well in the software. So the de-sign should reduce the complexity. Realizability is another design criterion, which has two aspects: tech-nical and economic realizability. Economic realizability is out of scope as it does not concern my design effort. So the whole focus was on the technical realization of the GameBus software. Documentation of the API is yet another design criterion, which could make it easy for other programmers or third party app integrators to integrate their platform to GameBus and understand the GameBus API. Verification & validation is the second last criterion. Verification in-tends to demonstrate whether the system is built right (i.e. according to specs); this can be done by testing. Validation intends to demonstrate that the right system has been built, i.e. whether the specs were the cor-rect ones and captured the intention of the customer. Impact is the last criterion deemed applicable. It focuses on how the artifact produced affects its environment. This will not only impact the people in how their data (health) is monitored and they are informed but also, when the reference software is rolled out, what impact this could have on the software community, achieved through documenta-tion. It is important to note that the last two criteria items were not chosen due to time constraints.

The two Design Criteria that do not apply.

1. Elegance (Esthetics): Does it have aspects of beauty?

2. Genericity: Is it reusable in another context, best practices?

Elegance (of the API or Data Model) is one design criterion, which was not emphasized during this project. This is because the aim was to realize the backend, which is not directly related to the way how it has been constructed. Elegance of a design or an implementation reflects the way in which it has been structured and crafted. When a design or piece of code is at exactly the right level of abstraction, i.e. contains all the essentials and nothing more, it becomes easy to understand and fol-low through. It then emanates a sense of logic or order which is appeal-ing. The use of standards facilitates this, but also the choice of classes and patterns helps a lot. On the other hand, for the software community the concepts used and realized during the development of the system are somewhat explicit, so none of the realized aspects should come across as a surprise to the software community. Also, the focus was on utilizing existing software /apps to keep the focus on integrating rather than beautifying them. Genericity is another design criterion, which was not applicable as each project is unique in its goals and the intended use. So, this is not reusable in a different context (as opposed to a similar or identical con-text). 3.5. Data Model: It was required to design a GameBus specific Data Model, which con-tains a number of entities and their relationships such that it enables the programmers to capture and store the games’ and their players’ data into the GameBus repository. The Data Model has to be generic but it should support initially at least three games, namely (1) Strava (through Tapiriik), (2) Griddlers, and (3) Cog Games: The latter in-cludes cognitive games, which are designed by neurologists at Tele-com Italia, to train cognitive features, such as memory and attention.

Initially, RaPIDO was planned to be integrated into GameBus. We found out at a very early stage that RaPIDO was not mature enough for integration and hence out of scope. RaPIDO encourages children to participate in physical activities outside so that they could keep their physical health in a good condition. 3.6. Detailed problem description: “Design a data model, which Synergetics staff could use for generating the centralized GameBus repository. Integrate three different Games (as decided by the Project Manager) with the GameBus, such that their data is stored in the repository where it can be used for querying. These integrations should demonstrate correctness, security, and perfor-mance. The integration process should be documented in such a way that third parties could connect to the GameBus repository without any help from the Synergetics staff. Mediate between human-centric and computer-centric staff for communications and discussions on different

17 | P a g e

aspects of the project. Deliver tested results based on standard web technologies (such as JSON and OAUTH) under planned activities.” The core of the problem from the software perspective is “software integration & testing” where I had to integrate various games and en-sure that they are integrated well with the GameBus. Of course, one expects to encounter integration related problems due to the difference of the interfaces provided and required. The second aspect would be to make the backend for the integration of various games in such a way that, there is a room for extensibility. One thing was to integrate one app, and document it based on the first experience insights, integrate the second one. Building on experience naturally helped in improving the integration process. Secondly, a modular approach was followed which helps if a component is integrated or needed to be removed or enhanced.

I had to realize the integration (goal) of a number of games, in the form of creating API's (features).

3.9. The characteristics of the API

The API should support storage of results for different modalities such as per user, game, and circle of friends. It should be documented in such a way that third parties could connect to GameBus, without any further support. It should be accessible by third parties through a RESTful endpoint. The API’s qualities have been summarized earlier in section 2.4

3.10. Challenges 1. Deliver properly tested software for the users 2. Use state of the art technologies (such as JSON and OAuth) 3. Meeting time constraints is a challenge since there are new

technologies involved that need to be learned and then used in this project’s context.

4. Lead the API integration and testing 5. Mediate between Synergetics programmers and USI designer 6. Deliver quality software as demonstrated by unit and regression

tests.

3.11. Dependencies: 1. Synergetics staff needed a data model from which they could

generate a web-based storage repository using Sqrrl Enterprise (secure, scalable, and flexible NoSQL database).

2. I developed API for the first integrations of external Game APIs and the centralized repository

3. CNR needed the API to integrate their social wellbeing compo-nent to the GameBus.

3.12. Societal perspective At a global level, this project is supposed to address the following societal challenges

1. To counter social exclusion and cognitive decline for elderly people and at the same time increasing physical activities for both the elder and the younger generations.

2. To seamlessly monitor elderly people about their health (e.g. cognitive decline, reduction in social interactions, and reduc-tion in physical activity levels. There is a problem with these from the point of view of deterioration).

3. To provide a novel means to empower family members in tak-ing care of one another; this is needed due to cutbacks in the re-imbursements of professional care.

All this has to be done with the help of well integrated games. My project’s contribution would be to provide the platform for this, that is to realize a backend from software perspective, which would enable all this as a gaming experience, thereby helping to address the above stated societal problems.

19 | P a g e

4 System Architecture This chapter details the system architecture for this project. It explains to some length the chosen architecture. 4.1. Introduction This chapter provides a comprehensive description of the architecture. This description is based on the 4+1 architecture model [8]. This model focuses on 4 + 1 architectural views to describe the different aspects of the system that concern different stakeholders and an extra view with the use cases. Each of these views presents the most significant arti-facts and possibly related architectural decisions:

• The Logical view describes the system from the conceptual point-of-view. It focuses on the functionality, which elements provide this and how the different elements interact.

• The Development view describes the system from an imple-mentation point-of-view. It focuses on the structure as seen in development.

• The Process view describes the system processes and their communication. It focuses on modeling the system into com-municating tasks. It considers quality attributes of the system as well.

• The Deployment view describes the system installation and ex-ecution options. It focuses on the environment where the sys-tem gets deployed. It is often a bridge between hardware and software worlds.

The next sections are described with the help of diagrams and architec-tural pattern(s). For detailed understanding of the pattern(s), please re-fer to [9] and [10].

4.2. Architecture Overview The GameBus backend is based on the following types of component: Business Logic, RESTful endpoint (CRUD Services), and storage (Da-ta Access layer). The solution is based on the application of different architectural pat-terns, design patterns and methods in the field of software engineering. Some of those applied techniques or patterns have been replaced at lat-er stages of the project with a better alternative or because of changes in the requirements; all such details are mentioned in the next chapter “System Design”. The main layers of the System can be seen in Figure 4. These compo-nents are given from a conceptual, development, process and deploy-ment perspective in the following sections.

4.2.1 Logical View The logical view is concerned with the functionality that the system provides to its end users, supporting functional requirements and show-ing how the system is decomposed into a set of different abstractions.

Figure 4- Logical View Components

This is a layered architecture, in which we have 3 layers: (1). The Rest-ful layer for client requests. (2). the business logic layer for all the business logic functionalities, and (3): the storage layer representing the data storage and repository. This architecture addresses reduction of the complexity through modular design which enables extensibility and loose coupling between the components. The arrows depict dependencies and they all point on way (from right to left, according to the principle of separation of concerns: the left-most layer does not know about the details of a more right side layer. The arrow which is shown from storage layer towards the Business logic is just for the response.

Table 1- Components in the logical View Component Elements Business Logic Business rules, functions, core

functionalities implemented RESTful Endpoint: GameBus API

REST based endpoint for others to have access to the GameBus ser-vices. Contains the GameBUS API endpoints.

Storage: Repository & Data Mod-el

The Data Access Layer which is generated as Repository based on the data model. The domain model, which is at the core of the solution since, all the games’ and players’ data is stored based on this data model.

21 | P a g e

This view is more about how the different classes interact with each other. The Data Model below shows the information (entities) and their structural relationships. The behavioral interactivity is shown later in the next chapter, where methods are also represented in the diagram for the respective classes. This is shown below which is exactly imple-mented as the links between different entities here dictate. The relevant class diagram is shown below.

Figure 5- The Data Model

4.2.2 Development View In this view, the architecture is described from an implementation point-of-view. The conceptual components introduced earlier in the logical view are further elaborated and explained based on the techno-logical constraints and the non-functional requirements. From software designer’s perspective, this view uses component or package diagrams, which illustrates how different packages are cou-pled together. Every package (or component) contributes differently to the system.

Figure 4- Package Decomposition at the top level with reference to figure 4 above

1. Package src.main.java contains further 13 packages as repre-sented in Figure 7. This figure covers most of the figure 4 above in its main package, especially the whole of Business Logic layer.

2. Package src.main.resources contain the resources, which are required by both main.java and test.java packages. These in-clude any configuration files, system level properties and vari-ables for which we want to keep values but we do not want to expose them directly in the src package.

3. Package test.java contains the tests for the functionalities of-fered by the main packages, thus it requires them to be tested.

23 | P a g e

Figure 5- Package Decomposition of src.main.java

This Figure is further elaborated in 5.5. Packaging components The above is appropriate since our system is a Java implementation of APIs, where different APIs call other APIs to fulfill different business requirements. Since usability and extensibility are two important non-functional re-quirements in this project, a framework which can organize well the users’ inputs, can control the data model and is able to present different views is preferred choice. Therefore, the Model – View – Controller (MVC) architecture pattern is applied. For further details, please see [11], [12], and [15]. This pattern separates the entire architecture (Figure 4) into three parts:

• Model: containing application data. • View: Requests the information from the model that helps the

view to generate output for the user • Controller: Business logic, interpreting the inputs from the user,

manipulating the model and updating the view.

4.2.3. Process View This view discusses the dynamic aspects of the system and elaborates on the system processes and how they communicate. This view models the interactivity of the system.

Main Processes GameBus is executed in two main processes, in a server and as an app. It has to be running on the server such that the GameBus app can ac-cess its various functionalities offered by the GameBus platform. The dynamic aspects of the GameBus are shown in figure 6. Once the user sees that the server is running, and the corresponding app is running which means that it can call functions offered by the service. It will call the corresponding rest service as requested by the user.

Figure 6- Sequence in the Process View

4.2.4. Deployment View This view describes the mapping of the software components onto the topology of the physical layers along with the communication between these components.

25 | P a g e

Figure 7- Deployment perspective

The choices available for the deployment are described in detail in chapter 8: Deployment. The Figure 8 above represents the GameBus jar; which contains all the packages represented in Figure 4 above. This has to run on our IsLab server. For database, MySQL was used.

4.2.5. Use Case This shows a use case diagram, followed by a use case description “Play a game” based on template. The other use case descriptions would be quite similar, therefore they are skipped for brevity. The names of the other use cases are given below: 1. Register Google Fit as a game 2. Contribute a game 3. Communicate to player 4. Define a challenge 5. Manage a challenge 6. Set privacy controls 7. Manage Circles 8. Monitor Peer status 9. Add a challenge 10. Join a challenge 11. Check Leaderboard 12. Discuss with players 13. Monitor own status

Use Case Scenarios

Figure 8- GameBus Use cases

Table 2- Use Case 1: Play a Game Primary Actor: Player Context of use: the player wants to play a game that is available Scope: GameBus application Precondition: GameBus server is running and app is connected to it Success Guarantees: The user can log in to the system and the system can display the games that he is allowed to play and store his data on the server. Main Success Scenario 1: User registers to the GameBus Platform 2: GameBus stores the user in its database and redirect it to the home page 3: User selects a game from the platform 4: GameBus redirects the user to the selected game mode 5: User starts playing the game and accomplishes different levels of the game as he/she wishes so Alternate flows 1a: user is already registered in the platform Extensions 5a: The player invites other players to play the game The player joins a challenge The player creates a challenge

27 | P a g e

5. System Design The previous chapter provided a high level overview at the system lev-el and its architecture. In this chapter, the design for the components of the system architecture (Chapter 4) is emphasized. The goals, and the design decisions of the essential components are elaborated. Based on both functional and non-functional requirements, the major design is-sues are discussed and presented in this chapter.

5.1. Introduction The initial output of the “4+1” method could have been a good base-line to start working on explaining components in the proposed archi-tecture. However, I focused on improving the confidence about the system design and development by going through a few iterations. Af-ter describing an overall architecture, the concrete design issues are discussed in this chapter and implementation related aspects are cov-ered in the next chapter.

5.2. GameBus Data Model This model captures all the entities relevant for the GameBus project and their relationships. Figure 5 above shows the GameBus Data Mod-el. For better readability, find a more readable version in appendix A.

The colors in the model are meant just for development purposes and project management in terms of priorities. Thus, the priorities for de-velopment to progress were (1) green, (2) yellow, (3) purple, (4) blue and (5) gray for the rest of the entities. The green ones involved captur-ing and storing information about the activities of the player(s), gameDescriptors of the game and their corresponding properties. As each gameDescriptor has different properties, thus their corresponding data needs to be stored. The yellow colored ones include the points earned? Challenges and tags associated to a game. Purple ones include the reward, the sponsors, game, and who has the right to show chal-lenges. Blue ones contain, the role, point mappings based on the role, rules related to challenges, their conditions and the operators for them. Last but not least, Data provider signifies the provider of data such as Telecom Italia or CNR Italy and TokenForDataProvider has the corre-sponding tokens. These tokens are used to identify and grant access, and are strings.

The description of the entities present in the model is given below:

Game is an entity that describes the game that is being played.

GameDescriptor: describes the game Descriptor of a game. As a

game can have many game descriptors, which vary from game to game

but they are different parts of a game.

GameSession describes the game Session of a player in which he or

she plays the game. Stores the details of time, if it is manual or not.

User: is a person who uses the system

Player: is a user who plays a game

Property: describes any attribute against which a player will have val-

ues when he/she plays a game.

PropertyType: describes the type of the data that a property will con-

tain.

PropertyInstance: contains the instantaneous value of a property.

Circle: is a group or team of players

Support: is the number of likes a player gets in his game session.

Tag: Categorizes a game as being social, physical, or cognitive.

PersonalPoint: are the points obtained during a game session (or game

sessions) when a player participates in a challenge.

Participation: shows the participation of player in challenge(s).

Reward: is attained based on participation in challenge(s).

Challenge: is the concept which defines a target to be achieved by

players based on which they get rewards.

Operator: used to define conditions for a challenge

Condition: belongs to a challengeRule, and it helps in evaluating the

challenges.

ChallengeRule: help concretizing the challenge(s)

Sponsor: who sponsors a challenge? In our model a user can be a

sponsor; then such a sponsor (user) would have RightToShow chal-

lenge(s).

RighToShowChallenge: defines whether a challenge is to be shown to

a specific circle or not based on the sponsor’s rights.

DataProvider: are the provider(s) of data at present they are Telecom

Italia, Dropbox-Tcx, and Griddlers.

TokenForDataprovider: contains the token, which then DataProvid-

er(s) could give their users to use in GameBus.

Role: describes a role that a player can have.

PointMapping: are defined or assigned values (scores) based on the

role.

29 | P a g e

5.3 Patterns applied As the data model was the core in order to model the domain and capture the domain knowledge. An iterative approach was followed to design the data model. The reasons for this were (1) to build the understanding of the domain, (2) test and validate this understanding by prototyping the API based on that data model, (3) get the early feedback from partners and stakehold-ers. After the design of the data model, another design issue was about the Data Access. Problem: Access to data depends on the source(s) of the data. Access to a persistent storage also varies on type of the data-base technology such as RDBMS, OODBMS, and NoSQL and its implementation. In this project we needed to persist data. Some options are bean managed persistence, container managed persistence, and JDBC API. We can use these options when only one type of persistence storage is being used. In case of different types of persistent storage, this may create a direct dependency between the application code and the data access code. However, including the connectivity and data access code with-in the business components creates a tight coupling between the business functions and data source implementation. The design challenge is to reduce this coupling because otherwise such de-pendencies in components would make it difficult to deal with changes in the underlying data source. This tight coupling re-sults in changing every time the component (business logic) when a new data source is added. Solution: Use a DAO (Data Access Object) to abstract and encapsulate all access to the data sources. The DAO manages the connec-tion with the data source(s) to retrieve and store data.

• Patterns applied (used) in DAOs as explained in [9] are: • Adapter • Abstract Factory • Singleton

Figure 9- DAO applied in GameBus context (Adapter)

Here DAO is an adapter between the business object and the data store. The

DAO uses a transfer object to transmit data to the client. So the transfer ob-

ject acts as a data carrier. For more details on DAO pattern, please refer to

[7].

The sequence diagram in figure shows the interaction between the var-ious participants in this pattern.

31 | P a g e

Figure 10- Interaction between participants in DAO pattern [7] The factory pattern can be used to produce the required Data Access

Objects when the underlying storage is not going to change from one

implementation to another.

To make the application flexible, factory method and abstract factory

pattern are leveraged. When the underlying storage mechanism is go-

ing to change, the Abstract factory can be used. This in turn can use the

Factory pattern.

The factory method provides two advantages: Loose coupling and seg-

regation of responsibilities: instead of hard binding the whole logic for

the object we are assigning the responsibility to another object. The

only drawback it has is that it limits performance due to loose coupling

resulting in creation of additional objects.

Abstract Factory with only one database

Figure 11- DAO Pattern with MySQL

Singleton is used to restrict the instantiation of the class to one object. So there will be only one MySQL database instantiated. As shown in the middle of the diagram, MySqlPlayerDAO (MysqlActivityDAO, and MysqlChallengeDAO) represents the singleton. The entire tree organizes a number of singletons which is shown here to exemplify 3 of them; the arrow is just mean to visually emphasize the usage of the singleton pattern.

33 | P a g e

Abstract factory with two databases.

Figure 12- DAO with MySQL and Sqrrl Problem: We wanted to simplify development and maintenance of our programs. We wanted to be able to improve or modify individual sections without the need to know or touch other sections. In short, our aim was to achieve modularity.

Solution: Separation of concerns: It is a design principle which is aimed to separate a computer program into distinct parts such that each part achieves (contributes to / handles) a separate issue. In this project, I separated our programs into 3 different parts: Controller: Includes the controller part, handling of http requests. Service: includes the service level logic for the corresponding meth-ods. Response: This section contains and returns the response that is ex-pected and in the format that is expected. If the concerns are separated well, reusing, developing and updating such individual parts of the program is not only easy but can also be achieved independently. With logic separated into the different modules above, it has become well separated, not only for development, but also for updates in the code, as I have to only look for the relevant section, which would have been impossible in case of spaghetti code.

To achieve separation of concerns and decoupling, I used Spring MVC pattern [11], [12] to split the architecture into different stages. The Spring framework is an application framework and inversion of control container. It is a java platform that provides comprehensive support for development of java applications. Spring handles the infrastructure level details and lets the developers focus on their application. It sup-ports building POJO (Plain Old Java Object) based applications and applying enterprise services to those POJOs. The controller part represents the manipulation of the model element. The @Controller class annotation in Spring MVC is used to indicate that the class will serve as a controller. Spring does not enforce or re-quire extending or referencing any base class. The controller sends commands to the model layer to update its state. It can also ask the view to change its presentation of the model. Model: updates the view. View: Requests the information from the model that helps the view to generate output for the user. Spring framework supports building a JPA (Java Persistence API)[13] based data access layer. At early stages of the project, I have used DAOs to achieve the same. Usage of Spring Data JPA helped in reducing or even removing boil-erplate code I was writing for the service layer for retrieving the activi-ties. We annotate the class with @Repository to enable the exception trans-lation from JPA to Spring’s Data Access exception hierarchy. Besides this, we use @Transactional to ensure that the save operation performs as a transaction and to allow setting the read-only flag to true. In Spring Data JPA repository programming, we start with an interface for every managed domain object (the code that is written in Spring. An example of non managed code is code of a legacy application, which is not written using Spring). For example, for entity GameSes-sion, the interface would be like this:

Public interface GameSessionRepository extends JpaReposito-ry<GameSession, Long> { … }

This definition of interface serves two purposes. First, by extending the JpaRepository we automatically get a few generic CRUD methods into our system that allow saving game sessions, reading, deleting, and up-dating them. Second, this extension helps the Data repository to scan the class path for methods, thereby creating a Spring bean (an object that is instantiated, configured, and managed by Spring) for it. An entity is considered new, if its id property is null. Since the CRUD methods of the JPA repository are already annotated with @transactional, we can remove this annotation. However, to be explic-it, when looking at the service level operations, it’s better to keep this

35 | P a g e

annotation here as well, whether they are happening as a transaction or not. Additionally, if a service layer method was modified for multiple calls, all the code would still execute as a single transaction. All we do is introduce a new method on the repository interface level and dele-gate from our original method to the new method. Improvements: Performance optimizations for both the persistence layer and

the database layer. Refactoring Introduction of a repository layer Free the clients from the need to call merge, or persist on the

Entity Manager

5.4. Usage Scenarios In designing a system, the main scenarios are identified by use cases, object diagrams and unit tests for the system. All this al-lows the designer to identify and pinpoint the responsibilities of each component of the system. The same has been considered for the GameBus project. The following diagrams depict some of the scenarios (or features) addressed by the GameBus pro-ject. The use cases? presented before, in Figure 8, are described here.

Playing a game The main usage scenario is playing a game. This involves se-lecting the game that a player intends to play. Then of course he has to select which game Descriptor he is going to play. Thereafter, he can select whether he wants other players in his circle to play it together.

Joining a challenge Any player can join a challenge, which means he/she will par-ticipate in that specific challenge.

Manage a circle A player can manage a circle, means he/she can create a circle, add members to it, etc.

Defining a challenge: Both a programmer and a sponsor can define a challenge. For

example a challenge could be who will complete a 2 kilometer running challenge first? Or who solves a specific puzzle first and correctly etc.?

Contributing a game A GameBus partner such as Telecom Italia, CNR Italy can add a new game to the GameBus platform.

5.5. Packaging components The classes in the model are grouped in to different packages, accord-ing to their purpose. All packages along with their dependencies are shown in Figure 5- Package Decomposition of src.main.java (Chapter 4). API: contains the Spring application entry point. In case of multiple servers, here the rerouting could be configured. Configuration: contains the OAuth and Spring application security configurations. Some data initialization has been also done in this package. API.Details: offers the possibility to get users and its details. Exception: exceptions are configured here. Filter: GameBus CORS (Cross-Origin Resource Sharing) filters and mocked resources are configured in this package. Jaxb: contains the Jaxb code, which is used to transform tcx (Garmin Training Center Database xml file. Strava uses this format to store the data for its players. These are stored in user’s DropBox folder) files in to java objects, which are then stored into the JPA repository. Model: package contains first class citizens of the domain model that capture the concepts centered on GameBus. Entities are data-oriented, so they do not contain so much behavior. Repository: Repository contains the repositories for all entities where they offer different possibilities for searching over those entities. Response: offers the possibility to return the expected response by the app in the required format. For now this has been only done for activi-ties (Game Sessions) of the users. Service: enables the possibility to offer different services at the user and activity level. Such as registering a new activity or retrieving a new activity. Web: This contains the controllers for the services offered in the ser-vice package. Web Form: contains different forms such as signup form and activity. Servlets: contains the servlets for DropBox related authentication workflow in connection with the integration of a user’s data from Stra-va.

5.6. CRUD API The CRUD API made at early stages of the project, was exposing the data access to the client. It would have never been a good solution. So I decided to abstract away from that by creating a middle layer where the front app queries this middle layer and then this middle layer talks to the service layer. So, all that data access code is now hidden from the client. As a result, the client only gets what he needs without being exposed to how it is collected and where it resides. This service layer then returns the data in JSON format as expected by the mobile app. The mobile app is the front end part of the GameBus, which was de-veloped and delivered by Sagiton.

37 | P a g e

Figure 13- Business logic layer The business logic layer, as presented in Figure 4 before, is part of the overall GameBus platform. The components mentioned in the Figure 16 are described below:

5.7. DropBox-Connector One of the advantages of the GameBus is that the users can connect to different apps using a single platform. Strava is one such app, which is integrated into the GameBus platform through tapirijk service. And that service relies on the Dropbox in such a way that all the user’s data is stored in one folder of his/her Dropbox account. When a user wants to connect to DropBox from within GameBus, the user needs to allow the GameBus app to access the apps folder, such that GameBus could retrieve his activity data. This module focuses on realization of that connection and issues related to it. After the user al-lows the GameBus to access his DropBox (Apps) folder, the GameBus gets the access to it and stores an access token for that user.

5.8. DropBox-Web hook Through the Web hook DropBox notifies the GameBus app when the user files are changed in his DropBox apps folder, rather than requiring GameBus to poll frequently for changes. Every time a change happens in user’s files, the web hook URI specified at the configuration time will receive an http request informing it about the changes. This web hook strategy is used in combination with the delta, which can be peri-odically called to keep track of changes. The delta in DropBox context is a term (also a REST endpoint offered by DropBox), which refers to the changes in the files for any user. Other (less efficient and old fashioned) design choices were:

a. RSS feeds b. Sync API c. LongPoll_delta

d. Script on server plus parsing the change log file. Here techniques in b, c, and d are mainly for client side apps. For the server side we have delta, RSS feeds and web hook, where the last one is the most efficient and most recent one.

5.9. Jaxb By leveraging Java Architecture for XML Binding (Jaxb), I have man-aged to retrieve the contents of the tcx file and store them in the JPA repository. Later I retrieved the contents of the files from JPA reposito-ry and followed a natural step to check for the consistency of the val-ues. It is needed to be done so that we know the values retrieved are the same as what was stored on user’s behalf. This was achieved with the help of junit tests on both copies of the values (the ones in tcx file and the ones stored in our JPA repository). For retrieval, a better design alternative was XQuery instead of retriev-ing by java code with the dot method fashion. Due to time constraints, this was not fully applied and leveraged. However, I still recommend this as a good design alternative due to the following three reasons. When using XQuery:

1. You have to write less code 2. It is faster 3. And takes less memory than simple java code.

5.10. Integration The last step in design was, how the design would be realized when the games would be integrated into the GameBus platform. Here, I present a brief recap of what has been done until now. Integration effort started with hosting our partners at TU/e. We first started the integration of Cog Games into our GameBus platform. The process started at the very first step as unauthorized insertion of data, creating the entities for Cog Games into GameBus and persisting them. For this task, we had several discussions and later when our partners were able to integrate all their data, including the capability to specify the relations among entities, we decided to take the next step for realiz-ing authentication. After the authentication workflow was accomplished, we moved on to integrate another app: Strava. The data for players is stored in Apps folder in DropBox through a service called Tapiriik. I had to realize the DropBox authentication in such a way that when a user is asked about the access to his apps folder in DropBox, once he authenticates, GameBus would have access to his data in the “Apps” folder. After having granted access to a player’s activities data, the next re-quired step was how to use that data and process it, such that it could be stored in GameBus. For that I had to process the data, by first con-verting the xml-like file into JSON and then storing the relevant data through GameBus API.

39 | P a g e

The last integration started with the 3rd game from our partners, called Griddlers. Some initial requests besides authentications have been per-formed. This has been accomplished and is fully integrated in to the GameBus platform.

5.11. Integration of games This can be done in many ways. I have decided to pick an entity ori-ented one since it helps to model relationships between entities both at the model, and the API level. Thus the API can communicate on the basis of entities, while regarding their relationships. The different integration scenarios are given below. 5.11.1. Integration scenario for End users This case is represented in Figure 14 below.

Figure 14- integration scenario for End users

This diagram shows the procedure when an end user logins or signups in to the Game Bus app, the GameBus app will store its encrypted file into its Database. While on the other hand if CAMEO or CogGame needs to check for the validity of the user, they will read or decrypt the corresponding file. 5.11.2. Integration for external games with REST API This is shown in Figure 15 below. This is for any third parties, who wish to integrate with GameBus App and have their own REST API.

Figure 15- integration scenario for external games having a REST API

The GameBus App connects to such third party apps. That app checks for the validity of the token and other values? When they are correct, GameBus app gets connected with those apps and thereafter can use the services offered by them. 5.11.3. Integration for Trusted Apps with REST API This scenario is represented in Figure 16 below. This is applicable for trusted apps or partners having their own REST API.

41 | P a g e

Figure 16- Integration scenario for trusted apps with REST API

Trusted apps (those from partners) can use the GameBus credentials to use the GameBus REST API. If the credentials are correct, GameBus returns them a token which they can further use for calling the Game-Bus API.

5.12 Conclusion: In this chapter, the design for the components of the system architec-ture is emphasized. The goals and the design decisions of the essential components are elaborated. The major design issues are discussed and presented in this chapter. First the data model was presented, followed by the design issues and their solution, concluding with the choices of the framework, patterns and integration scenarios.

6. Implementation This chapter mentions some significant implementation details/steps for the GameBus project.

6.1. Introduction As part of this project, GameBus baseline product was realized. This baseline was based on the proposed architecture and requirements presented earlier. There are many technological options during imple-mentation of the system. Selection of the relevant and proper technolo-gies and their application to the overall architecture is of significant importance.

6.2. Individual Scope My individual effort for implementation scope consisted of the follow-ing:

• Design the Data Model • Generate the repository • Integrate Strava • Integrate Griddlers • Integrate Cog Games • Integrate CAMEO • Document for third parties

The data model after some operations have been added to the respec-tive entities is presented below. This served the purpose of partner dis-cussions, agreements on functions allowed etc.

Figure 17- Data model with operations

43 | P a g e

Here the operations for User and Game Session classes are added in to the diagram above. For details, and better readability, you are advised to see appendix C.

6.3. Technological choices for the implementation efforts Some of the technologies were chosen by the project partners even be-fore the start of the project. There I had no choice but to use them, un-less they become irrelevant or less useful based on my experience at the early stage of this project. The former ones included JSON, Sqrrl, and OAUTH. I had to choose the following technologies based on the needs and their suitability in the project’s context. DAOs: Data Access Objects:

Applied these patterns to make access agnostic of the underly-ing technology. More details about these can be found in the previous chapter “System Design”.

MySQL: Sqrrl was decided by the partners as the storage layer technolo-gy but later I found out that this is not mature enough, so I de-cided to choose MySQL as an alternative, since MySQL is ma-ture, popular, and easy to learn. After the first 3 months, mostly MySQL was used for data storage.

Tomcat: Tomcat was used as the server environment to run the applica-tion.it was used since it executes Java servlets and it can render web pages that include JSP code.

Servlets and JSP: Servlets were used to handle the DropBox authentication flow for getting access to Strava data through a service called Ta-piriik. JSP (Java Server Pages) were used for viewing the redi-rected pages after authentication. They were used since they are very handy in doing low level handling of the requests.

VMware (Or Virtual Box): Virtual box was used as the development environment after the first half of the project. Since the deployment was at the server, it was easy to debug and deploy while working in Linux envi-ronment instead of moving back and forth between windows and Linux and solving issues.

Jenkins: Jenkins was used for continuous integration and seeing the re-

sults of the tests. POSTMAN:

POSTMAN was used as a GUI (desktop) tool to execute the http requests to the GameBus service endpoint. The reason that this tool was used to execute the requests is for ease of use and user friendliness. However, over time, I realized that CURL is much more strong and easy to execute requests at the cost of less friendliness.

CURL:

CURL was used as a command line tool to execute the http re-quests to the GameBus service endpoint.

Junit: Junit tests are used to see the correctness of the methods writ-ten. Junit framework was used to enable execution of such tests.

JPA: JPA was used for persistence of the data model entities. Spring:

Spring framework was used as an application framework, as an IOC container, to automate many of the boilerplate code. It made developing the application easy based on POJO pro-gramming model.

Gradle: Gradle replaced maven for dependency management. It was far better than Maven, as you don’t need to worry about versions and such small details.

Maven: POM based dependency management model which was used in earlier stages of the project.

Enterprise Architect: This tool was used for creating all the designs, diagrams for this project. Jaxb Java Architecture for XML binding (Jaxb) was used in GameBus pro-ject for getting the data from dropbox-tcx files. Those tcx files have an xml like structure, thus I deployed Jaxb to do the Jaxb mapping and then store those xml tags as JPA objects in GameBus JPA repository.

45 | P a g e

7. Verification & Validation This chapter discusses the verification and validation techniques con-sidered during this project. The goal is to make sure that the required specifications are met. The latter focuses on the question “Are we building the right product”? And the former is concerned about “Are we building the product right?

7.1. Verification 7.1.1. System Testing For scenarios or end to end testing mainly, some manual tests were done at each stage when different modules were combined together. Due to time limitations, it was impossible to automate the system test-ing. 7.1.2. Unit Testing For verification of the object diagrams, the requirements or use case were used. The unit tests were the basic tool used throughout the pro-ject. This helped to answer the question are we developing the func-tionality right? Based on the results, the functionalities were enhanced or adapted in order to answer the question above.

7.2. Validation 7.2.1. Object Diagrams For validation purposes, object diagrams were used. They were gener-ated using an online tool as mentioned in [14]. They are all part of the Appendix G. 7.2.2. Prototyping Besides object diagrams, prototype was a second alternative which was used to ensure that we are building the right product or module. A number of iterations were performed based on the complexity for the module which was being developed. After each iteration, the feedback gathered either by manual tests, or insights was addressed in the subse-quent iteration.

47

8. Deployment In this chapter, we discuss the servers where the application is de-ployed, such that it is remotely accessible. Obviously, for testing pur-poses the GameBus application was deployed in first place at our ear-ly-age friend “localhost” but later we had two options as described be-low.

8.1. Deployment at Islab Server

Figure 18- Deployment option 1 Islab server

For deployment at the islab server, I configured port redirects. The following data illustrates that.

HTTP and HTTPS servers in VM and their ports. The main http server was configured to run on port 8081, which redirects to external port 8024. The HTTPS server was configured on port 443 which redirects to 8443. The jenkins server (for continuous integration) was deployed at port 8080, which redirects to the external port 8023.

8.2. Deployment at WSO2 8.2.1. Synergetics Enterprise Service Bus (ESB)

Figure 19- Deployment option 2 WSO2 server This deployment was tried at a very naive level, but due to time limita-tions a full deployment over WSO2 was not achieved. Nevertheless, this is very similar in many respects to the deployment at the islab server. The main advantage is that it provides all in one solution where you could also get statistics of API usage, Business Activity Monitor-ing, and other such features.

49

9. Conclusions This chapter concludes the project report about the opportunities iden-tified, addressed and discusses the future prospects

9.1. Project results The table below represents the goals along with percentage of remaining and achieved work products/tasks.

Table 3: Project results

Goals original eventual realized % remaining

DM Design √ √ √ -

Setup repo REST √ √ √ -

Integrate RaPIDO √ X Replaced by DB part of re-po

-

Moves X √ 30% 70%

Integrate Griddlers.net √ √ 30% 70%

Integrate Strava (Dropbox)

√ √ 90% 10%

Document √ √ √ -

Communication √ √ ~ NA

Correctness, security (tests)

√ √ 50% 50%

DB part of repo X √ √ -

Initialize reposito-ry…Sqrrl

X √ √ -

Original means that this requirement was planned or stated at the beginning of the project. And eventual means that what has ultimately been chosen or executed during this project. The crosses represent the absence of a goal at the start or at the end of the project.

9.2. Domain Model as central point of contact The main objective of this project is to make GameBus allow other ap-plications to integrate with its repository. By using the concepts de-fined in the domain model, third parties could map their domains to GameBus data model which would ease the integration process. Since the domain data model is at the core of the application, this becomes the one language for communication between any third party and GameBus. Thus anyone examining the code could easily understand what the software is doing.

9.3. Next Generation GameBus Another objective of this project is to allow the continuation of the pro-ject so that other services such as Analytics as a Service, integrated health monitoring and care could be offered basing on GameBus. The current state of GameBus presents some further opportunities:

1. The software can be extended 2. Other apps or games could be integrated

9.4. Other results Apart from what GameBus could be used for in future, some signifi-cant aspects/steps are given below, which were taken during the pro-ject, but not fully utilized. I think they could be valuable in future.

1. The data model is documented as it has grown through different stages. Such documentation could be useful for future entrants to the GameBus world.

2. Different techniques and design decisions were explored and documented

3. Sqrrl (a NoSQL based DB) was also examined besides MySQL and JPA. This was documented, but is not added into delivera-bles as per client request.

4. API is documented and was used by some of the partners. Their requests and queries are added to the documentation.

9.5. Future work This project was aimed at laying down the fundamental infrastructure for GameBus. Because of the time limits, the main focus was on cap-turing and modeling the “health and wellbeing” domain knowledge and realizing it in a future extendible manner. On this basis, the follow-ing possible directions could be chosen for application of GameBus results:

1. This data model can be extended to cover some other domains such as health related compliance and regulation procedures.

2. GameBus can be used in a broader context as a subsystem.

51 | P a g e

3. The GameBus can itself be enhanced further to cover future possible scenarios which might not have been relevant at the time this project was carried out.

4. Score infrastructure 5. Analytics as a Service

10. Project Management This chapter presents some insights into the management that was exe-cuted throughout the project. It discusses the project schedule, the plan, and the risk management.

10.1 Project Planning and scheduling The project can be divided in the following phases:

1. Planning 2. Learning 3. Prototyping 4. Documenting

In order to work out the above phases, I followed the following four-step approach to get the results iteratively.

• Plan • Execute • Evaluate • Adapt

Figure 20- Four step project management strategy At the beginning of the project, the focus was on planning the activities for the course of the project and their deliverables. In addition, the re-quirement identification was part of this phase of the project.

After the panning was made, a basic understanding of the domain was developed. The first step I took was to build a Data Model for covering the concepts associated with the domain. The Data Model was made in several small iterations. The next logical step was the execution of tasks to meet the goals set for the deliverables.

Then came the evaluation based on required or envisaged integrations for the GameBus project. Those Games enabled adaptation and exten-sions to the data model. The prototyping was handled on weekly basis.

Eventually, based on the achievements and mapping between domain model and apps, and the tasks accomplished, the planning was revised.

After the domain model was built, in the consolidation phase, the at-tention was shifted towards more technical aspects of the solution. This stage encompassed amongst others generating the repository based on our Data Model, learning/implementing in Sqrrl, and unit testing. Finally, in the integration phase, having the domain model, and the REST API in place, Cog game integration was performed as a Pilot integration which has definitely provided input for improvements. Then Strava was integrated into GameBus. The plan was presented to the supervisors during the first month. Af-terwards, a good deal of priority changes happened as a result of client and partner communication. This resulted in a lot of planning stress and regular changes. I had to adapt accordingly and this was one of the risks that were managed. Another risk was that we had ambitious part-ners and people working on the project, feeding in a lot of new or in-novative ideas. This was needed to be managed by sticking to the core of the project and its planning such that in the end we get to a working system not just ideas tried. One of the most challenging risks was if the partners don’t deliver on time how would that affect the project and its progress. As in every real life project, this did happen. Although it was challenging, my mit-igation strategy was to use a placeholder (alternative) or mock the de-pendent functionality such that I can still continue on progressing until the functionality gets delivered by the partner(s). By then, the corre-sponding mocked functionality was replaced by the one from the part-ners. During monthly Project Steering Group (PSG) meetings, firstly an overview of the past month’s progress (tasks and deliverables) was presented. Secondly, a more concrete plan was presented to the super-visors for the coming month. All important decisions were taken dur-ing these meetings regarding risks, and the deliverables. As a follow-up strategy, minutes of the meeting were sent either the same day or the very next day. After the initial learning phase, the problem was defined and the re-quirements were communicated using object diagrams, unit tests, and the initial project description. During the next few months, the Game-Bus repository was realized incrementally in several iterations. After that, integration options were discussed with the project manager and

53 | P a g e

other partners. Once the decisions were on the table, the project en-tered into the consolidation phase.

Throughout the project, the documentation was in focus, so it took dif-ferent forms such as object diagrams, screenshots, and cookbook. In first few months, there was a fast pace of writing a few chapters. At the later stage, when the API was realized, the focus shifted towards doc-umenting more “How-Tos” and “cookbook” kind of documentation. However, ultimately, the documentation was structured and put togeth-er a month before the project ended. The last month was spent on refining some loose ends and finalizing the documentation.

10.2. Work Breakdown Structure (WBS) Throughout the project, the work was done mostly in one week long iterations in an Agile fashion [16]. At the beginning of each iteration, the planned activities or deliverables (as presented in Figures 23, 24, and 25) were sorted out. They were then broken down further into tasks. Then on a daily basis, the tasks accomplished were noted down in addition to tasks postponed, or tasks having dependencies/delays, and tasks spanning more time than planned (see Figure 27: Tracking). Considering the progress of the previous day, tasks were taken for the next days. During each iteration, especially during first five months, we had a close collaboration with the project manager and user inter-face designer. In the first part of the project the task estimates were typically larger than at the later stage. This definitely had to do with the uncertainties and the unknowns involved at the beginning of the project.

A list of all tasks/features were maintained in the project LogBook in a chronological order, which has been helpful for traceability purposes. This iterative approach was suitable for the project. By regular demon-strations, the stakeholders had easily tracked the progress, and provid-ed their input.

Figure 21- Project Plan w.r.t Documentation This figure presents the date wise delivery of the documentation aspect

of the project.

Figure 22- Overall Plan A- Tasks w.r.t Deadlines This figure represents the tasks planned and their corresponding deliv-

ery date in alignment with the initial assignment goals of the project.

55 | P a g e

Figure 23- LogBook- Daily Tasks Tracking This figure presents the way I kept track of the tasks online such that they can be accessed by the project supervisors. Many of the tasks in-volved communicating, collaborating with the project partners, so a lot of time was spent on this too, in realizing this project. The planning, scheduling, WBS, tracking and risk management pre-sented above helped to achieve the goals of the project. In addition to that, they have given insights where it could have been done better.

11. Project Retrospective This chapter reflects upon the entire process of the project. It also re-visits the design criteria to check whether they were applied / consid-ered successfully. 11.1. Introduction I mentioned already, in the previous chapter, the project started with a learning phase focusing on learning the problem and its domain, baselining the scope of the project, and identifying an initial set of re-quirements. Additionally, while getting to know the stakeholders to the extent possible, I tried to meet their expectations during the project. The thing that remained helpful during the project was having regular meetings with the stakeholders, especially with the supervisors. These meetings were used as a tool to present my understanding of the do-main/project and to gather additional knowledge. In addition to that, the Project Steering Group (PSG) meetings proved to be a useful tool to steer the project and align our viewpoints, at the same point finding out the differences, and concerns of the parties involved. The domain modeling and engineering that were (intentionally) made in a less effi-cient way sparked discussions about how modeling should be done, and to this degree they (the modeling and engineering efforts) served the purpose for which they were planned. Moreover, the discussions also addressed how they should be modeled, instead of the chosen way of doing them in an inefficient manner. Near the end of the project, it became evident that clearly there is a huge scope in the GameBus project in many dimensions, including the design side. There are of course many opportunities within that dimen-sion that GameBus could benefit from. However, due to time bounds, only a few of the design opportunities were addressed. Nevertheless, they are strong enough to proof that the other opportunities could be addressed as the resources allow. At the quite early phases of the project, it became evident that integrat-ing the RaPIDO platform with the GameBus repository would not yield many results. Resultantly, this was removed from the assignment goals, since the RaPIDO game was not mature enough to be integrated into GameBus.

11.2. Design opportunities revisited The design criteria that were selected to be applied (or not) to this pro-ject as mentioned in Sections 3.5 and 3.6 are: Complexity, Realizabil-ity, and Documentation. The not applicable ones are Elegance and Ge-nericity. Complexity regards the extent to which the designed artifact is based on its structure. In this respect, all the complexity has been tackled by

57 | P a g e

application of separation of concerns, thus making the design more modular. Such that, when a developer needs to understand its structure or extends this code base, he could look in different modules inde-pendently and can easily understand what each different part does. This design criterion, in particular the Reduction of complexity indica-tor, regards the hierarchical decomposition in the design such that they are divided into separate components. The challenge during this was of course to reduce the structural complexity by creating more abstract or layered design. Realizability concerns if the project is realizable technically. In this respect, the project has been not only just realized but realized using the best design alternatives and technical choices. Documentation means it should be documented in such a way that any future developer or 3rd part willing to integrate their game with the GameBus platform should be able to do so without any further help. This has been achieved as per other standard counterparts. Additional-ly, to test the early integrations this is being used and adapted accord-ingly. Elegance regards the aesthetics or beautification of the project. If it concerns with GUI, it was not at all required as it concerned my efforts since my role was to realize the backend for the GameBus platform. However, if we relate this to the quality of the code produced in terms of readability, compactness, structure of the code (accessible class, se-quence and activity diagram), and being self-evident this seems appli-cable. And most of it has been achieved by application of the design principles, but it was not tested or measured quantitatively or qualita-tively. Genericity is another design criterion which was not applicable as each project is unique in its goals and the intended use. So, this project is not completely reusable in a different context without modifications and adaptations.

Glossary CNR TI SAI PDEng EIT ST TU/e UI API RaPIDO Cog Games JSON NoSQL CRUD DAO MVC RDBMS OODBMS JDBC JPA OAuth REST Jaxb XQuery

Italian National research Centre Telecom Italia Stan Ackermans Institute Professional Doctorate in Engineering European Institute of Technology Software Technology Eindhoven University of Technology User Interface Application programming Interface A game for kids to perform more outside physical activi-ties. Cognitive Games designed by TI to measure cognitive decay JavaScript Object Notation Not Only SQL Create, Read, Update, and Delete Data Access Object Model View Controller Relational Database Management Systems Object Oriented Database management Systems Java Database Connectivity Java persistence API Open standard for authorization. An open protocol to al-low secure authorization in a simple and standard method from web, mobile and desktop applications Representational State Transfer. An architectural style for distributed hypermedia systems. Java Architecture for XML binding An XML Query language

JSP POJO IOC POM XML HTTP HTTPS CAMEO SSH Islab WSO2

Java Server Pages Plain Old Java Object Inversion of Control Project Object Model, a dependency management file in maven Extensible Markup Language Hyper Text Transfer Protocol HTTP with SSL Context Aware MiddlewarE for Opportunistic mobile so-cial networks Secure Sockets Layer or “Secure Shell” Information Systems Laboratory The Open Source SOA company or “Web Services oxy-genated” company

PSG Project Steering Group

59

Bibliography

References 1. Information Systems, research group in industrial engineering

http://is.ieis.tue.nl/?page_id=243 2. GameBus Proposal ACCEPTED Call_15024_19+Sep+2014.pdf 3. http://www.livestrong.com/article/245944-how-does-playing-sports-

affect-your-health/ 4. K. van Hee and K. van Overveld, "Criteria for assessing a technolog-

ical design," 2010. 5. http://www.sei.cmu.edu/reports/07tr005.pdf 6. V. Arnaboldi, M.Conti, and F. Delmastro, CAMEO: A novel context-

aware middleware for opportunistic mobile social networks, Perva-sive and Mobile Computing (2013)

7. Core J2EE Patterns - Data Access Object, http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

8. Philippe Kruchten, "Architectural Blueprints—The “4+1” View Model of Software Architecture," IEEE Software, no. 12, pp. 42-50, 1995.

9. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software.: Addison-Wesley Professional, 1994.

10. Frank Buschmann et al., Pattern-Oriented Software Architecture Volume 1: A System of Patterns.

11. A Generic MVC model in Java, 12. Java SE application design with MVC, Robert Eckstein, March 2007 13. Spring Data JPA http://projects.spring.io/spring-data-jpa/ 14. http://instant-storyboarding.de/ 15. http://www.slideshare.net/sanjeevwebx/3-tier-architecture-2410697 16. Cockburn, Alistair, Agile Software Development. 17. Basic Use Case Template, Alistair Cockburn, 1996 18. Cockburn, Alistair and Highsmith, James A. (Eds.), the Agile Soft-

ware Development Series. Boston: Addison-Wesley, 2002. (0-201-69969-9)

Appendix A This appendix contains the data model in different viewings, split into two parts in order to help the reader for better understanding and read-ability. This has been hidden due to confidentiality reasons.

Appendix B This contains the data model. This has been hidden due to confidential-ity reasons.

Appendix C This contains the data model with operations. This has been hidden due to confidentiality reasons.

Appendix D This appendix contains the API documentation. This is to be used for any third parties who are interested in integrating their app into the GameBus platform. This has been hidden due to confidentiality rea-sons.

Appendix E This appendix contains a very detailed analysis of the stakeholders in-volved in the GameBus project. This has been taken away as to shorten this report and make it more concise. However, the readers interested in having more detailed view from stakeholders perspective, could go through this appendix.

Appendix F This appendix lists some of the common problems, or issues occurred during the development of this project. And this includes a quick start solution guide for such issues. This could be helpful for prospective developers or the GameBus team. Appendix G This appendix contains the scenarios and their corresponding object diagrams. They have been hidden due to confidentiality reasons.

61

About the Author

Chan Naseeb received his Bachelors in Computer Science from COM-SATS Institute of Information Technology, Pakistan, in 2007. His thesis is named “Online Instrument Calibration System for a Cement factory”. After that he decided to trade the sun to broaden his exposure, in 2008 he came to Italy, and graduated with Master of Science in Computer Engi-neering (with scholarship) from Politecnico Di Milano (2010). His Master thesis focused on Ontologies, knowledge representation in semantic web, making a comparison of Ontology engineering, reasoning and manage-ment systems. During his stay at Politecnico Di Milano, he won the opportunities to participate in a summer school (in Italy) and in two one week courses at ParisTech France, regarding “Operations Research” and “Scientific Methods for Research in Computer Science” under the ATHENS (Ad-vance Technology Higher Education Network/SOCRATES) framework. After working for 6 months in Milan as a Software Engineer, he came to the Netherlands as knowledge immigrant, and so far he has an experience of 3 years in industry. During his work he mainly focused on web application development, mobile application development, portal development and training con-sultants. His interests range from Software Engineering (OOAD), BPM to Semantic web, Big Data and Linked Data. Since September 2013, he started his professional Doctorate in Engineering (PDEng in Software Technology) at TU/e. There he followed several courses and workshops including about Object Oriented Design and Analysis, Design patterns, Testing, and Software Architecture. He has worked on 4 different in-house projects performing in different roles. In his last project, he was the team leader for QVTo Optimization project. He has been also the Project Manager and Scrum Master while supervising and guiding Nine Bachelor students for their final projects. Beside this, he also did a one week mini project about Free Text tagging system to create a prototype of a semantic based infrastructure. From January to September 2015, he has worked in the Industrial Engi-neering department as an API Designer and as a Backend developer for the project “Software Integration between external Game APIs and the Game Bus repository”. After completion of his Doctorate, he has joined Accenture as a Team Lead.