Introduction la conduite de projets informatiques reposant sur un langage orient objets

Olivier Sigaud Edition 2005-2006

Table des matires

1 Vocation de ce document 2 La mthodologie : pour quoi faire ? 3 Aspects techniques de la conduite de projets 3.1 Le cycle de vie dun projet informatique . . . . . 3.1.1 Les grandes activits du cycle de vie . . . 3.1.2 Modles de cycles de vie . . . . . . . . . 3.2 Analyse et conception . . . . . . . . . . . . . . . 3.2.1 Analyse . . . . . . . . . . . . . . . . . . 3.2.2 Conception . . . . . . . . . . . . . . . . 3.3 Mise en uvre de lanalyse . . . . . . . . . . . . 3.3.1 Introduction . . . . . . . . . . . . . . . . 3.3.2 Cas dutilisation et diagramme des cas . . 3.3.3 Le diagramme de classes danalyse . . . 3.3.4 Les diagrammes de squences danalyse . 3.4 Mise en uvre de la conception . . . . . . . . . 3.4.1 Introduction . . . . . . . . . . . . . . . . 3.4.2 Le diagramme de classes de conception . 3.4.3 Le diagramme de squence de conception 3.4.4 Les diagrammes tats-transitions . . . . . 3.4.5 Conception avance . . . . . . . . . . . 3.4.6 Implmentation et intgration . . . . . . 2 2 4 4 4 7 8 9 9 10 10 10 12 13 14 14 15 16 16 17 18

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

3.5

3.6

Outils du gnie logiciel . . . . . . . . . . . . . . . . . 3.5.1 Gnration de squelettes . . . . . . . . . . . . 3.5.2 Reverse engineering . . . . . . . . . . . . . . Conventions de notation et codage propre dune classe 3.6.1 Conventions de notation . . . . . . . . . . . . 3.6.2 Commentaires . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

19 19 20 20 20 21 22 22 22 23 24 25 25 25

4 Aspects organisationnels et humains de la conduite de projets 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Quelques causes classiques de dysfonctionnement . . . . . . . . . . . 4.3 Quelques lignes sur le rle de chef de projet . . . . . . . . . . . . . . 5 Conclusion gnrale 6 NETographie (dernire mise jour : 2001-2002) 6.1 Programmation objets et UML . . . . . . . . . . . . . . . . . . . . . 6.2 Les design patterns (ou patrons de conception) . . . . . . . . . . . .

1 Vocation de ce document
Ce document sadresse de futurs ingnieurs qui seront confronts dans leur vie professionnelle au dveloppement dapplications informatiques de taille variable reposant sur des langages orients objets. Il est destin prsenter quelques connaissances de base sur la conduite de projets informatiques mettant en uvre une mthodologie oriente objets et, en particulier, utilisant le langage UML. En outre, il dveloppe quelques conseils et rexions plus directement applicables la conduite du projet autour duquel est construit le cours in204. Les concepts de base de la programmation oriente objets ainsi que les lments du langage UML et les diagrammes correspondants sont supposs connus. Le lecteur est invit se rfrer aux polycopis de JAVA ([Sig05b]) et UML ([Sig05a]) pour une prsentation de ces aspects prliminaires.

2 La mthodologie : pour quoi faire ?

Il y a un monde entre lactivit dun dveloppeur passionn qui ralise son logiciel dans son coin et le dveloppement industriel dune application de grande taille qui peut rassembler quelques centaines de dveloppeurs sur plusieurs annes.

Dans le premier cas, la mthodologie est affaire dhabitudes personnelles et se constitue au l de lexprience. A chacun de trouver ses propres recettes pour dvelopper vite et bien. Le dveloppeur isol se constitue son propre style de programmation, son rpertoire dastuces pour rsoudre des problmes de codage qui reviennent souvent, lensemble des comportements qui lui permettent de limiter au maximum la fastidieuse chasse aux bugs. Dans lindustrie, les soucis defcacit, de rutilisation de solutions connues, ou de programmation sans erreur sont bien sr pris en charge, mais les ds supplmentaires que pose le partage du travail viennent sy ajouter. Au l du temps, les projets informatiques sont devenus de plus en plus complexes et ce phnomne na fait que saccentuer avec lapparition et la propagation des langages orients objets. Les quipes de conception deviennent donc de plus en plus importantes, entranant un besoin croissant de communication entre les divers spcialistes. Dune part, le besoin exprim par le client souvent incomptent dans le domaine de la conception informatique est gnralement ou et incomplet. Rciproquement, le concepteur est tranger au monde du client. Il sagit donc de trouver un langage commun entre ces deux mondes pour instaurer un dialogue et identier les clauses contractuelles de manire satisfaisante pour les deux parties. Il rsulte de ce constat que malgr tous les efforts dploys lvolution du cahier des charges au cours du dveloppement est quasiment invitable. Dautre part, le dveloppement lui-mme est effectu plusieurs, les diffrentes parties dun logiciel sont toujours plus ou moins interdpendantes, si bien qu tout moment du cycle de vie dun projet, de la spcication la validation nale, les dveloppeurs et concepteurs doivent se mettre daccord sur les fonctionnalits en interagissant au quotidien. Le problme du gnie logiciel est donc de : limiter lvolution du cahier des charges et rduire le risque de malentendu entre clients et concepteurs ainsi quentre quipes de concepteurs en sappuyant sur un langage de modlisation standard et non ambigu ; rpondre le plus rapidement possible une volution du cahier des charges en rduisant le temps du cycle lmentaire qui spare les spcications de la ralisation ; limiter au maximum les rpercussions dune modication dans une phase du dveloppement sur les autres phases ; fournir des moyens de communication et de structuration du travail collectif les plus efcaces possible pour permettre une collaboration distribue ; terme, automatiser le passage de la spcication limplmentation. An de prsenter les solutions du gnie logiciel ces problmes, nous adoptons le

plan suivant. Dans une premire partie, nous nous focalisons sur les aspects techniques lis la mise en uvre dUML. Nous commenons par prsenter les diffrentes activits correspondant au dveloppement dun logiciel complexe en quipes, puis nous numrons diffrentes faon dorganiser ces activits dans le temps. Cette prsentation nous conduit expliciter la diffrence fondamentale entre les activits qui relvent de lanalyse et celles qui relvent de la conception. Sur cette base, nous donnons quelques indications sur la faon dont les diffrents diagrammes proposs par UML doivent tre utiliss dans le cadre de lanalyse et de la conception. En particulier, nous faisons ressortir lobjectif ultime qui consiste formaliser clairement les interactions entre les codes dvelopps par diffrentes quipes et se reposer sur un outil de gnration automatique de squelettes de code pour entriner cette formalisation. Dans une seconde partie, nous abordons les aspects humains et organisationnels de la conduite de projets en quipe. Nous nous bornons mettre en vidence quelques difcults couramment rencontres et suggrer des pistes de rexion pour affronter ces difcults le moins navement possible.

