introduction - eyrolles

1

Introduction

« Le sage montre la Lune, le sot regarde le doigt. »

Lao-Tseu

Usage et destination du présent ouvrage

Durant ces dernières années, l’approche objet s’est peu à peu imposée comme l’élémentunificateur de la fabrication de tous les constituants d’un système d’information, que cesoit au niveau technique (langages, bases de données, interfaces), au niveau fonctionnel(objet « métiers »), au niveau architectural (« composants ») ou au niveau conceptuel.Cette uniformisation des modes de raisonnement et de spécification constitue un formi-dable atout pour la démarche de conception et de mise en œuvre d’un système complexe,démarche qui peut s’appuyer, du début à la fin, sur un ensemble cohérent de concepts.Quelques obstacles résiduels viennent hélas noircir ce tableau. En particulier, la multipli-cité des outils, des langages et des notations tend à cacher ce socle commun. De plus, leschoix techniques qu’il convient d’effectuer (Java ou C++ ?) interviennent à mauvaisescient dans un processus qui ne devrait s’attacher qu’aux principes fondamentaux avantde s’inquiéter de détails relatifs à l’implantation.

Cet ouvrage a pour objet de replacer dans un contexte général une approche objet géné-ralisée pour la spécification de systèmes d’information, approche qui tente de s’abstraireautant que faire se peut de considérations techniques relatives soit à

l’implantation

, soitaux

notations

utilisées. Notre ambition est donc double :

•

Donner du sens

aux spécifications produites durant la phase de description fonctionnelle,technique et architecturale d’un système d’information et montrer qu’il se ramène le plussouvent à quelques motifs ou concepts fondamentaux.

Livre Rochfeld.book Mardi, 11. décembre 2001 4:22 16

Traité de modélisation Objet

2

•

Illustrer pratiquement

l’application de ces concepts objets fondamentaux par des études decas restreintes mais représentatives d’une large palette de problèmes usuels, en dégageant,du mieux que cela est possible, des archétypes de problèmes et en justifiant les différentschoix possibles.

Notre propos n’est pas de réinventer une nouvelle méthode ou de proposer un nouveaulangage. Conformément à notre conviction, à savoir qu’il est maintenant nécessaire dedégager une démarche d’application des outils existants qui repose sur la mise en valeurde leurs fondements objet, nous nous appuyons sur quelques outils largement diffusés etdéveloppons une démarche unificatrice qui montre comment, en s’appuyant sur leursfondements communs, il est possible d’obtenir naturellement une démarche cohérente etapplicable à toutes les dimensions d’un système. Parmi les principaux outils utilisés dansce livre, citons la notation UML, OOM – une démarche de conception objet issue deMerise –, et enfin les principes fondamentaux de la programmation objet.

La notation unifiée (UML) bénéficie d’un engouement certain depuis sa standardisationpar l’OMG, le 17 novembre 1997. Un ouvrage publié par Addison-Wesley en présenteles principaux concepts :

The Unified Modeling Language Reference Manual

, dû àG. Booch, I. Jacobson et J. Rumbaugh). Cette notation constitue désormais un standardde représentation des modèles. En revanche, les utilisateurs regrettent l’absence d’unedémarche de modélisation/développement qui bénéficierait d’une audience comparable.Un processus unifié a certes été proposé. Il est défini par l’ouvrage

The Unified SoftwareDevelopment Process

, rédigé par les mêmes auteurs et publié par le même éditeur. Desversions personnalisées, telle celle de Rational (RUP), sont disponibles, qui représententun fonds documentaire important (plus de 4000 pages pour le RUP).

Il nous a semblé utile de proposer une fusion de la notation unifiée et d’une démarche quiexploite l’expérience acquise depuis plus de vingt ans dans la conception des systèmesd’information d’entreprises, le plus souvent en utilisant Merise

1

ou, plus récemment, saversion orientée objet

2

pour ce qui est relatif à l’utilisation des nouvelles technologies.C’est ce résultat qu’exploite partiellement le présent ouvrage.

Nous proposons une réflexion globale sur la modélisation objet et sur ses nombreusesfacettes. Pour ce faire, nous nous appuyons sur un ensemble d’exercices à même d’illus-trer ce processus et de dégager un ensemble de choix possibles pour chacun des modèlesproposés, choix dont la satisfaction constitue l’essence du travail du concepteur. En effet,il est de la responsabilité de ce dernier de prendre en compte l’expression des besoins del’utilisateur, ou, pour les projets importants, ceux formulés par une maîtrise d’œuvre, detenir compte de l’usage projeté des modèles en construction, mais aussi de son intimeconviction quant à ce qui doit y figurer, avant de proposer un modèle qu’il juge adéquatet de le faire valider par les structures de décision. Nous essaierons de

dégager l’essenced’un tel processus

qui est indépendant d’une notation particulière. Nous présenterons

1. A. R

OCHFELD

, J. M

ORÉJON

,

La Méthode Merise

, tome 3,

Gamme opératoire

, les Editions d’Organisation,Paris, 19892. M. B

OUZEGHOUB

, A. R

OCHFELD

, OOM –

La Conception objet des systèmes d’information

, Hermès« Science », Paris, 2000


Introduction

C

HAPITRE

1

3

dans un premier temps les principes communs aux orientations objet que nous souhaitonsexploiter et qui se situent à l’arrière-plan d’UML. Les éléments de modélisation exploi-teront cette notation dont nous rappellerons les conventions avant de les utiliser dans lesdifférents chapitres qui suivent.

Il est à remarquer que le présent ouvrage ne constitue en aucun cas un traité de modé-lisation spécifique à UML. Comme le stigmatise Lao-Tseu, dans ce proverbe rappeléen exergue de ce chapitre premier, « … le sot regarde le doigt » ; ici, ce peut être lanotation, et nous nous efforcerons d’éviter ce travers assez courant dans le présentouvrage.

Ce traité de modélisation s’adresse en premier lieu aux consultants et aux concepteurs,chevronnés ou débutants, puisque aucune connaissance antérieure n’est supposée. Ils ytrouveront un ensemble de réflexions à même de les aider lorsqu’ils seront amenés àeffectuer des choix de modélisation dans le cadre de leurs interventions en entreprise.Les concepteurs de système d’information, qu’ils interviennent en tant qu’assistants àune maîtrise d’ouvrage ou à une maîtrise d’œuvre, apprécieront, nous l’espérons, leséclaircissements sur la modélisation métier ou sur la modélisation technique qui parsè-ment les réflexions accompagnant les différentes études de cas. Néanmoins, cet ouvragesera particulièrement utile aux étudiants des écoles d’ingénieur, en DESS ou en DEA quiy trouveront tout à la fois une présentation simple des principes communs aux orien-tations objet ainsi qu’une illustration des difficultés du processus de modélisation. Lesenseignants l’exploiteront pour le support de leurs cours et de leurs travaux pratiques.Tous les lecteurs y trouveront des éclaircissements, et quelque matière à réflexion, sur ladifficulté de la modélisation objet.

Bien que ce livre soit composé d’études de cas distinctes qui, pour d’évidentes raisonspédagogiques, ne correspondent que d’une manière simplifiée aux situations réellesrencontrées par un concepteur, l’à-propos de ce dernier lui permettra certainement derelier des aspects fondamentaux couverts par ce livre et favorisera la construction d’unesolution à même de satisfaire les futurs utilisateurs.

Avant d’aborder les différentes études de cas, nous effectuons les rappels nécessaires à lacompréhension des principes communs aux orientations objet. Cette présentation vise àrendre possible une lecture totalement autonome du présent ouvrage.

Principes communs aux orientations objet

La présentation des principes et de toutes les techniques de programmation orientée objetexcède de loin le cadre fixé à ce livre. Nous nous limiterons donc aux aspects qui permet-tent de spécifier en détail certaines opérations du système d’information. Cette spécifica-tion est l’occasion de rapprocher la représentation

dynamique

du système (autrement dit,les fonctions, les opérations) de sa représentation

statique

(soit, le modèle des objets), etdonc de valider cette dernière. Cette présentation est complétée par un ensemble deconventions graphiques propres à UML, rappelées dans le chapitre 2.


Traité de modélisation Objet

4

Concepts de base

Les orientations objet trouvent leur origine dans une programmation spécifique, la

programmation objet

. Cette programmation objet peut être considérée comme une exten-sion de la notion de la

programmation

modulaire

, qui a eu cours dans les années 1970.Un module y était un ensemble de traitements satisfaisant un des besoins fonctionnels del’application, par exemple les accès à une base de données ou l’application d’un ensem-ble de règles de gestion. Le fait d’utiliser des fonctions mettait l’accent sur le

traitement

de l’information, les données étant considérées comme des informations transitoires quisont échangées entre les fonctions.

Les orientations objet proposent une intégration plus poussée des données et des traite-ments. Un

objet

peut être simplement défini comme un

sous-système

, doté de ses propresinformations et traitements, qui se charge de fournir des services au reste de l’application.

En introduisant des objets dans l’application, on obtient des « boîtes noires » dont lefonctionnement interne n’est pas connu du reste de l’application, mais qui sont capablesde réaliser certaines tâches en fonction de demandes très simples. Toutes les connaissan-ces requises pour faire fonctionner un objet ne doivent pas être utiles pour l’applicationqui doit juste connaître l’interface permettant de demander à un des objets de déclenchertelle ou telle opération.

L’utilisation des objets implique une démarche de conception un peu particulière qui serautilisée par les différentes études de cas et dont le noyau est présenté à la fin de cetteintroduction. Il faut considérer une application comme un « client », plutôt paresseux,qui se repose autant que possible sur les services fournis par des prestataires qui sontexperts dans un domaine particulier et se chargent d’accomplir des tâches à la demande.L’application est alors juste une sorte de coordinateur qui répartit le travail à effectuer, etne veut surtout pas savoir

comment

ce travail est effectué.

Une orientation commune aux approches objet réside en l’exploitation de mécanismespuissants qui facilitent une intégration forte des traitements et des informations qui leursont nécessaires, favorisant par là même l’émergence de solutions à base d’élémentsautonomes.

Objets et classes

Les orientations objet disposent de leur propre terminologie, cohérente, même si ellesemble parfois manquer de simplicité. La présentation qui suit est très concise et viseessentiellement à définir le vocabulaire qui nous sera utile.

Un objet est doté d’une part d’une

identité

propre qui permet de le distinguer des autresobjets, et d’autre part d’un ensemble d’

attributs

qui le décrivent. Dans cette approche,tout peut être considéré comme un objet : un fichier, une personne, une voiture, unefacture, etc. L’environnement technique (le langage de programmation par exemple) doitgérer automatiquement l’identification des objets et permettre d’accéder à ses attributs.Nous noterons l’accès à un attribut par le symbole ->. Si, par exemple,

personne

est unobjet, alors

personne->nom

désignera l’attribut

nom

de cet objet.


Introduction

C

HAPITRE

1

5

Comment faire pour définir soi-même ses propres objets ? On utilise des classes, quitiennent lieu de constructeurs permettant d’engendrer des objets. Une classe est une sortede « moule » à partir duquel on peut créer à la demande des objets, conformes à ladescription de la classe. C’est aussi le représentant collectif d’un ensemble d’objets quiapporte des services qui n’ont de signification qu’à ce niveau ; par exemple, un service decréation d’objets ne peut être porté par des objets encore inexistants. La même distinctiona lieu entre une classe et ses objets qu’entre le type string et l’ensemble des chaînes decaractères, ou entre le schéma d’une table relationnelle et le contenu de cette table.

Une classe définit non seulement les attributs communs à tous ses objets, mais égalementleur comportement ou, pour dire les choses plus simplement, l’ensemble des fonctionsqu’on peut leur appliquer. Un objet ne devrait pas être seulement vu comme un ensembled’attributs, mais aussi – et surtout – comme un petit système fournissant des services auxautres objets qui l’utilisent. Un objet Fichier, par exemple, devrait fournir des servicescomme Ouvrir() le fichier, le Fermer(), Lire() (une ligne ou un mot), Ecrire(), etc.

Les attributs mentionnés jusqu’alors sont associés aux objets. Leur valeur peut varierd’un objet à un autre. Le nom d’un fichier binaire ou pas sera différent de celui de toutautre fichier. Il peut se faire que certains attributs prennent une valeur qui serait communeà l’ensemble des objets d’une classe. Par exemple, il se peut qu’à tous les articles d’uneentreprise soit appliqué un taux unique de T.V.A. Pour éviter de répéter inutilement cettevaleur dans chaque objet, on définira alors l’attribut taux de TVA comme un attribut declasse, ce qui aura pour effet d’en factoriser automatiquement la valeur à ce niveau.

Services et méthodes

La description de certaines méthodes est une étape essentielle dans la conception d’unsystème d’information basé sur des principes orientés objet. Une méthode est un serviceproposé à l’ensemble de l’application par les objets d’une classe. L’idée fondamentale àl’arrière-plan de cette notion de service est que les opérations les plus complexes peuventsouvent être obtenues par la coordination d’un ensemble de demandes très simples, cequi permet de décomposer un système en sous-systèmes indépendants, et donc de maîtriserla complexité de l’ensemble.

Une analogie assez parlante consiste à considérer la relation qu’entretiennent un maîtred’ouvrage et des artisans. Dans son domaine d’activité, chaque artisan sait effectuer desprestations complexes. Le maître d’ouvrage en revanche ne veut surtout pas s’encombrerl’esprit avec les détails techniques des différents travaux engagés. Il se concentre sur lavision globale et délègue à chaque intervenant la responsabilité d’accomplir une destâches contribuant au résultat final.

Dans le cas d’un système d’information, chaque objet doit être un de ces artisans quiaccomplit, individuellement et surtout indépendamment des autres objets, une partie desfonctionnalités. Le système lui-même est le coordinateur qui planifie l’action des objets.Un des grands avantages de cette démarche est qu’elle autorise la conception successivede chaque classe d’objet comme s’il s’agissait d’un sous-système autonome. On peut,


Traité de modélisation Objet6

dans un deuxième temps, oublier toutes les fonctionnalités internes de ces sous-systèmeset ne conserver que la liste des tâches (ou services) qu’ils sont capables d’effectuer.

Dans ce livre, les services (méthodes) sont décrits à l’aide de pseudo-code. Son écritureest un moyen simple et rigoureux de spécifier des algorithmes sans s’embarrasser descontraintes syntaxiques d’un véritable langage de programmation. Nous en donnonsquelques exemples simples dans la suite de ce chapitre.

Encapsulation et méthodes

Il est fortement recommandé de cacher les attributs d’un objet et de n’y accéder quepar l’intermédiaire de ses services. Les attributs d’un objet Fichier, comme son nom,son emplacement, son état (ouvert, fermé), ne regardent pas l’utilisateur de l’objet.Cette dissimulation des attributs est désignée par le terme d’encapsulation et offre denombreux avantages dont, par exemple, la possibilité de revoir complètement l’organi-sation interne d’un objet sans remettre en cause les applications qui l’utilisent puisqueces dernières ne voient que les services de cet objet. Conséquence de cette isolation, lesvaleurs associées aux attributs d’un objet ne sont jamais partageables en tant quetelles. Seules des fonctions appropriées permettront, selon certaines modalités deconfidentialité, de récupérer ces valeurs.

Les fonctions définies dans le cadre d’une classe sont des méthodes dans la termino-logie objet. Il faut toujours considérer un objet comme un petit système et les méthodescomme les fonctions de ce système. Une des conséquences, parfois difficile à comprendre,de ce concept est qu’une méthode s’exécute toujours dans le contexte d’un objet parti-culier et dispose d’un accès privilégié aux attributs de cet objet qui peuvent donc êtreconsidérés comme des variables implicites, sans que ces dernières ne soient accessi-bles de l’extérieur. Un tel mode d’appel isole aussi bien l’objet appelé que l’objetdemandeur, et aucun effet en retour d’une demande de service (d’un appel de procédure)n’est ici à craindre.

