CHAPITRE 7

Introduction UML

Introduction la programmation oriente objets

71

eivd

Tlcommunications

mjn

7.1

Introduction

UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le processus d'laboration des modles. Cependant, dans le cadre de la modlisation d'une application informatique, les auteurs d'UML prconisent d'utiliser une dmarche :
itrative et incrmentale, guide par les besoins des utilisateurs du systme, centre sur l'architecture logicielle.

D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits devrait favoriser la russite d'un projet. Mais que recouvre la notion de projet ?
7.1.1

La notion de projet

La notion de projet est souvent considre diffremment selon le secteur dactivit dans lequel on se trouve. Ainsi, un "projet" dans le domaine commercial sera-t-il abord diffremment dun projet dans un dveloppement de microlectronique, et encore diffremment dans un projet informatique. Or, il sagit fondamentalement dune seule et mme chose! Dans ce cas, on devrait pouvoir utiliser des mthodes identiques pour ces diverses modlisations. Cest effectivement le cas pour les modlisations orientes objets, mais pas pour les modlisations bases sur la notion de procdure : la procdure est une notion trop abstraite pour tre aisment traduite en termes matriels. Un PLL (Phase Locked Loop, boucle asservie en phase) est un objet faisant partie, avec dautres, dun objet plus complexe qui est un dmodulateur FM. En revanche, comment mettre en relation le circuit intgr implmentant la fonction de dmodulation avec les fonctions de Bessel dcrivant le spectre de la modulation, de manire ce que cette relation soit utilisable tout au long de la chane de dveloppement ? Clairement, il apparat que les mathmatiques (donc, les algorithmes) ne sont ncessaires qu un niveau atomique du fonctionnement de notre systme, alors que le fonctionnement global doit tre dcrit dune autre manire. En rsum, il faut idalement pouvoir dcrire un projet sans tenir aucunement compte des moyens utiliss pour venir bout de ce projet; cest cette condition que lon peut valablement conduire un projet intgrant aussi bien du logiciel que du matriel. La syntaxe utilise pour la modlisation doit tenir compte de cette condition. Un projet est constitu de diverses phases, dont toutes sont essentielles, mais dont certaines prennent plus dimportance que dautres selon loptique dans laquelle on se place; les figures suivantes montrent un tel cycle vu sous langle de la documentation de projet. La division en plusieurs figures est uniquement de des contraintes de mise en page. La description du cycle de vie du projet est faite laide de UML (Unified Modeling Language) dont nous reparlerons plus loin.

72

Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

FIGURE 7.1

La premire phase du projet

Dans la premire phase, seul le client et le vendeur sont concerns, le dveloppement nintervient quen guise de conseil au vendeur, et na aucun pouvoir excutif. Les arguments sont conomiques, et le dveloppement doit estimer aussi prcisment que possible linvestissement quil devra consentir pour raliser le projet, de manire ce que le vendeur puisse rdiger une offre aussi raliste que possible. Cette phase est extrmement dlicate : lexprience joue un rle prpondrant. Le vendeur a toute latitude pour moduler les prix selon limportance du projet pour la socit : il peut donc sous-valuer le projet alors mme que le dveloppeur avait donn un pravis nettement moins optimiste; mais le dveloppeur na pas non plus intrt survaluer le travail, puisquil risque de faire chouer le projet !

Introduction la programmation oriente objets

73

eivd

Tlcommunications

mjn

FIGURE 7.2

Ltape intermdiaire du dveloppement

Dans la deuxime phase, le dveloppeur est lacteur principal. La premire tche est la rdaction de la spcification du produit raliser, tche des plus dlicates, puisque cette spcification est juridiquement contraignante : si le produit fini ne correspond pas la spcification, ft-ce sur lun ou lautre point de dtail, le client peut refuser le paiement du travail. Bien quil soit rare que lon en arrive l, cette procdure est possible, surtout entre partenaires commerciaux ne se connaissant pas trs bien. Ensuite, on dbute le dveloppement proprement dit. La phase de modlisation est celle qui nous proccupe principalement ici. Avec la spcification, il sagit de la phase la plus importante du processus de dveloppement; bien que dans le processus de fabrication du produit, les deux phases sont reprsentes de manire conscutive, il existe un certain paral74
Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