3 Aspects techniques de la conduite de projets

3.1 Le cycle de vie dun projet informatique
3.1.1 Les grandes activits du cycle de vie On peut identier diffrentes activits dans toute mthodologie de ralisation de logiciels. Si le nom des activits et les dcoupages entre activits varient parfois, cest surtout la faon dont on les enchane plus ou moins squentiellement qui change dune mthodologie lautre. Classiquement, on retrouve les activits suivantes : Expression des besoins Cette premire activit est toujours informelle, souvent peu prcise. Elle mane du client, aid par des gens capables de conrmer que le travail est techniquement ralisable. Elle produit le cahier des charges. Cette premire activit se focalise sur les fonctionnalits externes du logiciel : ce quil doit faire et surtout sur la faon de lutiliser. Le cahier des charges peut tre une base pour lancer un contrat. Spcication/Analyse Le cahier des charges rsultant de lactivit prcdente est trop imprcis pour servir de base la conception. On a besoin dun document qui soit la fois le plus rigoureux possible pour servir de point dentre aux concepteurs, tout

en restant totalement comprhensible par le client. Ce document est appel spcication et fait gnralement lobjet dune pr-tude contractuelle. La ncessit dtre comprhensible par le client et la ncessit dtre prcis techniquement pour orienter sufsamment les choix du concepteur sont antagonistes. Ce dilemme conduit divers rafnements de cette activit en documents de spcication intermdiaires, ralisant un plus ou moins bon compromis. Ainsi, on peut tablir des cahiers des charges structurs qui formalisent le besoin, des cahiers de recueil des exigences qui r-expriment techniquement ces besoins, ou encore distinguer des spcications gnrales, plutt lusage du client, et des spcications dtailles, plutt lusage du concepteur. Dans ce cas, tablir les spcications dtailles revient entamer lactivit de conception. Face au ou terminologique et mthodologique qui entoure ces diffrentes activits, on prfrera les regrouper en une activit, lanalyse, et sen tenir la distinction entre analyse et conception qui sera prsente dans la section 3.2, la page 8. Conception Cette activit consiste trouver pour chaque besoin exprim une solution informatique compatible avec lensemble des autres besoins. On dtaillera davantage cette activit dans la section 3.2.2, la page 9. Implmentation Limplmentation consiste raliser le programme conformment aux critres dnis dans les phases prcdentes. Cette activit reste couramment celle qui prend le plus de temps, surtout si on a nglig les activits prcdentes. En particulier, le cot dune erreur (en temps et en main duvre ...) est dautant plus important quelle a lieu dans les phases amont dun projet. Tests et vrication Cette activit permet de dtecter les erreurs de programmation et de vrier que lapplication fonctionne (lapplication fait quelque chose, apparemment dans le respect des spcications). En partie simplie par la rigueur et le typage des langages de programmation modernes, cette activit reste indispensable, surtout en ce qui concerne les fonctionnements dit dexception. Chaque ligne de code devrait tre excute au moins une fois pendant ces tests. Pour un maximum de garantie, cette opration doit tre relance chaque modication et gagne grandement tre automatise. Il existe des outils permettant dautomatiser les tests de lutilisateur en simulant son comportement devant lcran. Validation La validation correspond la recette du logiciel. Elle est ralise par le client pour sassurer que lapplication correspond bien au besoin quil a initialement

exprim. Le cahier de recette effectu par ses soins sappuie sur les spcications. Cest lors de cette activit que le client indique si, en n de compte, il est satisfait ou non. Si ce nest pas le cas, il faut identier linsufsance et remonter jusqu lactivit en cause. Si cest le besoin initial qui a t mal exprim, il faut tout recommencer. Bien que ralise par le client lorsque le produit est termin, le concepteur gagne inclure cette activit dans le cycle de conception lui-mme. Ceci vite les surprises de dernire minute. Cependant, laspect gnralement interactif de cette activit la rend pnible quand elle est rpte trop frquemment. Documentation, maintenance et archivage Diffrents types de documentation sont gnralement demands par le client : un manuel destin lutilisateur (manuels dutilisation et de rfrence), et une documentation de ralisation. Cette activit, qui peut passer pour une corve, est non seulement ncessaire pour satisfaire la demande du client, mais elle est galement vitale pour le concepteur lui-mme qui pourra lexploiter pendant la conception. De plus, une documentation commence (et maintenue) le plus tt possible permet dassurer sa cohrence avec le produit quelle dcrit. De mme, les problmes de maintenance sont de plus en plus pris en compte ds la phase de spcication car celle-ci inue lourdement sur la conception mme (mise en place de tests intgrs ou autres fonctionnalits spcialises...). Quant larchivage, les problmes ne sont pas les mmes suivant que le systme dvelopper est destin au grand public et risque alors dtre totalement prim au bout de deux ans (programme de commande dun magntoscope) ; ou bien sil est destin tre intgr une centrale nuclaire ou un sous-marin. Dans ce cas, la dure de vie du systme global est de lordre de 30 ans, et malgr (ou cause de) lvolution technologique il faut tre capable dapporter des modications pendant de longues annes. Il peut alors tre ncessaire darchiver non seulement les sources des programmes dvelopps mais galement les compilateurs et autres outils utiliss, voire les stations de travail munies de leur environnement dexploitation sous lesquels fonctionnaient ces outils. En gnral, il est moins coteux de redvelopper le produit partir des spcications dorigine (do limportance de la documentation). Malheureusement, pour les trs vieux projets, elles sont parfois inexistantes ou trop imprcises. Il est alors ncessaire de faire appel aux techniques de Reverse engineering (voir paragraphe 3.5.2 la page 20). Une autre fonction de larchivage est de mmoriser la comptence de lentreprise. Dans ce cas, ce nest pas le produit ralis qui est intressant, mais les tours de main et autres secrets de fabrication qui ont t ncessaires pour parvenir au rsultat.