Une méthode appliquée à un objet Fichier peut donc manipuler les attributs de l’instancede ce fichier. Afin de les distinguer des autres variables, on utilise en général un mot-clécomme self qui désigne l’objet courant. La notation self->nom, self->emplacement,self->etat, sera donc employée, dans le cadre de la spécification d’une méthode, pourfaire référence aux attributs de l’objet Fichier au sein duquel la méthode s’exécute.

Il y a une grande différence entre ces variables et des variables normales d’une fonction :tandis que ces dernières apparaissent à chaque appel de la fonction (paramètres d’appel),les attributs d’un objet existent pendant toute la durée de vie de l’objet. Les premièresexistent donc avant l’exécution d’une méthode, et survivent après la fin de cette méthode.

A toute méthode est associé un ensemble de paramètres formels ou signature de laméthode. La sémantique de la méthode (son effet) est obtenue via un corps ou ensembled’instructions exécutables. Chaque méthode exploite les attributs de l’objet porteur,complétés par les paramètres transmis. De plus, il peut exister une vision différenciée desméthodes. Certaines méthodes sont ainsi « visibles » par tous les objets, d’autres visiblesuniquement par les sous-classes d’objets d’une même hiérarchie, d’autres enfin ne sont


IntroductionCHAPITRE 1

7

visibles que par la classe elle-même, en tant que représentant collectif des objets, et paspar ces objets. C’est le cas d’une méthode telle que créer qui n’a de sens qu’au niveau dela classe, les objets d’implantation n’existant pas encore.

Comme toute caractéristique d’un objet, les méthodes sont elles aussi encapsulées. Seulleur nom et leur signature sont connus, leur corps n’est jamais accessible de l’extérieur.Cette qualité est importante et permet d’associer à une méthode un corps variable dansle temps. Rien n’interdit que ce corps soit écrit dans un langage particulier (Cobol,Fortran, C++, Java) et qu’il évolue sans que les mécanismes de mise en communicationne soient appelés à changer. Cela confère aux orientations objet des capacités d’urbani-sation du logiciel, même s’il est ancien, très intéressantes. On peut ainsi imaginer réuti-liser des programmes éprouvés, écrits dans un langage procédural (Cobol, Fortran),dans un environnement objet.

Communication par message

La contrepartie de l’isolation des objets ou encapsulation est que tout objet est un mini-système indépendant. La communication entre les objets n’est possible qu’au travers del’échange de messages. Chaque message constitue une demande de service formulée parl’objet émetteur à destination de l’objet récepteur, porteur de la méthode à même derendre le service demandé.

Dans une approche plus classique, le message est en fait analogue à un appel de procé-dure. Il est composé des paramètres d’appel propres au contexte de l’appel, paramètresqui doivent être en accord en type et en nombre avec les paramètres formels de la signa-ture de cette méthode. Différence essentielle avec la programmation classique, il estindispensable de préciser l’objet cible du message, chaque objet étant porteur des métho-des définies au niveau de la classe. La méthode appelée va s’exécuter dans le contexteparticulier d’un objet. Ainsi la méthode Fournir_nom() fournira le nom (la valeur) del’objet sollicité par le message Fournir_nom(objet-cible, param2, param3,..,paramn.).

Spécialisation et autres concepts

Un autre principe commun aux orientations objet est la spécialisation : il est possible decréer des sous-classes qui définissent des objets plus spécialisés que ceux de la classemère. Par exemple, une classe FichierBinaire pourrait gérer un type particulier de fichier,

Urbanisation du logiciel

Comme pour la rénovation d’une ville, l’urbanisation du logiciel consiste à le rénover en tenant compte de l’évolu-tion de son utilisation. De nouvelles voies de communication (appels de procédures) sont tracées, de nouveauxquartiers sont définis (blocs de logiciels), en exploitant au maximum les immeubles existants, ici les logiciels.Dans ce contexte, il est très intéressant de pouvoir faire appel à des programmes anciens, éventuellement volu-mineux, éprouvés et validés par un usage décennal, sédimentés (des parties en assembleur, d’autres en Cobol,en Fortran), le tout à travers une nouvelle présentation, en orientée objet. Le logiciel « réurbanisé » se présentealors comme un ensemble de classes et d’objets, doté de méthodes dont le corps fait appel aux programmesantérieurs.



avec des méthodes d’ouverture, de fermeture et de lecture/écriture particulières. Selon lecontexte, on peut alors considérer un fichier binaire comme un fichier normal, et luiappliquer les méthodes de la super-classe, ou comme un fichier spécialisé. Nombre deconcepts découlent de la spécialisation.

Héritage

Toutes les caractéristiques d’une super-classe (attributs, méthodes, contraintes) sonthéritées par la ou les sous-classes, cet ensemble formant une hiérarchie d’héritage ou degénéralisation/spécialisation. Il y a alors factorisation des éléments communs au niveaude la racine de la hiérarchie. Par exemple, un FichierBinaire est un Fichier et doit doncpouvoir se comporter comme tel. Ces différentes caractéristiques sont ainsi transmises àtout élément de la hiérarchie. Ainsi, les attributs d’une classe C sont communs à tous lesobjets des classes de la hiérarchie dont la racine est C.

Composition

Sauf précision contraire, tout attribut d’une classe est monovalué. Pour tout objet, cetattribut est associé à une seule valeur (on dira aussi qu’il s’agit d’un attribut atomique).Certains attributs peuvent être définis en tant que multivalués. Une personne aura ainsiplusieurs prénoms ou plusieurs numéros de téléphone. Nous utiliserons la notation UML[1+] pour définir des attributs multivalués. Ainsi un attribut téléphone[1+] associé à uneclasse signifiera-t-il que plusieurs numéros de téléphones peuvent être gérés.

Ce mécanisme de composition peut être étendu aux objets eux-mêmes. Un véhicule, parexemple, sera vu comme la composition d’un châssis, d’une carrosserie, d’un moteur,etc. Ce moteur lui-même sera défini comme étant composé de cylindres, de pistons, d’unvilebrequin, suscitant la création d’une nouvelle forme de hiérarchie, une hiérarchie decomposition.

Surcharge

Souvent, le comportement des objets d’une sous-classe est un raffinement de celui desobjets de la super-classe. L’ouverture d’un fichier binaire ou les opérations de lecturepeuvent différer de celles d’un fichier ordinaire. On modifie alors la définition de laméthode, tout en gardant le même mode d’appel. Ce n’est pas le système extérieur eneffet qui doit distinguer les fichiers binaires des fichiers simples. Il doit pouvoir deman-der une lecture comme un service à un objet, et c’est alors à cet objet lui-même, en fonc-tion de sa classe ou sous-classe spécifique, de déterminer quelle est la version appropriéede la méthode de lecture qui doit être employée. On parle de surcharge pour indiquer laredéfinition d’une méthode au niveau d’une sous-classe. Il y a dans les faits substitutiond’un corps à un autre corps. Il peut aussi y avoir surcharge de signature. Dans ce cas, il ya moins de paramètres, ou certains des paramètres formels sont dotés d’un type différentde ceux de la méthode générique. Certaines contraintes, que nous ne détaillerons pas ici,car elles n’entrent pas dans le cadre de notre développement, permettent d’assurer lacohérence des modes d’appel des services au sein d’une hiérarchie de classe.



9

La notion d’envoi de message est particulièrement pertinente quand on prend en comptece mécanisme de surcharge. Quand on s’adresse à un objet, on ne connaît pas forcémentla classe à laquelle il appartient dans une hiérarchie d’héritage. On ne peut donc pas direque l’on appelle une fonction ou une procédure puisqu’on ne peut pas – ne doit pas –savoir quelle est, parmi toutes les implantations possibles, surchargées, de cette procé-dure, celle qui sera utilisée. C’est à l’objet lui-même de déterminer la version exacte de laméthode qui doit permettre de satisfaire au mieux la demande de service.

L’envoi de message prend donc, dans ce contexte, une signification cohérente avec lereste des concepts orientés objet, et plus globalement avec la démarche d’abstraction quivise à rester à un niveau le plus général possible. On ne déclenche pas une fonction, ondemande, d’une manière très déclarative, la fourniture d’un service.

ExempleNous allons donner, pour illustrer les concepts qui viennent d’être présentés ainsi que lesnotations que nous utilisons dans ce livre, la description d’une classe qui permet de gérer desobjets géométriques, et qui, par exemple, peut être utilisée par un outil de dessin vectoriel.

Classes

La définition de la classe comprend un ensemble d’attributs et deux méthodes : l’une,Afficher(), pour afficher l’objet sur un écran, l’autre, Surface(), pour calculer la surfacede l’objet.

Voici, ci-après, avec une notation simplifiée, comment on créerait cette classe dans unlangage orienté objet standard comme le C++ ou Java. Le mot-clé var y indique un attributdes objets, et méthode le début de la définition d’une méthode.

