Memoire Online - Conception et transformation d'une application web en application mobile

- disponibles sur un grand nombre de modèles de téléphones la diversité et le volume des ventes des Androphones étant sans limites ;

- un téléphone globalement plus rapide puisqu'il est dépossédé des surcouches imposées par les constructeurs ;

- des possibilités de sur-cadencement ou de sous-cadencement des composants afin d'obtenir un téléphone plus réactif, plus puissant ou plus autonome que la version originale.

- Certains téléphones qui ne peuvent normalement pas être mis à jour peuvent utiliser la version d'Android avec une version alternative.

- le principal reste la stabilité qui peut poser des conflits entre les processus et conduire au redémarrage intempestif du téléphone, ce problème étant de moins en moins fréquent avec Android 4.4 ;

- certaines fonctionnalités sont plus lentes d'autres plus rapides parfois inexistantes (Appareil photo, touches en façade, réactivité de l'écran) ;

- du fait du grand choix de ROM disponibles, l'utilisateur risque de perdre beaucoup de temps à sélectionner celle qui lui convient le mieux ;

Android définit un support compatible comme étant un support capable d'exécuter n'importe quelle application Android. Pour permettre aux fabricants d'y parvenir, Android réalise le Compatibility Program (programme de compatibilité). Les différents supports sont :

Le processus unifié est un processus de développement moderne, itératif, efficace sur des projets informatiques de toutes tailles. Très complet, il couvre l'ensemble des activités, depuis la conception du projet jusqu'à la livraison de la solution. Intégrant une organisation de projet type, une méthodologie utilisant UML et un ensemble de bonnes pratiques cohérentes entre elles, il permet de circonvenir aux problèmes récurrents que rencontrent nombre de réalisations : dérive des coûts et des délais, qualité insuffisante, réponse incomplète aux attentes des utilisateurs. Un point d'excellence de cette démarche est son adaptabilité : UP peut se décliner en fonction de l'ampleur d'un projet, de l'expérience de l'équipe qui l'assume, de la nature de la solution à construire¹⁰.

Le processus de développement UP, associé à UML, met en oeuvre les principes suivants :

Ces principes sont à la base du processus unifié décrit par les auteurs d'UML. II.1.2.1. Processus guidé par les cas d'utilisation

L'orientation forte donnée ici par UP est de montrer que le système à construire se définit d'abord avec les utilisateurs. Les cas d'utilisation permettent d'exprimer les interactions du système avec les utilisateurs, donc de capturer les besoins. Une seconde orientation est de montrer comment les cas d'utilisation constituent un vecteur structurant pour le développement

10 Prof. Associé., MUSANGU LUKA Marcel, Conception de méthode Agiles, Cours inédit, L1 IG, ISP/Bukavu, 20142015.

et les tests du système. Ainsi le développement peut se décomposer par cas d'utilisation et la réception du logiciel sera elle aussi articulée par cas d'utilisation.

Ce type de démarche étant relativement connu dans l'approche objet, il paraît naturel qu'UP préconise l'utilisation du principe de développement par itérations successives. Concrètement, la réalisation de maquette et prototype constitue la réponse pratique à ce principe. Le développement progressif, par incrément, est aussi recommandé en s'appuyant sur la décomposition du système en cas d'utilisation. Les avantages du développement itératif se caractérisent comme suit:

- les premières itérations permettent d'avoir un feed-back des utilisateurs, - les tests et l'intégration se font de manière continue,

Les auteurs d'UP mettent en avant la préoccupation de l'architecture du système dès le début des travaux d'analyse et de conception. Il est important de définir le plus tôt possible, même à grandes mailles, l'architecture type qui sera retenue pour le développement, l'implémentation

11 Prof. Dr., MUSANGU LUKA, Conception de système d'information,Cours inédit, L1 IG, ISP/Bukavu, 2014-2015.

et ensuite le déploiement du système. Le vecteur des cas d'utilisation peut aussi être utilisé pour la description de l'architecture.

L'analyse des risques doit être présente à tous les stades de développement d'un système. Il est important de bien évaluer les risques des développements afin d'aider à la bonne prise de décision. Du fait de l'application du processus itératif, UP contribue à la diminution des risques au fur et à mesure du déroulement des itérations successives.

Le processus unifié s'organise dans la répétition d'un nombre de cycles qui se termine par une nouvelle version du logiciel.