3.1.2 Modles de cycles de vie Lenchanement des diffrentes activits prcdentes peut se faire selon diffrents modles de cycle de vie, qui enchanent ces activits en phases plus ou moins successives. Le cycle de vie linaire Dans le principe, chaque phase est conue pour tre indpendante de celles qui lui succdent. Dans ce modle, on sefforce de sen tenir ce principe, si bien quon ne commence une phase que lorsque la prcdente est termine. Ce style denchanement apparat toutefois difcile planier et peu exible. Une erreur de spcication ou danalyse cote trs cher car elle est vue tardivement et entrane une lourde perte de temps. En pratique, il savre que la ralisation des phases en aval conduit systmatiquement des retours sur les phases plus amont. Le cycle en V
Expression des besoins Spcification gnrale Spcification dtaille Implmentation Recette Validation Test

F IG . 1 Le cycle en V : le client se situe tout en haut, le dveloppeur tout en bas. Ce modle a longtemps t le plus utilis. Comme lillustre la gure 1, il consiste concevoir progressivement et de plus en plus profondment lapplication, puis remonter depuis le test des composants lmentaires (ds quils sont termins) jusqu lintgration et la validation nale des besoins. Il se distingue du modle linaire par le fait quon peut commencer une activit avant davoir termin la prcdente. Malgr lamlioration par rapport au modle prcdent, linconvnient de ce modle reste que le client ne voit le produit que lorsque celui-ci est termin, avec tous les risques que cela comporte. Le modle en spirale Lide du modle en spirale est de fournir le plus rapidement possible un prototype permettant de valider les concepts, et parfois de rpondre un appel doffre avec un prototype de type illustratif . Le principe est alors de fournir rgulirement une nouvelle version de lapplication en se rapprochant progressivement 7

de lapplication nale. Un des avantages de ce modle est de garantir en cas de glissement des dlais une application qui tourne, bien que ne prsentant pas toutes les fonctionnalits. Par son aspect itratif, ce modle ncessite un cycle de dveloppement le plus court possible de la spcication la ralisation des prototypes. La programmation oriente objets se prte bien la mise en uvre de ce type dapproches, car des versions non spcialises de classe peuvent naturellement servir dimplmentation grossire mais rapidement oprationnelle. Il est toutefois rare que les premiers prototypes ne soient pas profondment bouleverss par les itrations successives. Avec UML : un processus itratif Le cur de la dmarche demploi dUML consiste tirer parti de la complmentarit des diffrentes vues proposes par le langage et des redondances que cette complmentarit implique. Plutt que de constituer les vues les unes aprs les autres, il est avantageux de les constituer en parallle, le travail dans une vue appelant des modications dans les autres vues. Lanalyse et la conception voluent ainsi rapidement, puis nissent par se stabiliser lorsque les vues convergent. Lanalyste et le concepteur doivent donc se laisser guider par un souci de cohrence entre les vues vis--vis du problme modlis. Dune faon gnrale, pour une partie donne dun logiciel, on suite lordre analyseconception-implmentation mais, compte tenu de la diversit des applications, un niveau plus global le processus de dveloppement suit un ordonnancement diffrent chaque fois en fonction des contraintes qui psent sur chacune des quipes de dveloppement. La planication du droulement dun projet logiciel est un mtier part entire, pour lequel existent des outils ddis de gestion des plannings. Nous allons tout de mme pointer dans la suite un certain nombre dinterdpendances induites par UML et qui ont une inuence sur le droulement de tous les processus.

3.2 Analyse et conception

Une bonne mthodologie de ralisation de logiciels suppose une bonne matrise de la distinction entre lanalyse et la conception. Nous allons voir que le respect dune distinction entre des phases danalyse et de conception rigoureusement indpendantes nest pas tenable, mais il est important davoir en tte la diffrence lorsquon sapprte raliser un logiciel. Encore une fois, il est important de garder lesprit qu UML noffre pas une mthodologie pour lanalyse et la conception, mais un langage qui permet dexprimer le rsultat de ces phases.

3.2.1 Analyse Lanalyse rpond la question que faut-il faire ? . Cette activit a pour but de se doter dune vision clairement formalise du problme pos et du systme raliser en dterminant les lments concerns et leurs interactions. Son rsultat est un modle reprsentant le problme et les principaux lments du systme raliser. Elle regroupe les phases dexpressions des besoins et de spcication des mthodologies classiques. Il est important dinsister sur les caractristiques suivantes de lanalyse : elle ncessite de comprendre en dtail les problmes et concepts de lutilisateur, elle doit tre (en principe) indpendante des aspects techniques, les choix portant sur les modles rsultants doivent tre justis (simplication du modle, explicitation des hypothses, etc.). Les documents produits dans le cadre de lanalyse vont permettre aux auteurs de la spcication de sassurer que lquipe charge du dveloppement a bien compris le problme qui lui est pos et quaucun aspect pertinent na t oubli. La conception peut alors dmarrer sur des bases saines. 3.2.2 Conception La conception, mene la suite de lanalyse, rpond la question comment faire ce quil faut faire ? . Le processus de conception a pour but de ger les choix techniques (langages de programmation, algorithmes, bibliothques, architectures matrielles, etc.). Il xe les performances (si elles ne font pas dj partie du cahier des charges, par exemple quand le contexte oprationnel limpose), et dnit la stratgie de programmation : choix des structures de donnes (et de leur persistance), choix des algorithmes utiliser, choix des langages, etc. La phase la plus amont de la conception consiste gnralement identier une approche du problme rsoudre qui va induire un style de conception plus ou moins adapt ce problme. Le rsultat de la conception est une bauche dimplmentation, dcrite par un modle prcis du systme raliser. Nous allons voir que des ateliers de gnie logiciel permettent un passage trs naturel de la conception limplmentation.

3.3 Mise en uvre de lanalyse

3.3.1 Introduction Les lments dun systme informatique peuvent tre dcrits selon trois points de vue plus ou moins dpendants les uns des autres : la vue fonctionnelle, qui indique ce que doivent faire les objets du programme. Cette vue est ralis laide des cas dutilisation. la vue structurelle (ou statique), qui fait apparatre la composition hirarchique des objets et de leurs relations. Cette vue est ralis laide des diagrammes de classes. la vue dynamique, qui prend en compte le droulement du fonctionnement de lapplication. En analyse, cette vue est ralise laide des diagrammes de squence. Ces points de vue peuvent sappliquer de manire rcursive chacun des composants dune application. Dans le cadre de lanalyse, il est frquent de commencer par identier les cas dutilisation pour partager le travail, puis on construit en parallle les diagrammes de classes et de squence correspondant chacun des cas. Nous verrons cependant que le recours aux cas dutilisation nest pas universel. Nous allons nous pencher sur ces activits dans les sections qui suivent. 3.3.2 Cas dutilisation et diagramme des cas Le diagramme des cas est une vue synthtique. Son rle essentiel est dinciter les analystes et concepteurs reprsenter le problme du point de vue du client ds la phase initiale du projet. Commencer par tablir le diagramme des cas permet de mener un dveloppement orient utilisateur et de dcouper le systme global en grandes tches qui pourront tre rparties entre les quipes de dveloppement. Il permet en outre de sassurer dun seul coup dil que lensemble des exigences fonctionnelles du systme ont bien t prises en compte. Pour le dessiner, on sattache dans un premier temps identier les principales familles dacteurs, en fonction de leur rle vis--vis du systme. Reconnatre un acteur Un acteur est un agent (humain ou logiciel) externe au systme en cours de dveloppement. Il faut, mme dans ce second cas, que le systme soit actif voire quil initialise le contact sinon il peut tre rsum en une donne. Par exemple, si lon fait appel une horloge externe pour mettre jour lhoraire, cette horloge ne peut tre considre comme un acteur. Un logiciel de guidage de vhicule embarqu, par contre, qui doit interroger par satellite une base de donnes lui indiquant 10