Classe Geom{ // D'abord les variablesvar abscisses, ordonnees; // Les coordonnées var nbPoints; // Nombre de points // Puis les méthodes Méthode ajoutPoint (x, y) { self->abscisses[self->nbPoints] = x; self->ordonnees[self->nbPoints] = y; self->nbPoints = self->nbPoints + 1; }

Classe

Une classe est une sorte de moule pour construire – on parle « d’instanciation » – des objets qui se conformentà la définition de la classe. On procède souvent à l’instanciation d’un objet, à l’aide d’une instruction de program-mation objet, avec le mot-clé new.



Méthode afficher (ecran) { for (i = 0; i < self->nbPoints; i++) ecran->affiche(self->abscisses[i], self->ordonnees[i]); } Méthode surface () { // Ici un calcul de surface ... retourner surface; }}

Voici un exemple d’utilisation des services de la classe : on crée un objet icône, on décritsa géométrie par une liste de points, puis on calcule sa surface.

icone = new Geom; // Ajout de quelques points icone->ajoutPoint(12, 43); icone->ajoutPoint(32, 30); icone->ajoutPoint(56, 6); // Calcul de la surface print "Surface = ", icone->surface();

Dès qu’un objet est instancié, il devient possible de lui appliquer les méthodes de saclasse.

Sous-classes

On peut créer des sous-classes d’une classe. Les objets d’une sous-classe sont desobjets de la classe mère, mais comportent en outre des attributs et un comportement(ensemble de méthodes) spécifiques. On peut par exemple définir des sous-classesRectangle, Polygone, etc., pour la classe Geom.

Les attributs et les méthodes de Geom sont héritées par Rectangle ou Polygone. Cependant,un rectangle par exemple a une définition plus précise qu’un objet géométriquequelconque : il a seulement quatre sommets, qui sont à angles droits. L’instanciation d’unobjet de la classe Rectangle devrait tester que ces contraintes sont bien vérifiées. De même,la méthode de calcul d’une surface est bien plus facile à implanter pour un rectangle. Onpeut donc remplacer la définition générale de la méthode Surface() par une implantationplus spécifique : c’est la surcharge. Voici comment nous noterons cette redéfinition :

Classe Rectangle Spécialise GeomMéthode surface (){ retourner (self->abscisses[1] - self->abscisses[0]) * (self->ordonnees[1] - self->ordonnees[0]);}



11

Le calcul de surface pour un rectangle consiste simplement à multiplier la hauteur par lalargeur, ce qui est beaucoup plus simple (et donc plus efficace) qu’un calcul de surfacepour un objet géométrique quelconque. Nous verrons que la surcharge est, d’une manièregénérale, un outil extrêmement puissant pour décrire, au sein d’une hiérarchie de spécia-lisation, les aspects spécifiques à une ou plusieurs sous-classes.

Composition de l’ouvrageLa suite de cet ouvrage illustre l’exploitation des principes communs aux orientationsobjet, au travers de l’utilisation de modèles spécifiques notés UML, dont un bref rappelfait l’objet du chapitre 2. Différentes études de cas sont ensuite exploitées.

Le chapitre 3 présente le système d’information de la « société Amarilli ». Il y est étudiéles fondements du modèle des besoins, ceux du modèle des données, support du modèlede classes. A ce titre, sont fournis des rappels sur la modélisation entité-association, tantil est vrai qu’un modèle de classes doit avoir une sémantique précise qui ne peut lui êtrefournie que par un modèle de ce type, sous peine de ne pouvoir supporter les besoins deses utilisateurs dans des conditions satisfaisantes et de présenter des difficultés d’évolu-tion ou de maintenance. Ce chapitre est aussi l’occasion d’un premier examen de la dyna-mique des objets. Ce modèle entité-association est complété par des réflexions initialessur la modélisation des cycles de vie de certains des objets définis.

Le chapitre 4 présente le système d’information du « groupe EuroRest ». Il y est montrécomment un système objet peut s’appuyer sur trois niveaux fonctionnels pour construiredes traitements complexes. Son modèle des besoins, relativement élaboré, est simplifiépar l’usage de fonctions externes réutilisées. Son modèle des données comporte plusieursobjets complexes, puisque composés d’autres objets. Des méthodes, simples, sontdétaillées et décrites à l’aide d’un pseudo-code. Une ébauche de scénario introduit laproblématique de la modélisation des processus.

Le chapitre 5 présente le système d’information d’un « service de Hot-Line ». Il y estdétaillé le modèle des besoins, le modèle des données et le modèle de classes. Les fonde-ments du modèle des processus sont rappelés et quelques T-scénarios sont fournis.

Le chapitre 6 présente le système d’information d’un « éditeur de revues scientifiques »doté de nombreux processus. Son modèle des données repose sur la définition d’objetscomplexes, composés d’autres objets. Son modèle de classes détaille la séquenced’échange des messages induite par la nature complexe des objets et propose le cycle de viedes objets les plus significatifs. Son modèle de processus détaille deux des unités detraitements, complétés par un T-scénario.

Le chapitre 7 décrit un « système d’information documentaire » au travers de deuxmodèles, le modèle des besoins d’une part, le modèle d’architecture d’autre part. Aumodèle des besoins, relativement complexe, sont associées des techniques de validationde la décomposition. Le modèle d’architecture détaille la couche fonctionnelle ainsi quela couche organisationnelle. La couche Application est esquissée, de même que lacouche Informatique et que la couche Infrastructure.



Le chapitre 8 décrit le « fonctionnement d’une installation technique », un « ascenseur ».Son fonctionnement conduit à introduire de nouveaux concepts ou plutôt de nouvellesextensions de concepts plus classiques. Ainsi, le modèle des besoins complète le conceptd’acteur humain par celui d’acteur matériel et de classe matérialisée. Bien qu’étantsimple, le modèle des objets décrit les composants de l’installation et montre les retom-bées des contraintes techniques sur le modèle des objets. Le modèle de processus s’attacheà trois moments clés du fonctionnement : le démarrage, le déclenchement de la sécurité etl’arrêt de la cabine d’ascenseur. Des scénarios leur sont également attachés.

Le chapitre 9 décrit l’« administration d’un ordinateur ». Bien que le modèle des besoinsne détaille que quelques processus élémentaires, il montre des variantes de modélisation etdégage des ambiguïtés relativement au statut de ce modèle. Il réexploite certaines exten-sions introduites par le chapitre précédent. Le modèle des objets définit un objet relative-ment complexe, doté de nombreux composants. Le modèle de processus est particuliè-rement riche et propose le modèle de plusieurs tâches. Les scénarios correspondants sontaussi décrits.

Le chapitre 10 décrit le système d’information d’une entreprise industrielle, une« exploitation minière ». Une démarche en deux étapes est adoptée. La première se basesur des spécifications assez grossières et permet d’élaborer rapidement des modèlessimplifiés du système. Dans une seconde étape sont ajoutées de nouvelles spécificationsafin de démontrer les avantages d’une approche objet en termes d’évolutivité et deréutilisation des composants. Le modèle des objets est relativement riche et détaille leshiérarchies de spécialisation dans lesquelles se situent plusieurs objets. Le modèle deprocessus est particulièrement riche. Une description de plusieurs tâches est proposée,complétée par les scénarios correspondants.

Le chapitre 11 présente le système d’information d’un « tour operator ». Il constitue engrande partie une réflexion sur les effets bénéfiques de la généricité. Son modèle desbesoins dégage un modèle métier riche mais en grande partie classique. Le modèle desobjets est centré sur un concept central celui de Services. L’exploitation de différentesformes de hiérarchies de spécialisation crée une capacité d’évolution du système d’infor-mation qui sera appréciée par les utilisateurs. Le modèle de processus met en œuvre unegénéralisation de certaines unités de traitement. Une forme riche de réseau de Petri estexploitée : les réseaux de Petri à prédicat et à capacité. Cette généralisation est aussiexploitée au niveau de T-scénarios qui deviennent des T-scénarios centrés eux aussi surle concept générique de services. Originalité très forte de l’étude de cas, une couchefonctionnelle générique d’architecture de la solution est proposée.

Le chapitre 12 décrit le système d’information d’un « garage » qui présente des caractèreslui aussi très classiques. Cette étude de cas rend possible l’examen des différents effets dela création de métaclasses, de la spécialisation de classes et, plus originale, celle decertains scénarios génériques. Des fonctions de gestion très souvent rencontrées fontl’objet d’un modèle de besoins classique. Son originalité : il sert de base au calcul de lacharge d’étude et de développement au travers de la technique des points de fonction. Lemodèle des objets pousse la généralisation à son terme et dégage un ensemble de messagesstructurels, mis en facteur d’une manière bénéfique. Une hiérarchie métaclasse-classes est



13

aussi proposée. Une réflexion sur la généralisation des messages conduit à dégager unT-scénario structurel. De plus, le modèle des besoins est le support d’une réflexionmétrologique, rendant possible une évaluation des charges d’étude et de développement.Le modèle de processus y est relativement riche et des règles de validation en sontproposées et leurs effets dégagés. Des A-scénarios sont présentés et la généralisation estportée à son terme au travers d’un T-scénario générique, conséquence du T-scénario struc-turel antérieur.

Le chapitre 13 décrit le système d’information d’un « rallye automobile » à étapes, quis’appuie sur un corpus de règles particulièrement riche, qui structure totalement les diffé-rents modèles. Le modèle des besoins dégage un ensemble de fonctions à même de pren-dre en compte les différentes règles. Le modèle des objets identifie les objets pertinents,supports du corpus de règles. Quant au modèle de processus, l’existence du corpus derègles a un effet direct sur les événements d’entrée et de sortie, ainsi que sur les synchro-nisations où les conditions de sortie associées. En dernier lieu, l’effet des règles sur lesT-scénarios est montré.

L’ensemble des études de cas couvre les différents principes qui régissent les orientationsobjet. Il en montre la variété, illustre les difficultés qui en découlent et dégage des solutionsqui peuvent être réutilisées.

Une conclusion montre l’évolution des concepts objet, de la programmation à la concep-tion, et dégage quelques tendances fortes du développement actuel du logiciel, en parti-culier l’usage de plus en plus généralisé d’un logiciel embarqué dans des produits degrande consommation (automobile, produits de grande consommation). Bien sûr, desconséquences en sont tirées sur les capacités requises de la modélisation objet.


2Prise en compte

des principes communsaux orientations objet

à l’aide d’UML

Rappels sur la notation UMLLa notation UML constitue un standard de fait quant au processus de conception orientéobjet. Nous ne rappelons ci-après que ses principales conventions. UML propose unensemble d’outils, à savoir :

• une notation, qui est particulièrement exploitée dans le présent ouvrage ;

• un métamodèle sémantique extensible, qui précise la sémantique des éléments de la nota-tion, ou stéréotypes, dont certains, nouveaux, seront introduits pour le support de conceptsappropriés, sans contrevenir au métamodèle sémantique de la notation ;

• une définition d’une interface avec les services de CORBA ou avec le langage XML.

La contribution majeure d’UML prend la forme d’un ensemble de diagrammes qui accom-pagnent le processus de modélisation et de développement d’une solution logicielle, àsavoir :

• des diagrammes de cas d’utilisation, qui sont exploités dans le cadre de l’expression desbesoins à satisfaire ;

• des diagrammes de classes et d’objets, précisant les classes et les objets qui sont associésau système d’information de l’entreprise ;



• des diagrammes de collaboration entre objets qui décrivent les interactions entre objets, oumessages échangés par les objets ;

• des diagrammes d’états-transitions, qui décrivent les cycles de vie des objets de la classe,en termes d’états et de transition d’état, diagrammes qui viendront compléter une définitiontextuelle des cycles de vie ;

• des diagrammes d’activité, qui décrivent la sémantique d’une opération en termesd’actions, ou par extension l’enchaînement d’opérations ;

• des diagrammes de séquence, ou diagramme de collaboration entre objets, ordonnée dansle temps, qui serviront de support à différents types de scénarios proposés ;

• des diagrammes de composants, qui décrivent les dépendances de compilation ou d’exécu-tion des modules qui constituent un logiciel, pour lesquels de nouveaux stéréotypes serontintroduits afin de supporter différents types de regroupement proposés ;

• des diagrammes de déploiement, qui décrivent les équipements connectés et leur mode deconnexion, diagrammes qui seront exploités pour le support de la solution technique proposée.

La section suivante décrit l’usage qui peut être fait de ces différents diagrammes pour lareprésentation des éléments de réflexion indispensables à l’expression d’une solution et àson implantation.

Principaux modèles d’appui à une spécification d’un système d’information

Quelle que soit la démarche utilisée pour concevoir et développer un système d’informa-tion, certains résultats intermédiaires se révèlent indispensables. Il s’agit de différentsmodèles qui apportent les éléments de réflexion propres à faciliter les quelques choix quijalonnent le chemin qui va de l’expression des besoins à la mise en œuvre de la solutionproposée, puis implémentée. Chacun de ces modèles fait appel à un ou plusieursdiagrammes UML ; chacun de ces diagrammes peut être exploité dans le cadre d’un oude plusieurs modèles.

En premier lieu, ces éléments de réflexions visent à définir la portée du projet d’informatisa-tion, à en délimiter la portée, dans l’espace et dans le temps. Il s’agit de définir l’environne-ment de ce projet, ainsi que les fonctionnalités à prendre en compte. On y parvient au traversd’un modèle des besoins, qui dégage les différents cas d’utilisation du système actuel oufutur. Un modèle de ce type exploite exclusivement les diagrammes de cas d’utilisation.

Il s’agit ensuite de dégager les classes et les objets exploités lors des différents casd’utilisation. Un modèle des classes et des objets est alors construit à l’aide des dia-grammes UML correspondants. Les collaborations entre les objets sont alors dégagées, àl’aide d’un diagramme, puis les états et transitions de ces objets sont décrits.

Chaque cas d’utilisation est ensuite précisé en dégageant ses conditions de déclenchementet ses sorties, sous la forme d’un modèle de processus. Il s’agit d’un enrichissement des casd’utilisation par des synchronisations, avant que les scénarios d’utilisation de ces objets nesoient précisés sous la forme de divers diagrammes de séquence.


Prise en compte des principes communs aux orientations objet à l’aide d’UMLCHAPITRE 2

17

Un modèle d’architecture de la solution proposée est alors bâti. Il précise les différentesfonctionnalités implantées, de nouveau sous la forme de diagrammes de cas d’utilisation,regroupés sous la forme de composants fonctionnels. Suite à cela, une vision organisa-tionnelle est exploitée, dégageant les acteurs collectifs, les sites de création des objets, lesfonctions supportées et leurs sites d’utilisation. Cette vision organisationnelle exploiteles diagrammes d’activité avec travées. Une solution informatique est alors proposée, quiexploite tant le diagramme des composants (informatiques) que celui du déploiement,dégageant les éléments matériels de la solution.

Ce processus très général s’inspire librement du processus de conception/ développementproposé par OOM1. La figure 2-1 présentée ci-après décrit les interactions entre cesdifférents modèles.

Modèle des besoins

Le modèle des besoins décrit le réel à modéliser tel qu’il est perçu par les utilisateurs. Onprocède à l’identification des besoins par rapport aux acteurs impliqués dans l’organisation,aux flux d’informations qui circulent entre ces acteurs, aux principaux processus qui trans-forment ces flux et aux ressources utilisées par ces processus. L’analyse des besoins est unetâche qui consiste à circonscrire le domaine de l’application et à identifier les matériaux debase qui vont servir en entrée de la modélisation conceptuelle. L’analyse des besoins peutêtre appréhendée comme une négociation entre le chef du projet et ses partenaires, maîtrised’ouvrage, maîtrise d’œuvre et futurs utilisateurs, en vue d’établir un contrat sur les fonc-tionnalités et les limites du système d’information. Le résultat de cette phase est un rapportde spécifications initiales des besoins qui sont exprimés en termes de diagrammes de fluxde données (DFD) transposés dans un environnement objet, de règles de gestion et decontraintes générales d’exploitation. A partir de ce rapport, on peut dériver les spécifica-tions formelles des modèles de données, de traitements et de l’architecture du systèmeprojeté.

1. M. BOUZEGHOUB, A. ROCHFELD, OOM – La Conception objet des systèmes d’information, chapitres 9 et 10,Hermès « Science », Paris, 2000.

Figure 2-1

Les modèles de support d’un processus de spécification/ développement et leurs interactions

Modèled'architecture

CLASSES

Modèle desclasses et des objets

Dynamique desobjets

FONCTIONS

Scénariosfonctionnels

Modèle desprocessus

Modèledes besoins



Sa représentation repose sur les conventions du diagramme des cas d’utilisation. Commedans la notation UML et dans les méthodes de développement qui s’en inspirent, USDP(Unified Software Development Process) par exemple, défini par Ivar Jacobson, GradyBooch et James Rumbaugh et publié par Addison-Wesley en 1999, ou le RUP (RationalUnified Process), personnalisation de Rational de ce processus, le modèle des besoinsjoue un rôle tout à fait central dans le processus de conception/ développement d’unsystème d’information. Il constitue la base à partir de laquelle les autres modèles trouve-ront les éléments de départ qui leur sont nécessaires. Nous avons renforcé cet aspect parl’introduction d’un stéréotype supplémentaire dans le diagramme des cas d’utilisation,conférant ainsi une traçabilité maximale aux différents modèles, les uns par rapport auxautres, qui se déclinent en partant de ce modèle originel.

Sa notation trouve son origine dans les diagrammes de flux, transposés dans un environ-nement objet à l’aide de la notation des diagrammes de cas d’utilisation. Cet environne-ment fait apparaître :

• les acteurs (figure 2-2) qui interagissent avec le système d’information. Le formalismeutilisé transparaît ci-après ; il distingue les acteurs internes ou intervenants métier et lesacteurs externes ou acteur métier UML. Dans l’exemple de la figure 2-6, le Passager etle Service de police sont des acteurs externes, alors que l’Agent commercial y est unacteur interne. Cette catégorisation, bien que possible en UML, n’est pas systématique.De nouveaux stéréotypes d’acteurs pourront être ajoutés afin de couvrir des besoinsspécifiques, comme cela sera montré dans le cadre de certaines études de cas ;

• les fonctions assurées par le système d’information ou processus, qui définissent les casd’utilisation (figure 2-3) de ce système, par exemple Réservation (de billets d’avion),Annulation (d’une réservation), Enregistrement (d’un passager, via un agent commer-cial), Contrôle (via le service de police), etc. Chacune d’elles peut être décomposée etun indice (ou un identifiant) la situe dans sa hiérarchie de décomposition. Un tel indicese révèle très utile dans le cadre d’un projet réel dont il facilite le suivi, quand bienmême il ferait l’objet d’une gestion manuelle. Ces fonctions font appel au graphismeprésenté ci-après ; elles constituent la forme initiale des services ou méthodes qui fontpartie des principes communs aux orientations objet ; elles peuvent aussi être repré-sentées sous une forme simplifiée décrite par la figure 2.3b. Cette forme sera exploitéele plus souvent lors d’une énumération des processus qui ne fait pas appel aux acteursou aux ressources évoquées ci-dessous.

Figure 2-2

Les conventions graphiques de représentation des acteurs Acteur externe Acteur interne



19

• les ressources informationnelles (figure 2-4) ou (ébauches de) classes exploitées par lesfonctions du système d’information, telles que les RESERVATIONS, les VOLS ou (la listedes) PASSAGERS. Elles font appel au graphisme présenté ci-après :

• les flux échangés entre les acteurs et les fonctions du système d’information, ou entre cesdernières et les ressources ;

• ces flux sont représentés comme une flèche entre l’émetteur et le récepteur (figure 2-5a) ;

• ils peuvent être échangés :

– entre acteurs externes ou internes et un processus du système d’information,– d’un acteur externe vers un acteur interne, et réciproquement, – entre processus,– entre processus et ressources informationnelles ou ébauches de classe,

toutes situations qui font appel aux conventions graphiques présentées ci-après (figure 2-5b) :

• ces flux constituent la forme initiale des messages entre objets.

Figure 2-3a.

Un processus ou un cas d’utilisation

Figure 2-3b

Représentation simplifiée d’un processus

Figure 2-4

Représentation d’une ébauche de classe

Figure 2-5a

Représentation de flux

Figure 2-5b

Représentation de différents flux dans un processus ou un cas d’utilisation

n.n. PROCESSUSn.n. : indice de localisation

ou identifiant du processus

n.n. PROCESSUS

CLASSE

Acteur externe Acteur interne

n.n. PROCESSUSCLASSE



Par convention, un flux orienté vers l’ébauche de classe est équivalent à un message decréation ; une flèche de la classe vers le processus est quant à elle équivalente à uneconsultation et une flèche dans les deux sens équivaut à une consultation suivie d’unemise à jour.

Un exemple de modèle des besoins est fourni ci-après (figure 2-6). Il porte sur la gestiondes Passagers et sur différentes fonctions associées (Réservation, Enregistrement, Annu-lation, Contrôle) et fait appel à différents acteurs (Passager, Agent commercial, Servicede police), internes ou externes. Seuls certains flux sont explicités.

Figure 2-6

Un exemple de modèle de besoins

Service de police

Passager

Agent commercial1.1.

RÉSERVATION

VOLS

1.2.ENREGISTREMENT

1.3. ANNULATION

1.4. CONTRÔLE

PASSAGERS

Demande d'enregistrement

Nom PassagerInfos confort

InfosPassager

InfosPassager

RESERVATION

Confirmation deréservation

Demande de réservation

Infos Passager

Vols et Tarifs

Demanded'annulation

infos sur le vol

Nom PassagerN˚ Vol

Confirmation de réservation



21

Modèle de classes et d’objets

Le modèle des classes et des objets décrit les objets persistants du système d’information.Chaque type d’objet sera répertorié selon ses attributs (simples ou complexes), ses opéra-tions et un ensemble de règles contrôlant son intégrité ou son cycle de vie. Ce dernier estponctué par l’arrivée d’événements qui sont la cause de ses changements d’états prédéfinis.Ces événements sont représentés dans des règles actives. C’est surtout ce modèle des classeset des objets qui exploite les principes communs aux orientations objet rappelés dans lasection précédente. Il fait appel aux conventions graphiques des diagrammes de classes,des diagrammes d’objets et des diagrammes de collaboration.

Fondements

Le modèle des objets utilise à des fins de structuration le formalisme entité-association,tel qu’il est mis en œuvre par les diagrammes de classes et d’objets. Ce formalisme cons-titue l’un des points de consensus entre les différentes méthodes, méthodes purementsystémiques ou méthodes de conception orientées objet. Un tel modèle tire parti del’enrichissement des règles de modélisation, de l’introduction de nouvelles variétés decontraintes (contraintes de spécialisation, d’agrégation et contraintes portant sur le cyclede vie des objets).

De ce fait, les règles de gestion ou les règles techniques propres au système d’informationsont réellement prises en compte. Un tel modèle a vocation à exprimer la sémantique desinformations manipulées et des objets qui en découlent. Il est à remarquer que, dans cequi suit, afin de simplifier un tel modèle, nos attributs ne sont pas typés, facilité que UMLautorise.

Conventions graphiques utilisées

Pour la représentation du modèle des classes, les conventions suivantes sont utilisées.

Le nom des classes est en capitales, le nom des attributs est en minuscule, avec une première lettre majuscule.

Le nom des associations ou des rôles est marqué en italique avec une première lettre majuscule. Autant quefaire se peut, à ce rôle ou à cette association est associé un verbe sous une forme active ou passive.

Les identifiants des classes et des associations sont préfixés par #.

Le nom des méthodes est en italique, suivi des symboles ().

Comme il est habituel en UML, le nom des instances de classes, c’est-à-dire des objets, est souligné.



Classes, objets, attributs

Ce modèle repose sur l’utilisation :

• d’attributs ou informations liées à l’un des objets exploités par le système d’information.Ces attributs peuvent être élémentaires ou atomiques (le Nom, l’Age), structurés (commel’Adresse) ou multivalués (une Personne peut avoir plusieurs Prénoms ou plusieursNuméros de téléphone) ;

• de classes ou description formelle de l’un de ces objets, en termes d’attributs mais aussi decomportements élémentaires et de contraintes propres à ces derniers ;

• d’associations ou lien sémantique entre plusieurs des objets du système d’information, cesdernières se traduisant éventuellement en des classes associatives.

Un modèle de ce type a pour vocation de préciser la sémantique des informationséchangées au travers du système d’information. Il ne permet pas en tant que tel la priseen compte d’une organisation des données particulière. Il est en général traduit en unmodèle relationnel, organisation de données parmi les plus courantes, standard de laprofession pour lequel de nombreux logiciels ou SGBD sont disponibles, tant surmicro-ordinateurs que sur des ordinateurs plus conséquents. Ce modèle relationnel estle standard de fait de l’organisation des données. Très simple et trop permissif, il nepeut être utilisé en tant que tel pour traduire la sémantique des données, d’où le détourindispensable par un modèle sémantique. Une telle organisation peut être supportée pardes serveurs-concentrateurs ou des postes clients. Des règles simples de passage d’unmodèle conceptuel à un modèle relationnel ont été définies. Ainsi entités et associa-tions se transforment-elles en tables relationnelles. Les autres contraintes sont traduitesen des dépendances entre clés présentes dans les différentes tables. Certains SGBDgèrent les contraintes de cycles de vie comme des procédures enregistrées, déclenchéeslors des créations, des mises à jour ou des suppressions de données. Ces différentesactions peuvent alors être assimilées aux événements et actions que nous avonsévoqués plus haut.

Le modèle des objets que nous exploitons se situe au confluent des orientations objet(dont il reprend les principes communs) et des orientations données. Ces dernières setraduisent ici par l’usage d’un identifiant sémantique associé aux classes. Leurs attri-buts présentent une dépendance pleine et directe par rapport à cet identifiant. De cefait, bien que l’usage d’attributs multivalués soit possible en UML, le modèle obtenuest en troisième forme normale, au sens de la théorie relationnelle. Les classes définiessont optimales, non fragmentées, et minimisent les créations, les mises à jour ou lessuppressions, par là même les performances des bases de données associées à des finsde mémorisation de l’état des objets. Selon les principes communs aux orientationsobjet, les objets sont certes identifiés, à l’aide d’un oid (object identifier), mais cedernier n’a aucune sémantique et n’est qu’un repère de ces objets, qui est notammentexploité pour leur adresser des messages.



23

Les classes sont identifiées, ce qui n’est pas habituel mais permis dans un diagrammede classes. Un ou plusieurs des attributs d’une classe constitue(nt) son identifiantsémantique. Une concaténation des identifiants des classes participantes constituequant à elle l’identifiant d’une association. Ce dernier peut être complété par un attri-but propre à l’association. La démarche consiste donc à identifier tout d’abord uneclasse comme une entité (ou respectivement comme une association), avant que desméthodes ne lui soient associées.

Multiplicités

La figure 2-7, que l’on vient de présenter, fournit un exemple de représentation de classesdans laquelle apparaissent des contraintes de cardinalités ou multiplicités, contrainte surrôle, qui est classique dans le modèle entité-association servant de soubassement aumodèle de classes. Cette représentation permet de répondre à la question suivante : étantdonné ici une instance de l’association Achat, combien de PERSONNES, qui y jouent lerôle d’acheteurs, met-elle en jeu ? : 1 et 1 seule, combien de Magasins peuvent-ils jouerle rôle de vendeurs : 1 à 1 seul, combien d’Articles, qui jouent le rôle d’objet de l’Achat,sont-ils impliqués ? Réponse : plusieurs.

Il est bon d’insister sur le caractère plus ou moins général des multiplicités dégagées.Une multiplicité est toujours associée au rôle d’un objet. Il est possible de dégager unecontrainte très générale de ce type, et par là même un modèle de portée maximale. Ons’intéressera alors à tous les objets d’une même classe, aussi bien à ceux qui jouent ce

Figure 2-7

Un modèle de classes

#Nom_MagasinAdresse_Magasin

MAGASIN

#Num_ArticleDésignationQuantité dispo.

ARTICLE

#PersonneNomDate_de_naiss.AgeTéléphone[1+]

Fournir_Nom()Calculer_Age()Age[18..65]

PERSONNE

Achat

Objet1+

Vendeur1

Acheteur1

Prix

Attribut

Attribut multivalué

Comportement

Contraintes



rôle qu’à ceux que ne le jouent pas ou pas encore ! Cela sera repéré par une multipli-cité minimale de 0, afin d’englober les objets qui ne jouent pas le rôle. D’une manièreplus courante, il est possible de s’intéresser à une vue particulière du modèle défini,portant par exemple sur les seuls objets qui jouent le rôle considéré. La multiplicitéminimale sera alors de 1, comme pour ARTICLE dans la figure 2-7, plus haut. Il estenfin possible de s’intéresser à un exemple d’objet, afin de dégager la configuration desobjets qui participent au rôle de l’objet choisi, ce dernier devenant en quelque sorte lecentre du modèle. Un objet de ce type sera repéré par une multiplicité unique de 1,comme MAGASIN dans la même figure. UML exploite tout particulièrement lesdiagrammes de classes à ces fins d’explicitation, usage auquel nous nous rallierons leplus souvent dans nos différentes études de cas. Une utilisation différente des multi-plicités sera explicitée le cas échéant.

En outre, relativement à ces multiplicités, un sens de lecture est toujours sous-entendu. Al’objet central est associé un rôle actif, alors que le (ou les) autre(s) rôle(s) font appel àdes verbes au passif.

Les classes comprennent :

• les attributs qui leur sont propres,

• le comportement auquel les autres objets peuvent faire appel au travers de méthodes, selondes modalités d’exploitation particulières (méthodes privées, méthodes publiques, méthodessemi-publiques), chacune d’elles accompagnées des paramètres correspondants.

Associations

Les associations si elles ne sont pas porteuses d’attributs ou de méthodes ne sont repré-sentées que par une liaison entre classes. En revanche, si elles sont porteuses d’attributsou de méthodes, elles sont complétées par une classe associative, comme ci-avant Achat.PERSONNE, classe complète, comprend des attributs, un comportement traduit par deuxméthodes et une contrainte sur l’âge. Téléphone y est un attribut multivalué dePERSONNE, comme l’indique la multiplicité associée, ici 1+. Par différence avec unattribut simple, à un attribut multivalué est associé un ensemble de valeurs, en lieu etplace d’une valeur unique.

Des formes plus élaborées de classes peuvent être exploitées. L’exemple décrit par lafigure 2-8 est celui d’une facture de réparation d’un véhicule. Y apparaissent les classesFACTURE, ARTICLE, VEHICULE, CLIENT ; ainsi que différentes associations.

Parmi elles, l’association LF (Ligne de facture), à laquelle est associée la classe associa-tive porteuse des attributs Qté et MontLigne et de la méthode Calcul_MontLigne(). LFest associée à ARTICLE, alors que FACTURE entre dans une association n-aire avecCLIENT et VEHICULE, via l’association Concerne. A cette association est liée uneclasse associative CONC, porteuse de la méthode Créer_concerne().[]



25

Collaboration entre objets et messages structurels

Un diagramme de collaboration peut préciser les messages qu’échangent les objets.Ainsi l’objet FACTURE demande-t-il à la classe LF de créer les différentes lignes defacture. A leur tour, chacune d’elles prend connaissance de la quantité disponible et duprix unitaire de chacun des ARTICLEs. A la suite de quoi, FACTURE demande commu-nication des différents montants Ligne. Enfin, FACTURE demande la création d’uneinstance de l’association Concerne, via la classe associative associée. Les différentsmessages peuvent être étiquetés afin d’en préciser l’ordre d’émission. Ainsi, dans lediagramme de collaboration de la figure 2-9 ci-après :

1. les lignes de factures LF sont créées,

2. chacune d’elles prend connaissance de la quantité disponible (QtéDispo) del’ARTICLE qui lui correspond, en vue d’une confrontation avec la Quantité (factu-rée),

3. puis de son prix unitaire Prix U, afin de calculer le Montant Ligne (MontLigne),

4. ces Montants Lignes sont alors exploités par la FACTURE en vue de calculer lemontant total (MonttTotal) de cette FACTURE,

Figure 2-8

Le modèle objet d’une facture de réparation

#FactureDateMonttTotal

CalculMonttTotal()EditerFacture()

FACTURE

1+

Concerne

#ClientNomPrénom[1+]

CLIENT

#VéhiculeMarqueEtat

Fournir_état()

VEHICULE

1+Porte sur

#ArticleDésignationPrixUQtéDispoFournir_PrixU()Fournir_QtéDispo()

ARTICLE

MontLigneQuantité

CalculMontLigne()

LF



5. la FACTURE ainsi constituée est alors associée à une instance de CONC, lien avecun CLIENT et un VEHICULE.

Il est possible de conférer à un tel diagramme de collaboration une sémantique plus forteque celle qui est habituelle en UML.

Hiérarchies

Dans un modèle de classes, il est aussi possible de spécifier des hiérarchies de spécialisationet des hiérarchies de composition, en utilisant l’un des principes communs aux orientationsobjet.

Ainsi, dans cette figure 2-10a, un VEHICULE (entité générique) peut-il être un CAMION,une VOITURE ou un BUS, où Matricule et Marque sont communs aux différentes spécia-lisations CAMION, VOITURE, BUS. De plus, il est possible de faire ressortir si l’ensem-ble des spécialisations est en disjonction (comme ci-après), ou, au contraire, si certainesspécialisations sont en intersection. Si l’on rajoutait la spécialisation VEHICULE UTILI-TAIRE, un VEHICULE pourrait être spécialisé à la fois en VOITURE, en CAMION et enVEHICULE UTILITAIRE.

En accord avec les principes communs présentés au chapitre 1, il est aussi possiblede définir des métaclasses ou classes abstraites. Contrairement aux classes pourlesquelles les instances sont des objets, les métaclasses s’instancient en d’autres classes.

Figure 2-9

Une collaboration entre Facture et ses différents composants

FACTURE

Fournir_PrixU()Fournir_QtéDispo()

ARTICLELF

1:[1+]Créer_LF()

2:QtéDispo ?3:PrixU ?

4:[1+] MontLigne ?

Créer_concerne()

Concerne

5:Créer_Concerne()

Collaborations structurelles et collaborations contextuelles

Les collaborations structurelles sont liées à la nature des objets, alors que les collaborations contextuelles, rela-tives à une utilisation particulière des objets, relèvent de la description d’un scénario, représenté à l’aide d’undiagramme de séquence ou d’un diagramme d’activité. Chaque message échangé correspond à une demandede service (à une méthode) particulière.



27

Figure 2-10a

Une hiérarchie de spécialisations

Figure 2-10b

Hiérarchie de définitions

#VéhiculeMarqueTypePuissance

VEHICULE

VOITURE

CatégorieNbPassagers

BUS

PoidsLongueurChargeUtile

CAMION

entitégénérique

entitésspécialisées

#PersonneNomAdresseTéléphone[1+]

Fournir_Nom()Fournir_Adresse()

PERSONNE

CLIENT REPRESENTANT EMPLOYE

MARTIN DURAND



Une hiérarchie de spécialisation d’attributs et de valeurs sera ainsi représentée, selon lesconventions de la figure 2-10b, où Personne est une métaclasse (une classe abstraite),CLIENT, REPRESENTANT, EMPLOYE, des classes instances de PERSONNE, MARTINet DURAND des instances de client.

Certaines classes peuvent aussi être composées. Ainsi, chaque VEHICULE (figure 2-11)est vu comme une composition de ROUES (de 4 à 6), de CHASSIS et de MOTEUR. Cedernier, à son tour, peut être décrit comme la composition d’un vilebrequin, de cylindreset de pistons, décomposition qui n’est pas représentée ici.

La multiplicité du composé par rapport au composant peut aussi intervenir, commec’est habituellement le cas dans UML. Un losange blanc traduit une appartenanceexclusive d’un composant à son composé, un losange noir une appartenance multiple àplusieurs composés.

Des contraintes sur les cycles de vie d’objets peuvent aussi être précisées. Elles indiquentles contraintes de transitions d’état (ou de valeur) associées à l’attribut d’un objet. Ellessont déterminées par les valeurs discrètes et successives prises par l’attribut d’une classe,suite à une succession d’événements. Par exemple, un des cycles de vie pesant sur laPersonne peut prendre la forme :

• Lors naissance(pi) Alors statut(pi):="enfant"; enregistrer(pi) ;

• Lors anniversaire(pi) Si 10<âge(pi)<18 Alors statut(pi):="adolescent" ;

• Lors anniversaire(pi) Si 18<âge(pi)<65 Alors statut(pi):="adulte" ;

• Lors anniversaire(pi) Si 65<âge(pi) Alors statut(pi):="retraité" ;

indiquant qu’une Personne naît « enfant » et qu’elle est enregistrée dans cet état, au traversde la mémorisation d’une valeur de son statut ; et, par ailleurs, que sur un même événement« anniversaire », selon son âge, elle peut prendre l’un des plusieurs statuts possibles.

Figure 2-11

Une hiérarchie (partielle) de composition

VEHICULE

ROUES CHASSIS MOTEUR

4..6 1 1



29

Graphiquement (figure 2-12), ces cycles de vie font appel aux conventions des diagrammesétats-transitions. L’état enfant y est vu comme initial, l’état retraité comme final. Lestransitions sont décorées par des conditions appropriées.

Modèle des processus

Généralités

Le modèle des processus est un ensemble de modèles qui correspond à différents niveauxde représentation du SI (système d’information). A chacun de ces niveaux, une unité detraitement (voir figure 2-13) est définie. Elle correspond à un cas d’utilisation du SI, enri-chi de concepts supplémentaires. Sa spécification exploite un réseau de Petri. Au niveaude représentation le plus fin, chaque unité de traitement correspond à une transaction (ausens base de données) définie à l’aide des opérations élémentaires attachées aux objets.L’enchaînement de ces opérations est vu comme un scénario agissant sur des objets, quiest décrit par un réseau d’événements et de résultats où les transitions représentent lesopérations de transformation. Un tel réseau exploite exclusivement la communication parmessages. De nombreux scénarios peuvent être élaborés pour réaliser la même transac-tion. Ce concept de scénario, ou son équivalent, se retrouve dans la plupart desdémarches à base d’objets. La représentation de ces scénarios exploite les conventionsgraphiques des diagrammes de séquence et des diagrammes d’activité.

Ce modèle décrit les traitements qu’une application souhaite réaliser sur les objetsdéfinis. Il est constitué d’un ensemble de fonctions qui interagissent, éventuellement, lesunes avec les autres, celles qui apparaissent dans le modèle des besoins. Plusieursniveaux de représentation canoniques permettent de représenter ces interactions : (i) leniveau du système qui décrit les interactions entre différentes fonctions, (ii) le niveau dela fonction, (iii) le niveau de la transaction qui décrit les interactions entre objets à traversles messages qu’ils s’échangent. Un dernier niveau, l’opération ou l’action élémentaire,décrit le niveau le plus fin d’action sur un objet ou sur une donnée. Lui correspondent destraitements de type saisie, calcul, affichage, sélection, etc. Le passage d’un niveau à unautre constitue un raffinement des concepts du niveau supérieur.

Figure 2-12

Un cycle de vie représenté comme un diagramme états-transitions enfant adolescent

adulteretraitéâge > 65

âge < 18

âge > 18



Unités de traitement

Synchronisation, précondition

A chaque unité de traitement est attachée une synchronisation sur événements quiprécise la condition de son déclenchement, condition combinant un ou plusieursévénements, selon une expression logique. Cette combinaison peut aussi spécifierl’ordre d’arrivée des événements (séquentiel ou simultané), le délai entre deux événe-ments, et éventuellement le nombre d’occurrences de chaque type d’événement quidoivent être présentes. Ces informations apparaissent alors comme un décor de lasynchronisation.

Un même type d’événement peut participer au déclenchement de plusieurs unités de trai-tement différentes. Dans certains cas, plusieurs instances d’un même type d’événementsont impératives.

Bien que chaque unité de traitement corresponde à un cas d’utilisation antérieur, certainesd’entre elles peuvent constituer un raffinement extrémal non pris en compte par undiagramme antérieur de cas d’utilisation.

Figure 2-13

Une unité de traitement

Précondition et/ousynchronisation

résultat 1

résultat 2

Postondition

n.n. Unité de traitement

événement 1 événement n

événement 1



31

L’unité de traitement bénéficie entre autres valeurs ajoutées de la synchronisation.Cette dernière sera réexploitée par les différents scénarios, sous forme de conditionpesant sur l’envoi des messages. Elle est incluse sous une forme classique en UMLdans la figure 2-13. Sauf précision contraire, il lui est associé un prédicat et sur lesdifférents événements contributifs.

Une précondition peut faire parti de la synchronisation d’une unité de traitementsous la forme d’une expression logique susceptible de comporter deux types deconditions :

• des conditions sur les attributs des événements déclencheurs ;

• des conditions sur l’état courant de certains objets du système d’information. Ellescorrespondent alors à une partition des objets du modèle à une spécialisation sur critère(exemple : le sous-ensemble des assurés ayant moins de 5 ans de permis) à laquelle sontassociés des traitements ou des règles de gestion particuliers.

Postcondition

La postcondition est-elle aussi une expression logique qui décrit les conditions determinaison de l’unité de traitement, de production de certains résultats. Cetteexpression peut être simple (porter sur un seul événement) ou complexe (porter surplusieurs événements). Elle peut aussi consister en une vérification de la compatibi-lité de l’état de certains objets, eu égard à certaines règles. La partie supérieure de lapostcondition fait ressortir la ou les (post)conditions proprement dites, et la partieinférieure les actions qui produisent les résultats (changement d’état d’un objet,création d’un objet).

La postcondition peut revêtir plusieurs formes distinctes :

• Il peut s’agir d’une travée condition-action, comme celle qui est représentée figure 2-13.Ces travées sont alors indépendantes les unes des autres.

• Il peut s’agir d’une forme n conditions – 1 action (voir figure 2-14, partie a).

• Il peut s’agir d’une forme 1 condition – n actions (voir figure 2-14, partie b). Une formeparticulière en est la condition (plutôt l’absence de condition) toujours.

• Les conditions peuvent enfin être combinées à plusieurs niveaux, formant un arbre deconditions.



La figure 2-14 fournit la représentation graphique de ces différentes possibilités. Ellessont exploitées par quelques études de cas.

Cette postcondition constitue un complément à la description d’un cas d’utilisation qui,le cas échéant, pourra être représenté graphiquement, comme dans la figure 2-14, oucomme un commentaire, un décor, accompagnant la description d’une unité de traite-ment. Ce commentaire pourra faire usage de la forme si condition alors action, formedéjà rencontrée lors de la prise en compte des cycles de vie.

Evénements

Les synchronisations exploitent les événements alors que les postconditions produisentdes résultats qui peuvent devenir des événements pour d’autres unités de traitement. Unévénement est un message (au sens des principes communs aux orientations objet rappe-lés dans le chapitre 1) ou un signal reçu par une unité de traitement (un système, unefonction, une transaction ou un objet.)

Parmi les événements, on distingue ceux qui proviennent de l’extérieur du système d’infor-mation (événements externes) et ceux qui circulent à l’intérieur du SI (événements internes).

Parmi les événements externes, on distingue les événements temporels et les événementsémis par d’autres agents externes ou événements métier, correspondant à la finalité d’undes processus métier. Parmi les événements internes, on distingue ceux qui sont émis pardes objets et ceux qui le sont par les opérations (événements de synchronisation). Demême, parmi les événements émis par les objets, distingue-t-on deux catégories : lesdemandes de services (messages à d’autres objets) et la notification d’état (création,suppression, modification). L’événement ici évoqué est aussi celui qui est susceptibled’intervenir dans un cycle de vie.

La figure 2-15 présentée ci-après résume les différentes classes et sous-classes d’événe-ments auxquels il est possible de faire appel. Cette hiérarchie large d’événements contri-bue d’une part à assurer la traçabilité des éléments du système d’information et d’autrepart permet d’assurer la construction du système sans rupture et avec une continuitétotale, du niveau le plus abstrait à celui de l’implantation effective.

Figure 2-14

Différentes postconditions

résultat 1

n conditions

1 action résultat 1 résultat 2

a) n conditions - 1 action b) condition toujours - n actions



