air - User contributions [en]

EA2014

2014-11-07T00:54:45Z

RICM4-prj14-grp8: /* Séance Ven. 7/11 */

[[EA2013|<< Etudes 2013]] [[EA|Sommaire]] [[EA2015|Etudes 2015 >>]]

=Etudes d'approfondissement=
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5

L'objectif des études approfondissement est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un formulaire (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

La présentation peut être réalisée avec [[reveal.js]]

[[File:presentation-EA-RICM5-1314.pdf|transparents d'introduction à l'UE]]

[http://imag-moodle.e.ujf-grenoble.fr/course/view.php?id=64 Site Moodle]

=Planning des séances=

==Séance Ven. 3/10==
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
* 19: Flavien Peyre, [[Firefox OS]] (démo d'une app eCOM avec un téléphone ZTE Open C prété, mise en place sur le Marketplace FFOS). [[EA2014FirefoxOS|Fiche de synthèse]] [http://slides.com/darkskull/firefoxos#/ Tranparents]
* 21: Pierre-Henri Ginoux, [[Elastic Search]] ([[Lucene]], Marvel, Kibana, Logstach) Démo: intégration à votre projet [[ECOM-RICM]] [[EA2014_Elastic_Search|Fiche de synthèse]] [[Media:ElasticSearch.pdf|Transparents]]
* Clément VALENTIN, [[Open Data]] : [[OData]], ... ([[Watchdogs We Are Data]]) [[EA2014_Open_Data|Fiche de synthèse]] Tranparents

==Séance Ven. 10/10==
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
* 3: FREBY Rodolphe, Protocoles de communication pour l'IoT et le M2M : [[MQTT]], [[XMPP]] IoT, CoAP, [[Adaptive Machine Messaging Protocol (AMMP)|AMMP]] ... : démonstration de [[MQTT]] avec [[Mosquitto]] et [[Node-RED]] et [[CoAP]] avec démonstration de [[Copper]] et [[Californium]] (démo avec [[Arduino Yún]]). [[EA2014ProtforIoT|Fiche de synthèse]] [[Media:SlideIoT_html.zip‎|Transparents]]
* 10: El Hadji Malick FALL, [[OS for WSN]] (dont [[Mbed OS]], [[RIOT]]). Démo de [[TinyOS]] avec le simulateur [[TOSSIM]] [[EA2014_OSforWSN|Fiche de synthèse]] [http://slides.com/falle38/osforwsn--2#/ Tranparents]

==Séance Ven. 17/10==
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
* 5. Paul Labat, [[Speech Recognition]], [[EA2014_speech_recognition | Fiche de synthèse]]
* 15. Patrick Perea, Simulateurs 3D : [[SGD]], [[Anarchy]] ... [[EA2014_Sim3D_education | Fiche de synthèse]] [http://slides.com/patrick91perea/simulateurs3d/live#/ Tranparents]
* 16. William Bobo , GPGPU et Programmation de GPGPU [[EA2014_GPGPU|Fiche de synthèse]] [[https://slides.com/willbobo/gpgpu Transparents]]

==Séance Ven. 24/10==
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
* 9: Adam TIAMIOU, [[Smart City]], [[EA2014 - Smart City - Fiche de synthèse | Fiche de Synthèse]], [https://slides.com/laraisonduplusjuste/smart-city/ Transparent]
* 18. Jérôme BARBIER, Communications longue distance pour l'[[Internet des Choses]] : [[SigFox]], [[LoRa]], ... Démonstration avec les starter kits Semtech et une passerelle Kerlink (disponible à [[FabMSTIC]]). [[EA2014_IoT_Communication | Fiche de synthèse]] [[Media:Slides-ea-presentation.zip‎|Transparents]]
* 6. Paul Mariage, [[BitCoin]] : principes, vices et vertus

==Séance Ven. 7/11==
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
* 12. Arthur Clerc-Gherardi, [[OSGi]],[[EA2014_OSGi | Fiche de synthèse]], [http://slides.com/rynn69270/deck/live Transparents]
* 11. Adji SAMBE, [[Scalatra]],[[EA2014_Scalatra | Fiche de synthèse]]
* 14. Augustin Husson, Conteneurs Linux ([[LXC]], [[Docker]], [[FreeBSD Jails]], [[OpenVZ]], [[Solaris Zones]] ...) : démonstration de [[Docker]] et de [[Docker OAR Cluster]]. [[EA2014_Docker|Fiche de synthèse]] [http://slides.com/augustinhusson/les-conteneurs#/ Slides]

==Séance Ven. 14/11==
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
* 7: Lionel, BOEY , [[NoSQL]] : [http://en.wikipedia.org/wiki/Shard_%28database_architecture%29 Sharding], [http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_CAP Theoreme de Brewer], MongoDB, GigaSpaces, Cassandra, BigTable/GAE DataStore, ...
* Tiaming GUO, Solutions [[Publish-Subscribe]] : Event Admin, [[ROS]], [[AMQP]] ([[RabbitMQ]] ...), [[MQTT]], [[XMPP]], [[UPnP]] GENA, [[PubNub]], [[PubSubHubbub]], [[Apache Kafka]], Siena ... (?) : démonstration de [[PubNub]] et [[PubSubHubbub]], démonstration du déploiement d'[[Apache Kafka]] sur le cloud [[Azure]]
* 8. Radhoane Ben younes, [[Business Process Management]]. Démonstration de BonitaSoft dans le projet [[eCOM]].

==Sujets non choisis==
# (Complex) [[Event Stream Processing]] : démonstration de [[Apache Storm]] et de [[Spark Streaming]] sur le cloud [[Azure]]. Démo supplémentaire du SaaS [[IFTTT]]
# [[BPM]] : démonstration de l'outil OW2 Bonita sur le processus de suivi des stages (?)
# [[Speech Recognition]]
# Simulateurs 3D : [[SGD]], [[Anarchy]] ...
# [[Software Forensics]] : cas d'étude Linagora vs Bluemind (vous compléterez les pages en et fr de Wikipédia sur ce sujet).
# [[Continuous Delivery]]
# [[Privacy policy guidelines]] : Démo: application à votre projet [[ECOM-RICM]]
# Protocoles, Formats et Plateformes pour le bâtiment intelligent : [[oBIX]], ... démonstration d'[[IoTSys]]

EA2014 OSGi

2014-11-07T00:53:00Z

RICM4-prj14-grp8: /* Introduction */

[[Image:osgi_alliance.jpg|right|thumb|300px|OSGi Alliance]]

= Présentation =

* Enseignants : Georges-Pierre Bonneau, Didier Donsez ([[EA2014]])
* Sujet : OSGi
* Date : 17 octobre 2014
* Auteur : Arthur Clerc-Gherardi

== Mots Clés ==
OSGi, SOA, Module, Bundle, Apache Karaf, Eclipse, Life Cycle

= Synthèse =

== Introduction ==
Vous aimeriez pouvoir coder du JAVA et le déployer à chaud comme du JS ou du PhP car vous en avez marre de redéployer vos VM. Vous en avez assez des problèmes de versions de librairies non compatibles ? Vous souhaiteriez pouvoir utiliser plusieurs versions d'une même librairie pour une execution de programme ? Vous voudriez ne plus jamais avoir de "ClassNotFoundException" ? OSGi est alors le parfait framework pour vous.

OSGi est un framework orienté service permettant aux développeurs de créer des bundles (appelés aussi modules) qui seront indépendants les uns des autres. Ils peuvent s'utiliser entre eux, mais si l'un plante, ça ne fera pas planter tout le programme.

On peut donc dire que pour la mise en place d'une architecture SOA, OSGi peut être réellement intéressant.

Nous allons donc voir un bref résumé d'OSGi pour au moins comprendre son intérêt et sa structure.

== Le fonctionnement ==
[[File:functionning_1.png|center|Fonctionnement du framework OSGi|400px]]

Comme on peut le voir grâce au schéma ci-dessus, les modules OSGi travaillent sur plusieurs couches :
*La couche Services met les services proposés à l'utilisateur en avant, sans leur montrer l'implémentation (une interface)
*La couche Cycle de vie va prendre en compte les états courants de chaque bundle
*La couche Module va mettre en place les différents bundle en les chargeant ainsi que leurs dépendances
*La couche Java Execution Environment est la couche que l'on utilise habituellement pour lancer nos programmes java

Les avantages que l'on peut déjà voir sont par exemples, l'isolation de chaque module ce qui va permettre à des bundles ayant besoin d'une même ressource mais de version différente de fonctionner. En effet côté JAVA, chaque bundle possède son propre classloader.

== Le cycle de vie ==

Comme expliqué ci-dessus, chaque bundle va vivre selon un automate qui sera son cycle de vie. Chaque bundle va alors s'occuper de son propre cycle de vie.
Le bundle peut soit être non-opérationnel, c'est à dire qu'il est présent mais n'a pas été déployé et n'est donc pas utilisable par les autres bundles. Il peut être au contraire opérationnel, et dans ce cas les autres bundles auront accès à ses services.

On peut diviser ces deux étapes en un automate un peu plus complet :

[[File:automaton_1.png|center|Cycle de vie d'un bundle|400px]]

*Etat Installé : le composant vient d'être installé correctement mais n'est pas encore utilisable
*Etat Resolu : les dépendances liés à ce composant ont été résolues
*Etat Désinstallé : le composant vient d'être désinstallé
*Etat Démarrage : état transitoire où le bundle effectue les actions nécessaires (comme la souscription au registre) avant d'être utilisable par tous
*Etat Actif : le bundle est utilisable par les autres bundles
*Etat Arrêt : état transitoire où le bundle se désinscrit du registre

== Structure du bundle OSGi ==

Chaque bundle peut être considéré comme un grosse boîte avec certaines propriétés :
*Les services apportés par le bundle
*Les services dont il a besoin pour fonctionner
*Les packages importés et exportés (par défaut 0)
*L'activateur qui va définir son cycle de vie
*Les ressources nécessaires au fonctionnement du bundle (image, xml...)
*Un fichier MANIFEST qui va contenir les informations du bundle

Pris, sur le site de IBM, un exemple de manifest :

[[File:manifest_osgi.png|center|Exemple de MANIFEST|400px]]

Expliquons brièvement à quoi sert chaque partie :
*Manifest-Version va nous donner la version du manifest car on peut en avoir plusieurs vu que les versions sont indépendantes les unes des autres
*Bundle-ManifestVersion va nous donner le numéro de révision du bundle
*Bundle-Name, le nom du bundle
*Bundle-SymbolicName, permet d'identifier un bundle dans un runtime
*Bundle-Version, la version du bundle
*Bundle-Activator, le lien qui servira d'Activator pour le bundle
*Import-package, les dépendances nécessaires au fonctionnement du bundle
*Export-package, les dépendances que l'on veut mettre à disposition
*Web-contentpath, présent dans le cas où le projet est une application web
*Export-EJB, présent dans le cas où l'on fait un projet JEE

Il faut savoir qu'il en existe beaucoup d'autres, je vous conseille donc de vous rendre sur la doc de [http://www.osgi.org/javadoc/r6/core/ OSGi].

== Fonctionnement des services ==

Comme expliqué précédemment, les bundles fonctionnent avec un système de service. Ce système est appelé le registre de service. Ce registre va être accédé en permanence par les bundles dans le but de connaître les services actifs.

Les MAJ de ce registre se fait par les bundles eux-mêmes :
*Lorsqu'ils sont en démarrage, ils s'enregistrent en donnant les services qu'ils peuvent fournir et ce dont ils ont besoin.
*Lorsqu'ils s'arrêtent, ils se désinscrivent du registre.

Les fichiers qui sont transférés pour l'inscription et la désinscription sont de la forme : [http://www.osgi.org/javadoc/r2/org/osgi/framework/Filter.html LDAP].

Côté utilisateur, seule une interface du service sera visible ainsi qu'un numéro de version.

Le petit plus du registre de services, est qu'il est doté d'un système de notifications : c'est à dire que dès qu'un service est disponible par exemple, ceux qui en avait besoin vont être notifié et vont donc pouvoir devenir actif.

== Domaines d'applications ==

Voici des exemples concrets qui pourraient être utiles :
*Vous avez un système déjà présent en production et vous ne pouvez pas vous permettre d'arrêter la plateforme. Dans ce cas OSGi est un framework parfait, si vous avez pensé à l'implémenter avant la mise en production. Vous allez pouvoir mettre à jour des services et les déployer sans rien arrêter.
*Tout projet nécessitant un SOA léger

== Sources ==

*[http://lig-membres.imag.fr/donsez/cours/osgi.pdf Cours de Didier Donsez]
*[http://air.imag.fr/index.php/Tutorial_OSGi_avec_Apache_Felix Tuto Apache Felix]
*[http://www.osgi.org/javadoc/r2/org/osgi/framework JavaDoc Osgi]

EA2014 OSGi

2014-11-07T00:52:20Z

RICM4-prj14-grp8:

[[Image:osgi_alliance.jpg|right|thumb|300px|OSGi Alliance]]

= Présentation =

* Enseignants : Georges-Pierre Bonneau, Didier Donsez ([[EA2014]])
* Sujet : OSGi
* Date : 17 octobre 2014
* Auteur : Arthur Clerc-Gherardi

== Mots Clés ==
OSGi, SOA, Module, Bundle, Apache Karaf, Eclipse, Life Cycle

= Synthèse =

== Introduction ==
Vous aimeriez pouvoir coder du JAVA et le déployer à chaud comme du JS ou du PhP car vous en avez marre de redéployer vos VM. Vous en avez assez des problèmes de versions de librairies non compatibles ? Vous souhaiteriez pouvoir utiliser plusieurs versions d'une même librairie pour une execution de programme ? Vous voudriez ne plus jamais avoir de "ClassNotFoundException" ? OSGi est alors le parfait framework pour vous.

OSGi est un framework orienté service permettant aux développeurs de créer des bundles (appelés aussi modules) qui seront indépendants les uns des autres. Ils peuvent s'utiliser entre eux, mais si l'un plante, ça ne fera pas planter tout le programme.

On peut donc dire que pour la mise en place d'une architecture SOA, OSGi peut être réellement intéressant.

== Le fonctionnement ==
[[File:functionning_1.png|center|Fonctionnement du framework OSGi|400px]]

Comme on peut le voir grâce au schéma ci-dessus, les modules OSGi travaillent sur plusieurs couches :
*La couche Services met les services proposés à l'utilisateur en avant, sans leur montrer l'implémentation (une interface)
*La couche Cycle de vie va prendre en compte les états courants de chaque bundle
*La couche Module va mettre en place les différents bundle en les chargeant ainsi que leurs dépendances
*La couche Java Execution Environment est la couche que l'on utilise habituellement pour lancer nos programmes java

Les avantages que l'on peut déjà voir sont par exemples, l'isolation de chaque module ce qui va permettre à des bundles ayant besoin d'une même ressource mais de version différente de fonctionner. En effet côté JAVA, chaque bundle possède son propre classloader.

== Le cycle de vie ==

Comme expliqué ci-dessus, chaque bundle va vivre selon un automate qui sera son cycle de vie. Chaque bundle va alors s'occuper de son propre cycle de vie.
Le bundle peut soit être non-opérationnel, c'est à dire qu'il est présent mais n'a pas été déployé et n'est donc pas utilisable par les autres bundles. Il peut être au contraire opérationnel, et dans ce cas les autres bundles auront accès à ses services.

On peut diviser ces deux étapes en un automate un peu plus complet :

[[File:automaton_1.png|center|Cycle de vie d'un bundle|400px]]

*Etat Installé : le composant vient d'être installé correctement mais n'est pas encore utilisable
*Etat Resolu : les dépendances liés à ce composant ont été résolues
*Etat Désinstallé : le composant vient d'être désinstallé
*Etat Démarrage : état transitoire où le bundle effectue les actions nécessaires (comme la souscription au registre) avant d'être utilisable par tous
*Etat Actif : le bundle est utilisable par les autres bundles
*Etat Arrêt : état transitoire où le bundle se désinscrit du registre

== Structure du bundle OSGi ==

Chaque bundle peut être considéré comme un grosse boîte avec certaines propriétés :
*Les services apportés par le bundle
*Les services dont il a besoin pour fonctionner
*Les packages importés et exportés (par défaut 0)
*L'activateur qui va définir son cycle de vie
*Les ressources nécessaires au fonctionnement du bundle (image, xml...)
*Un fichier MANIFEST qui va contenir les informations du bundle

Pris, sur le site de IBM, un exemple de manifest :

[[File:manifest_osgi.png|center|Exemple de MANIFEST|400px]]

Expliquons brièvement à quoi sert chaque partie :
*Manifest-Version va nous donner la version du manifest car on peut en avoir plusieurs vu que les versions sont indépendantes les unes des autres
*Bundle-ManifestVersion va nous donner le numéro de révision du bundle
*Bundle-Name, le nom du bundle
*Bundle-SymbolicName, permet d'identifier un bundle dans un runtime
*Bundle-Version, la version du bundle
*Bundle-Activator, le lien qui servira d'Activator pour le bundle
*Import-package, les dépendances nécessaires au fonctionnement du bundle
*Export-package, les dépendances que l'on veut mettre à disposition
*Web-contentpath, présent dans le cas où le projet est une application web
*Export-EJB, présent dans le cas où l'on fait un projet JEE

Il faut savoir qu'il en existe beaucoup d'autres, je vous conseille donc de vous rendre sur la doc de [http://www.osgi.org/javadoc/r6/core/ OSGi].

== Fonctionnement des services ==

Comme expliqué précédemment, les bundles fonctionnent avec un système de service. Ce système est appelé le registre de service. Ce registre va être accédé en permanence par les bundles dans le but de connaître les services actifs.

Les MAJ de ce registre se fait par les bundles eux-mêmes :
*Lorsqu'ils sont en démarrage, ils s'enregistrent en donnant les services qu'ils peuvent fournir et ce dont ils ont besoin.
*Lorsqu'ils s'arrêtent, ils se désinscrivent du registre.

Les fichiers qui sont transférés pour l'inscription et la désinscription sont de la forme : [http://www.osgi.org/javadoc/r2/org/osgi/framework/Filter.html LDAP].

Côté utilisateur, seule une interface du service sera visible ainsi qu'un numéro de version.

Le petit plus du registre de services, est qu'il est doté d'un système de notifications : c'est à dire que dès qu'un service est disponible par exemple, ceux qui en avait besoin vont être notifié et vont donc pouvoir devenir actif.

== Domaines d'applications ==

Voici des exemples concrets qui pourraient être utiles :
*Vous avez un système déjà présent en production et vous ne pouvez pas vous permettre d'arrêter la plateforme. Dans ce cas OSGi est un framework parfait, si vous avez pensé à l'implémenter avant la mise en production. Vous allez pouvoir mettre à jour des services et les déployer sans rien arrêter.
*Tout projet nécessitant un SOA léger

== Sources ==

*[http://lig-membres.imag.fr/donsez/cours/osgi.pdf Cours de Didier Donsez]
*[http://air.imag.fr/index.php/Tutorial_OSGi_avec_Apache_Felix Tuto Apache Felix]
*[http://www.osgi.org/javadoc/r2/org/osgi/framework JavaDoc Osgi]

File:Osgi alliance.jpg

2014-11-07T00:52:00Z

RICM4-prj14-grp8:

EA2014 OSGi

2014-11-07T00:51:37Z

RICM4-prj14-grp8:

[[Image:osgi_alliance.png|right|thumb|300px|OSGi Alliance]]

= Présentation =

* Enseignants : Georges-Pierre Bonneau, Didier Donsez ([[EA2014]])
* Sujet : OSGi
* Date : 17 octobre 2014
* Auteur : Arthur Clerc-Gherardi

== Mots Clés ==
OSGi, SOA, Module, Bundle, Apache Karaf, Eclipse, Life Cycle

= Synthèse =

== Introduction ==
Vous aimeriez pouvoir coder du JAVA et le déployer à chaud comme du JS ou du PhP car vous en avez marre de redéployer vos VM. Vous en avez assez des problèmes de versions de librairies non compatibles ? Vous souhaiteriez pouvoir utiliser plusieurs versions d'une même librairie pour une execution de programme ? Vous voudriez ne plus jamais avoir de "ClassNotFoundException" ? OSGi est alors le parfait framework pour vous.

OSGi est un framework orienté service permettant aux développeurs de créer des bundles (appelés aussi modules) qui seront indépendants les uns des autres. Ils peuvent s'utiliser entre eux, mais si l'un plante, ça ne fera pas planter tout le programme.

On peut donc dire que pour la mise en place d'une architecture SOA, OSGi peut être réellement intéressant.

== Le fonctionnement ==
[[File:functionning_1.png|center|Fonctionnement du framework OSGi|400px]]

Comme on peut le voir grâce au schéma ci-dessus, les modules OSGi travaillent sur plusieurs couches :
*La couche Services met les services proposés à l'utilisateur en avant, sans leur montrer l'implémentation (une interface)
*La couche Cycle de vie va prendre en compte les états courants de chaque bundle
*La couche Module va mettre en place les différents bundle en les chargeant ainsi que leurs dépendances
*La couche Java Execution Environment est la couche que l'on utilise habituellement pour lancer nos programmes java

Les avantages que l'on peut déjà voir sont par exemples, l'isolation de chaque module ce qui va permettre à des bundles ayant besoin d'une même ressource mais de version différente de fonctionner. En effet côté JAVA, chaque bundle possède son propre classloader.

== Le cycle de vie ==

Comme expliqué ci-dessus, chaque bundle va vivre selon un automate qui sera son cycle de vie. Chaque bundle va alors s'occuper de son propre cycle de vie.
Le bundle peut soit être non-opérationnel, c'est à dire qu'il est présent mais n'a pas été déployé et n'est donc pas utilisable par les autres bundles. Il peut être au contraire opérationnel, et dans ce cas les autres bundles auront accès à ses services.

On peut diviser ces deux étapes en un automate un peu plus complet :

[[File:automaton_1.png|center|Cycle de vie d'un bundle|400px]]

*Etat Installé : le composant vient d'être installé correctement mais n'est pas encore utilisable
*Etat Resolu : les dépendances liés à ce composant ont été résolues
*Etat Désinstallé : le composant vient d'être désinstallé
*Etat Démarrage : état transitoire où le bundle effectue les actions nécessaires (comme la souscription au registre) avant d'être utilisable par tous
*Etat Actif : le bundle est utilisable par les autres bundles
*Etat Arrêt : état transitoire où le bundle se désinscrit du registre

== Structure du bundle OSGi ==

Chaque bundle peut être considéré comme un grosse boîte avec certaines propriétés :
*Les services apportés par le bundle
*Les services dont il a besoin pour fonctionner
*Les packages importés et exportés (par défaut 0)
*L'activateur qui va définir son cycle de vie
*Les ressources nécessaires au fonctionnement du bundle (image, xml...)
*Un fichier MANIFEST qui va contenir les informations du bundle

Pris, sur le site de IBM, un exemple de manifest :

[[File:manifest_osgi.png|center|Exemple de MANIFEST|400px]]

Expliquons brièvement à quoi sert chaque partie :
*Manifest-Version va nous donner la version du manifest car on peut en avoir plusieurs vu que les versions sont indépendantes les unes des autres
*Bundle-ManifestVersion va nous donner le numéro de révision du bundle
*Bundle-Name, le nom du bundle
*Bundle-SymbolicName, permet d'identifier un bundle dans un runtime
*Bundle-Version, la version du bundle
*Bundle-Activator, le lien qui servira d'Activator pour le bundle
*Import-package, les dépendances nécessaires au fonctionnement du bundle
*Export-package, les dépendances que l'on veut mettre à disposition
*Web-contentpath, présent dans le cas où le projet est une application web
*Export-EJB, présent dans le cas où l'on fait un projet JEE

Il faut savoir qu'il en existe beaucoup d'autres, je vous conseille donc de vous rendre sur la doc de [http://www.osgi.org/javadoc/r6/core/ OSGi].

== Fonctionnement des services ==

Comme expliqué précédemment, les bundles fonctionnent avec un système de service. Ce système est appelé le registre de service. Ce registre va être accédé en permanence par les bundles dans le but de connaître les services actifs.

Les MAJ de ce registre se fait par les bundles eux-mêmes :
*Lorsqu'ils sont en démarrage, ils s'enregistrent en donnant les services qu'ils peuvent fournir et ce dont ils ont besoin.
*Lorsqu'ils s'arrêtent, ils se désinscrivent du registre.

Les fichiers qui sont transférés pour l'inscription et la désinscription sont de la forme : [http://www.osgi.org/javadoc/r2/org/osgi/framework/Filter.html LDAP].

Côté utilisateur, seule une interface du service sera visible ainsi qu'un numéro de version.

Le petit plus du registre de services, est qu'il est doté d'un système de notifications : c'est à dire que dès qu'un service est disponible par exemple, ceux qui en avait besoin vont être notifié et vont donc pouvoir devenir actif.

== Domaines d'applications ==

Voici des exemples concrets qui pourraient être utiles :
*Vous avez un système déjà présent en production et vous ne pouvez pas vous permettre d'arrêter la plateforme. Dans ce cas OSGi est un framework parfait, si vous avez pensé à l'implémenter avant la mise en production. Vous allez pouvoir mettre à jour des services et les déployer sans rien arrêter.
*Tout projet nécessitant un SOA léger

== Sources ==

*[http://lig-membres.imag.fr/donsez/cours/osgi.pdf Cours de Didier Donsez]
*[http://air.imag.fr/index.php/Tutorial_OSGi_avec_Apache_Felix Tuto Apache Felix]
*[http://www.osgi.org/javadoc/r2/org/osgi/framework JavaDoc Osgi]

EA2014 OSGi

2014-11-07T00:27:15Z

RICM4-prj14-grp8:

= Présentation =

* Enseignants : Georges-Pierre Bonneau, Didier Donsez ([[EA2014]])
* Sujet : OSGi
* Date : 17 octobre 2014
* Auteur : Arthur Clerc-Gherardi

== Mots Clés ==
OSGi, SOA, Module, Bundle, Apache Karaf, Eclipse, Life Cycle

= Synthèse =

== Introduction ==
Vous aimeriez pouvoir coder du JAVA et le déployer à chaud comme du JS ou du PhP car vous en avez marre de redéployer vos VM. Vous en avez assez des problèmes de versions de librairies non compatibles ? Vous souhaiteriez pouvoir utiliser plusieurs versions d'une même librairie pour une execution de programme ? Vous voudriez ne plus jamais avoir de "ClassNotFoundException" ? OSGi est alors le parfait framework pour vous.

OSGi est un framework orienté service permettant aux développeurs de créer des bundles (appelés aussi modules) qui seront indépendants les uns des autres. Ils peuvent s'utiliser entre eux, mais si l'un plante, ça ne fera pas planter tout le programme.

On peut donc dire que pour la mise en place d'une architecture SOA, OSGi peut être réellement intéressant.

== Le fonctionnement ==
[[File:functionning_1.png|center|Fonctionnement du framework OSGi|400px]]

Comme on peut le voir grâce au schéma ci-dessus, les modules OSGi travaillent sur plusieurs couches :
*La couche Services met les services proposés à l'utilisateur en avant, sans leur montrer l'implémentation (une interface)
*La couche Cycle de vie va prendre en compte les états courants de chaque bundle
*La couche Module va mettre en place les différents bundle en les chargeant ainsi que leurs dépendances
*La couche Java Execution Environment est la couche que l'on utilise habituellement pour lancer nos programmes java

Les avantages que l'on peut déjà voir sont par exemples, l'isolation de chaque module ce qui va permettre à des bundles ayant besoin d'une même ressource mais de version différente de fonctionner. En effet côté JAVA, chaque bundle possède son propre classloader.

== Le cycle de vie ==

Comme expliqué ci-dessus, chaque bundle va vivre selon un automate qui sera son cycle de vie. Chaque bundle va alors s'occuper de son propre cycle de vie.
Le bundle peut soit être non-opérationnel, c'est à dire qu'il est présent mais n'a pas été déployé et n'est donc pas utilisable par les autres bundles. Il peut être au contraire opérationnel, et dans ce cas les autres bundles auront accès à ses services.

On peut diviser ces deux étapes en un automate un peu plus complet :

[[File:automaton_1.png|center|Cycle de vie d'un bundle|400px]]

*Etat Installé : le composant vient d'être installé correctement mais n'est pas encore utilisable
*Etat Resolu : les dépendances liés à ce composant ont été résolues
*Etat Désinstallé : le composant vient d'être désinstallé
*Etat Démarrage : état transitoire où le bundle effectue les actions nécessaires (comme la souscription au registre) avant d'être utilisable par tous
*Etat Actif : le bundle est utilisable par les autres bundles
*Etat Arrêt : état transitoire où le bundle se désinscrit du registre

== Structure du bundle OSGi ==

Chaque bundle peut être considéré comme un grosse boîte avec certaines propriétés :
*Les services apportés par le bundle
*Les services dont il a besoin pour fonctionner
*Les packages importés et exportés (par défaut 0)
*L'activateur qui va définir son cycle de vie
*Les ressources nécessaires au fonctionnement du bundle (image, xml...)
*Un fichier MANIFEST qui va contenir les informations du bundle

Pris, sur le site de IBM, un exemple de manifest :

[[File:manifest_osgi.png|center|Exemple de MANIFEST|400px]]

Expliquons brièvement à quoi sert chaque partie :
*Manifest-Version va nous donner la version du manifest car on peut en avoir plusieurs vu que les versions sont indépendantes les unes des autres
*Bundle-ManifestVersion va nous donner le numéro de révision du bundle
*Bundle-Name, le nom du bundle
*Bundle-SymbolicName, permet d'identifier un bundle dans un runtime
*Bundle-Version, la version du bundle
*Bundle-Activator, le lien qui servira d'Activator pour le bundle
*Import-package, les dépendances nécessaires au fonctionnement du bundle
*Export-package, les dépendances que l'on veut mettre à disposition
*Web-contentpath, présent dans le cas où le projet est une application web
*Export-EJB, présent dans le cas où l'on fait un projet JEE

Il faut savoir qu'il en existe beaucoup d'autres, je vous conseille donc de vous rendre sur la doc de [http://www.osgi.org/javadoc/r6/core/ OSGi].

== Fonctionnement des services ==

Comme expliqué précédemment, les bundles fonctionnent avec un système de service. Ce système est appelé le registre de service. Ce registre va être accédé en permanence par les bundles dans le but de connaître les services actifs.

Les MAJ de ce registre se fait par les bundles eux-mêmes :
*Lorsqu'ils sont en démarrage, ils s'enregistrent en donnant les services qu'ils peuvent fournir et ce dont ils ont besoin.
*Lorsqu'ils s'arrêtent, ils se désinscrivent du registre.

Les fichiers qui sont transférés pour l'inscription et la désinscription sont de la forme : [http://www.osgi.org/javadoc/r2/org/osgi/framework/Filter.html LDAP].

Côté utilisateur, seule une interface du service sera visible ainsi qu'un numéro de version.

Le petit plus du registre de services, est qu'il est doté d'un système de notifications : c'est à dire que dès qu'un service est disponible par exemple, ceux qui en avait besoin vont être notifié et vont donc pouvoir devenir actif.

== Domaines d'applications ==

Voici des exemples concrets qui pourraient être utiles :
*Vous avez un système déjà présent en production et vous ne pouvez pas vous permettre d'arrêter la plateforme. Dans ce cas OSGi est un framework parfait, si vous avez pensé à l'implémenter avant la mise en production. Vous allez pouvoir mettre à jour des services et les déployer sans rien arrêter.
*Tout projet nécessitant un SOA léger

== Sources ==

*[http://lig-membres.imag.fr/donsez/cours/osgi.pdf Cours de Didier Donsez]
*[http://air.imag.fr/index.php/Tutorial_OSGi_avec_Apache_Felix Tuto Apache Felix]
*[http://www.osgi.org/javadoc/r2/org/osgi/framework JavaDoc Osgi]

EA2014 OSGi

2014-11-07T00:26:50Z

RICM4-prj14-grp8:

= Présentation =

* Enseignants : Georges-Pierre Bonneau, Didier Donsez ([[EA2014]])
* Sujet : OSGi
* Date : 17 octobre 2014
* Auteur : Arthur Clerc-Gherardi

== Mots Clés ==
OSGi, SOA, Module, Bundle, Apache Karaf, Eclipse, Life Cycle

= Synthèse =

== Introduction ==
Vous aimeriez pouvoir coder du JAVA et le déployer à chaud comme du JS ou du PhP car vous en avez marre de redéployer vos VM. Vous en avez assez des problèmes de versions de librairies non compatibles ? Vous souhaiteriez pouvoir utiliser plusieurs versions d'une même librairie pour une execution de programme ? Vous voudriez ne plus jamais avoir de "ClassNotFoundException" ? OSGi est alors le parfait framework pour vous.

OSGi est un framework orienté service permettant aux développeurs de créer des bundles (appelés aussi modules) qui seront indépendants les uns des autres. Ils peuvent s'utiliser entre eux, mais si l'un plante, ça ne fera pas planter tout le programme.

On peut donc dire que pour la mise en place d'une architecture SOA, OSGi peut être réellement intéressant.

== Le fonctionnement ==
[[File:functionning_1.png|center|Fonctionnement du framework OSGi|400px]]

Comme on peut le voir grâce au schéma ci-dessus, les modules OSGi travaillent sur plusieurs couches :
*La couche Services met les services proposés à l'utilisateur en avant, sans leur montrer l'implémentation (une interface)
*La couche Cycle de vie va prendre en compte les états courants de chaque bundle
*La couche Module va mettre en place les différents bundle en les chargeant ainsi que leurs dépendances
*La couche Java Execution Environment est la couche que l'on utilise habituellement pour lancer nos programmes java

Les avantages que l'on peut déjà voir sont par exemples, l'isolation de chaque module ce qui va permettre à des bundles ayant besoin d'une même ressource mais de version différente de fonctionner. En effet côté JAVA, chaque bundle possède son propre classloader.

== Le cycle de vie ==

Comme expliqué ci-dessus, chaque bundle va vivre selon un automate qui sera son cycle de vie. Chaque bundle va alors s'occuper de son propre cycle de vie.
Le bundle peut soit être non-opérationnel, c'est à dire qu'il est présent mais n'a pas été déployé et n'est donc pas utilisable par les autres bundles. Il peut être au contraire opérationnel, et dans ce cas les autres bundles auront accès à ses services.

On peut diviser ces deux étapes en un automate un peu plus complet :

[[File:automaton_1.png|center|Cycle de vie d'un bundle|400px]]

*Etat Installé : le composant vient d'être installé correctement mais n'est pas encore utilisable
*Etat Resolu : les dépendances liés à ce composant ont été résolues
*Etat Désinstallé : le composant vient d'être désinstallé
*Etat Démarrage : état transitoire où le bundle effectue les actions nécessaires (comme la souscription au registre) avant d'être utilisable par tous
*Etat Actif : le bundle est utilisable par les autres bundles
*Etat Arrêt : état transitoire où le bundle se désinscrit du registre

== Structure du bundle OSGi ==

Chaque bundle peut être considéré comme un grosse boîte avec certaines propriétés :
*Les services apportés par le bundle
*Les services dont il a besoin pour fonctionner
*Les packages importés et exportés (par défaut 0)
*L'activateur qui va définir son cycle de vie
*Les ressources nécessaires au fonctionnement du bundle (image, xml...)
*Un fichier MANIFEST qui va contenir les informations du bundle

Pris, sur le site de IBM, un exemple de manifest :

[[File:manifest_osgi.png|center|Exemple de MANIFEST|400px]]

Expliquons brièvement à quoi sert chaque partie :
*Manifest-Version va nous donner la version du manifest car on peut en avoir plusieurs vu que les versions sont indépendantes les unes des autres
*Bundle-ManifestVersion va nous donner le numéro de révision du bundle
*Bundle-Name, le nom du bundle
*Bundle-SymbolicName, permet d'identifier un bundle dans un runtime
*Bundle-Version, la version du bundle
*Bundle-Activator, le lien qui servira d'Activator pour le bundle
*Import-package, les dépendances nécessaires au fonctionnement du bundle
*Export-package, les dépendances que l'on veut mettre à disposition
*Web-contentpath, présent dans le cas où le projet est une application web
*Export-EJB, présent dans le cas où l'on fait un projet JEE

Il faut savoir qu'il en existe beaucoup d'autres, je vous conseille donc de vous rendre sur la doc de [http://www.osgi.org/javadoc/r6/core/ OSGi].

== Fonctionnement des services ==

Comme expliqué précédemment, les bundles fonctionnent avec un système de service. Ce système est appelé le registre de service. Ce registre va être accédé en permanence par les bundles dans le but de connaître les services actifs.

Les MAJ de ce registre se fait par les bundles eux-mêmes :
*Lorsqu'ils sont en démarrage, ils s'enregistrent en donnant les services qu'ils peuvent fournir et ce dont ils ont besoin.
*Lorsqu'ils s'arrêtent, ils se désinscrivent du registre.

Les fichiers qui sont transférés pour l'inscription et la désinscription sont de la forme : [http://www.osgi.org/javadoc/r2/org/osgi/framework/Filter.html LDAP].

Côté utilisateur, seule une interface du service sera visible ainsi qu'un numéro de version.

Le petit plus du registre de services, est qu'il est doté d'un système de notifications : c'est à dire que dès qu'un service est disponible par exemple, ceux qui en avait besoin vont être notifié et vont donc pouvoir devenir actif.

== Domaines d'applications ==

Voici des exemples concrets qui pourraient être utiles :
*Vous avez un système déjà présent en production et vous ne pouvez pas vous permettre d'arrêter la plateforme. Dans ce cas OSGi est un framework parfait, si vous avez pensé à l'implémenter avant la mise en production. Vous allez pouvoir mettre à jour des services et les déployer sans rien arrêter.
*Tout projet nécessitant un SOA léger

== Sources ==

[http://lig-membres.imag.fr/donsez/cours/osgi.pdf Cours de Didier Donsez]
[http://air.imag.fr/index.php/Tutorial_OSGi_avec_Apache_Felix Tuto Apache Felix]
[http://www.osgi.org/javadoc/r2/org/osgi/framework JavaDoc Osgi]

EA2014 OSGi

2014-11-07T00:26:37Z

RICM4-prj14-grp8:

= Présentation =

* Enseignants : Georges-Pierre Bonneau, Didier Donsez ([[EA2014]])
* Sujet : OSGi
* Date : 17 octobre 2014
* Auteur : Arthur Clerc-Gherardi

== Mots Clés ==
OSGi, SOA, Module, Bundle, Apache Karaf, Eclipse, Life Cycle

= Synthèse =

== Introduction ==
Vous aimeriez pouvoir coder du JAVA et le déployer à chaud comme du JS ou du PhP car vous en avez marre de redéployer vos VM. Vous en avez assez des problèmes de versions de librairies non compatibles ? Vous souhaiteriez pouvoir utiliser plusieurs versions d'une même librairie pour une execution de programme ? Vous voudriez ne plus jamais avoir de "ClassNotFoundException" ? OSGi est alors le parfait framework pour vous.

OSGi est un framework orienté service permettant aux développeurs de créer des bundles (appelés aussi modules) qui seront indépendants les uns des autres. Ils peuvent s'utiliser entre eux, mais si l'un plante, ça ne fera pas planter tout le programme.

On peut donc dire que pour la mise en place d'une architecture SOA, OSGi peut être réellement intéressant.

== Le fonctionnement ==
[[File:functionning_1.png|center|Fonctionnement du framework OSGi|400px]]

Comme on peut le voir grâce au schéma ci-dessus, les modules OSGi travaillent sur plusieurs couches :
*La couche Services met les services proposés à l'utilisateur en avant, sans leur montrer l'implémentation (une interface)
*La couche Cycle de vie va prendre en compte les états courants de chaque bundle
*La couche Module va mettre en place les différents bundle en les chargeant ainsi que leurs dépendances
*La couche Java Execution Environment est la couche que l'on utilise habituellement pour lancer nos programmes java

Les avantages que l'on peut déjà voir sont par exemples, l'isolation de chaque module ce qui va permettre à des bundles ayant besoin d'une même ressource mais de version différente de fonctionner. En effet côté JAVA, chaque bundle possède son propre classloader.

== Le cycle de vie ==

Comme expliqué ci-dessus, chaque bundle va vivre selon un automate qui sera son cycle de vie. Chaque bundle va alors s'occuper de son propre cycle de vie.
Le bundle peut soit être non-opérationnel, c'est à dire qu'il est présent mais n'a pas été déployé et n'est donc pas utilisable par les autres bundles. Il peut être au contraire opérationnel, et dans ce cas les autres bundles auront accès à ses services.

On peut diviser ces deux étapes en un automate un peu plus complet :

[[File:automaton_1.png|center|Cycle de vie d'un bundle|400px]]

*Etat Installé : le composant vient d'être installé correctement mais n'est pas encore utilisable
*Etat Resolu : les dépendances liés à ce composant ont été résolues
*Etat Désinstallé : le composant vient d'être désinstallé
*Etat Démarrage : état transitoire où le bundle effectue les actions nécessaires (comme la souscription au registre) avant d'être utilisable par tous
*Etat Actif : le bundle est utilisable par les autres bundles
*Etat Arrêt : état transitoire où le bundle se désinscrit du registre

== Structure du bundle OSGi ==

Chaque bundle peut être considéré comme un grosse boîte avec certaines propriétés :
*Les services apportés par le bundle
*Les services dont il a besoin pour fonctionner
*Les packages importés et exportés (par défaut 0)
*L'activateur qui va définir son cycle de vie
*Les ressources nécessaires au fonctionnement du bundle (image, xml...)
*Un fichier MANIFEST qui va contenir les informations du bundle

Pris, sur le site de IBM, un exemple de manifest :

[[File:manifest_osgi.png|center|Exemple de MANIFEST|400px]]

Expliquons brièvement à quoi sert chaque partie :
*Manifest-Version va nous donner la version du manifest car on peut en avoir plusieurs vu que les versions sont indépendantes les unes des autres
*Bundle-ManifestVersion va nous donner le numéro de révision du bundle
*Bundle-Name, le nom du bundle
*Bundle-SymbolicName, permet d'identifier un bundle dans un runtime
*Bundle-Version, la version du bundle
*Bundle-Activator, le lien qui servira d'Activator pour le bundle
*Import-package, les dépendances nécessaires au fonctionnement du bundle
*Export-package, les dépendances que l'on veut mettre à disposition
*Web-contentpath, présent dans le cas où le projet est une application web
*Export-EJB, présent dans le cas où l'on fait un projet JEE

Il faut savoir qu'il en existe beaucoup d'autres, je vous conseille donc de vous rendre sur la doc de [http://www.osgi.org/javadoc/r6/core/ OSGi].

== Fonctionnement des services ==

Comme expliqué précédemment, les bundles fonctionnent avec un système de service. Ce système est appelé le registre de service. Ce registre va être accédé en permanence par les bundles dans le but de connaître les services actifs.

Les MAJ de ce registre se fait par les bundles eux-mêmes :
*Lorsqu'ils sont en démarrage, ils s'enregistrent en donnant les services qu'ils peuvent fournir et ce dont ils ont besoin.
*Lorsqu'ils s'arrêtent, ils se désinscrivent du registre.

Les fichiers qui sont transférés pour l'inscription et la désinscription sont de la forme : [http://www.osgi.org/javadoc/r2/org/osgi/framework/Filter.html LDAP].

Côté utilisateur, seule une interface du service sera visible ainsi qu'un numéro de version.

Le petit plus du registre de services, est qu'il est doté d'un système de notifications : c'est à dire que dès qu'un service est disponible par exemple, ceux qui en avait besoin vont être notifié et vont donc pouvoir devenir actif.

== Domaines d'applications ==

Voici des exemples concrets qui pourraient être utiles :
*Vous avez un système déjà présent en production et vous ne pouvez pas vous permettre d'arrêter la plateforme. Dans ce cas OSGi est un framework parfait, si vous avez pensé à l'implémenter avant la mise en production. Vous allez pouvoir mettre à jour des services et les déployer sans rien arrêter.
*Tout projet nécessitant un SOA léger

== Sources ==

[http://lig-membres.imag.fr/donsez/cours/osgi.pdf Cours de Didier Donsez]
[http://air.imag.fr/index.php/Tutorial_OSGi_avec_Apache_Felix Tuto Apache Felix]
[http://www.osgi.org/javadoc/r2/org/osgi/framework JavaDoc Osgi]

EA2014 OSGi

2014-11-07T00:24:39Z

RICM4-prj14-grp8:

EA2014 OSGi

SRS SeriousGame RICM Group

2014-04-10T00:23:07Z

RICM4-prj14-grp8: /* 6. Index */

SRS SeriousGame RICM Group

2014-04-10T00:18:59Z

RICM4-prj14-grp8: /* 4. Product evolution */

Proj-2013-2014-SeriousGame-Parole-et-Geste

2014-04-10T00:10:45Z

RICM4-prj14-grp8: /* Week 12 (March 31th - March 11th) */

= Introduction =
Development of small 2D games to help children with language disorder.
A second objective is the recovery of the game data to determine the progression and the troubles experienced by children. In this way, we can understand their cognitive abilities and find better ways to help them.

= Team =

*Tutors : Olivier Richard, Marion Dohen, Estelle Gillet-Perret, Amelie Rochet-Capellan

*Members : Mehdi NAIT-SIDOUS, Pierre-Henri GINOUX

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Links =

*[http://kivy.org Kivy]
*[http://gameprogrammingpatterns.com Blog on architectural patterns in game code]
*[https://www.dropbox.com/l/q6E0fhCswT7FbeS18PzV6e Image resources]
*[http://sega.tech.nhl.nl/wiki/index.php/Knowledgebase Wiki with a lot of links on serious game]

= Project objectives =
Le but du projet est de développer une application comprenant des mini jeux qui permettent d'évaluer scientifiquement si la gestualité manuelle peut aider des enfants présentant des troubles communicatifs à mieux apprendre de nouveaux mots.
Une fois cette phase effectuée, il s'agira ensuite de finaliser afin de proposer un outil facilement utilisable à un maximum d'utilisateurs implémentant une méthode d'apprentissage de nouveaux mots en utilisant la gestualité manuelle.

Il faut garder à l'esprit que le jeu n'est qu'une composante du logiciel, nous allons donc dans un premier temps implémenter un jeu simple mais qui permettra de tester toute les composantes de l'application.

Objectifs pour le premier prototype de jeu :
A REMPLIR

Objectifs pour l'application :
* Système de login pour identifier l'utilisateur de manière unique
* Facilité d'ajouter un nouveau jeu dans l'application
* Stockage des résultats en local
* Possiblité d'envoyer les résultats sur un serveur Web
* Possibilité de modifier la configuration pour chaque jeu (changer la difficulté, les images utilisées...)

http://air.imag.fr/index.php/SRS_SeriousGame_RICM_Group

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - Janurary 19th) ==
*Project discovery
*Learning of Python
*Research on Kivy
*Research on serious gaming

== Week 2 (January 20th - Janurary 26th) ==
*Defining functional specifications
*Defining the problems we may/will have to sort out, like being able to store data using a user password. [http://pastebin.com/hvLUT6vc More details (in French)]
*Learning how SQLite works and can be use to store game data

== Week 3 (January 27th - February 2th) ==
*Reflexion about the class structure of the application
*Find a way to create dynamically the database
*Reflexion about the storage of settings

== Week 4 (February 3th - February 9th) ==
* Meeting with Marion Dohen and Amelie Rochet-Capellan
* Reflexions about the specifications
* Split the job in different steps (cf. documentation)

== Week 5 (February 10th - February 16th) ==
* First UML diagrams
* Begin of the first game prototype development
* Complete the online documentation

== Week 6 (February 17th - February 23th) ==
* Include the SQlite Data Base in the application
* game prototype development
* Complete the online documentation

== Week 7 (February 24th - March 2nd) ==
* UML Diagrams
* Game prototype development
* Complete the online documentation

== Week 8 (March 3th - March 9th) ==
* End of the UML documentation
* Game prototype development (drag picture OK, sound OK)
* Complete the online documentation

== Week 9 (March 10th - March 16th) ==
* Manage collide between widgets
* Display score and time and store it in data base
* Create two different class, Object and Category

== Week 10 (March 17th - March 23th) ==
*Add an end game Menu
*Create an "interesting" GamePlay

== Week 11 (March 17th - March 23th) ==
*Correct bugs on prototype
*Enable video add
*Complete the online documentation

== Week 12 (March 24th - March 30th) ==
*Correct lasts bugs on prototype

== Week 13-14 (March 31th - March 11th) ==
*Game3 development
*Enable CSV export of data stored in the data base
*Objects are now loaded from a txt file thanks to a parser
*3 items are randomly chosen and displayed on the left
*2 forms are randomly chosen and displayed on the right+1 corresponding to an object on the left
*Correct and Wrong answers are stored in the data base and can be export in CSV
*Objects are displayed dynamically

Proj-2013-2014-SeriousGame-Parole-et-Geste

2014-04-10T00:10:31Z

RICM4-prj14-grp8: /* Progress of the project */

= Introduction =
Development of small 2D games to help children with language disorder.
A second objective is the recovery of the game data to determine the progression and the troubles experienced by children. In this way, we can understand their cognitive abilities and find better ways to help them.

= Team =

*Tutors : Olivier Richard, Marion Dohen, Estelle Gillet-Perret, Amelie Rochet-Capellan

*Members : Mehdi NAIT-SIDOUS, Pierre-Henri GINOUX

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Links =

*[http://kivy.org Kivy]
*[http://gameprogrammingpatterns.com Blog on architectural patterns in game code]
*[https://www.dropbox.com/l/q6E0fhCswT7FbeS18PzV6e Image resources]
*[http://sega.tech.nhl.nl/wiki/index.php/Knowledgebase Wiki with a lot of links on serious game]

= Project objectives =
Le but du projet est de développer une application comprenant des mini jeux qui permettent d'évaluer scientifiquement si la gestualité manuelle peut aider des enfants présentant des troubles communicatifs à mieux apprendre de nouveaux mots.
Une fois cette phase effectuée, il s'agira ensuite de finaliser afin de proposer un outil facilement utilisable à un maximum d'utilisateurs implémentant une méthode d'apprentissage de nouveaux mots en utilisant la gestualité manuelle.

Il faut garder à l'esprit que le jeu n'est qu'une composante du logiciel, nous allons donc dans un premier temps implémenter un jeu simple mais qui permettra de tester toute les composantes de l'application.

Objectifs pour le premier prototype de jeu :
A REMPLIR

Objectifs pour l'application :
* Système de login pour identifier l'utilisateur de manière unique
* Facilité d'ajouter un nouveau jeu dans l'application
* Stockage des résultats en local
* Possiblité d'envoyer les résultats sur un serveur Web
* Possibilité de modifier la configuration pour chaque jeu (changer la difficulté, les images utilisées...)

http://air.imag.fr/index.php/SRS_SeriousGame_RICM_Group

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - Janurary 19th) ==
*Project discovery
*Learning of Python
*Research on Kivy
*Research on serious gaming

== Week 2 (January 20th - Janurary 26th) ==
*Defining functional specifications
*Defining the problems we may/will have to sort out, like being able to store data using a user password. [http://pastebin.com/hvLUT6vc More details (in French)]
*Learning how SQLite works and can be use to store game data

== Week 3 (January 27th - February 2th) ==
*Reflexion about the class structure of the application
*Find a way to create dynamically the database
*Reflexion about the storage of settings

== Week 4 (February 3th - February 9th) ==
* Meeting with Marion Dohen and Amelie Rochet-Capellan
* Reflexions about the specifications
* Split the job in different steps (cf. documentation)

== Week 5 (February 10th - February 16th) ==
* First UML diagrams
* Begin of the first game prototype development
* Complete the online documentation

== Week 6 (February 17th - February 23th) ==
* Include the SQlite Data Base in the application
* game prototype development
* Complete the online documentation

== Week 7 (February 24th - March 2nd) ==
* UML Diagrams
* Game prototype development
* Complete the online documentation

== Week 8 (March 3th - March 9th) ==
* End of the UML documentation
* Game prototype development (drag picture OK, sound OK)
* Complete the online documentation

== Week 9 (March 10th - March 16th) ==
* Manage collide between widgets
* Display score and time and store it in data base
* Create two different class, Object and Category

== Week 10 (March 17th - March 23th) ==
*Add an end game Menu
*Create an "interesting" GamePlay

== Week 11 (March 17th - March 23th) ==
*Correct bugs on prototype
*Enable video add
*Complete the online documentation

== Week 12 (March 24th - March 30th) ==
*Correct lasts bugs on prototype

== Week 12 (March 31th - March 11th) ==
*Game3 development
*Enable CSV export of data stored in the data base
*Objects are now loaded from a txt file thanks to a parser
*3 items are randomly chosen and displayed on the left
*2 forms are randomly chosen and displayed on the right+1 corresponding to an object on the left
*Correct and Wrong answers are stored in the data base and can be export in CSV
*Objects are displayed dynamically

SRS SeriousGame RICM Group

2014-03-10T13:31:39Z

RICM4-prj14-grp8: /* 4. Product evolution */

SRS SeriousGame RICM Group

2014-03-10T13:13:43Z

RICM4-prj14-grp8: /* 3.1 Requirement X.Y.Z (in Structured Natural Language) */

SRS SeriousGame RICM Group

2014-03-10T13:10:36Z

RICM4-prj14-grp8: /* 3.1 Requirement X.Y.Z (in Structured Natural Language) */

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==

This Software Requirements Specification (SRS) identifies the requirements for the serious game.
In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

- The product we are developing is a application of serious games
- The platform our app is used for .... WIP

==1.3 Definitions, acronyms and abbreviations==
*Python : Python is a programming language that lets you work more quickly and integrate your systems more effectively.
*Kivy : Kivy is an open source python library for rapid development of applications that make use of innovative user interfaces, such as multi-touch platforms.
*SQlite : Sqlite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL data engine.

==1.4 References==
*[http://www.python.org/ Python] for definitions and documentation.
*[http://kivy.org/#home Kivy] for definitions and documentation.
*[http://www.sqlite.org/ SQlite] for definitions and documentation.

==1.5 Overview of the remainder of the document==
The SRS regroup the specification of [[Serious_Game:_Handicap,_parole_et_geste]]. The second part is a General Description of the project and the third part presents all the requirements.The fourth part regroup some ideas to improve the final application. These ideas could be implement in future projects to improve the application.

=2. General description=
==2.1 Product perspective==
This project aim to develop an application including several games to help trisomic children to improve their gesture skills.

==2.2 Product functions==
==2.3 User characteristics==
The user doesn't need any IT skills. Somone is needed to log in and eventually configure the game, then the child just need to understand game's rules and he also needs to know how to use a tablet.

==2.4 General constraints==
Application constraints
*Local save of statistics
*Upload statistics
*Easy to add a game
*Easy to use
*Identification with a personnal ID
*Dynamic data base

Game constraints
*Sound
*Record
*Interesting gameplay

==2.5 Assumptions and dependencies==
=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.

==3.1 Requirement X.Y.Z (in Structured Natural Language)==
'''Function''':Rate scientifically if the gesture(touch pad) can help children with communicative troubles to learn new words.

'''Description''':Implement an application with several serious games

'''Inputs''': Pictures of houses, characters and vehicles. Words and sounds.

'''Source''': Researchers

'''Outputs''': Help children to learn new words

'''Destination''': Children T21

'''Action''':
* Several Games available
* Save game's actions in a local data base

'''Non functional requirements''':

'''Pre-condition''':
*Have a tablet with the application
*

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

=5. Appendices=
=6. Index=

Proj-2013-2014-SeriousGame-Parole-et-Geste

2014-03-10T12:47:34Z

RICM4-prj14-grp8: /* Week 8 (March 3nd - March 9th) */

= Introduction =
Development of small 2D games to help children with language disorder.
A second objective is the recovery of the game data to determine the progression and the troubles experienced by children. In this way, we can understand their cognitive abilities and find better ways to help them.

= Team =

*Tutors : Olivier Richard, Marion Dohen, Estelle Gillet-Perret, Amelie Rochet-Capellan

*Members : Mehdi NAIT-SIDOUS, Pierre-Henri GINOUX

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Links =

*[http://kivy.org Kivy]
*[http://gameprogrammingpatterns.com Blog on architectural patterns in game code]
*[https://www.dropbox.com/l/q6E0fhCswT7FbeS18PzV6e Image resources]
*[http://sega.tech.nhl.nl/wiki/index.php/Knowledgebase Wiki with a lot of links on serious game]

= Project objectives =
Le but du projet est de développer une application comprenant des mini jeux qui permettent d'évaluer scientifiquement si la gestualité manuelle peut aider des enfants présentant des troubles communicatifs à mieux apprendre de nouveaux mots.
Une fois cette phase effectuée, il s'agira ensuite de finaliser afin de proposer un outil facilement utilisable à un maximum d'utilisateurs implémentant une méthode d'apprentissage de nouveaux mots en utilisant la gestualité manuelle.

Il faut garder à l'esprit que le jeu n'est qu'une composante du logiciel, nous allons donc dans un premier temps implémenter un jeu simple mais qui permettra de tester toute les composantes de l'application.

Objectifs pour le premier prototype de jeu :
A REMPLIR

Objectifs pour l'application :
* Système de login pour identifier l'utilisateur de manière unique
* Facilité d'ajouter un nouveau jeu dans l'application
* Stockage des résultats en local
* Possiblité d'envoyer les résultats sur un serveur Web
* Possibilité de modifier la configuration pour chaque jeu (changer la difficulté, les images utilisées...)

http://air.imag.fr/index.php/SRS_SeriousGame_RICM_Group

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - Janurary 19th) ==
*Project discovery
*Learning of Python
*Research on Kivy
*Research on serious gaming

== Week 2 (January 20th - Janurary 26th) ==
*Defining functional specifications
*Defining the problems we may/will have to sort out, like being able to store data using a user password. [http://pastebin.com/hvLUT6vc More details (in French)]
*Learning how SQLite works and can be use to store game data

== Week 3 (January 27th - February 2th) ==
*Reflexion about the class structure of the application
*Find a way to create dynamically the database
*Reflexion about the storage of settings

== Week 4 (February 3th - February 9th) ==
* Meeting with Marion Dohen and Amelie Rochet-Capellan
* Reflexions about the specifications
* Split the job in different steps (cf. documentation)

== Week 5 (February 10th - February 16th) ==
* First UML diagrams
* Begin of the first game prototype developpement
* Complete the online documentation

== Week 6 (February 17th - February 23th) ==
* Include the SQlite Data Base in the application
* game prototype developpement
* Complete the online documentation

== Week 7 (February 24th - March 2nd) ==
* UML Diagrams
* Game prototype developpement
* Complete the online documentation

== Week 8 (March 3th - March 9th) ==
* End of the UML documentation
* Game prototype developpement (drag picture OK, sound OK)
* Complete the online documentation

Proj-2013-2014-SeriousGame-Parole-et-Geste

2014-03-10T12:47:11Z

RICM4-prj14-grp8: /* Progress of the project */

= Introduction =
Development of small 2D games to help children with language disorder.
A second objective is the recovery of the game data to determine the progression and the troubles experienced by children. In this way, we can understand their cognitive abilities and find better ways to help them.

= Team =

*Tutors : Olivier Richard, Marion Dohen, Estelle Gillet-Perret, Amelie Rochet-Capellan

*Members : Mehdi NAIT-SIDOUS, Pierre-Henri GINOUX

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 4], [[Polytech Grenoble]]

= Links =

*[http://kivy.org Kivy]
*[http://gameprogrammingpatterns.com Blog on architectural patterns in game code]
*[https://www.dropbox.com/l/q6E0fhCswT7FbeS18PzV6e Image resources]
*[http://sega.tech.nhl.nl/wiki/index.php/Knowledgebase Wiki with a lot of links on serious game]

= Project objectives =
Le but du projet est de développer une application comprenant des mini jeux qui permettent d'évaluer scientifiquement si la gestualité manuelle peut aider des enfants présentant des troubles communicatifs à mieux apprendre de nouveaux mots.
Une fois cette phase effectuée, il s'agira ensuite de finaliser afin de proposer un outil facilement utilisable à un maximum d'utilisateurs implémentant une méthode d'apprentissage de nouveaux mots en utilisant la gestualité manuelle.

Il faut garder à l'esprit que le jeu n'est qu'une composante du logiciel, nous allons donc dans un premier temps implémenter un jeu simple mais qui permettra de tester toute les composantes de l'application.

Objectifs pour le premier prototype de jeu :
A REMPLIR

Objectifs pour l'application :
* Système de login pour identifier l'utilisateur de manière unique
* Facilité d'ajouter un nouveau jeu dans l'application
* Stockage des résultats en local
* Possiblité d'envoyer les résultats sur un serveur Web
* Possibilité de modifier la configuration pour chaque jeu (changer la difficulté, les images utilisées...)

http://air.imag.fr/index.php/SRS_SeriousGame_RICM_Group

= Progress of the project =

The project started January 14th, 2013.

== Week 1 (January 13th - Janurary 19th) ==
*Project discovery
*Learning of Python
*Research on Kivy
*Research on serious gaming

== Week 2 (January 20th - Janurary 26th) ==
*Defining functional specifications
*Defining the problems we may/will have to sort out, like being able to store data using a user password. [http://pastebin.com/hvLUT6vc More details (in French)]
*Learning how SQLite works and can be use to store game data

== Week 3 (January 27th - February 2th) ==
*Reflexion about the class structure of the application
*Find a way to create dynamically the database
*Reflexion about the storage of settings

== Week 4 (February 3th - February 9th) ==
* Meeting with Marion Dohen and Amelie Rochet-Capellan
* Reflexions about the specifications
* Split the job in different steps (cf. documentation)

== Week 5 (February 10th - February 16th) ==
* First UML diagrams
* Begin of the first game prototype developpement
* Complete the online documentation

== Week 6 (February 17th - February 23th) ==
* Include the SQlite Data Base in the application
* game prototype developpement
* Complete the online documentation

== Week 7 (February 24th - March 2nd) ==
* UML Diagrams
* Game prototype developpement
* Complete the online documentation

== Week 8 (March 3nd - March 9th) ==
* End of the UML documentation
* Game prototype developpement (drag picture OK, sound OK)
* Complete the online documentation

File:RICM4-1314-GL-DM-SeriousGame.pdf

2014-03-10T08:23:08Z

RICM4-prj14-grp8: RICM4-prj14-grp8 uploaded a new version of "File:RICM4-1314-GL-DM-SeriousGame.pdf"

DM Génie Logiciel
Ginoux, Nait-Sidous

Proj-2013-2014-SeriousGame-Parole-et-Geste/UML

2014-03-10T01:50:24Z

RICM4-prj14-grp8:

[[File:RICM4-1314-GL-DM-SeriousGame.pdf]]