le trac, peut considrer le logiciel exploitant la base de donnes comme un acteur lui communiquant les bouchons. Reconnatre un cas dutilisation Les cas dutilisation sobtiennent en identiant les actions ou vnements discrets demands ou raliss par les acteurs autour du systme. On distingue dans la pratique deux familles de cas : les cas correspondant des objectifs de lutilisateur ; les cas dinteraction proprement dit, qui peuvent ntre que des moyens servant un objectif. La premire famille est particulirement importante, puisquelle spcie les besoins des acteurs. Raliser sparment chacun des cas dutilisation permet de sassurer que lon rpond bien au besoin de chaque classe dutilisateurs. Dcrire un cas dutilisation La description textuelle des cas dutilisation est particulirement utile dans le cas (frquent) o une socit de service en informatique non spcialiste du domaine dapplication (ou toute quipe remplissant ce rle) est charge dinformatiser un processus ralis par des humains. Le premier travail de conceptualisation consiste interviewer les diffrents acteurs pour comprendre les processus, si bien que la description textuelle se trouve adapte au recueil et la mise en forme des rsultats de ces interviews. Toute la difcult consiste sarrter au bon niveau de dtail pour ne pas trop empiter sur le travail associ aux autres vues. Par ailleurs, la description textuelle est lun des documents les plus adapts la discussion avec le client au moment o lon sassure que lon a correctement captur lensemble des exigences fonctionnelles du systme raliser. Afner les liens entre cas dutilisation Pour faire la distinction entre des liens de type extend ou de type include 1 , il suft de considrer quun cas utilis rsulte dune dcomposition effectue des ns de factorisation. Il en va diffremment du cas tendu qui ajoute des fonctionnalits un cas existant mais englobe ce cas. En gnral, le cas normal est utilis par une famille dacteurs, le cas qui ltend est destin une autre famille dacteurs. Un cas dutilisation doit tre dcompos en plusieurs sous-cas uniquement si un besoin exprs de lutilisateur est exprim tt dans le processus danalyse et de spcication. Sinon, un premier diagramme se contentera des cas dutilisation standards et dautres diagrammes, lors ditrations postrieures, mentionneront les cas particuliers quil est ncessaire dtendre.
1 Voir

le polycopi [Sig05a] pour une dnition.

11

Conseils pratiques Pour construire la vue fonctionnelle, il peut tre avantageux de commencer par une premire bauche de diagramme des cas visant lexhaustivit, bauche qui se rafnera lors de la description ne des diffrents cas. La description textuelle des cas donne les premiers lments pour lidentication des classes, oprations et attributs. Elle constitue donc un bon pralable lcriture des diagrammes de classes. En effet, reprer les mots et les verbes importants dans ces descriptions textuelles permet dextraire les objets et les mthodes pertinentes pour lanalyse. Prise de recul Tous les aspects mthodologiques portant sur les cas dutilisation et le diagramme des cas sont particulirement utiles dans le cadre des systmes de traitement de linformation faisant apparatre de nombreux acteurs et de nombreuses fonctionnalits. Dans de tels contextes, ils constituent un excellent guide pour le dcoupage de lapplication en fonctionnalits plus ou moins indpendantes, donc un partage du travail au sein de lquipe de projet. Mais ce contexte nest pas universel. Dans un projet de type recherche mettant au prise un utilisateur unique avec un systme complexe, un tel dcoupage peut savrer relativement inoprant. Il faut donc rchir avant davoir recours une telle approche. Lide gnrale retenir est quun bon partage du travail dans le cadre de lanalyse consiste en gnral sparer dans la mesure du possible des parties du projet concernes par des fonctionnalits indpendantes. 3.3.3 Le diagramme de classes danalyse
effectue 1 0..*

Chauffeur Age Nom

1 conduit 0..*

Trajet
1..*

comprend 2..* dessert 1..* 2..*

Bus

Station

F IG . 2 Un diagramme de classes danalyse Les diagrammes de classes danalyse servent identier les principaux objets du domaine modlis par le systme, tablir leurs relations, et les regrouper en entits plus vastes donnant des vues partielles sur le systme.

12

Dcoupage en packages pour lanalyse En rgle gnrale, on aura tendance effectuer un regroupement en packages qui suit plus ou moins le dcoupage en cas dutilisations. Mais certaines classes plus centrales que dautres seront prsentes dans de nombreux cas dutilisations. On cherche alors identier et regrouper des ensembles de classes qui ont une forte connectivit. Une fois le dcoupage en cas obtenu, on ralise un diagramme des objets participants au cas, ce qui se traduit par un diagramme de classes pour chaque cas. Cela peut conduire identier un package par cas mais, dans la pratique, le dcoupage en packages suit rarement cette logique. En particulier, de nombreuses classes interviennent dans plusieurs cas, les classes qui apparaissent dans le maximum de cas sont les plus centrales, on effectue souvent le regroupement en packages en se fondant sur cette notion de centralit. Choix des objets reprsents Dans des diagrammes de classe danalyse, on ne fait en gnral apparatre que des objets du domaine modliss, souvent appels objets mtier . En effet, on dcrit le monde dans lequel on va travailler et non pas le logiciel que lon va raliser, donc tous les objets qui nont de sens que pour le fonctionnement du logiciel sont exclure. On peut ventuellement agrmenter les objets choisis de quelques attributs ou oprations, mais condition que ces lments soient pertinents dans le domaine et non pas dans lapplication dvelopper. Lessentiel est de sefforcer ce stade de ne pas faire des choix qui relvent de la conception. 3.3.4 Les diagrammes de squences danalyse Traditionnellement, dans les mthodologies orientes objets, ou dans les dveloppements classiques, les concepteurs utilisent des scnarios typiques dutilisation du logiciel, pour mieux comprendre et identier les besoins du client. Les diagrammes de squences permettent de formaliser le droulement de ces scnarios. Ils ont pour objet de dcrire des scnarios particuliers de comportement des acteurs vis--vis du systme. Un diagramme de squences danalyse permet de vrier que tous les acteurs, les classes, les associations et les oprations ont bien t identis dans les diagrammes de cas et de classes. Par ailleurs, il constitue une spcication utile pour la conception des algorithmes ou des automates. Construire un diagramme de squences peut amener rafner la description des use cases, identier de nouveaux objets quil va falloir ajouter aux diagrammes de classes, ou revoir un dcoupage en packages lorsque deux objets apparaissent fortement corrls.