33

Les études de cas présentés exploitent la plupart de ces types d’événements, à l’exceptiondes événements système. Nous les avons néanmoins mentionnés pour illustrer la géné-ralité du concept d’événement exploité.

Niveaux de décomposition canoniques

Pour représenter un système simple, quelques niveaux de décomposition suffisent. Pourdes systèmes plus complexes, il est utile de proposer des niveaux canoniques permettantde repérer certaines représentations. La figure 2.16 propose une telle hiérarchie dedécomposition. Y apparaissent :

• le domaine fonctionnel ou regroupement d’un ensemble d’unités de traitement propres à unmétier ou tout autre regroupement fonctionnel bornant un champ d’étude, éventuellementdécomposé si besoin est en sous-domaines ;

• l’activité ou unité de traitement centrée sur les échanges avec un acteur externe, elle aussiéventuellement décomposée ;

Figure 2-15

Hiérarchie des événements exploitables

Evénement

Validation

Evénementexterne

Evénementinterne

Evénementtemporel

Evénementmétier

Evénementtemporel

organisationnel

Messaged'objet

Evénementorganisationnel

Notification derésultat

Evénementsystème

Evénementd'interface

Autorisation

Débuttransaction

Fintransaction

Annulation

Créationd'objet

Suppressiond'objet