Les phases d'un processus de développement sont des états de celui-ci à un instant.

Le cycle de développement du Processus Unifié organise les tâches et les itérations en quatre phases5 :

? Inception ou lancement : Cette phase correspond à l'initialisation du projet où l'on mène une étude d'opportunité et de faisabilité du système à construire. Une évaluation des risques est aussi réalisée dès cette phase. En outre, une identification des principaux cas d'utilisation accompagnée d'une

description générale est modélisée dans un diagramme de cas d'utilisation afin de définir le périmètre du projet. Il est possible, à ce stade, de faire réaliser des maquettes sur un sous-ensemble des cas d'utilisation identifiés. Ce n'est qu'à l'issue de cette première phase que l'on peut considérer le projet véritablement lancé

? Elaboration : Cette phase reprend les résultats de la phase d'Inception et élargit l'appréciation de la faisabilité sur la quasi-totalité des cas d'utilisation. Ces cas d'utilisation se retrouvent dans le diagramme des cas d'utilisation qui est ainsi complété. Cette phase a aussi pour but d'analyser le domaine technique du système à développer afin d'aboutir à une architecture stable. Ainsi, toutes les exigences non recensées dans les cas d'utilisation, comme par exemple les exigences de performances du système, seront prises en compte dans la conception et l'élaboration de l'architecture. L'évaluation des risques et l'étude de la rentabilité du projet sont aussi précisées. Un planning est réalisé pour les phases suivantes du projet en indiquant le nombre d'itérations à réaliser pour les phases de construction.

? Construction : Cette phase correspond à la production d'une première version du produit. Elle est donc fortement centrée sur les activités de conception, d'implémentation et de test. En effet, les composants et fonctionnalités non implémentés dans la phase précédente le sont ici. Au cours de cette phase, la gestion et le contrôle des ressources ainsi que l'optimisation des coûts représentent les activités essentielles pour aboutir à la réalisation du produit. En parallèle est rédigé le manuel utilisateur de l'application.

? Transition : Après les opérations de test menées dans la phase précédente, il s'agit dans cette phase de livrer le produit pour une exploitation réelle. C'est ainsi que toutes les actions liées au déploiement sont traitées dans cette phase. De plus, des « bêta tests » sont effectués pour valider le nouveau système auprès des utilisateurs.

? Une phase peut-être divisée en itérations. Une itération est un circuit complet de développement aboutissant à une livraison (interne ou externe) d'un produit exécutable. Ce produit est un sous-ensemble du produit final en cours de développement, qui croît de manière incrémentale, d'itération en itération pour

devenir le système final. Chaque itération au sein d'une phase aboutit à une livraison exécutable du système.

Les activités représentent les actions à effectuer au cours d'une phase : une phase passe par l'ensemble des activités. Le temps passé par activité est fonction des phases. Nous nous limiterons donc à ne donner qu'une brève explication de chaque activité. Expression des besoins UP propose d'appréhender l'expression des besoins en se fondant sur une bonne compréhension du domaine concerné pour le système à développer et une modélisation des procédures du système existant. Ainsi, UP distingue deux types de besoins :

? les besoins fonctionnels qui conduisent à l'élaboration des cas d'utilisation,

? les besoins non fonctionnels (techniques) qui aboutissent à la rédaction d'une matrice des exigences.