13

Jean:Personne

:Ascenseur
1 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
Appel (RdC)

Jacques:Personne
1 0 0 1 0 1 0 1 0 1 0 1 0 1 250 ms 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

Allumage bouton dappel Ouverture porte(RdC) Choix Etage 3 Allumage voyant 3

250 ms

1 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

Appel (2ime tage) Allumage bouton dappel Ouverture porte(2ime tage) Ouverture porte(3ime tage)

Ouverture porte(3ime tage)

F IG . 3 Un diagramme de squences danalyse noter que dterminer lensemble des diagrammes de squences qui permet de couvrir tous les modes de fonctionnement pertinents pour une application est une question difcile.

3.4 Mise en uvre de la conception

3.4.1 Introduction La conception est la phase qui permet de passer de la description claire dun problme, dgage par lanalyse, la ralisation informatique de sa solution, lors de limplmentation. Il sagit dune activit qui peut tre extrmement complexe et qui requiert un niveau dexpertise trs lev. L o un novice risque de concevoir des solutions mdiocres, lourdes, maladroites, difcilement modiables et rutilisables, un chef de projet expriment peut au contraire trouver immdiatement une solution simple, claire, lgante un mme problme de conception. Face cette situation o le niveau d(in)exprience est un facteur crucial pour la qualit du rsultat, la tendance du gnie logiciel est de prconiser des mthodes robustes et efcaces, bien prouves, qui permettent, si on les suit rigoureusement, darriver un niveau de qualit honorable quel que soit le niveau dexpertise du concepteur concern. 14

La dmarche que nous proposons ici est fonde sur les mcanismes suivants : une transformation progressive des diagrammes de classes et de squence danalyse en diagrammes de conception, par ajout de classes, enrichissement des informations portes par les classes et formalisation des messages impliqus dans les diagrammes de squence ; le recours des outils de gnration automatique de squelettes de code pour ger un contrat entre quipe permettant le passage de la conception limplmentation. Lide centrale est que formaliser totalement les mthodes de communication entre les quipes permet par la suite aux diffrentes quipes de coder indpendamment les unes des autres, en ayant des garanties sur les mthodes offertes par les classes dveloppes ailleurs. En outre, disposer dun squelette de code complet peut contribuer rsoudre des problmes de compilation locale une quipe, quand cette compilation fait appel des classes dveloppes ailleurs. 3.4.2 Le diagramme de classes de conception De lanalyse la conception Nous avons dit que, dans le cadre de lanalyse, seuls les noms des attributs et les principales mthodes publiques de la classe doivent tre mentionnes. Dans le cadre dune conception au contraire, la description des classes doit tre exhaustive. En effet, si lon a recours un outil de gnration de squelette de code avant de passer limplmentation, il faut que ce squelette soit complet ds la conception, pour ne pas engendrer des aller-retours. Cette opration suppose de dterminer un type pour toutes les donnes manipules par lapplication, ce qui ne va pas de soi. Pour certains lments simples comme une date, par exemple, choisir entre les reprsenter laide dune classe ou bien dun type de base une chane de caractre est un choix non trivial qui peut demander de lexprience. Mais les diffrences entre un diagramme de classes danalyse et un diagramme de classes de conception ne se limitent pas au seul niveau de description. Les diagrammes de classes danalyse ne font gnralement apparatre que des classes mtiers. De nombreuses classes spciques du logiciel ralis seront ajoutes lorsque lon passe de lanalyse la conception. Si, en pratique, passer la conception revient enrichir considrablement les diagrammes de classes danalyse, il faut garder lesprit le fait que cet enrichissement rsulte dun profond changement de point de vue sur le projet et non dun simple afnement de la vision prcdente. Dcoupage en packages pour la conception Du point de vue de la conception, le souci majeur auquel rpond le dcoupage en packages est un souci de compilation. 15

Il faut assurer une indpendance maximale entre les packages et, surtout, viter les phnomnes de dpendances croises. Quand on passe la conception, de nombreuses classes outils plus ou moins gnriques apparaissent et, alors que les dcoupages prcdents insistaient en gnral sur la sparation dentits fonctionnelles indpendantes, on cherche plutt stratier lapplication en couches, chaque package reposant sur des packages de plus bas niveau. Les couches les plus basses sont en gnral les plus stables et les plus rutilisables, on a intrt les raliser en premier car les couches suivantes en dpendront. Le dcoupage en packages est sans doute un des processus le plus dlicat de la gestion dun projet, dans la mesure o il faut le faire rapidement pour partager efcacement le travail entre les quipes, mais llaboration des diffrentes vues peut amener le ramenager souvent. Cest lensemble de ces contraintes quil faut avoir en tte lorsque lon effectue le dcoupage de lapplication en packages. Seule lexprience pratique permet de dterminer des mthodes conduisant des bons dcoupages. 3.4.3 Le diagramme de squence de conception Le passage des diagrammes de squence danalyse aux diagrammes de squence de conception peut se rsumer un impratif simple : tout change dinformation entre deux objets formalis par un envoi de message en analyse doit se traduire en conception par un certain nombre dappels de mthodes. videmment, puisquon ajoute des classes intermdiaires, un mme message peut correspondre le dclenchement dun nombre plus ou moins importants de mthodes. Un travail important de la conception consiste dune part attribuer les bonnes mthodes aux bonnes classes et, dautre part, dterminer prcisment la signature de chacune des mthodes. Il ne va pas de soi, en effet, de dterminer quels sont les paramtres dont une mthode aura rellement besoin avant de lavoir code. Il faut noter que la plupart des ateliers de gnie logiciel offrent une fonctionnalit bien pratique : au fur et mesure quon ajoute des mthodes dans un diagramme de squence, ces mthodes sajoutent automatiquement dans la description des classes sur les diagrammes de classes. Cela permet de passer ltape de gnration de code rapidement une fois que tous les diagrammes de squence pertinents ont t dessins. 3.4.4 Les diagrammes tats-transitions Le diagramme tats-transitions est sans doute la plus complexe des vues proposes par UML. Sa mise au point demande un effort qui ne vaut la peine que pour certains objets, dont le comportement dynamique est trop complexe pour tre appr-