Changement d'état d'un objet

Interdiction



• la tâche ou unité de traitement centrée sur un acteur interne, décomposée éventuellementen sous ;

• l’action ou unité de traitement liée à un objet, aussi appelée méthode.

La plupart de ces niveaux seront exploités par les différentes études de cas.

Scénarios

L’aboutissement du modèle de processus est le scénario qui décrit un ordonnancement desmessages échangés entre les objets du modèle conceptuel, scénario qui constitue l’équiva-lent d’un programme informatique dans un environnement non objet. Ce scénario fait appelaux conventions graphiques des diagrammes de séquence. Il dégage :

• l’acteur interne ou externe, origine ou destinataire d’un événement/ résultat ;

• l’événement dont il est la source ou la destination ;

• la condition qui pèse sur l’envoi d’un message d’action, condition qui a été explicitée anté-rieurement par la description des processus ;

Figure 2.16

Niveaux de décomposition canoniques

Domaine fonctionnel

Sous-domainefonctionnel

Activité

Sous-activité

Tâche

Sous-tâche

Action



35

• l’action qui ici ne peut revêtir que la forme d’un message à un objet ou à une classe, selonla nature du déclenchement souhaité ;

• l’objet ou la classe cible du message.

Les différents types de scénarios font appel aux conventions graphiques des diagrammesde séquence ou à celles des diagrammes d’activité avec travées. Trois types de scéna-rios peuvent être définis, à savoir des scénarios d’activités (A-scénarios), des scéna-rios de tâches (T-scénario) et enfin des scénarios de dialogue ou D-scénario. Deuxexemples de T-scénario complémentaires sont fournis par les figures 2-17a et 2-17b.

Le premier (figure 2-17a ci-dessus) est déclenché par une demande de récupération devéhicule émise par un Client et transmise via le Garagiste. Un message demandant lacréation de la Facture est émis à destination de la classe (l’objet n’existe pas encore).L’état du véhicule est alors vérifié – il doit être dispo(nible). Cette condition aura faitpartie au préalable de la description d’une unité de traitement. Une facture est émise ettransmise au Client.

Figure 2-17a

Premier exemple de T-scénario

Client

Garagiste

Demande

Facture

Demande

#Véhicule

Fournir_état()état[dispo, dispo]

VEHICULE

Dde état

MontTotF

Créer_Facture()CalculerMontTotF()Editer_Fact()

FACTURE

Véhicule dispo

Véhiculedisponible

Facture

Véhiculedisponible



Un paiement est alors effectué par le Client via le Garagiste (événement). Son montantest rapproché du montant de la facture. En cas d’identité, il y a création d’un Paiementvia un message à la classe correspondante. Cette seconde partie du même scénario estdécrite par la figure 2-17b.

Ces scénarios exploitent la communication par message, l’un des principes communsaux objets. Les demandes de service qui y sont exploitées sont très simplifiées dans lamesure où le contexte de l’appel est défini par la sémantique des objets. Les paramètresd’appel sont ainsi moins nombreux, nombre d’entre eux étant définis, factorisés, dansle modèle objet. Le gros des effets d’un scénario est ainsi obtenu au travers des classesinvisibles d’un scénario (liés à la structure d’un objet) qui sont décrites par undiagramme de collaboration, tel celui de la figure 2-9 plus haut. De ce fait, aucun deces éléments n’a à figurer dans un scénario, ce dernier ne devant faire apparaître que leséléments propres à son contexte. Une telle approche renforce l’aspect systémique detout objet qui est à même d’exploiter les attributs de son environnement immédiat, lesobjets auxquels il est associé.

Une autre représentation possible des scénarios repose sur l’exploitation des diagrammesd’activité avec travée. La figure 2-17c décrit la première partie du T-scénario présentéeplus haut, à l’aide d’un tel diagramme, où les travées correspondent aux acteurs, àl’objet et à la classe impliqués. On notera qu’il est fait usage d’un prédicat sur l’état duVEHICULE et sur le statut de la FACTURE.

Figure 2-17b

T-scénario 2nde partie

Client

Garagiste

DemandePaiement

MontTotF

Fournir_MontTotF()

FACTURE

Paiement reçu

MontantP

CréerPaiement()

PAIEMENT



37

Modèle d’architecture de la solution

Généralités

L’objectif du modèle d’architecture est double. Il s’agit tout à la fois de préciser les fonc-tions automatisées, la nature des des fonctions développées et les préoccupations asso-ciées (organisationnelles – sites -, logicielles, matérielles) et la localisation de leurs utili-sateurs. Il s’agit aussi de faire clairement ressortir la nature des ressources utilisées. Endernier lieu, les solutions techniques disponibles doivent être précisées, ainsi que leursavantages et inconvénients.

Le modèle d’architecture tire parti des composants des autres modèles (modèle desbesoins, modèle des objets, modèle des processus).

Il fournit des éléments de réponse à une très grande variété de préoccupations, qui vontdes modalités d’interconnexion d’équipements, distribués ou non, jusqu’à l’utilisation defonctions et de ressources d’un système d’information, local ou réparti. Il prend encompte l’ensemble des éléments constitutifs d’une architecture, éléments relevant detrois types d’architecture décrits par la figure 2-18 ci-après, à savoir :

• une architecture fonctionnelle dégageant les différentes fonctions exécutées par le systèmed’information automatisé, en liaison avec celles qui sont représentées par le modèle desbesoins à l’aide de diagrammes des cas d’utilisation ;

Figure 2-17c

Début d’un T-scénario représenté à l’aide d’un diagramme d’activité avec travées

Client Garagiste

VEHICULE FACTURE

Demande Demande état

Véhiculedispo

CréerFacture()

CalculMontTotF()

Editerfacture()

FACTURE crééeFACTURE



• une architecture organisationnelle précisant les sites d’utilisation des fonctions du SI, lesacteurs impliqués et leurs prérogatives ;

• une architecture opérationnelle traduite à son tour en :

– une couche application identifiant les fonctions à implanter, sous la forme de sous-programmes, de modules représentant le corps de méthode d’une classe,

– une couche informatique précisant les différents logiciels exploités, aussi bien lesserveurs et clients logiciels que les protocoles de communication (Corba, Java-beans), couche qui inclut par extension tout le logiciel non développé par un projet,

– une couche infrastructure précisant à son tour les différents équipements physiquesconnectés, processeurs, serveurs et clients physiques, etc.

Quelques nouveaux stéréotypes sont proposés pour couvrir l’ensemble des besoins demodélisations, stéréotypes qui compléteront ceux exploités par le diagramme des casd’utilisation, le diagramme d’activité, le diagramme de composant et le diagramme dedéploiement.

Un concept central du modèle d’architecture : l’URF

La couche organisationnelle fait appel à de nouveaux éléments qui permettent dedétailler les acteurs de l’organisation et leur localisation. Elle précise en outre quelssont les utilisateurs des différentes fonctions du système d’information. Elle s’appuie

Figure 2-18

La hiérarchie des composants d’une solution

ARCHITECTURE

ARCHITECTUREFONCTIONNELLE

ARCHITECTUREOPERATIONNELLE

ARCHITECTUREORGANISATIONNELLE

COUCHEAPPLICATION

COUCHEINFORMATIQUEet MIDDLEWARE

COUCHEINFRASTRUCTURE



39

sur l’organigramme fonctionnel de l’entreprise, ou sur l’existence d’un ensemble departenaires coopérants. Cet ensemble est décomposé, dans un premier temps, en unitésde responsabilité fonctionnelles ou URF. Leur description peut faire appel le caséchéant à un ensemble de ressources informationnelles. Elle s’appuie sur les conventionsgraphiques du regroupement UML ou paquetage.