L'analyse permet une formalisation du système à développer en réponse à l'expression des besoins formulée par les utilisateurs. L'analyse se concrétise par l'élaboration de tous les diagrammes donnant une représentation du système tant statique (diagramme de classe principalement), que dynamique (diagramme des cas d'utilisation, de séquence, d'activité, d'état-transition...).

La conception prend en compte les choix d'architecture technique retenus pour le développement et l'exploitation du système. La conception permet d'étendre la représentation des diagrammes effectuée au niveau de l'analyse en y intégrant les aspects techniques plus proches des préoccupations physiques.

12 Prof. Dr., MUSANGU LUKA, Conception de système d'information,Cours inédit, L1 IG, ISP/Bukavu, 2014-2015.

Cette phase correspond à la production du logiciel sous forme de composants, de bibliothèques ou de fichiers. Cette phase reste, comme dans toutes les autres méthodes, la plus lourde en charge par rapport à l'ensemble des autres phases (au moins 40 %).

- La bonne implémentation de toutes les exigences (fonctionnelles et techniques), - Le fonctionnement correct des interactions entre les objets,

- la bonne intégration de tous les composants dans le logiciel. Classiquement, différents niveaux de tests sont réalisés dans cette activité : test unitaire, test d'intégration, test de réception, test de performance et test de non régression.

15 Prof. Dr., MUSANGU LUKA, Conception de système d'information,Cours inédit, L1 IG, ISP/Bukavu, 2014-2015.

Il existe plusieurs processus de développement qui implémente le UP dont le plus intéressant le 2UP (2 Tracks Unified Process). Pour un modèle2TUP, tout développement peut être décomposé et traités en parallèle selon un axe fonctionnel et un axe technique. Nous pouvons ainsi suivre les évolutions liées aux changements des besoins fonctionnels et aux changements des besoins techniques6. La schématisation du processus de développement correspond alors à un Y. Les deux perspectives se rejoignant lors de la phase de conception préliminaire.

La spécification des besoins représente une manière assez simple du cycle de développement d'une application. On décrit sans ambiguïté l'application à développer. Dans ce chapitre nous allons spécifier l'ensemble des besoins fonctionnels et non fonctionnels liées à notre application. Ensuite, nous allons modéliser les spécifications semi-formelles des besoins à l'aide des diagrammes de cas d'utilisation et les diagrammes de séquences.

En effet, l'identification des besoins fonctionnels représente une étape importante du processus de développement 2TUP (2 Tracks Unified Process)

Ce point a pour but de présenter les besoins fonctionnels auxquels devrait répondre notre application.

On va s'intéresser à la branche gauche du cycle en Y qui est « la capture des besoins fonctionnels » en décrivant les différentes façons qui seront disponible pour permettre les acteurs d'utiliser la future application mobile.

Dans le cadre de la modélisation de notre système, nous nous contenterons des diagrammes suivants : dans les vues statiques on va utiliser les diagrammes classes et les diagrammes de cas d'utilisation. En suite dans les vues dynamiques on va utiliser le diagramme de séquences et d'activité.

? Le diagramme de cas d'utilisation est un service rendu à l'utilisateur, il implique des séries d'actions plus élémentaires.

? Un Acteur est une entité extérieure au système modélisé, et qui interagit directement avec lui.

A noter que les acteurs impliqués dans un cas d'utilisation sont liés par une association et un acteur peut utiliser plusieurs fois le même cas d'utilisation.

En ce qui concerne les acteurs en UML, on peut noter qu'un acteur correspond à un rôle et ce n'est pas une personne physique. Les acteurs sont les utilisateurs du système.

? Une même personne physique peut être représentée par plusieurs acteurs si elle a plusieurs rôles

? Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront représentées par un seul acteur

? En plus des utilisateurs, les acteurs peuvent être : des périphériques, des logiciels déjà disponibles intégrés dans le projet et des systèmes informatiques externes au système mais qui interagissent avec lui.

+ Acteur principale : l'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est à l'initiative des échanges nécessaires pour réaliser le cas d'utilisation.

+ Acteurs secondaire : sont sollicités par les systèmes alors que le plus souvent les acteurs principaux ont l'initiative des interactions.

Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation.

Avant tout, on doit d'abord recenser ces cas d'utilisation en tenant compte des principes ci-après :

> Il faut se placer du point de vue de chaque acteur et déterminer comment il sert le

système. Dans quels cas il l'utilise et à quelles fonctionnalités doit-t-on avoir les accès. > Il faut éviter les redondances et limiter les nombres de cas en se situant au bon niveau

> Il ne faut pas faire apparaître les détails des cas d'utilisations, mais il faut rester au niveau des grandes fonctionnalités du système.

Une étude succincte du système à mettre en place nous a permis d'identifier les acteurs et les cas d'utilisations correspondantes :

b) Administrateur : Acteur secondaire est le second acteur principal qui utilise le système pour y' Contrôler les demandes et répondre aux messages des mobinautes;

Le diagramme de contexte statique est un diagramme dans lequel chaque acteur est relié par une association à une classe centrale unique représentant le système.

1. *

Système de réservation de places dans le bateau

Mobinaute

Administrateur

Le diagramme des cas d'utilisation présente la structure des grandes fonctionnalités nécessaires aux utilisateurs du système. Il assure la relation entre l'utilisateur et les objets du système et se présente comme suit :