16

hend par quelques diagrammes de squence. Il est donc important de se demander, lorsquon modlise une application, quels sont les objets pour lesquels il faut raliser ce diagramme. Par ailleurs, lorsque lautomate associ un objet devient trop complexe, il est ncessaire de se demander sil ne faut pas dcomposer en plusieurs objets, ce qui conduit au moins revoir les diagrammes de classes. 3.4.5 Conception avance Il nest pas question dans un polycopi adress des dbutants de prsenter dans le dtail toutes les mthodes de conception les plus avances, mais il est bon que le lecteur connaisse au moins lexistence des lments qui suivent. Les frameworks Un framework est un logiciel constitu essentiellement de classes gnriques et dans lequel les traitements gnriques qui font intervenir ces classes sont fournis. Si le framework est bien conu, lquipe de dveloppement qui veut lutiliser na plus qu driver certaines classes correspondant aux cas particuliers quelle veut traiter et dnir les traitements spciques de ces classes, ce qui permet de raliser diverses applications spcialises similaires en vitant de redvelopper chaque fois les parties communes. Les framework font un usage intensif des interfaces et de lhritage. Le recours aux interfaces permet dimposer aux programmeurs qui veulent utiliser un framework la liste des mthodes spcialises quils doivent dvelopper pour intgrer leurs propres classes. Dans ce cadre, le lecteur trouvera dans [GHJV96] un ensemble de considration sur la rutilisabilit des modles de conception expliquant pourquoi il ne faut pas abuser de lhritage en programmation oriente objets. Les composants Les architectures de composants constituent une approche de la rutilisation orthogonale la prcdente. Un composant est un module logiciel autonome, qui peut tre compil sparment et qui offre des fonctionnalits bien dnies au travers dune interface bien spcie. Une architecture de composants est en gnral constitue dune bibliothque de composants, dune infrastructure qui permet dassurer la communication entre les composants et des mcanismes qui permettent de construire un logiciel particulier en faisant appel une partie des composants prsents dans la bibliothque. Vis--vis dune bibliothque de classes, une architecture de composants se distingue surtout par deux aspects : 17

 il nest pas ncessaire de recompiler les composants lorsquon construit un logiciel qui y fait appel ; la communication entre les composants peut se faire par appel direct des mthodes, mais aussi via des communications par le rseau, ce qui permet de distribuer une application sur plusieurs machines de faon totalement transparente. Les deux principaux exemples darchitectures de composants sont CORBA, dans lequel les composants ne peuvent communiquer que par des appels au rseau, mme sils sont sur la mme machine, et COM, qui ne fonctionne que dans les environnement dexploitation de Microsoft. Une architecture de composants offre des garanties dindpendance maximale entre les diffrents modules dune application, tel point quils peuvent souvent tre dvelopps dans des langages de programmation diffrents. Les design patterns Face la rcurrence en analyse de problmes qui se ressemblent tous dune application lautre, des modles standards de conception sont apparus peu peu. Ce sont les design patterns, prsents dans louvrage de rfrence [GHJV96] ainsi que sur le site [url1]. Le terme pattern est traduit par patron dans le sens dun modle utilis par un couturier pour sadapter diffrents contextes. Cest une entit rellement rutilisable en informatique car un patron est trs abstrait vis--vis des langages de programmation qui permettent de le raliser. Cest une aide pour trouver une solution un problme prcis dans un contexte bien dni. Leur usage systmatique conduit une standardisation de la conception et favorise la comprhension de programmes crits par dautres. 3.4.6 Implmentation et intgration Dvelopper une application en quipes spares pose des problmes au moment de limplmentation. Mme en supposant que lon connaisse prcisment les signatures de toutes les mthodes offertes par les autres quipes, il se pose un problme de compilation. En effet, la partie dveloppe par une quipe ne pourra pas tre compile si elle fait appel des classes et des mthodes fournies par dautres quipes, mais absentes au moment de la compilation. Or il est important de pouvoir compiler et tester sa partie avant lintgration pour viter davoir rechercher tous les bugs seulement une fois le logiciel assembl. Une solution classique ce problme consiste dvelopper des classes bouchons quasiment vides et qui ne sont l que pour la compilation. Mais ces dveloppements sont une perte de temps.

18

Lapproche que nous prconisons consiste mener la totalit de la conception avec un atelier de gnie logiciel et de gnrer un squelette complet du code avant de passer limplmentation. Avec cette approche, chaque quipe pourra dvelopper exclusivement le code des mthodes dont elle a la charge et compiler le tout, en respectant scrupuleusement la contrainte de ne toucher la signature daucune mthode. Par ailleurs, des ns de test des parties spares, il ne suft pas que le code puisse tre compil, il est parfois ncessaire de disposer de mthodes externes fonctionnelles pour valider un comportement interne. Pour attnuer la porte de ce problme, plutt que dattendre davoir ralis lintgration complte avant deffectuer des tests, il est prfrable de se doter dun outil de gestion de versions qui permette plusieurs quipes de travailler en parallle sur le mme code et dintgrer leurs dveloppements successifs dans une version commune que chacun rcupre intervalles rguliers. Des outils tels que CVS ou S UBVERSION sont conus spciquement pour assurer le bon fonctionnement de cette mthode de travail. Une contrainte mthodologique vidente qui va avec lemploi de tels outils consiste nintgrer son travail la version commune quune fois que le code correspondant compile correctement.

3.5 Outils du gnie logiciel

3.5.1 Gnration de squelettes partir dun diagramme de classes sufsamment dtaill, il est facile de gnrer automatiquement des lments de code dans un langage de programmation orient objets. Les gnrateurs peuvent dcrire les classes, les attributs, les accesseurs associs chacun de ces attributs, les signatures des mthodes dcrites par le concepteur. Ces outils gnrent donc le squelette dune application et font gagner du temps aux dveloppeurs en leur pargnant les phases fastidieuses et rptitives (en particulier, lcriture de tous les accesseurs). Il faut noter toutefois que, les diffrents langage de programmation orient objets ayant chacun leurs particularit, il est difcile dassurer la fois une indpendance totale de la conception vis--vis du langage de programmation cible et la possibilit de gnrer le code dans un langage de programmation plutt quun autre partir de cette conception gnrique . Sil est assez facile dengendrer des squelettes donnant la signature de toutes les mthodes, il est beaucoup plus difcile, par contre, dautomatiser lcriture de code algorithmique partir de la description du comportement des oprations, donc de la dynamique de lapplication. De telles gnrations automatiques de code sont encore du domaine de la recherche.

