Les processus unifiés et UML
Chap. I
Généralités et plan prévisionnel de la réalisation du projet
Conception et réalisation d’un système d’information de gestion des clients d’un laboratoire provincial de la sante publique «La science restera toujours la satisfaction du plus haut désir de notre nature, la curiosité; elle fournira à l’homme le seul moyen qu’il ait d’améliorer son sort’’ [Ernest Renan]
Dans le cadre de ce chapitre, nous allons définir quelques généralités portant sur la méthode et outils mettant en évidence la réalisation de notre projet.
Nous allons commencer par présenter le langage de modélisation unifié UML (Unified Modeling Language), définir la démarche générique du processus de développements logiciel qui l’accompagne, énumérer les architectures réseaux.
I.I. Les processus unifiés et UML
Pendant plusieurs décennies, le monde informatique a toujours rêvé d’un processus qui puisse garantir le développement efficace de logiciels de qualité, valable quel que soit la grandeur et la complexité du projet, et présentant de bonnes pratiques adaptées à la méthode en question, surtout que, de nos jours, les logiciels demandés sont de plus en plus imposants et exigeants qu’auparavant.
Le processus unifié semble être la solution idéale pour remédier à l’éternel problème des développeurs. En effet, il regroupe les activités à mener pour transformer les besoins d’un utilisateur en un système logiciel quel que soit la classe, la taille et le domaine d’application de ce système.
Le processus unifié utilise le langage UML (Unified Modeling Language). Ce langage de modélisation est une partie intégrante du processus unifié, ils ont été d’ailleurs développés de concret.
Essayons tout d’abord de présenter UML, car ses diagrammes sont utilisés dans chaque phase et activité du processus unifié, ensuite nous reviendrons sur la présentation du processus unifié.
I.1 Présentation d’UML
I.1.1 La notation UML
UML (Unified Modeling Language), se définit comme un langage de modélisation graphique et textuel destiné à comprendre et à définir des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.
UML modélise l’ensemble des données et des traitements en élaborant des différents diagrammes. En clair, il ne faut pas designer UML en tant que méthode (Il y manque la démarche) mais plutôt comme une boite d’outils qui sert à améliorer les méthodes de travail7.
I.1.2 Les diagrammes d’UML
UML dans sa version 2 s’articule autour de treize diagrammes, chacun d’entre eux est dédié à la représentation d’un système logiciel suivant un point de vue particulier.
Ces diagrammes sont regroupés dans deux grands ensembles: les diagrammes structurels et les diagrammes de comportement.
L’ensemble des treize types de diagrammes UML peut ainsi être résumé sur la figure ci- dessous :
Figure 1 : Schéma d’ensemble des diagrammes d’UML 2
Diagramme de Comportement
→ Diagramme d’activité, Diagramme de cas d’utilisation, Diagramme d’état, Diagramme d’interaction, Diagramme de composant, Diagramme d’objet, Diagramme de classe, Diagramme de déploiement.
Diagramme de structure composite
→ Diagramme de package, Diagramme de séquence, Diagramme de communication, Diagramme de vue d’ensemble d’interaction, Diagramme de Timing.
Diagrammes structurels ou diagrammes statiques (UML Structure)
• diagramme de classes (Class diagram)
• diagramme d’objets (Object diagram)
• diagramme de composants (Component diagram)
• diagramme de déploiement (Deployment diagram
• diagramme de paquetages (Package diagram)
• diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
• diagramme de cas d’utilisation (Use case diagram)
• diagramme d’activités (Activity diagram)
• diagramme d’états-transitions (State machine diagram)
Diagrammes d’interaction (Interaction diagram)
o diagramme de séquence (Sequence diagram)
o diagramme de communication (Communication diagram)
o diagramme global d’interaction (Interaction overview diagram)
o diagramme de temps (Timing diagram)
Diagramme de Structure
Nous présentons ci-dessous les diagrammes UML 2, que nous avons utilisés dans le cadre de ce projet et quelques notions de base qui leurs étant associées.
I.1.3 Le diagramme de cas d’utilisation
Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans l’analyse d’un système8.
• Acteur
Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié9.
• Cas d’utilisation (use case)
Représente un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier10.
• Les relations entre acteurs
La seule relation entre acteur est la relation de généralisation. Quand un acteur fils hérite d’un acteur père, il hérite en réalité de toutes les associations du père11.
• Les relations entre cas d’utilisation
> Relation d’inclusion
Une relation d’inclusion d’un cas d’utilisation A par rapport à un cas d’utilisation B signifie qu’une instance de A contient le comportement décrit dans B12.
> Relation d’extension
Une relation d’extension d’un cas d’utilisation A par un cas d’utilisation B signifié qu’une instance de A peut être étendue par le comportement décrit dans B.
> Relation de généralisation
Les cas d’utilisation descendants héritent de la description de leurs parents communs. Chacun d’entre eux peut néanmoins comprendre des interactions spécifiques supplémentaires.
I.1.4 Diagramme de séquence
Ce diagramme permet de décrire les scénarios de chaque cas d’utilisation en mettant l’accent sur la chronologie des opérations en interaction avec les objets13.
• Scénario:
Représente une succession particulière d’enchaînements, s’exécutant du début à la fin du cas d’utilisation, un enchaînement étant l’unité de description de séquences d’actions14.
• Ligne de vie
Représente l’ensemble des opérations exécutées par un objet15.
• Message
Un message est une transmission d’information unidirectionnelle entre deux objets, l’objet émetteur et l’objet récepteur. Dans un diagramme de séquence, deux types de messages peuvent être distingués :
> Message synchrone
Dans ce cas l’émetteur reste en attente de la réponse à son message avant de poursuivre ses actions16.
> Message asynchrone
Dans ce cas, l’émetteur n’attend pas la réponse à son message, il poursuit l’exécution de ses opérations17.
I.1.5 Diagramme d’activité
Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d’utilisation. Il permet aussi de représenter les flots de contrôle et les flots de données18.
• Action : correspond à un traitement qui modifié l’état de système. L’enchaînement des actions constitue le flot de contrôle19.
• Le passage d’une action à une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d’une action et provoquent le début d’une autre (elles sont automatiques)20.
• Activité : représente le comportement d’une partie du système en termes d’actions et de transitions21.
7 F. Juliard UML Unified Method Language, Journal Université de Bretagne Sud UFR SSI-IUP Vannes, 2001- 2002.
8 Joseph Gabay et David Gabay, Mise en œuvre guidée avec études de cas, édition Dunod, Paris 2008. 9 Pascal ROQUES, UML 2 par la pratique étude de cas et exercices corrigés, ÉDITIONS EYROLLES, Septembre 2006, p16.
10 Idem, p 16.
11 Ibidem, p 25.
12 Ibidem, p 53.
13 Joseph Gabay et David Gabay, Mise en œuvre guidée avec études de cas, édition Dunod, Paris 2008, p 11.
14 Pascal ROQUES, UML 2 par la pratique étude de cas et exercices corrigés, ÉDITIONS EYROLLES, Septembre 2006, p 18.
15 Joseph Gabay et David Gabay, Mise en œuvre guidée avec études de cas, édition Dunod, Paris 2008, p 91et/ou 106.
16 Ibid.
17 Ibid.
18 Idem, p 26.
19 Ibidem, p 88.
I.1.6 Diagramme de classe
Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs.
En conception, le diagramme de classes représente la structure d’un code orienté22.
• Une classe
Représente la description abstraite d’un ensemble d’objets possédant les mêmes caractéristiques. On peut parler également de type23.
• Un objet
Est une entité aux frontières bien définies, possédant une identité et encapsulant un état et un comportement. Un objet est une instance (ou occurrence) d’une classe24.
• Un attribut
Représente un type d’information contenu dans une classe25.
• Une opération
Représente un élément de comportement (un service) contenu dans une classe26.
• Une association
Représente une relation sémantique durable entre deux classes27.
• Une superclasse
Est une classe plus générale reliée à une ou plusieurs autres classes plus spécialisées (sous-classes) par une relation de généralisation. Les sous-classes« Héritent » des propriétés de leur superclasse et peuvent comporter des propriétés spécifiques supplémentaires28.
20 BALAGIZI Olivier, Cours de Génie logiciel, inédit L2, ISC/Goma, 2012-2013, p 31.
21 Joseph Gabay et David Gabay, Mise en œuvre guidée avec études de cas, édition Dunod, Paris 2008, p 97. 22 Pascal ROQUES, UML 2 par la pratique étude de cas et exercices corrigés, ÉDITIONS EYROLLES, Septembre 2006, p 76 et/ou 81.
23 Idem, p 77 et /ou 82.
24 Ibidem.
25 Ibid.
26 Ibid.
27 Ibid.
28 Idem, p 78 et/ou 83.
I.1.7 Diagramme de déploiement
Ce diagramme décrit l’architecture technique d’un système avec une vue centrée sur la répartition des composants dans la configuration d’exploitation29.
I.2 Le processus unifié
I.2.1 Définition d’UP Processus Unifié
Pour définir le processus unifié, nous allons simplement définir les deux termes qui le composent :
• Processus
Suite continue d’opérations constituant la manière de fabriquer. En d’autres termes, c’est une succession de tâches dans le but d’accomplir un travail, un projet.
• Unifié
Participe passé du verbe unifié, être amené à l’unité, se fondre en un tout. En fait, les méthodes d’analyse et de conception orientées objet, étaient variées jusqu’à ce que Rambaugh, Jacobson et Booch eut l’idée de les unifier.
I.2.2 Les principes d’UP Processus Unifié
Le processus unifié s’appuie sur les principes suivants :
> Piloté par les cas d’utilisation
Comme nous avons déjà vu, un cas d’utilisation représente une fonctionnalité qui satisfait un besoin d’un utilisateur.
Le processus suit une voie spécifique, en procédant par une série d’enchaînement d’activités, dérivées d’un cas d’utilisation. Un cas d’utilisation est analysé, conçu, implémenté et enfin testé.
> Centré sur l’architecture
L’architecture logicielle représente les aspects statiques et dynamiques du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et reflétés par les cas d’utilisation.
L’architecture propose une vue d’ensemble de la conception faisant ressortir les caractéristiques essentielles en laissant de côté les détails secondaires.
Il faut noter que tout produit est à la fois forme et fonction. L’une ou l’autre isolément ne saurait suffire. Les cas d’utilisation et l’architecture doivent s’équilibrer pour créer un produit réussi.
> Itératif et incrémental
Vu que les projets à réaliser sont de plus en plus complexes et grands, l’idée est de découper le travail en mini projets. Chacun d’entre eux représente une itération qui donne lieu à un incrément.
Les itérations désignent des étapes de l’enchaînement d’activités, tandis que les incréments correspondent à des stades de développement du produit30.
I.2.3 Les phases du processus unifié
Le processus unifié se déroule en quatre phases, incubation, élaboration, construction et transition.
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 : capture des besoins, analyse, conception, implémentation et test.
Figure 2 : cycle de vie du processus unifié
1. Inception (Incubation)
C’est la première phase du processus unifié. Il s’agit de délimiter la portée du système, c’est-à-dire tracer ce qui doit figurer à l’intérieur du système et ce qui doit rester à l’extérieur, identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences nécessaires dans cette phase.
Il s’agit aussi d’établir une architecture candidate, c’est-à-dire que pour une première phase, on doit essayer de construire une architecture capable de fonctionner. Dans cette phase, il faut identifier les risques critiques susceptibles de faire obstacles au bon déroulement du projet31.
2. Elaboration
C’est la deuxième phase du processus. Après avoir compris le système, dégagé les fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant consiste à stabiliser l’architecture du système.
Il s’agit alors de raffiner le modèle initial de cas d’utilisation, voire capturer de nouveaux besoins, analyser et concevoir la majorité des cas d’utilisation formulés, et si possible implémenter et tester les cas d’utilisation initiaux32.
3. Construction
Dans cette phase, il faut essayer de capturer tous les besoins restants car il n’est pratiquement plus possible de le faire dans la prochaine phase.
Ensuite, continuer l’analyse, la conception et surtout l’implémentation de tous les cas d’utilisation. A la fin de cette phase, les développeurs doivent fournir une version exécutable du système33.
29 Joseph Gabay et David Gabay, Mise en œuvre guidée avec études de cas, édition Dunod, Paris 2008, p 26.
30 Ivar Jackobson, Grady Boosh, James Rambaugh, Le processus unifié de développement logiciel, Editions Eyrolles, 1999.
31 Idem.
32 Ibidem.
33 Ibid.
34 Ibid.
4. Transition
C’est la phase qui finalise le produit. Il s’agit au cours de cette phase de vérifier si le système offre véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les manques dans la documentation du logiciel et adapter le produit à l’environnement (mise en place et installation) 34.