Ces URF sont proches des « unités métier » (Business Unit) définies par le RUP, qui fontalors appel au graphisme de la figure 2-19 présentée ci-après.

Nous avons choisi d’utiliser le stéréotype de paquetage ou de regroupement, étiqueté parle nom de l’« unité métier », qui est plus simple. Il constitue l’une des occurrences de cestéréotype, d’autres peuvent se voir exploiter comme le montre la figure 2-20, où lepremier d’entre eux est indifférencié.

Figure 2-19

Une « unité métier »

Figure 2-20

Représentations de différents types de regroupement

REGROUPEMENT DE TYPE URF

URF

REGROUPEMENT DE TYPE SITE

S

REGROUPEMENT DE TYPE PROCESSUS

P

REGROUPEMENT



La mise en évidence des URFs repose sur l’examen :

• de l’organigramme fonctionnel d’une entreprise ou des partenaires coopérants,

• de la répartition des sites et des acteurs, en regard des fonctions assumées,

• des relations fonctionnelles entre de telles cellules et des responsabilités associées.

La figure 2-21, présentée ci-après fournit, à titre d’exemple, l’organigramme simplifiéd’un service documentaire.

Il y a là une première représentation des modalités de communication de contexte local(les clients du système documentaire, le service des prêts, dans notre exemple) àcontexte global (le service des commandes et du maintien de la base de données docu-mentaire). Cette facette se plaque naturellement sur un modèle client-serveur, dont elleconstitue le complément. Ces unités se distinguent, pour certaines, par leurs ressourcespropres (bases de données locales) et par leurs ressources collectives (base d’entre-prise) auxquelles elles accèdent, selon des modalités (droits, prérogatives, confidentialité...)appropriées.

Chaque URF possède son propre système d’information détaillé, comprenant des activi-tés (A) ou des tâches (T), exploitées par ses acteurs internes et externes. Des prérogativesvariées peuvent être associées à différentes URF. Seules certaines fonctions peuvent ainsiêtre utilisées par une URF. Seules certaines tâches, liées à une même fonction, sontdisponibles pour une URF alors que la totalité d’entre elles l’est pour une autre URF. Unemême tâche peut faire appel à un ensemble d’actions légèrement différent pour une URFdonnée. Qui plus est, ces modalités portent aussi sur la nature des actions qui agissent surles objets manipulés par les fonctions (création, consultation, suppression).

Nous faisons figurer ci-après (figure 2-22) un exemple de couche organisationnelle liéeau système documentaire où apparaissent les trois URF déjà présentées. Remarquez queles processus y sont précisés en tant qu’activité (A) ou que tâche (T). Les flux de donnéesy sont en traits pleins noirs, les interactions avec les acteurs en traits pleins blancs.

Figure 2-21

L’organigramme d’un service documentaire

Site des clientsdu système documentaire

Service des prêts

Service des commandeset de maintien de la BDD



41

A chaque fonction d’une URF est associé un dossier ou ensemble des objets sur lesquelsla fonction est susceptible d’agir (création, consultation, mise à jour). C’est ce dossier quisert au maintien de l’intégrité des systèmes et des données. Toute modification d’unedonnée ne devient effective qu’après que la fonction locale a été exécutée et que seseffets ont été intégrés par le système d’information global (principe du commit, ou duchangement d’état, à deux phases ou à deux niveaux – local, global).

Des performances peuvent être définies au niveau du système d’information (nombred’occurrences de tâches à satisfaire, temps de réponse de l’unité de traitement requis ouprévu, volume de ressources d’un certain type, à prévoir ou disponible, etc.), qui est un

Figure 2-22

Trois URFs du système documentaire

Servicedes commandes

URFClient

Servicedes prêts

RESERVATIONPRÊT

Réservation

T

LECTEURS

Inscription

T

Demande de prêt

Recouvrementd'ouvrage

T

Retour d'ouvrage

Livraisond'ouvrage

Gestion descommandes

A

Consultation

A

Demanded'information

Prêt

A

Demanded'inscription

Base de donnéesdocumentaire



besoin non fonctionnel identifié par le modèle des besoins. Ces performances« détaillées » devront être compatibles, de manière descendante, du système d’informa-tion à l’infrastructure informatique. Pour faciliter l’étude des performances et les tests debon fonctionnement, des couplages standards sont définis entre les différentes couchesdu modèle : les fonctions liées aux URF sont couplées à des postes clients et à des postesserveur (couche informatique), ces derniers sont quant à eux liés à des processeurs(couche informatique détaillée), eux-mêmes supportés par des équipements et desmédias de communication (couche infrastructure). Certaines des prérogatives de l’URFpeuvent avoir trait aux accès fonctionnels sécurisés des services Internet, autre besoinnon fonctionnel. Parmi ceux-ci (SMTP, HTTP, DNS, FTP, Telnet), seuls certains pourraientêtre associés à une URF.

Il est à remarquer que ces URF ne sont qu’une des possibilités de regroupement. D’autressont exploitées par les études de cas (site ou regroupement de processeurs, unité d’exécutioncomme en UML, etc. comme déjà précisé).

La couche Application détaille les applications à développer, alors que la couche Infor-matique précise les logiciels réutilisés, les progiciels, le logiciel de base, les bus logiques– Corba – exploités, etc. Ces deux couches font appel au diagramme de composantsd’UML, tel qu’il apparaît dans la figure 2-23 ci-après. Un tel diagramme décrit deséléments logiciels et leurs relations dans l’environnement de réalisation ou d’exploita-tion. Ces éléments peuvent être des modules, des processus (informatiques), des tâches,des programmes principaux, des sous-programmes ou des sous-systèmes. Les dépendancesentre composants sont aussi représentées, entre A et B ici.

Des regroupements logiciels peuvent aussi être précisés.

Figure 2-23

Dépendance entre modules

A B

Figure 2-24

Un regroupement A des sous-systèmes B et C

A

B C



43

Ainsi le système A (figure 2-24), qui peut correspondre à la décomposition d’un proces-sus en programmes et sous-programmes, rassemble les sous-systèmes B et C, selon uncritère logique tel que l’unité de compilation ou d’exécution, voire l’appartenance à unemême URF.

La couche Infrastructure précise les éléments physiques constitutifs d’une solution,exprimée selon les conventions du diagramme de déploiement. Un tel diagramme montrela disposition de différents matériels (ou nœuds) qui entrent dans la composition d’unsystème physique. Il est fait usage de certains stéréotypes repérés par des guillemets(« »). La figure 2-24 fournit une illustration d’une telle couche.

Il est à noter que des stéréotypes plus variés seront exploités par différentes études de cas,en particulier par celle du chapitre 7.

La démarche d’élaboration des modèles exploitée par les études de cas

L’ensemble des études de cas exploitent une démarche similaire. Cette dernière reposesur l’utilisation des quatre modèles complémentaires (voir figure 2-1) présentés : lemodèle des besoins, le modèle des données, le modèle fonctionnel, aussi appelé modèledes processus ou modèle des traitements, et le modèle d’architecture. Il est fait usage dela décomposition décrite par la figure 2.16.

Figure 2-25

Une couche Infrastructure et ses différentes classes de matériels

Tx Serveur3

ServeurSGBD 1

Imprimante« Dispositif »

PCPilote

Porte*

Console« TCP/IP »

1

* « RNIS »

1maître

1..10



La démarche générale (voir figure 2-26) qui est mise en œuvre peut être synthétisée de lamanière suivante :

1. Un modèle Métier global est établi par prise en compte des acteurs externes princi-paux et des processus Métier, sous la forme d’un premier diagramme des cas d’utili-sation. Ce modèle Métier dégage ainsi les différents Métiers exercés par une mêmeentreprise.

2. Des modèles Métier détaillés sont produits, par prise en compte des acteurs externeset internes, des processus et des ébauches de classes. Chacun d’eux détaille l’un desmétiers exercés par l’entreprise.

3. Un modèle Métier de niveau Activité est proposé par prise en compte des interactionsavec un acteur externe.

4. Pour chacune de ces activités, les tâches correspondantes sont identifiées.

5. Un modèle Métier de niveau Tâche est proposé par prise en compte du détail d’uneactivité, centrée sur les interactions entre un acteur interne et un autre acteur externeou interne.

6. Les ébauches de classes sont complétées et enrichies sous la forme d’un modèle declasses et d’objets. L’évolution de ces derniers est précisée sous la forme d’un cyclede vie d’objets faisant appel à un diagramme états-transitions.

7. Un modèle de processus précise les conditions de déclenchement et la production dechacun des processus qui apparaissent dans le modèle des besoins. Chacun d’eux estensuite explicité sous la forme d’un scénario exploitant un diagramme de séquence.

8. Les différents modèles suscitent enfin la description de la solution fonctionnelle,organisationnelle, logicielle puis matérielle, ou modèle d’architecture qui exploite lesdiagrammes de cas d’utilisation, de composants fonctionnels, d’activités, lesdiagrammes de composants informatiques et les diagrammes de déploiement.



45

Figure 2-26

Noyau de la démarche de modélisation

ProcessusActeurs externes

Processus

ProcessusMétier

ProcessusMétier

détaillés

Processus

Activité1 acteurexterne

CLASSE

Processus

1 acteur interneet d'autres

acteurs

Tâche

CLASSEModèle desclasses et des

objets

Modèle desprocessus

et scénarios

Acteur

ProcessusCLASSE

Acteur interne

n acteursinternes et 1

externen Tâches

Acteur


3Société Amarilli

Principaux apports de l’étude de cas

L’étude de cas présente les fondements du modèle des besoins et ceux du modèle desdonnées, support du modèle de classes. Elle est aussi l’occasion d’un premier examende la dynamique des objets.

Relativement au modèle des besoins, nous utiliserons les concepts issus ou dérivés dela technique des diagrammes de flux de données – DFD (acteurs, flux, processus etébauches de classes, décomposition) – et nous exploiterons le diagramme des casd’utilisation.

L’examen du modèle des données nous permettra de revoir ses concepts clés issus dumodèle entité-association (attribut, entité, association, problématique de l’indexationdes entités et des associations).

Nous procéderons en dernier lieu à une première réflexion sur la dynamique desobjets, qu’elle se traduise par un cycle de vie d’objets textuel ou par un diagrammeétats-transitions UML graphique.



Présentation de l’étude de cas

Vous êtes chargé de réaliser le système d’information de la société Amarilli qui orga-nise des spectacles de différentes natures (théâtres, concerts, animations diverses). Onne s’intéresse qu’aux spectacles sur scène comprenant l’intervention d’un ou deplusieurs artistes interprètes. Ce système d’information repose entre autres sur troisobjets métier qui sont, respectivement, les acteurs, les pièces (de théâtre) et lestournées de représentation.

Les activités de la société sont principalement les suivantes :

• Produire un spectacle. Il s’agit de choisir une œuvre, d’embaucher les acteurs ou lesartistes pour l’interpréter, d’organiser toute la préparation (achat des droits d’auteur, répé-titions, acquisition des décors et matériels divers). Le choix de l’œuvre résulte d’une déci-sion interne à la société, tenant compte de facteurs tels que l’attente (supposée) du public,une commémoration (bicentenaire de la mort de Mozart, centenaire de la naissance deBrecht) ou une proposition d’un des directeurs artistiques.

• Diffuser un spectacle. Quand un spectacle est produit, il faut le vendre ! Cette activitécomprend en premier lieu la recherche de salles adaptées à une production. On s’adresseà des gestionnaires de salle auprès desquels on loue celle qui convient pour une périodedonnée.

La société Amarilli doit aussi s’occuper de tout ce qui entoure la représentation, de lalogistique du spectacle : réservation des transports, des hôtels, des restaurants, gestiondes déplacements, réceptions, etc.

• Gérer les artistes. Amarilli prend sous contrat certains artistes et gère leur carrière. Cettegestion consiste (i) à les inclure dans les spectacles organisés par la société ou à lesproposer à d’autres sociétés organisatrices ; (ii) à assurer leur promotion (passages dans lesmédias, publicité).

• Gérer les pièces. Beaucoup de spectacles de la société sont des pièces de théâtre. Ils’agit de pièces classiques dues à des auteurs reconnus ; des dramaturges grecs (Euri-pide, Sophocle), élisabéthains (Shakespeare, Ben Jonson), français (Molière, Racine,Corneille), contemporains (Brecht, Pinter, Weiss), voire des créations originalescommanditées par la société.

Une pièce est d’abord choisie, puis elle est mise en scène et les rôles sont attribués à desacteurs ; ensuite, cette pièce donne lieu à une première lecture et à des répétitions. Unepremière présentation en costumes est donnée (la couturière) ; s’ensuit une premièreprésentation publique (la générale), suivie d’un nombre variable de représentations.


Société AmarilliCHAPITRE 3

49

Une pièce de théâtre est composée d’un ou de plusieurs actes, eux-mêmes composésd’une ou de plusieurs scènes. Elle comprend un ensemble de personnages (au moins un)ou rôles, chaque personnage apparaissant dans au moins une scène.

Une pièce est donnée dans le cadre de représentations ou de tournées qui impliquent unensemble d’acteurs. Chaque personnage est interprété par un acteur, mais un acteur peutinterpréter plusieurs rôles, le plus souvent mineurs, comme c’est notamment le cas desstagiaires. D’autres artistes interviennent. Pour simplifier, on tiendra compte uniquementdu metteur en scène. Une représentation a lieu dans une salle. Une tournée comprend unensemble de représentations.

Enfin, une pièce est écrite par un et un seul auteur (on ne tient pas compte des créationscollectives).

Il vous est demandé de concevoir le modèle des besoins, en vous appuyant sur les grandesfonctions du SI, telles que gestion des acteurs, gestion des pièces, gestion des tournées,gestion de la logistique, etc. Ces fonctions seront ensuite décomposées jusqu’à un niveautâches. Vous exploiterez les conventions du diagramme des cas d’utilisation.

Le modèle des objets fera ressortir la sémantique des objets métier (acteurs ou artistes,pièces, représentations, tournées). Il vous est demandé en particulier :

• d’identifier et de spécifier (par leurs attributs) les principales entités qui caractérisent unepièce de théâtre et ses rôles ;

• de représenter l’association entre une pièce et un auteur, entre une pièce et ses rôles ;

• de représenter l’association (ou les associations) entre les entités pièce, acte et scène. Depréciser quelle est la particularité de ce type d’association et de leur représentation (parcomparaison avec les associations précédentes) ;

• on souhaite aussi savoir quel personnage intervient dans quelle scène (pour alimenter unmoteur de recherche spécifique sur Internet) : il convient de proposer un modèle. Si ondevait gérer le texte de chaque rôle, où le mettrait-on ?

• de proposer le modèle de la représentation d’une pièce. Où situer la date d’unereprésentation ? Où peut figurer l’attribut « Nombre de spectateurs » ?

• comment peut-on représenter l’association entre un auteur et ses descendants (héritiers) ?

De nouveau, vos réflexions sur la modélisation des données puis des classes serontconduites dans le cadre d’un modèle des objets qui exploite les conventions dudiagramme de classes UML.

Vous procéderez enfin à un examen de la dynamique des principaux objets. Les cycles devie de l’acteur, de la pièce puis de la tournée seront décrits avant que leurs interactions nesoient dégagées, en premier lieu à l’aide d’une notation textuelle, puis en utilisant undiagramme états-transitions UML.



Présentation des modèlesModèle des besoins

Le modèle global des besoins fait l’objet de la figure 3-1. Il s’agit d’un modèle métier quidégage les acteurs externes et internes (au sens des DFD) les plus structurants, à savoir : lesspectateurs, les acteurs externes et internes, les fournisseurs (ou prestataires de service), les« financiers », etc. Il précise ainsi le métier de l’entreprise concernée.