Un acteur représente l'abstraction d'un rôle joué par des entités externe qui interagissent directement avec le système étudié. Un acteur peut consulter, et/ou modifier directement l'état du système, en émettant, en recevant des messages éventuellement porteurs de données. Voici quelques explications sur les acteurs du système :

0. Le mobinaute : Il est celui qui souhaite avoir une précision et réserver la place alors il va falloir pour lui s'inscrire et une fois que celui-ci a déjà rempli condition demander par l'entreprise pour avoir accès au système il doit obtenir un message de confirmation pour qu'il puisse assurer ses responsabilités et ainsi voyager au temps planifié,

1. L'administrateur : c'est le responsable de l'application, celui qui fait passer les mouvements qui se font dans l'application en permanence comme : la publication, publicité, mise à jour,...

Un cas d'utilisation (use case) représente l'ensemble de séquence d'action réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier. En effet, ils sont des représentations fonctionnelles du système, ils permettent de modéliser les attentes des utilisateurs afin de réaliser une bonne délimitation du système et également d'améliorer la compréhension de son fonctionnement Voici l'illustration graphique de ce tableau par le diagramme de cas d'utilisation :

? Selon Pierre Gérard, la méthode comprend trois sortes de relation ou association qui sont¹⁶ :

? Inclusion : le cas A Inclut le cas B(c'est-à-dire B est une partie obligatoire de A) ? Extension : le cas B étend le cas A( c'est-à-dire A est la partie optionnelle A )

¹⁶ Pierre Gérard, modélisation des objets élémentaire avec UML 2, Edition DUT Informatique, Page 13

? Généralisation : le cas A est une généralisation du cas B (B est une sorte de A)

Dans notre diagramme de cas d'utilisation, nous allons décrire certaines cas pour expliciter l'utilisation du système tels que

0. Cas d'utilisation S'inscrire
Résume : ce cas d'utilisation permet à l'acteur de s'inscrire pour qu'il puisse accéder à la page de réservation
Acteur : Mobinaute
Condition : le Mobinaute doit se connecter au site de la société
Scenario En se connectant au site le mobinaute qui veut nouer une bonne relation avec les Etablissements SILIMU, s'il est intéresse il doit d'abord s'inscrit en s'enregistrant dans la base de la société
1. Cas d'utilisation Authentification		Résume : ce cas permet à un utilisateur de se connecter au système, et lui présenter l'interface et les fonctionnements relatifs à son profil.
Acteurs : Administrateur, Mobinaute
Condition : introduire le login et mot de passe
Scenario : le système invite l'acteur à entre son login et son mot de passe et l'acteur saisit puis le système vérifie les paramétrages si c'est correcte il ouvre l'espace de travail correspondant au profil.
2. Cas d'utilisation réserver une place

Résume : permet aux mobinaute de se réserver une place dans le bateaux qui voyage ce jour-là et dans la mesure du possible venir lui prendre par le bus à son domicile.
Acteur : Mobinaute
Condition : Il faut qu'il s'enregistre d'abord

17 Pierre GERARD. Modélisation des objets élémentaires avec UML 2, Ouvrage Edition D.U.T informatique page 13

18 Oscar MARCOS ENAGNON ADOUN. Conception en génie informatique et télécommunication Ouvrage Edition 2009

La modélisation dynamique décrit le comportement dynamique du système. Pour notre mémoire en ce qui concerne la modélisation dynamique nous allons utiliser le diagramme de séquence.

Après l'évaluation de la technologie, les applications mobiles et les sites web ont progressivement évolué, les attentes des utilisateurs et des clients également. De ce fait, notre application utilise l'architecture MVC. L'architecture MVC (Modèle, Vue et Contrôleur) est un concept très puissant qui intervient dans la séparation des données (modèle), de l'affichage (vue) et des actions (contrôleur)

Représente le comportement de l'application : traitements des données, interactions avec la base de données, etc. Il décrit les données manipulées par l'application et définit les méthodes d'accès.

Correspond à l'interface avec laquelle l'utilisateur interagit. Les résultats renvoyés par le modèle sont dénués de toute présentation mais sont présentés par les vues. Plusieurs vues peuvent afficher les informations d'un même modèle. Elle peut être conçue en html, ou tout autre « langage » de présentation. La vue n'effectue aucun traitement, elle se contente d'afficher les résultats des traitements effectués par le modèle, et de permettre à l'utilisateur d'interagir avec elles

