JY Tigli Homepages

• Les nouveaux Systèmes Informatisés et extension du binôme BackEnd - FrontEnd
• Organisation, Eléments Techniques et Méthodologie

Support de présentation et décomposition du projet 2018

Les nouveautés de 2019

• Domaine 2019 : Smart Building … Gestion intelligente des files d'attente …

Deux plateformes sont à la disposition des étudiants pour le développement de ce projet.

• une plateforme Raspberry PI et
• une plateforme cible Android comme un smartphone

On peut distinguer deux grands types d'architectures logicielles dès lors que l'on met en place un équipement connecté qui peut être à la fois un terminal offrant une GUI comme une interface Web ou une plateforme de développement d'un objet connecté (mon Smartphone est avant tout, un ensemble de capteurs et d'actionneurs, comme la tactilité de l'écran, le capteur sonore, l'inclinomètre et l'affichage, le buzzer, etc.).

Selon le point de vue, le développement avec des mobiles peut reposer sur deux grands types d'architectures :

• Une approche Frontend - Backend telle que vous l'avez appréhendée lors de la première partie de votre projet. En génie logiciel, les termes front-end et back-end font référence à la séparation des préoccupations entre la couche de présentation (front-end) et la couche d'accès aux données (back-end). Dans le modèle client – ​​serveur, le client est généralement considéré comme le serveur frontal et le serveur, comme le serveur principal, même lorsqu'un travail de présentation est en réalité effectué sur le serveur lui-même. Cette vision est plutôt adaptée à l'utilisation du smartphone comme terminal utilisateur exécutant des applications qui communiquent avec le backend. Ces applications peuvent être natives. Mais dans la mesure du possible, on leur préférera des applications web dotées de mécanismes de responsive design qui pourront s'exécuter sur n'importe cible dotée d'un browser.

• L'autre approche consiste à considérer le smartphone comme un dispositif physique ou objet connecté particulier. Dans ce cas votre Smartphone doit être vu comme un des N équipements connectés autour de vous offrant des services à l'instar de ceux fournis par votre backend, google, votre SMART TV etc. La vision architectural est alors celle d'un ensemble d'API accessibles via le Web (services web) proposant différentes fonctionnalités, fussent-elles liées à des SAAS providers, des équipements connectés etc. On parle parfois dans ce cas de bus de services .

Ce second type d'intégration d'un smartphone est souvent difficile à envisager. En effet le smartphone est trop souvent perçu comme un terminal mobile plus proche du PC que de la télécommande, et pourtant …

Voici donc quelques exemples où le smartphone n'est pas un terminal complet susceptible d'accueillir des applications interactives dotés d'interacteurs graphiques.

Le smartphone comme écran tête haute, par exemple, ne permet que d'afficher des images, des vidéos, des pages web etc. mais ne permet pas d'interagir avec des applications, et donc d'entrer des données.

Le smartphone est aussi une boîte contenant un grand nombre de capteurs, qui suffisent pour nombre d'applications n'utilisant pas d'écran tactile.

Le téléphone peut être donc vu à l'instar du Rapsberry PI, comme un nano-ordinateur dotés de capteurs et d'actionneurs plus ou moins particuliers avec lesquels vous pouvez par programmation construire un équipement particulier. Dans ce projet, un bouton et un compteur sur l'écran en feront un objet similaire à celui des groupes utilisant un Raspberry PI.

Une architecture orientée service, est basée sur une approche distribuée. En premier lieu elle repose sur un ensemble de service disponibles. Chaque service fournit une API (Application Protocol Interface) comme celle d'une bibliothèque, à ceci près que les invocations de cette API se font à travers le réseau depuis un client vers un serveur.

Ces services peuvent fournir :

• des interfaces graphiques (ex. le Service Web ThingSpeak),
• des accès à des équipements physiques (ex. smart TV, smart sensors)
• des accès à des bases de données (ex. MongoDB)
• des accès à d'autres systèmes d'information (ex. Google API, Microsoft Azure) à haute valeur ajoutée (carte, traffic temps réel, reconnaissance d'image, reconnaissance vocale, etc.)

Tous ces services sont indépendants de l'application qui l'utilise. Ils sont ainsi utilisables et réutilisables par de multiples applications.

Une application est dès lors un orchestrateur qui gère la logique métier à mettre en place dans les interactions entre les services utilisés.

L'ajout d'un nouveau service dans les services disponibles est complétement indépendant de l'ajout d'une nouvelle application utilisant les services disponibles.

Cette architecture est donc particulièrement adaptée aux méthodes agiles où les incréments peuvent être de 2 catégories : ajouter un nouveau service (offert par un équipement, un système d'information, etc.) ou modifier l'application en modifiant la logique de l'orchestrateur.

Les protocoles d'échange entre vos fournisseurs d'API et votre orchestrateur(utilisateur des APIs) peuvent être de différentes natures.

• une des approches les plus connues et utilisées sont les Web services de type REST. Cette approche basée sur des communications Web (protocole HTTP),sont de type client/serveur. Les APIs sont donc accessibles à travers des Serveur Web. L'orchestrateur y accède avec des clients.
• d'autres approches peut se baser sur d'autres protocoles d'échange et même de modèle de communication. C'est le cas des communications événementiels qui se distingue des approches client/serveurs. Un des exemples les plus connus est MQTT.

Après avoir installé Android Studio