Les grandes fonctions du modèle des besoins font l’objet des cas d’utilisation présentésci-après. On y retrouve la gestion de chacun des grands objets mentionnés dans l’énoncé,à savoir :

• la Gestion des acteurs/artistes,

• la Gestion des pièces,

• la Gestion des tournées,

• complétée par une fonction de Gestion de la logistique.

La figure 3-2 présente la description de la fonction Gestion des acteurs qui met en jeul’Acteur, ainsi que les ressources informationnelles ou ébauches de classes ACTEUR,PIECE et ROLE.

La figure 3-3 présente celle de la fonction Gestion des pièces qui met en jeu le mêmeacteur externe et les mêmes ressources informationnelles que précédemment.

Figure 3-1

Le niveau métier du SI de la société

1.Système d'Information

de la société

Financiers

Spectateurs

Acteurs

Fournisseurs



51

La figure 3-4 présente la fonction plus complète de Gestion des tournées. Y apparaissentun nouvel acteur externe, le théâtre d’accueil (ou la MJC), ainsi que des ressources mobi-lisées par la tournée, à savoir les acteurs externes Fournisseur et Théâtre (ou MJC), ainsique les ressources suivantes :

• l’ACTEUR,

• la PIECE,

• la TOURNEE,

• la DATE (de la représentation, d’arrivée, de départ, etc.),

• le DECOR (de la pièce) et le matériel à transporter,

• le FOURNISSEUR (de ces éléments),

• le TRANSPORT (mode),

• l’HOTEL où vont séjourner les acteurs,

Figure 3-2

Gestion des acteurs

Figure 3-3

La gestion des pièces

1.1.Gestion des acteurs

Acteurs

ROLEACTEUR

PIECE

1.2.Gestion des pièces

Acteurs

ROLEACTEUR

PIECE



• le(s) LIEU(x) où la pièce va être donnée en représentation.

La décomposition de Gestion des pièces fait l’objet de la figure 3-5. Deux sous-fonctionsy apparaissent, à savoir Produire la pièce et Jouer la pièce. La première d’entre elles faitintervenir un nouvel acteur externe, l’auteur (de la pièce) La seconde fait intervenir elleaussi un nouvel acteur, les spectateurs.

Ont été regroupés au niveau de cette Gestion des pièces les acteurs communs à l’ensembledes composants, à savoir ici l’auteur et l’acteur. En revanche, figure au niveau de Jouerla pièce l’acteur propre à savoir les spectateurs. Produire la pièce crée les ressources, ouébauches de classes, AUTEUR, ACTEUR, PIECE et ROLE, ressources qui sont consultéespar Jouer la pièce ; en revanche, cette sous-fonction crée la classe SPECTATEURS.

Les activités et leurs sous-activités de Produire la pièce sont indiquées sur la figure 3-6.Elles sont exprimées sous forme de verbes actifs avec un complément d’objet, à savoir :

• choisir une œuvre ;

• contracter artiste ;

• préparer « tout ».

Figure 3-4

Gestion des tournées


PIECE

ACTEUR

SPECTATEUR

ROLE

Acteurs

Auteur

AUTEUR

REPRESENTATION

Spectateurs

1.2.1.Produire la pièce

1.2.2.Jouer la pièce

ACTEUR



53

La troisième sous-activité, préparer « le tout », peut être décomposée pour faire apparaîtreles « sous sous-activités » selon la hiérarchie :

Produire un spectacle

• préparer « le tout »

• acheter droits d’auteur (éventuellement)

• organiser les répétitions

• acquérir ou faire fabriquer les décors.

Dans cet exemple, les activités ne sont pas numérotées. Dans un projet réel, il est évidem-ment utile de numéroter les activités selon la hiérarchie de décomposition fonctionnelle.On écrirait alors :

1. Produire un spectacle

1.3. préparer « le tout »

1.3.1 .. acheter droits d’auteur (éventuellement)

Figure 3-5

La décomposition de Gestion des pièces


PIECE

ACTEUR

SPECTATEUR

ROLE

Acteurs

Auteur

AUTEUR

REPRESENTATION

Spectateurs1.2.1.

Produire la pièce1.2.2.

Jouer la pièce

ACTEUR



1.3.2 .. organiser les répétitions

1.3.3 .. acquérir ou faire fabriquer les décors

1.3.4 .. acquérir les droits d’auteurs.

Dans des projets importants, il est possible de cataloguer les messages et de les repérerpar une lettre dans les diagrammes de cas d’utilisation, afin de simplifier leur emploi.

Modèle des objets

Le modèle des objets est représenté à l’aide du diagramme de classes UML qui s’appuiesur la modélisation entité/ association, connue et pratiquée depuis longtemps dans laplupart des méthodes de conception, notamment celles qui sont orientées vers les basesde données. Dans UML, ce modèle est enrichi de nombreux concepts orientés objet(héritage, agrégation, méthodes).

Nous allons développer, pour ce premier exemple, une présentation très progressive de laconstruction d’un diagramme de classe limité aux aspects simples de la modélisationentité/ association, en justifiant en particulier par le détail certains choix de base surlesquels nous ne reviendrons plus dans les études de cas ultérieures.

Classes

Voyons en premier lieu les classes, en nous limitant pour l’instant à la représentation desclasses métiers. Une classe doit être pertinente pour l’application, et les objets de laclasse doivent être identifiables.

Et, tout d’abord, comment convient-il de procéder pour dégager des classes pertinentes ?Un point de départ très utile est le modèle de besoins où figurent déjà les ébauches desprincipales classes. Naturellement, la réflexion sur les données amènera à identifier denouvelles classes non perçues lors de la formalisation des besoins.

L’identification des objets est très importante et soulève quelques problèmes délicats.Un objet doit être identifiable afin de pouvoir le distinguer des autres objets. Dans lavie courante, l’identification d’objets distincts ne soulève pas de problème particulier.On sait bien, quand le besoin s’en fait sentir, se doter des moyens qui permettent dedistinguer deux personnes, deux sociétés, deux voitures. On utilise pour cela desméthodes intuitives et informelles qui peuvent varier selon le moment. Par exemple, ondistinguera deux personnes par leur nom, et on complétera par le prénom quand il y arisque d’ambiguïté.

Il est important de remarquer qu’en ce qui concerne la description des objets et des asso-ciations – éléments non fournis par ce modèle des besoins et valeur ajoutée de la modéli-sation des données–, il faut adopter une démarche plus systématique, pour les raisonssuivantes :

• on ne connaît qu’une description limitée d’un objet, sous forme d’une liste d’attributs ;



55

• l’identifiant doit impérativement faire partie de ces attributs ; cet identifiant doit être validedans tous les cas ; on ne peut se contenter de dire qu’une personne est identifiable par sonnom dans 95 % des cas, et se retrouver avec un problème sérieux dans les 5 % restants !

En pratique, il est difficile de trouver un ou plusieurs attributs satisfaisant les conditionsprécédentes. De plus, en termes d’implantation, il est souhaitable qu’un identifiant soitde la taille la plus réduite possible, et qu’il ne soit jamais nécessaire de le modifier. Onpeut envisager trois solutions :

1. on trouve un ou plusieurs attributs dont le regroupement tient lieu d’identifiant ; àl’extrême, l’ensemble des attributs d’un même objet peut constituer cet identifiant ;

2. on crée un attribut abstrait (un numéro) qui sera incrémenté pour chaque créationd’un objet ;

3. on repousse le choix de l’identifiant à la phase d’implantation.

La troisième solution, même si elle paraît naturelle dans une conception orientée objet(l’identifiant est indépendant des valeurs d’attributs et géré automatiquement par lesystème), fait que l’on ne peut manier la notion d’identifiant au stade de la conception,par exemple pour définir des associations. Nous adopterons donc dans nos corrigés ladeuxième solution, tout en étant conscient qu’il est possible de reconsidérer la prise encompte de l’identifiant au moment de l’implantation.

La première étape de l’élaboration du modèle objet consiste à énumérer les classes utiles,en s’aidant du modèle des besoins. On peut souvent le faire en considérant quelques casparticuliers. Nous allons dans un premier temps prendre en compte la liste suivante desclasses, présentées sous une forme textuelle, proche des conventions exploitées par lemodèle relationnel, où l’identifiant est préfixé par # :