19

Usage des cardinalits (ou multiplicits) Lemploi des cardinalits dans les diagrammes de classes est dlicat ds lors que lon a recours une outil de gnration automatique de squelettes. En effet, selon ce que recouvre le lien smantique reprsent par lassociation, les cardinalits peuvent diffrer subtilement entre deux classes pourtant identiques. Ainsi, sur la gure 2, si lon indique quun bus a toujours un et un seul chauffeur, on prsuppose quon ne sintresse quaux bus en train de rouler. Mais le jour o lon veut augmenter les fonctionnalits de lapplication et grer aussi les dpts de bus, alors il faut pouvoir traiter le cas des bus auxquels aucun chauffeur nest affect. Par ailleurs, il faut dcider si lon veut dire ou non que cest toujours le mme chauffeur qui est affect un bus donn. Or le code gnr peut diffrer largement selon la cardinalit que lon a indique car les gnrateurs de squelettes de code se fondent sur les cardinalits pour choisir les structures de donnes. Si on a employ une cardinalit de type simple (0 ou 1), lobjet reli sera un attribut simple. Au contraire, si on a employ une cardinalit multiple, lattribut engendr sera un conteneur dobjets du type de lobjet reli. Un changement de cardinalit peut donc amener des remises en question importantes dans le code gnr. 3.5.2 Reverse engineering Certains De plus en plus doutils permettent dautomatiser la rsolution du problme dit de Reverse engineering. Le but est de reconstruire des diagrammes de modlisation (bas niveau) partir des sources de programmes anciens et mal documents, en vue de le rimplmenter. En pratique, les outils de Reverse engineering sont surtout capables de reconstituer des diagrammes de classes. Un programme tant une solution particulire un problme donn (les spcications), le Reverse engineering peut effectivement aider retrouver et structurer lorganisation de ce programme (domaine de solution), mais il ne faut pas esprer quil reformule le besoin lui-mme (domaine de problme).

3.6 Conventions de notation et codage propre dune classe

3.6.1 Conventions de notation En gnral, une quipe de dveloppement se dote de conventions de notations prcises pour tout le code dun mme projet. Il est impratif de respecter ces conventions de notation pour faciliter la lecture du code par des dveloppeurs dautres quipes. Le respect de conventions de notation au sein dun projet facilite la collaboration entre

20

quipes si tout le monde adopte les mmes conventions. De plus, cest un aspect important de la propret du logiciel. Peu peu, des conventions de notation standards simposent, en particulier grce aux outils qui gnrent automatiquement des squelettes de code partir de vues UML (voir la section 3.5.1). Par exemple, en JAVA, les noms de toutes les mthodes commenceront par un verbe et une minuscule, suivi du complment dobjet avec une majuscule par mot. En C++, les noms des attributs commencent souvent par un underscore ( _ ) suivi dune majuscule, tandis quen JAVA on les note de la mme faon que les mthodes. Une bonne habitude consiste rendre tous les attributs privs et proposer des mthodes spciques pour y accder ou les modier. On appelle ces mthodes spciques des accesseurs et modieurs. Il est conseill de leur donner des noms adapts comme getDate() ou setDate(date), pour faciliter la lisibilit. Lemploi de langlais pour le nommage simpose peu peu aux dpends du franais, limportant tant de sefforcer dtre cohrent sur ce point au sein dun mme projet. 3.6.2 Commentaires La ralisation documente dune analyse et dune conception avec UML ne dispense pas de commenter les mthodes dveloppes lors du codage. La premire chose commenter est le rle de chaque classe au sein de lapplication. On y joint en gnral le nom de son auteur et les dates de modication. On commente ensuite les mthodes. En gnral, les commentaires comprennent pour chaque mthode une description du rle de la mthode dans lapplication, (cest--dire ce quoi elle sert et non pas ce quelle fait, ce qui doit tre vident pour le lecteur si le code est crit avec clart...), ainsi que la liste des paramtres dentre et la valeur de retour. Les commentaires lintrieur des mthodes sont en gnral dvolus la signication des variables intermdiaires ou lexplication des algorithmes trop complexes pour tre compris dun coup dil. Avec un langage comme JAVA, il existe une forme standard pour les commentaires den-tte de mthodes, ce qui permet loutil javadoc dinsrer ces commentaires dans une documentation quil gnre automatiquement dans des chiers HTML. On dispose ainsi pour chaque classe de la description de lensemble de ses attributs et de la liste des mthodes avec leurs commentaires. Certains langages permettent enn lusage dlments de contrle de la propret du code, qui donnent lieu des vrications lors de la compilation. Cest le cas du mot-clef const en C++ (ou nal en JAVA), qui indique quune donne ne peut pas tre modie. Le compilateur vrie alors que toute mthode qui est cense ne 21

pas modier cette donne ne fait appel qu des mthodes qui ont la mme proprit. Certains compilateurs sont plus permissifs que dautres sur ces aspects.

4 Aspects organisationnels et humains de la conduite de projets

4.1 Introduction
La russite dun projet informatique ralis en quipe suppose que soient correctement gres trois dimensions indissociables : la dimension technique ; la dimension organisationnelle ; la dimension relationnelle ; Si lusage veut quen cole dingnieur lenseignement soit focalis sur la dimension technique, il faut avoir lesprit le fait que, dans un contexte industriel, lexprience montre que ce sont surtout les facteurs humains (organisationnel et relationnel) qui dterminent le plus souvent le succs ou lchec dun projet. Lobjectif des quelques lignes qui suivent est de sensibiliser le lecteurs ces aspects importants et trop souvent passs sous silence. Cependant, il nest pas question de donner des recettes toutes faites dans ce domaine dlicat o le savoir-faire est avant tout une question de personnalit et dexprience, chacun ayant se forger la sienne.

4.2 Quelques causes classiques de dysfonctionnement

La liste ci-dessous nest pas exhaustive, elle sappuie sur un ouvrage de C. Bnard ([Bn92]). La divergence dintrts un ou plusieurs membres du projet ont des objectifs loigns ou non cohrents avec ceux du reste de lquipe. Linstabilit des objectifs lquipe est soumise des changements dobjectifs, de ressources, de chef de projet. Lambigut des rles les fonctions de chacun au sein du groupe sont oues, se chevauchent ou entrent en conit les unes avec les autres. La bataille des chefs plusieurs membres de lquipe tentent de diriger le projet, chacun dans sa direction.

