Conception d'une application de consultation en ligne des ouvrages d'une bibliothèque

I.2. CADRE THEORIQUE

Cette partie est consacrée à des outils et méthodes pour le développement de cette étude.

I.2.1. Méthode utilisée

Les méthodes d'analyse et de conception fournissent une méthodologie et des notations standards et universelles qui aident à recevoir les logiciels de qualité. Il existe différentes sortes pour classer ces méthodes.

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

> La distinction entre composition et décomposition

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

22

Elle met en opposé d'une part les méthodes ascendantes qui consistent à construire un logiciel par composition à partir des modules existants et d'autre part, les méthodes descendantes qui décomposent récursivement le système jusqu'à arriver à des modules programmables simplement.

> La distinction entre fonctionnelle dirigée par le traitement et orientée objet

Dans la stratégie fonctionnelle (également qualifiée de structurelle) un système est vu comme un ensemble hiérarchique d'unités en interaction. Les fonctions disposent d'un état local, mais le système a un état partagé, qui est centralisé et accessible par l'ensemble des fonctions. Chaque objet dispose d'un ensemble d'attributs décrivant son état et l'état du système est décrit (de façon décentralisée) par l'état de l'ensemble.

I.2.2. Processus de développement

Le processus de développement définit une séquence d'étapes, en parties ordonnées qui concourent à l'élaboration d'un logiciel ou à l'évolution d'un système existant. L'objet d'un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans le temps et des coûts prévisibles.²⁸

I.2.2.1. Processus unifié (Unified Process)

C'est un processus de développement logiciel construit sur UML. Il est itératif et inc rémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les risques.

> Itératif et incrémental : Le projet est découpé en itérations de courte durée (environ un mois) qui aident à mieux suivre

28 Pascal Roques et FrancK Vallée, UML2 en action, de l'analyse à la conception, Page 12

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

23

l'avancement global. A la fin de chaque itération, une partie exécutable du système final est produite de façon incrémentale.

> Centré sur l^,architecture : tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facilitée. Cette architecture (fonctionnelle, logique, matérielle etc.) doit être modélisée en UML et pas seulement documentée en texte.

> Piloté par les risques : les risques majeurs d'échec du projet doivent être identifiés au lus tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l'ordre des itérations. Nous identifions une première cause provenant de l'incapacité de l'architecture technique à répondre aux contraintes opérationnelles et une seconde cause liée à l'inadéquation du développement aux besoins des utilisateurs.

> Conduit par les cas d^,utilisatio n : le projet est mené en tenant compte des besoins et des exigences des utilisateurs. Les cas d'utilisation du futur système sont identifiés et décrits avec précision et priorité.

v Cycle de vie

Le processus unifié répète un certain nombre de fois une série de cycles. Tout cycle de vie se conclut par la livraison du produit aux clients et s'articule en quatre phases ; La création, l'élaboration, la construction et la transition. Chacune d'entre elle se subdivise à son tour en itérations.

Essayons tout d'abord de parler du cycle de vie UP, en suite nous reviendrons sur les phases du processus unifié.

Pour mener efficacement le cycle, les développeurs ont besoin de construire toutes les représentations du logiciel.

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

24

· Modèle d'analyse : détaille les cas d'utilisation et procède à une première répartition du comportement du système entre divers objets ;

· La conception : définit la structure statique du système sous forme de sous-systèmes, classes et interfaces. Elle définit les cas d'utilisation réalisé sous forme de collaboration entre les sous-systèmes, les classes et les interfaces ;

· Implémentation : intègre les composants (code source) et la correspondance entre les classes et les composants ;

· Déploiement : définit les noeuds physiques des ordinateurs et l'affection de ces composants sur les noeuds ;

· Test : décrit les cas de test vérifiant les cas d'utilisation.

Tous ces modèles sont reliés. Ensemble, ils représentent le système comme un tout. Les éléments de chacun des modèles présentent de dépendances de traçabilité, ce qui facilite la compréhension et les modifications ultérieures.

Phases et activités du processus unifié

Le processus unifié se déroule en quatre phases, chaque phase répète un nombre de fois une série d'itérations et chaque itération est composée de cinq activités : la capture de besoins, l'analyse, la conception l'implémentation et le test.

- Expression des besoins(capture des besoins)

L'expression des besoins comme son nom l'indique, permet de définir les différents besoins :

· Inventorier les besoins principaux et fournir une liste de leurs fonctions ;

· Recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à l'élaboration des modèles de cas d'utilisation ;

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

25

· Appréhender les besoins non fonctionnels (techniques) et livrer une liste des exigences ;

Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et représente sous forme des cas

d'utilisation et d'acteur les besoins du client.

- Analyse