llisme entre ces deux phases. Il est en effet difficile de raliser une spcification digne de ce nom sans avoir au moins une lgre ide de larchitecture de la solution1. En particulier, les cas dutilisation (Use Case, Voir diagrammes de cas d'utilisation , page82.) devraient constituer lune des bases les plus importantes pour ltablissement de toute spcification. La modlisation permet de dcomposer le problme en lments plus petits, donc plus facilement matrisables. Le fin du fin consiste effectuer une dcomposition de telle manire que des lments dj dvelopps auparavant puissent tre identifis et intgrs dans le modle. Limplmentation et le test de composants sont ensuite menes souvent de front par des dveloppeurs individuels.
FIGURE 7.3

Fin du cycle de dveloppement

Lorsque les divers dveloppeurs ont termin limplmentation des lments du modle, il faut encore les assembler. Souvent, des assemblages ont dj t faits au cours de limpl-

1. Certains auteurs pensent quil est au contraire indispensable de bien sparer ces deux phases; dailleurs, certaines grandes firmes utilisent des quipes diffrentes pour la spcification et la ralisation, et ne favorisent pas les contacts entre les deux quipes. Lavantage rside en une plus grande neutralit de la spcification; le risque est de spcifier des caractristiques difficiles (donc coteuses) implmenter.

Introduction la programmation oriente objets

75

eivd

Tlcommunications

mjn

mentation, mais la phase de test dintgration permet de comparer le produit avec la spcification. Cest une quipe indpendente du dveloppement, nayant pas particip la ralisation jusque l, qui idalement effectue ce test (test dintgration), sur les seules bases de la spcification et du mode demploi. Ensuite, le client va prendre livraison du produit, et mener bien ses propres tests, dans lenvironnement dexploitation. Cette phase est appele test systme. Ce nest que lorsque cette dernire phase a t passe avec succs que le produit est considr comme termin. En ralit, on devrait encore tenir compte du service aprs-vente, de la maintenance, du suivi de produit, des mises jour, etc... Nous ne le ferons pas dans le cadre de ce chapitre, car cela dpasse le problme du dveloppement dun produit proprement dit.
7.1.2

Comment minimiser les risques ?

Il est vident, dans ce modle, que plus la dtection dune erreur de conception se fait tardivement, plus le cot ncessaire la correction sera lev. Le scnario catastrophe pourrait tre le suivant :
Le test systme, chez le client, fait apparatre une faute grossire relativement la spcifi-

cation, faute lie lenvironnement du client, ce qui explique que le test dintgration n aie pas su la dceler. La socit est contrainte de reprendre le produit. Sur la base des indications fournies par le client (si tant est quindications il y a !), lquipe de test parvient reproduire et documenter, dans un rapport de test, la faute lintention de lquipe de dveloppement. Lquipe de dveloppement, aprs analyse dtaille de lerreur, constate que la cause est comprise dans le modle: en dautres termes, il nest pas possible de corriger lerreur sans se livrer des modifications majeures, touchant la structure mme de lapplication (modification radicale dun circuit intgr dans un dveloppement hardware, ou redveloppement de 30% du code dune application logicielle). Lanalyse de la spcification montre enfin lorigine du problme : la spcification est imprcise sur un point prcis, et il est possible de linterprter de plusieurs manires. Visiblement, le client qui a sign la spcification, lquipe ayant rdig cette spcification, et lquipe de dveloppement ayant interprt la spcification dans le but de raliser le produit nont pas compris la mme chose. Le client refuse dassumer le surcot, et fort de son bon droit, rclame une indemnit pour livraison retarde. La socit hsite engager une querelle juridique sur la base des imprcisions constates dans la spcification, car lissue en est hasardeuse, et de toutes faons mauvaise pour limage de marque de la socit. La socit va donc prendre en charge les rais de correction, et payer une indemnit pour livraison retarde. La socit perd donc beaucoup dargent dans cette affaire, et sa rputation est nanmoins ternie du fait du retard la livraison.

Il est donc vital que la mthode de dveloppement choisie permette de minimiser le nombre derreurs intervenant en fin de cycle de dveloppement (lors des tests, par exemple). Cette mthode doit donc fournir des outils permettant dobtenir trs tt des reprsentations dans un formalisme strict du produit, tel quil sera la livraison. Le formalisme doit permet-

76

Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

tre un meilleur change dinformations entre le client, le dveloppeur, et les rdacteurs de la spcification. Une spcification est en majeure partie textuelle, donc sujette interprtation. Il est donc important que loutil de modlisation permette aussi de servir de support la rdaction de la spcification. UML fournit des outils permettant de rpondre au moins partiellement ce besoin.

Introduction la programmation oriente objets

77

eivd

Tlcommunications

mjn

7.2

Dmarches

La notion de dmarche est importante dans le sens quil ny a pas de rgle prtablie dans le processus de modlisation : beaucoup dtapes sont fortement conditionnes par lintuition, le feeling de lingnieur. On peut dailleurs sestimer heureux quil en soit ainsi ! A quoi pourrait bien servir un ingnieur si son travail pouvait tre entirement codifi, et de ce fait implment par le premier ordinateur venu?
7.2.1

Une dmarche itrative et incrmentale ?

L'ide est simple : pour modliser (comprendre et reprsenter) un systme complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par tapes. Cette dmarche devrait aussi s'appliquer au cycle de dveloppement dans son ensemble, en favorisant le prototypage. Le but est de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent les systmes complexes.
7.2.2

Une dmarche pilote par les besoins des utilisateurs ?

Avec UML, ce sont les utilisateurs qui guident la dfinition des modles (mais cela devrait en fait tre le cas de toute dmarche de modlisation) :
Le primtre du systme modliser est dfini par les besoins des utilisateurs (les utilisa-

teurs dfinissent ce que doit tre le systme). Le but du systme modliser est de rpondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du systme). Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de dveloppement (itratif et incrmental) :
A chaque itration de la phase d'analyse, on clarifie, affine et valide les besoins des utili-