22

Le manque de crdibilit du chef de projet les comptences techniques, organisationnelles ou relationnelles du chef de projet ne sont pas reconnues par les membres de lquipe. Le manque de soutien de la hirarchie les dcisions ne sont pas prises lorsquelles sont ncessaire, les membres de lquipe ont limpression que leur projet ne sert rien. Linadquation des comptences les membres du projet se trouvent assigns des tches pour lesquelles ils nont pas la comptence requise. Le manque de motivation plus un personne se sent dans linscurit ou la tension, plus elle a tendance reporter son nergie sur autre chose que le projet. Le manque de communication les dcisions sont prises de faon locale et non coordonne, les quipes ne disposent pas des informations ncessaires pour mener bien leur travail.

4.3 Quelques lignes sur le rle de chef de projet

Un bon chef de projet doit savoir : grer laction en anticipant en se tenant en permanence au courant des difcults rencontres et en orientant les travaux en fonction de ltat davancement collectif. matriser le temps en estimant correctement les dures, en planiant an dviter les retards et les chamboulements mais en remettant jour les plannings quand cela parat ncessaire. dlguer bon escient en sachant couter les interventions justies, en attribuant les bonnes tches aux bonnes personnes et en manifestant sa conance dans la bonne conduite des tches dlgues. Cet aspect est lune des clefs de la motivation individuelle. assurer le bon climat relationnel en adaptant lorganisation de faon tirer le meilleur parti des ententes et viter les sources de conit, en anticipant les situation menant aux conits, et en assurant la motivation et la cohsion de lquipe de projet. viter le culte de la personnalit en se croyant indispensable et infaillible et en faisant que le projet tourne exclusivement autour de soi. 23

ne pas confondre moyens et objectifs en introduisant des outils dont lutilit est contestable dans le cadre dun projet donn et en faisant passer plus de temps aux membres de lquipe en activit organisationnelles (runions, etc.) quen travail effectif.

5 Conclusion gnrale
La conduite dun projet logiciel de grande envergure est une activit complexe, qui ncessite des outils, de la mthode et de lexprience. Dans ce document, nous avons propos des lments de dmarche visant rsoudre des problmes de coordination du travail collectif. Nous avons vu que les trois principales phases de la ralisation proprement dite dun logiciel sont les suivantes : 1. analyse (et afnement des spcications), 2. conception (gnrale et dtaille), 3. implmentation. Nous avons mentionn que pour chacune de ces phases les lments du systme complet peuvent tre dcrits de faon rcursive selon trois points de vue indpendants : la vue fonctionnelle, la vue structurelle et la vue dynamique. Gnralement les grosses applications doivent tre dcrites conjointement sous ces trois vues, mais certaines applications peuvent privilgier une vue particulire. Par exemple, une application temps rel faisant intervenir peu dobjets et dpourvue dinterface graphique aura un aspect dynamique bien plus important (protocoles, synchronisations, ...) que les aspects structurel et fonctionnel. loppos, la vue structurelle dune application dinterfaces utilisateur dans laquelle toutes les fonctionnalits sont disponibles en librairie sera prpondrante par rapport aux autres vues ; il en est de mme pour les applications utilisant principalement les bases de donnes. Pour conclure, disons que les mthodologies reposant sur UML (dont nous navons vu quune petite partie) sont conues comme un moyen gnrique pour dcrire des applications orientes objets, et de la mme faon quil nest pas judicieux de tenter dutiliser tous les lments de la langue franaise pour crire un article, vous ntes pas non plus oblig dutiliser tous les concepts d UML dans vos projets pour en tirer prot. Cest chaque utilisateur dUML dexploiter la partie qui lintresse pour rsoudre son problme.

24

6 NETographie (dernire mise jour : 2001-2002)

6.1 Programmation objets et UML
url1 - http ://www.csioo.com/cetusfr/software.html : carrefour Cetus : Orient Objets ; excellent, plus de 8000 liens. url2 - http ://www.cyber-espace.com/ronald/ : espace objet francophone. url3 - http ://www.rational.com/UML/resources.html : site de R A TIONAL

(principal acteur de UML) url4 - http ://www.omg.org : Object Management Group url5 - http ://www.lurpa.ens-cachan.fr/grafcet/grafcet_fr.html : Tout sur le Grafcet url6 - http ://www.ensta.fr/ osigaud/in204/index.html : Le site web du cours

6.2 Les design patterns (ou patrons de conception)

http ://www.csioo.com/cetusfr/oo_patterns.html : liste de rfrences concernant les patterns (ou patrons) http ://st-www.cs.uiuc.edu/users/patterns/patterns.html : page dentre principale pour les patterns

Rfrences
[Ben95] [Boo94] [Bn92] E. Bennatan. Management des projets informatiques : manuel du chef de projet. AFNOR, 1995. G. Booch. Object-Oriented Software Analysis and Design with Applications. Benjamin Cummings, 1994. C. Bnard. Les neufs points clefs de la conduite dun projet informatique. Editions dorganisation, 1992.

[GHJV96] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns : catalogue de modles de conception rutilisables. ITP, France, 1996. [Har87] D. Harel. Statecharts : A visual formalism for complex systems. Science of Computer Programming, 8, 1987.

[JBR97a] I. Jacobson, G. Booch, and J. Rumbaugh. The Objectory Software Development Process. Addison Wesley, 1997. 25

[JBR97b] I. Jacobson, G. Booch, and J. Rumbaugh. Unied Modeling Language Reference Manual. Addison Wesley, 1997. [JBR97c] I. Jacobson, G. Booch, and J. Rumbaugh. Unied Modeling Language User Guide. Addison Wesley, 1997. [JCJO92] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering : A Use case Driven Approach. Addison Wesley, 1992. [Lor97] [Mey97] [Rum96] [Sig05a] M. Lorenz. Object-Oriented Software Development. Prentice Hall, 1997. B. Meyer. Object-Oriented Software Construction. Prentice Hall, 1997. J. Rumbaugh. France, 1996. Modlisation et conception orientes objets. Masson,

O. Sigaud. Introduction la modlisation oriente objets avec UML. support du cours Gnie logiciel et programmation oriente objets de lENSTA, 2005. O. Sigaud. Introduction la programmation oriente objets avec Java. support du cours Gnie logiciel et programmation oriente objets de lENSTA, 2005.

[Sig05b]

26