Prend en charge la gestion des évènements de synchronisation pour mettre à jour la vue ou le modèle. Il n'effectue aucun traitement, ne modifie aucune donnée, il analyse la requête du mobinaute et se contente d'appeler le modèle adéquat et de renvoyer la vue correspondante à la demande. Choix de l'architecture MVC Nous avons choisi de travailler avec l'architecture MVC, car elle permet de bien séparer la logique de la présentation. La vue n'aura aucune logique d'imbriquer. Aussi, étant donné que tout est très bien séparé, il est très facile d'ajouter et de modifier au code sans que le reste ne s'effondre. C'est un pattern qui se prête très bien au développement. Le schéma suivant résume la structure générique d'une architecture MVC.

Flux de traitement. En résumé, lorsqu'un mobinaute fait une recherche à l'application :

La requête envoyée depuis la vue est analysée par le contrôleur (par exemple un clic de souris pour lancer un traitement de données) ;

Le contrôleur demande au modèle approprié d'effectuer les traitements et notifie à la vue que la requête est traitée (« via » par exemple un Handler ou callback) ;

La vue notifiée fait une requête au modèle pour se mettre à jour (par exemple affiche le résultat du traitement « via » le modèle). Avantages Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base de données de type SQL à XML en changeant simplement les traitements d'interaction avec la base, et les vues ne s'en trouvent pas affectées.

Le MVC montre ses limites dans le cadre des applications utilisant les technologies du web, bâties à partir de serveurs d'applications. Des couches supplémentaires sont alors introduites ainsi que les mécanismes d'inversion de contrôle et d'injection de dépendance.

Le diagramme de classes permet de spécifier la structure et les liens entre les objets dont le système est composé. Une classe est la description d'un ensemble d'objets ayant une sémantique, des attributs, des méthodes et des relations en commun.

Une classe est composée d'un nom, d'attributs et d'opérations. II.3.2.1.1 Formalisme de la classe

II.3.2.1.2. Identification des classes et description des associations II.3.2.1.2.1. Tableau des descriptions

Le diagramme de séquence représente la succession chronologique des opérations réalisées par un acteur. Il a une dimension temporelle et modélise les aspects dynamiques du système. Par contre nous utilisons les diagrammes d'activité pour documenter le logique métier durant l'analyse et non pour commencer prématurément l'implémentation.

Signalons que nous allons donner les diagrammes qui représentent les activités à réaliser pour chaque objet spécifié.

Pour ce cas nous représenterons seulement les diagrammes nécessaires de notre système

Ce diagramme montre comment un client peut s'enregistrer pour demande d'abonnement à son espace et l'envoyer.

Ce diagramme permet au mobinaute de saisir sa demande sous forme de message et l'envoyer au serveur

? Diagramme de séquence Répondre et mise à jour Messages et Mobinaute: ce diagramme va tant aider l'administrateur à répondre aux questions des mobinautes et par ricochet mettre à jours les inscriptions des mobinautes et leurs messages :

C'est un diagramme permettant de voir le comportement d'une personne qui veut se connecter. Et l'espace sera affiché quand le login et mot de passe sont corrects et non dans le cas contraire. Voici schématiquement ce diagramme :

Ce diagramme montre la répartition physique des éléments matériels du système (processeurs, périphériques) et leurs connexions. Cette architecture comprend des noeuds correspondant aux supports physiques (serveurs, routeurs,...) ainsi que la répartition des artefacts logiciels (bibliothèques, exécutables,...) sur ces noeuds.

? Noeud¹⁹ : un noeud correspond à une ressource matérielle de traitement sur laquelle des artefacts seront mis en oeuvre pour l'exploitation du système. Les noeuds peuvent être interconnectés pour former un réseau d'éléments physiques.

? Artefact²⁰ : est la spécification d'un élément physique qui est utilisé ou produit par le processus de développement du logiciel ou par le déploiement du système. C'est donc un élément correct comme un fichier, un exécutable ou une table d'une base de données.

19 Jérôme Chambard, Dictionnaire Du Web - Edition 2015, Ouvrage, Edition 2014

Conception et transformation d'une application web en application mobile

I.2.2.2. Leurs avantages sont les suivants