CONCEPTION DU COMPORTEMENT (DIAGRAMMES D’INTERACTION)

Notre diagramme de communications démarre par la réception d’un message système venant d’un acteur. Puisque la possibilité nous est donnée de ne pas nous préoccuper des objets d’interface, nous allons directement choisir un objet qui traitera cet événement système.La solution que nous avions mise en œuvre au chapitre précédent (étape 6) nous amenait à introduire un objet artificiel de conception de type « contrôleur » que nous aurions pu appeler ici En fait, dans le cas d’un système comprenant un nombre restreint d’opéra- tions système, une approche plus simple est possible, qui n’oblige pas à ajou- ter une nouvelle classe. Cette solution consiste à utiliser comme contrôleur une instance d’une classe d’analyse existante :• soit un objet représentant le système entier ou l’organisation elle-même ;• soit un objet représentant un rôle qui aurait réalisé l’opération système.Le premier choix possible est le plus direct, mais son inconvénient majeur, c’est que l’on affecte le traitement de toutes les opérations système à un objet unique, qui risque rapidement d’être surchargé en matière de responsabilités. C’est une solution acceptable dans notre exemple, et la classe candidate est la classe , ce qui n’apporte rien par rapport à la solution précédente. Nous conservons donc comme objet contrôleur pour notre opération système. Le diagramme de communication peut donc démarrer de la manière suivante.

Comment devons-nous maintenant procéder ? Il faut tout simplement étudier le contrat d’opération. Rappelez-vous cependant que les post-conditions répertoriées dans le contrat ne sont pas forcément ordonnées. Dans notre cas, il semble quand même raisonnable de commencer par la création de l’objet prêt puisque les autres post-conditions s’appliquent à ses attributs ou à ses liens.Si nous revenons au diagramme de classes d’analyse, nous constatons que quatre classes possèdent déjà une association avec la classe . Elles sont donc toutes de bonnes candidates initiales. Cependant, le meilleur choix est en général fourni par la classe qui possède une association de type composition, agréga- tion ou « enregistre ». Dans notre exemple, la classe , puisqu’il n’existe pas encore ! Il s’agit là d’une bonne pratique qui évite d’entrer dans des considérations qui dépendent du langage de program- mation cible. En Java (ou en C#), ce message de création se traduira proba- blement par le mot-clé , qui retournera une référence sur le nouvel objet.Ainsi, la bibliothèque a maintenant une référence sur l’objet p nouvellement créé. Notez que, puisque le message de création renvoie toujours une réfé- rence sur le nouvel objet, nous ne montrons pas le retour explicitement, bien que cela soit légal. On obtiendrait une représentation un peu plus lourde telle que celle qui est illustrée par la figure suivante.

Remarquez une fois de plus (voir chapitre 7, étape 8) l’utilisation de la notation décimale des numéros de messages, qui permet de représenter l’imbrication des messages. On notera également l’utilisation de la boucle au-dessus de l’objet qui symbolise un lien de l’objet vers lui-même comme support d’un message « à soi-même ».Revenons à l’établissement du contrat de l’opération. Que devons-nous faire maintenant ? Il nous faut un lien avec le livre dont l’attribut ISBN vaut l’ISBN passé en paramètre de l’opération Pour respecter le principe de faible couplage, il vaut mieux que la bibliothèque s’en charge, car elle possède déjà une association avec le catalogue, contraire- ment au prêt. De plus, il est fort probable que la bibliothèque doive collaborer avec le catalogue dans le cadre d’autres opérations système, par exemple lors de l’ajout de nouveaux livres. Il faut donc que la bibliothèque ait un lien perma- nent avec le catalogue, ce qui n’est pas du tout le cas du prêt. Toutes ces raisons font clairement pencher la balance en faveur de la bibliothèque.On notera que cela suppose que les objets catalogue et bibliothèque soient créés lors de l’initialisation du système et qu’un lien de visibilité soit établi entre eux. Il est courant en conception objet de travailler d’abord sur les colla- borations entre objets « métier », puis de traiter dans un second temps le pro- blème plus technique de l’initialisation du système informatique. Cela permet de s’assurer que les bonnes décisions d’affectation de responsabilités aux sur le bon objet livre. Le diagramme de communication modifié est présenté ci-après.