L'analyse permet d'accéder à une compréhension des besoins et des exigences des clients. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la solution. Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les structures sous une forme qui facilite la compréhension (scénarios), la préparation (définition de l'architecture), la modification et la maintenance du futur système.

Il s'écrit dans le langage des développeurs et peut être considéré comme une première ébauche du modèle de conception.

- Conception

La conception permet d'acquérir une compréhension approfondie des contraintes liées au langage de programmation, à l'utilisation des composants et au système d'exploitation.

Elle détermine les principales interfaces et les transcrit à l'aide d'une notation commune.

Elle constitue un point de départ à l'implémentation :

· Elle décompose le travail d'implémentation en sous-systèmes ;

· Elle crée une abstraction transparente de l'implémentation.

- Implémentation

L'implémentation est le résultat de la conception pour implémenter le système sous formes de composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutables et d'autres éléments du même type.

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

26

Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants pour chaque itération, et de produire les classes et les sous-systèmes sous formes de codes sources.

- Test

Les tests permettent de vérifier des résultats de l'implémentation en testant la construction.

Pour mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat de chacun.

v Les phases

Analyse des besoins ou inception

L'analyse des besoins donne une vue du projet sous forme de produit fini. Cette phase porte essentiellement sur les besoins principaux (du point de vue de l'utilisateur), l'architecture générale du système, les risques majeurs, les délais et les coûts. On le met en place le projet.

- Que fait le système par rapport aux utilisateurs ?

- Quelle va être l'architecture générale (cible) de ce système ?

- Quels vont être les délais, les coûts, les moyens, les ressources à déployer ? Elaboration

L'élaboration reprend les éléments de la phase d'analyse des besoins et les précise pour arriver à une spécification détaillée de la solution à mettre en oeuvre.

L'élaboration permet de préciser la plupart des cas d'utilisation, de concevoir l'architecture du système et surtout de déterminer l'architecture de référence.

Au terme de cette phase, les chefs de projet doivent être en mesure de prévoir les activités et d'estimer les ressources nécessaires à l'achèvement du projet.

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

27

Les tâches à effectuer dans la phase d'élaboration sont les suivantes :

- Créer une architecture de référence ;

- Identifier les risques, ceux qui sont de nature à bouleverser le plan, le coût et le calendrier ;

- Définir les niveaux de qualité à atteindre ;

- Formuler les cas d'utilisation pour couvrir les besoins fonctionnels et planifier la phase de construction ;

- Elabo re r une offre abordant les questions de calendrier, de personnel et de budget.

Construction

La construction est le moment où l'on construit le produit. L'architecture de référence se métamorphose en produit complet. Le produit contient tous les cas d'utilisation que les chefs de projet, en accord avec les utilisateurs ont décidés de mettre au point pour cette version.

Transition

Le produit est une version béta. Un groupe d'utilisateur essaye le produit et détecte les anomalies et défauts.

Cette phase suppose des activités comme la formation des utilisateurs clients, la mise en oeuvre d'un service d'assistance et la correction des anomalies constatées.

LE LANGAGE UML (UnifiedModelingLanguage)

UML se définit comme un langage de modélisation graphique et textuelle destiné à comprendre et à décrire les besoins, spécifier, concevoir des solutions et communiquer des points de vue.

UML unifie à la fois les notations et les concepts orientés objet. Il ne s'agit pas d'une simple notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au

28

même titre que les mots d'un langage. C'est pour ça qu'UML est présenté comme une méthode.

UML unifie également les notations nécessaires aux différentes activités d'un processus de développement offre, par ce biais le moyen d'établir le suivi des décisions prises, depuis la définition des besoins jusqu'au codage.²⁹

Le modèle en tant qu'abstraction d'un système s'accorde parfaitement bien avec les concepts orientés objets.

Un objet peut en effet représenter l'abstraction d'une entité utilisée en analyse, puis d'un composant de solution logicielle en conception.

UML s'articule autour de treize types de diagrammes répartis e deux grands groupes :

> Six diagrammes structurels

· Diagramme de classes : il montre les briques de base statiques : classes, associations, interfaces, attributs, opérations, généralisations, etc.

· Diagramme d'objet : il montre les instances des éléments structurels et leurs liens à l'exécution ;

· Diagramme de packages : il montre l'organisation logique du modèle et les relations entre pacKages ;

· Diagramme de composants : il montre des structures complexes avec leurs interfaces fournies et requises ;

· Diagramme de déploiement : il montre le déploiement physique des « artefacts » sur les ressources matérielles ;

· Diagrammes de structure composite : il montre l'organisation interne d'un élément statique complexe.

> Sept diagrammes comportementaux

²⁹Pitman N. UML2 en concentré, Paris 2006, Page 67

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

29

· Diagramme de cas d'utilisation : il montre les interactions fonctionnelles entre les acteurs et le système à l'étude ;

· Le diagramme de vue d'ensemble des interactions : il fusionne les diagrammes d'activité et de séquence pour combiner des fragments d'interaction avec des décisions et des flots ;

· Diagramme de séquence : il montre la séquence verticale des messages entre objets au sein d'une interaction ;

· Diagramme de communication : il montre la communication entre objets dans le plan au sein d'une interaction ;

· Diagramme d'activité : il montre l'enchainement des actions et décisions au sein d'une activité ;

· Diagramme de temps : il fusionne les diagrammes d'états et de séquence pour montrer l'évolution de l'état d'un objet au cours du temps ;

· Diagramme d^,état : il montre les différents états et transition possible des objets d'une classe.

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

KABAMBA MUKOLE René (René KM) Contact : [e-mail]

30