PIECE (#Ident, titre, dateCréation)

ACTE (#Ident, numéro)

SCENE (#Ident, numéro)

AUTEUR (#Ident, nom, dateNaissance, dateDécès)

ARTISTE (#Ident, nom, adresse, dateNaissance)

ROLE (#Ident, libellé)

SALLE (#Ident, adresse, capacité).

Les éléments essentiels, à ce stade, sont les noms des classes et le choix de l’identifiant.En revanche, la liste des attributs pour chaque classe est de moindre importance car onpeut facilement la remettre en question par la suite, le plus souvent pour l’enrichir. Lajustification de la présence ou pas d’un attribut relève d’une démarche d’abstraction quidoit être coordonnée avec les besoins fonctionnels de l’application : on peut procéder à lavalidation avec le modèle des besoins, et par ailleurs il est nécessaire de disposer d’unattribut pour pouvoir implanter une méthode. Nous insisterons sur ce point au moment dela description du comportement des objets.



La représentation de classes indépendantes les unes des autres est de peu d’intérêt. On vamaintenant décrire les associations entre classes. La figure 3-6a montre les premièresassociations entre, respectivement, les PIECEs et les AUTEURs d’une part, entre cesmêmes PIECEs et les ROLEs d’autre part. Il s’agit, pour l’instant, d’un cas très classiquede représentation entité/ association qui exploite la facilité qu’offre UML pour traduireune association binaire par un simple lien. Nous allons rappeler quelques principes debase, qu’il sera bon de garder en mémoire pour l’ensemble des autres études.

Un sens de lecture est privilégié pour la définition d’une multiplicité. Ainsi le schéma dela figure 3-6a se lit-il « une pièce jouée (centre de préoccupation, propre à un contexte,un cas d’utilisation) est écrite par 0 (minimal) ou 1 (maximal) auteur », ici indiqué, selonles conventions de UML, par 0..1. Le fait qu’« un auteur puisse écrire 0 (minimal) ouplusieurs (maximal, nombre indéterminé) pièces » y est sous-entendu. De même s’inté-resse-t-on à une PIECE et l’on note qu’elle contient plusieurs ROLES. Remarquons que,dans un modèle UML, on se centre souvent sur le rôle d’un des objets et on décrit lasituation par rapport à ce centre d’intérêt, relatif à une utilisation de l’objet.

En outre, il faut aussi s’intéresser au caractère plus ou moins général du modèle cons-truit. Si l’on s’intéresse aux données correspondant aux besoins d’une fonction, cellepar exemple qui gère les droits des auteurs (vivants et dont les œuvres ne sont pas dans

Multiplicité

Les multiplicités représentent les nombres minimal et maximal d’objets qui interviennent dans la compositiond’une même association. Les multiplicités sont placées du côté de la classe qu’elles concernent et elles sontliées au rôle joué par la classe dans l’association, même si ce dernier est omis afin de ne pas alourdir lemodèle. Les multiplicités sont bien sûr motivées par le monde réel, mais leur validité ne peut être jugée d’unepart que par rapport aux besoins de l’application, et d’autre part que par rapport à la signification attachée àchaque terme.

Figure 3-6a

Premières associations #ident

titredateCréation

PIECE

#identnomdateNaissancedateDécès

AUTEUR

est écrite

Ecrit

1

0..1

#identtitredateCréation

PIECE

#Identlibellé

ROLE

contient

Dans

1

1+



57

le domaine public), il est évident que dans ce cas la multiplicité minimale sera de 1,alors que cette dernière sera de 0 si l’on s’intéresse à l’ensemble des auteurs, connus ouinconnus.

De même, pourrait-on dire qu’un rôle (Dom Juan par exemple) apparaît dans plusieurspièces. Il est inutile de se battre pour des mots qui n’ont que la signification que l’on veutbien leur donner ; ici, un rôle désigne un des personnages de la pièce.

La démarche – et le mode de pensée – est donc malgré tout assez différent de que l’onpeut obtenir dans une optique entité/ association classique où les liens entre les objets desdeux classes seraient représentés d’une manière ensembliste (voir figure 3-6b), tous casd’utilisation confondus, en indiquant explicitement que les PIECES gérées sont multi-ples (au départ absentes) et qu’un AUTEUR (géré) peut écrire plusieurs pièces (0+), audépart 0.

On pourrait argumenter ici en disant qu’une pièce a forcément au moins un auteur. C’estpossible mais, du point de vue du système d’information, l’important est de savoir si onsera toujours en mesure de connaître cet auteur, ou si l’on peut se permettre de l’ignorer.Si la réponse est non à la première question, et oui à la seconde, alors les multiplicitésproposées seront considérées comme valides.

En résumé, il est important de faire des choix clairs et de s’assurer que la représentationd’une association se conforme à ces choix. Ces choix de modélisation sont effectués parle concepteur (c’est son boulot !), mais on procède à la validation d’un modèle en deman-dant l’accord explicite des personnes concernées (les futurs utilisateurs).

Les multiplicités maximales sont très importantes. Selon que la valeur est égale à« 1 » ou à « n », on obtiendra des modèles de données sensiblement différents. Deplus, il sera très difficile de remettre en cause ces choix une fois que l’implantation du

Figure 3-6b

Une vision ensembliste de PIECE et d’AUTEUR


PIECE

#identnomdateNaissancedateDécès

AUTEUR

jouée

est écrite

0+

0+



système sera effectuée. La multiplicité minimale (également appelée « contrainte departicipation ») est un peu moins importante ou, du moins, plus facile à reconsidérer.

La figure 3-7 montre les associations qui lient une PIECE, ses ACTES et les SCENESd’un acte, ainsi que leurs multiplicités. On a choisi ici de représenter une associationd’agrégation entre les trois classes. On peut remarquer en effet :

• qu’un acte est un composant d’une pièce (autrement dit : une pièce n’est pas complètementdéfinie si on ne connaît pas ses actes) ;

• en l’occurrence, cette agrégation est forte : un acte fait partie d’une pièce et d’une seule, etce lien ne change jamais ;

• la sémantique particulière de l’agrégation est illustrée par les propriétés suivantes :

i. un acte est une partie d’une pièce ;

ii. une opération appliquée au composé se propage au composant (par exemple, lamodification ou la destruction d’une pièce impliquent l’application de ces opéra-tions sur les actes et les scènes) ;

iii. les valeurs d’attributs du composé qualifient également le composant (par exemple,la date de création est pertinente pour la pièce, les actes, les scènes).

Par comparaison avec les exemples précédents, on peut observer qu’il s’agit dans tous lescas d’une association de un à plusieurs, avec une sémantique additionnelle dans le cas del’agrégation. On notera que distinguer une agrégation d’une association simple relève dujugement autant que d’une appréciation basée sur les critères précédemment donnés. Onpourrait par exemple discuter de la nature de l’association entre PIECE et ROLE.

Un ACTE est l’acte d’une et d’une seule PIECE, de même qu’une SCENE n’est la scèneque d’un seul ACTE. Par ailleurs, un ROLE, composant d’une SCENE, peut être lié àplusieurs SCENES distinctes. Dans ce cas, on utilise des multiplicités complémentairescomme cela apparaît dans la figure 3-8 ci-après.

L’attribut « numéro », présent dans ACTE et dans SCENE, indique que l’ordre est impor-tant. Une pièce n’est pas un ensemble d’actes (comme on pourrait dire d’une ville qu’elleest constituée d’un ensemble de bâtiments) mais une liste. Le numéro permet de définirl’ordre. On peut également, en notation UML, qualifier l’association par le mot-clé« ordonné », ce qui revient au même.

Figure 3-7

Composition PIECE-ACTE-SCENE #ident

titredateCréation

PIECE

#identnuméro

ACTE

#identnuméro

SCENE

1..n 1..n



59

Il existe (au moins) une autre représentation possible, liant encore plus étroitementpièces, actes et scènes. On peut en effet éviter de donner le statut de classe aux actes etaux scènes en les considérant comme des attributs dotés d’une structure complexe (voirchapitre 1) En voici la démarche et aussi la notation retenue :

• plusieurs attributs caractérisent une scène, par exemple son identifiant, son numéro et sadurée. On décrira donc les scènes, considérées comme un attribut structuré, par [#Ident,numéro, durée]. Autrement dit, scène est un attribut dont la valeur est complexe ;

• un acte comporte un identifiant, un numéro et une liste de scène. Une liste est notée <>. Ondéfinira donc les actes par [#Ident, numéro, scènes : <[#Ident, numéro, durée]> ;

• enfin, une pièce comporte un identifiant, un titre, une date de création et une liste d’actes.L’attribut correspondant est :[#Ident, titre, dateCréation, actes :[#Ident, numéro, scènes : <[#Ident, numéro, durée]>].

Cela sera représenté en UML comme une hiérarchie unique de classes (voir figure 3-9),où chaque sous-ensemble structuré est porté par une classe particulière. Il convient deremarquer que cette imbrication de valeurs complexes est mal prise en compte dans dessystèmes relationnels classiques. Elle est en revanche très bien gérée par des systèmesrelationnel-objet, ou par le langage XML. Selon le cas, on pourra donc être amené à choi-sir une modélisation classique qui se limite aux valeurs atomiques ou une modélisationqui accepte des structures évoluées d’attributs.

Figure 3-8

Une composition à sémantique renforcée


PIECE

#identnuméro

ACTE

#identnuméro

SCENE

#identnuméro

ROLE

0..n

1

0..n

1

0..n 0..n

Figure 3-9

Associations récursives #ident

titredateCréation

PIECE

0..1 suite de 0..1précédent suivant

#identnuméro

ACTE

0..1 0..1précédent suivant

#identnuméro

SCENE



On peut représenter encore d’une autre manière la séquence des actes et des scènes, enutilisant des associations récursives qui lient entre eux deux actes ou deux scènesconsécutifs. Dans un tel cas, on se trouve face à une certaine ambiguïté pour interpréterle sens de lecture de l’association. On doit alors introduire des rôles (voir chapitre 1)La figure 3-9 ci-après montre la représentation de l’ordre des actes et des scènes aumoyen d’associations récursives, pour lesquelles les cardinalités sont précisées.

Considérons maintenant la prise en compte du texte d’une pièce. Plusieurs choix sontpossibles. On peut tout d’abord le mettre au niveau de chaque scène, mais il faudrait alorsindiquer à quel rôle se rapporte chaque passage. On peut également le mettre au niveaude chaque rôle, mais il faut alors indiquer le découpage en scènes.

Le choix le plus judicieux est donc de placer le texte comme propriété de l’associationentre scène et rôle (voir figure 3-10). Il convient de remarquer que l’association figuredans se substitue à la composition de SCENE de la figure 3-9. Dans la mesure où lacomposition est une association particulière, rien n’interdit de nommer cette association,la composition précédente devient alors figure dans et il est possible de lui rattacher letexte en tant qu’attribut.

Par ailleurs, une Représentation peut être considérée simplement comme une associationentre une salle, une pièce et une date. Relativement à la date, on dispose de plusieurspossibilités. On peut la représenter comme une classe, ce qui permet de respecter rigou-reusement la règle qui veut qu’une association soit identifiée par la concaténation desidentifiants de ces classes. L’inconvénient, c’est que l’on alourdit le schéma avec uneentité qui porte très peu d’information. La solution consiste à indiquer simplement la datecomme attribut de l’association, en précisant qu’il fait partie de l’identifiant, celui-ciétant alors composé de la concaténation des identifiants des classes participantes avecl’attribut propre date. La figure 3-11 montre les deux versions de l’alternative, celle dedroite étant à préférer en raison de sa concision. Il ne faut cependant pas oublier qu’il nes’agit que d’une facilité de notation !

Figure 3-10

Placement du texte dans l’association #ident

titredateCréation

PIECE

#identnuméro

ACTE

#identnuméro

SCENE

#identnom

ROLEcontient1 0..n

textefigure dans0..n

0..n

0..n



61

Voici comment on introduit les acteurs dans le modèle. Un ACTEUR joue un rôle dansune PIECE, et nous sommes de plus intéressé par la date à laquelle il a joué la pièce.Une première solution, simple, consiste à représenter deux associations binaires, avecles classes citées dans la phrase qui précède, à savoir ACTEUR, ROLE, PIECE etDATE, dernier attribut que l’on se contentera d’introduire comme identifiant complé-mentaire dans le rôle (vu comme un des pôles de l’association Joue), comme cela estmontré ci-après. On obtient le schéma de la figure 3-12.

Figure 3-11

Association ternaire avec date

(a) avec une entité date (b) avec un attribut-clé complémentaire

#datenbSpectateurs


PIECE

#identnomadressecapacité

SALLE

Représentation

1

0..nnbSpectateurs


PIECE

#identnomadressecapacité

SALLE

#date

DATE

Représentation

1

0..n

0..n

Figure 3-12

Associations PIECE/ROLE et ACTEUR/PIECE/ROLE

#date


PIECE

#identlibellé

ROLE

#identnomdateNaissance

ACTEUR

Joue

joue1+

Contient

1

est contenu1+



Nous avons représenté l’association entre PIECE et ROLE car elle influe sur l’association.Comme un ROLE n’appartient qu’à une seule PIECE (« dépendance fonctionnelle »), ensimplifiant le réel qui est décrit, on connaît la PIECE quand on connaît le ROLE. On peutdonc s’épargner de placer la PIECE dans l’association ternaire qui représente le faitqu’un ACTEUR ait joué un ROLE dans une PIECE. On obtient, sans perte d’information,le schéma de la figure 3-13.

L’avantage d’une telle simplification est qu’elle permet d’éviter l’incohérencesuivante : un ACTEUR ne peut plus jouer dans une PIECE un ROLE qui ne fait paspartie de la PIECE ! Il s’agit cependant d’une technique de normalisation issue dumodèle relationnel : on peut éventuellement reporter cette amélioration au moment dupassage à une représentation logique, liée à une technique de mémorisation (relation-nelle, par exemple).

Enfin, comment représenter le fait qu’un ACTEUR ait joué dans une Représentation ?Cette Représentation est, jusqu’à présent, considérée comme une association, ce qui renddifficile de l’associer elle-même à des classes. La solution consiste alors à la promouvoirau rang de classe, ce qui la dote du même coup d’un identifiant propre. Il devient alorsfacile, par une association ternaire, d’introduire le fait qu’un acteur ait joué un rôle dansune représentation (figure 3-14).

Le lecteur attentif remarquera que cette association ternaire est assez permissive. Uneinstance de cette association est en effet un triplet (acteur, représentation, rôle), l’identi-fiant de cette occurrence étant la concaténation des identifiants des trois classes. On nepeut pas représenter deux fois un lien entre un acteur, une représentation et un rôle donné(cela n’aurait effectivement pas de sens) En revanche, il est possible pour un mêmeacteur de jouer deux rôles (différents) dans une même représentation. Inversement, unmême rôle peut être joué par deux acteurs différents dans la même représentation.

Figure 3-13

Association ACTEUR/PIECE/ROLE simplifiée

#date


PIECE

#identlibellé

ROLE


ACTEURjoue

1+1+

Contient

1

est contenu1+



63

Autrement dit, il est difficile d’exprimer des contraintes sur les associations ternaires. Enrègle générale, on essaiera de privilégier les associations binaires, au besoin en créant desclasses là où on aurait pu envisager de créer des associations.

Dynamique des objets

Nous souhaitons maintenant décrire la dynamique d’un certain nombre d’objets, c’est-à-dire la manière dont certains de leurs attributs se transforment dans le temps. Nous feronsapparaître cela au moyen, d’une part, des cycles de vie textuels d’objets et, d’autre part,des diagrammes états-transitions UML.

Cycles de vie d’objets

Tous les cycles de vie ne sont pas forcément complets, certains peuvent se limiter à unsous-ensemble d’états jugés intéressants ou représentatifs des situations qui ont un intérêtpour le système d’information d’une entreprise ou d’un système technique. Un cycle devie peut être mono-objet s’il ne met en jeu que les états d’un seul objet ou multi-objet s’il

Figure 3-14

Association avec REPRESENTATION transformée en classe


PIECE


ACTEUR

Dans 1 est joué 1 0..n1

Contient

1 0..n

Joue

#identDatenbSpectateurs

REPRESENTATION

#identadressecapacité

SALLE

#identlibellé

ROLE

1

#date

Qu’est-ce qu’un cycle de vie d’objets ?

Un cycle de vie est déclenché par un événement initiateur qui suscite la création de l’objet considéré. Il est ponc-tué par un ensemble d’états remarquables qui sont autant de valeurs distinctes et ordonnées d’un attribut del’objet. Un même objet peut avoir plusieurs cycles de vie distincts, chacun d’eux s’appuyant sur un attribut spéci-fique. Chaque cycle de vie se conclut par un événement final qui suscite la destruction (la suppression) del’objet.



traduit les interférences entre des cycles de vie d’objets distincts. Ce cas est le pluscourant et traduit le fait que tout objet est un mini-système ouvert dont les états évoluenten interactions avec un sous-ensemble d’objets qui constituent son environnement.

Tout cycle de vie d’objet peut être formalisé textuellement ou graphiquement. Ilexploite des états remarquables (des valeurs significatives) de certains attributs d’unmême objet. Pour des raisons de sécurisation de la transition ou autres, des états transi-toires peuvent être gérés : en entrée de la transition, en sortie de la transition, pendantla transition, etc. Dans ce qui suit, nous ne nous intéresserons qu’aux transitions relatives àdes événements extérieurs, ou événements externes métier.

Nous allons considérer, dans un premier temps, les cycles de vie textuels, en débutant parcelui de l’ACTEUR. Celui-ci (dans le cas de débutants) est d’abord convoqué à une audi-tion (il peut aussi venir spontanément) en tant que postulant, considéré ici comme unevariable de travail dotée des attributs nom et jeu. Il est auditionné puis éventuellementsélectionné. Il est ensuite affecté à un (ou plusieurs) rôle(s) (et ce pour tous les acteurs),pour autant qu’il y ait équivalence entre son type et celui du personnage, rôle(s) qu’iljoue lors de différentes représentations.

Cycle de vie de l’acteur début Quand dateaudition=datejour Si postulant.jeu=«bon» alors début nouveau(acteur); // on crée un objet acteur acteur.nom:=postulant.nom; acteur.état:=«sélectionné»; Si acteur.NbreReprésentations<10 alors début acteur.catégorie :=débutant; acteur.type={ingénu,valet_comédie,comique,tragique} fin; fin; Quand datelecture=datejour Si (acteur.statut=«sélectionné» et acteur.type= personnage.type) alors début {[acteur.statut=«affecté»; // interférence entre acteur // et pièce acteur.rôle=personnage.nom; acteur.cachet=nouveau(cachet) ou acteur.salaire =nouveau(salaire)]}; // création du //nouveau //cachet ou de nouveau salaire //de chaque acteur sélectionné fin; Quand ((Représentation.nombre>10) ou acteur.jeu=«bon») Si (acteur.statut= «débutant» alors // un débutant voit son statut changer après 10 // représentations ou de manière prématurée si //son jeu est trouvé bon par le metteur en scène



65

début {[acteur.statut=«intermittent»; acteur.cachet=nouveau(cachet)]}; fin; Quand datereprésentation=datejour Si acteur.statut = «affecté» alors début {[acteur.état=«joue» ; prestation.date=représentation.date; prestation.nombre=succ(prestation.nombre)]}; fin; fin cycle de vie de l’acteur;

Il est à noter que prestation.date est un attribut multivalué, choix justifié par le nombrede représentations dont il faut tenir compte pour les acteurs rémunérés « au cachet ».

Voyons maintenant le cycle de vie, textuel dans un premier temps, d’un objet PIECE.

Cycle de vie de la piècedébut Quand datechoix=datejour alors début nouvelle(pièce); // création de l’objet pièce pièce.statut=«choisie»; fin; Quand datelecture=datejour Si pièce.statut=« choisie » alors début pièce.statut=« peuplée »; {acteur.statut=«affecté »}; //il y a là interaction //entre le cycle de vie des //acteurs et celui de //la pièce fin; Quand daterépétition=datejour Si pièce.statut=« choisie » alors pièce.statut= « en répétition »; Quand (costumes=« livrés » et datecouturière=vrai) Si pièce.statut= « en répétition »; alors pièce.nature=« couturière »; Quand (décors=livrés et dategénérale=vrai Si pièce.nature=« couturière »; alors pièce.statut=« générale »; Quand jeu=« bon » Si pièce.statut=« en répétition »; alors pièce.statut=« jouable »; //le metteur en scène //décide que la pièce est jouable Quand (datereprésentation=datejour) Si pièce.statut=« OK »; alors début pièce.datereprésentation:=datejour; pièce.statut:=« représentée »; Si datedernière_représentation=datejour alors Supprimer(pièce); fin;

fin cycle de vie de la pièce;



Voyons enfin le cycle de vie de la TOURNEE. Il est conditionné par la succession desétats suivants (tournée planifiée, salles réservées, hôtels réservés, décors prêts, transportsréservés, tournée prête) :

Cycle de vie de la tournéedébut Quand dateplanification=datejour alors début nouvelle(tournée); tournée.statut:=« tournée planifiée »; fin; Quand Salles=OK Si tournée.statut=« tournée planifiée » alors tournée.statut:=« salles réservées »; Quand Hôtels=OK Si tournée.statut=« tournée planifiée » alors tournée.statut:=« Hôtels réservés »; Quand Transports=OK Si tournée.statut=« tournée planifiée » alors tournée.statut:=« Transports réservés »; Quand Décors=OK Si tournée.statut=« tournée planifiée » alors tournée.statut:=« décors prêts »; // l’ensemble de ces 1ers changements d’états // est parallèle Quand pièce.statut=« jouable » Si tournée.statut=« décors prêts » alors tournée.statut :=« prête »; // fin prép. // interférence entre cycles de vie de la pièce et de la tournée Quand datedebuttournée=datejour si tournée.statut=« prête » alors tournée.statut:= « en cours »; Quand pièce.datereprésentation=datefintournée si tournée.statut= « en cours » alors début tournée.statut:=« terminée »; supprimer(tournée);fin;fin cycle de vie de la tournée;

Diagramme états-transitions

Un cycle de vie d’objets doit être représenté graphiquement par un diagramme états-tran-sitions. La figure 3-15 fournit un tel diagramme qui correspond au cycle de vie d’objetsde la figure 3-14 où les contraintes de transition (équivalentes aux synchronisationsprécédentes) apparaissent comme un décor associé.

Il en va ainsi en particulier de la transition initiale, décorée par la contrainte datejour =dateaudition, et de celle vers l’état « sélectionné », lequel est décoré par la contrainted’égalité entre le type du Rôle et le type (de jeu) de l’acteur.



67

Figure 3-15

Un diagramme états-transitions partiel de l’objet Acteur

Do:créer Acteur Acteur.jeu := «bon»

Datejour =Dateaudition

Entry: Acteur.état := «sélectionné» Acteur.type := «ingénu»

Entry: Acteur.état := «affecté»


introduction - eyrolles

Documents