sateurs. A chaque itration de la phase de conception et de ralisation, on veille la prise en compte des besoins des utilisateurs. A chaque itration de la phase de test, on vrifie que les besoins des utilisateurs sont satisfaits.
7.2.3

Une dmarche centre sur l'architecture ?

Une architecture adapte est la cl de vote du succs d'un dveloppement. Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...). Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui permettent de dfinir un modle d'architecture (publication IEEE, 1995). Cette vue ("4+1") a fortement inspir UML. 78
Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

FIGURE 7.4

La vue "4+1"

Il faut noter un fait important dans cette vue : les besoins des utilisateurs sont au centre des proccupations, et tendent influencer toute autre vue. Cette optique, lorigine de laquelle se trouve surtout Ivar Jacobsson, a donn naissance lune des composantes les plus importantes dUML : les cas dutilisation.

Introduction la programmation oriente objets

79

eivd

Tlcommunications

mjn

7.3

Vues

On distingue deux catgories de vues du systme : les vues statiques et les vues dynamiques. Chacune de ces catgories comprend plusieurs vues : toutes ont leur importance, mais limportance relative des diverses vues peut varier en fonction du problme rsoudre : ainsi, la modlisation dun protocole de communication accordera probablement plus dimportance aux vues dynamiques du systme, alors que la modlisation dun tlphone portable accordera plus dimportance au ct statique. Une vue est la reprsentation dun aspect du modle, et tend mettre en vidence certaines caractristiques particulires, et mettre en lumire certains problmes particuliers qui vont se poser lors du dveloppement, si possible avant que la phase de ralisation proprement dite ait commenc.

80

Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

FIGURE 7.5

Les vues dfinies par UML

Introduction la programmation oriente objets

81

eivd

Tlcommunications

mjn

7.4

Vues statiques du systme

diagrammes de cas d'utilisation

7.4.1

Le diagramme des cas dutilisation est souvent la reprsentation directrice du systme, celle qui permet de valider la modlisation. Il dcrit le systme sous forme dune suite dactions et de ractions du systme des stimuli, vu du point de vue de lutilisateur.
7.4.2

diagrammes d'objets

Le diagramme dobjets permet de reprsenter les instances et leurs interactions. Ils dcrivent des instantans de ltat du systme, en montrant dans une situation particulire (cas dutilisation, souvent) les instances impliques, ainsi que leurs attributs significatifs.
7.4.3

diagrammes de classes

Le diagramme de classes permet lidentification et la dfinition des types composant le systme. Il exprime de manire gnrale la structure statique du systme, et montre les relations entre les classes composant le systme. Le diagramme de classes est trs li au code: on peut gnrer le code automatiquement partir du diagramme de classes.
7.4.4

diagrammes de composants

Ils dcrivent les lments physiques du systme et leurs relations dans lenvironnement de ralisation.
7.4.5

diagrammes de dploiement

Ils montrent la disposition physique des diffrents matriels (les noeuds) qui entrent dans la composition dun systme et la rpartition des programmes excutables sur ces matriels.

82

Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

7.5

Vues dynamiques du systme

diagrammes de collaboration

7.5.1

Ce diagramme exprime les interactions entre les objets (quel objet a besoin de quel autre pour remplir son rle). On peut considrer que le diagramme de collaboration est une extension du diagramme dobjets. Le diagramme de collaboration change au cours de la dure de vie du programme; il est difficile de dfinir un diagramme valable pour lensemble de la dure de vie du programme. Aussi se contente-t-on souvent de diagrammes dcrivant les collaborations dans des circonstances particulirement critiques ou difficiles.
7.5.2

diagrammes de squence

Les diagrammes de squence montrent des interactions entre objets selon un point de vue temporel.
7.5.3

diagrammes d'tats-transitions

Ces diagrammes visualisent des automates dtats finis, du point de vue des tats et des transitions.
7.5.4

diagrammes d'activits

Il sagit dune variante du diagramme dtats-transition, organis par rapport aux actions, et destin reprsenter le comportement interne dune mthode ou dun cas dutilisation.

Introduction la programmation oriente objets

83

eivd

Tlcommunications

mjn

84

Introduction la programmation oriente objets