Objet
  • Affiner les réalisations de cas d'utilisation en terme d'interactions
  • Affiner les exigences sur les opérations des classes de conception
  • Affiner les exigences sur les opérations des sous-systèmes de conception et/ou de leurs interfaces
Rôle :  Concepteur 
Fréquence :  Une fois par itération, pour un ensemble de Artefact : Concevoir les réalisations de cas d'utilisation
Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :  
Plus d'informations : 

détails de l'enchaînement des activités :   

Le comportement d'un système peut être décrit en utilisant un certain nombre de techniques - des collaborations ou des interactions. Cette activité décrit l'utilisation des interactions, en particulier des diagrammes de fonctionnement, afin de décrire le comportement du système. Les diagrammes de fonctionnement sont très utiles lorsque le comportement du système ou du sous-système peut être principalement décrit comme une messagerie synchrone. La messagerie non-synchrone, en particulier dans les systèmes déclenchés par l'événement, est souvent décrite plus facilement en terme d'automates à états et de collaborations, ce qui permet de définir de façon compacte les interactions potentielles entre les objets.

Créer des réalisations de cas d'utilisation Haut de la page

L'Artefact : Réalisation de cas d'utilisation permet de suivre le comportement du modèle de conception jusqu'au modèle de cas d'utilisation, et organise des collaborations dans le modèle de conception autour du concept de cas d'utilisation.

Créez une réalisation de cas d'utilisation de conception dans le modèle de conception pour chaque cas d'utilisation à concevoir. Le nom de la réalisation de cas d'utilisation de conception doit être le même que le cas d'utilisation associé, et une relation de "réalisation" doit être établie de la réalisation de cas d'utilisation de conception à son cas d'utilisation associé.

Décrire les interactions entre les objets de conception Haut de la page

Pour chaque réalisation de cas d'utilisation, vous devez illustrer les interactions entre les objets de conception qui y participent en créant un ou plusieurs diagrammes de fonctionnement. Des versions préliminaires de ces diagrammes peuvent avoir été créées pendant l'Activité : Analyse de cas d'utilisation.  Des "versions d'analyse" des réalisations de cas d'utilisation de ce type décrivent les interactions entre les classes d'analyse.  Elles doivent être modifiées pour décrire les interactions entre les éléments de conception.

La mise à jour des diagrammes de fonctionnement inclut les étapes suivantes :

  • Identifiez chaque objet participant au flot du cas d'utilisation. Cette tâche est effectuée en instanciant les classes et les sous-systèmes de conception identifiés dans l'Activité : Identifier les éléments de conception.
  • Représentez chaque objet participant dans un diagramme de fonctionnement. Effectuez une ligne de vie pour chaque objet participant au diagramme de fonctionnement. Pour représenter les sous-systèmes de conception vous pouvez faire les choix suivants :
    • Vous pouvez montrer des instances du sous-système sur le diagramme de fonctionnement
    • Vous pouvez utiliser les interfaces réalisées par le sous-système. Cette méthode est préférable si vous souhaitez montrer qu'un élément de modèle qui réalise la même interface peut être utilisé à la place de l'interface. Si vous choisissez de montrer des interfaces sur le diagramme de fonctionnement, vous devrez vous assurer qu'aucun message n'est envoyé de l'interface à d'autres objets. En effet, les interfaces encapsulent totalement la réalisation interne de leurs opérations. Ainsi, nous ne pouvons être sûrs que tous les éléments de modèles réalisant l'interface seront véritablement conçus de la même façon. Pour cette raison, aucun message envoyé à partir des interfaces ne doit apparaître sur les diagrammes de fonctionnement.
    • Vous pouvez utiliser le composant pour représenter le sous-système sur des diagrammes de fonctionnement. Utilisez le composant lorsque vous souhaitez montrer qu'un sous-système spécifique répond à un message. Dans ce cas, vous pouvez montrer des messages envoyés du composant à d'autres objets.

    Notez qu'il s'agit ici de diagrammes de fonctionnement au niveau du système montrant comment les instances des éléments de conception de haut niveau (généralement les sous-systèmes et les interfaces de sous-système) interagissent. Des diagrammes de fonctionnement montrant la conception interne des sous-systèmes sont produits séparément, dans le cadre de l'Activité: Conception de sous-système.

  • Notez que les interactions des objets actifs sont généralement décrites en utilisant des collaborations de spécification et des automates à états. Elles doivent être utilisées pour montrer comment les messages peuvent être envoyés à des objets actifs par d'autres éléments du système dans une réalisation de cas d'utilisation de taille plus importante. Généralement, les objets actifs sont encapsulés dans des sous-systèmes pour effectuer cette activité ; ainsi la réalisation de cas d'utilisation consiste en un ensemble de sous-systèmes interagissant ensemble. Les interactions définissent les responsabilités et les interfaces des sous-systèmes. Dans le cadre des sous-systèmes, les objets actifs représentent des fils d'exécution concurrents. Les sous-systèmes permettent de diviser le travail entre les équipes de développement, les interfaces servants de contrats formels entre les équipes.

    Commentaire accessoire sur l'affichage des messages provenant des sous-systèmes : le fait de réduire les messages aux interfaces réduit le couplage entre les éléments de modèles et améliore l'élasticité de la conception. Dans la mesure du possible, tentez d'atteindre cet objectif, et lorsqu'il existe des messages provenant de sous-systèmes et destinés à des éléments de modèles ne faisant pas partie de l'interface, essayez de les changer en messages destinés à des interfaces pour améliorer le découplage dans le modèle.

  • Représentez l'interaction ayant lieu avec les acteurs. Représentez chaque instance d'acteur et d'objet externe avec lesquels les objets participants interagissent par une ligne de vie dans le diagramme de fonctionnement.
  • Illustrez l'envoi du message entre les objets participants. Le flot d'événements commence en haut du diagramme et continue vers le bas, ce qui indique un axe vertical chronologique. Illustrez l'envoi du message entre les objets en créant des messages (flèches) entre les lignes de vie. Le nom d'un message doit être le nom de l'opération invoquée par le message. Dans les premières étapes de la conception, un nombre d'opérations limité sera attribué aux objets, vous devrez donc peut-être laisser cette information de côté et donner un nom temporaire au message ; ces messages sont appelés "non-attribués". Plus tard, lorsque vous aurez trouvé plus d'opérations des objets participants, vous devrez mettre à jour le diagramme de fonctionnement en "attribuant" les messages à ces opérations.
  • Décrivez ce qu'un objet fait lorsqu'il reçoit un message. Cette action est effectuée en attachant un script au message correspondant. Placez ces scripts dans la marge du diagramme. Utilisez un texte structuré ou un pseudocode. Si vous utilisez un pseudocode, assurez-vous d'utiliser des structures dans le langage d'implémentation pour que l'implémentation des opérations correspondantes soit plus facile. Lorsque la personne responsable de la classe d'un objet attribue et définit ses opérations, les scripts de l'objet fourniront une base pour ce travail.

Diagramme décrit dans le texte d'accompagnement.

Vous documentez le comportement de cas d'utilisation effectué par les objets dans un diagramme de fonctionnement.

Lorsque vous avez un comportement distribué entre les objets, prenez en compte la manière dont le flot sera contrôlé. Vous avez trouvé les objets en supposant qu'ils interagiraient d'une certaine manière dans la réalisation du cas d'utilisation, et qu'ils auraient un certain rôle. Lorsque vous distribuez le comportement, vous pouvez commencer à tester ces suppositions. Dans certaines sections du flot, vous pouvez décider d'utiliser une structure décentralisée ; dans d'autres, vous pouvez préférer une structure centralisée. Pour obtenir des définitions de ces variantes et des recommandations sur le moment où vous utiliserez les deux types de structure, voir Principes et conseils : Diagrammes de fonctionnement.

Vous aurez peut-être besoin de nouveaux objets à ce stade, par exemple si vous utilisez une structure centralisée et avez besoin d'un nouvel objet pour contrôler le flot. Souvenez-vous que tout objet que vous ajoutez au modèle de conception doit répondre aux exigences faites sur le modèle d'objet.

Intégrer des mécanismes de conception applicables

Pendant l'Activité : Analyse architecturale, des mécanismes d'analyse ont été identifiés.  Pendant l'Activité : Identifier des mécanismes de conception, les mécanismes d'analyse ont été affinés en mécanismes de conception, le mappage des mécanismes d'analyse aux mécanismes de conception est consigné dans le document d'architecture logicielle, et les mécanismes de conception sont documentés dans les ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websitePrincipes et conseils relatifs au projet.  

Pendant cette activité, la conception des cas d'utilisation, tous les mécanismes de conception applicables sont intégrés aux réalisations de cas d'utilisation.  Le concepteur examine les mécanismes de conception disponibles et détermine ceux qui s'appliquent à la réalisation du cas d'utilisation actuellement développé, en travaillant dans le cadre des recommandations et des conseils documentés dans le document d'architecture logicielle et les recommandations de conception.  
Commentaire : Un mécanisme de conception applicable peut avoir été identifié dans Activité : Analyse de cas d'utilisation, durant laquelle les classes d'analyse peuvent avoir été "référencées" à un mécanisme d'analyse spécifique, indiquant qu'une fonctionnalité spécifique devait être prise en charge dans la conception.  Dans ce cas, les mécanismes de conception applicables sont ceux qui sont associés aux mécanismes d'analyse auxquelles les classes d'analyse participant à la réalisation de cas d'utilisation ont été référencées.

Le concepteur intègre les mécanismes de conception applicables aux réalisations de cas d'utilisation en incluant les éléments de conception et les interactions d'éléments de conception nécessaires dans les réalisations de cas d'utilisation, en suivant les règles d'utilisation documentées dans les recommandations de conception.

Traiter toutes les variantes du flot d'événements

Vous devez décrire chaque variante de flot dans un diagramme de fonctionnement séparé. Les diagrammes de fonctionnement sont généralement préférables aux diagrammes de communication car ils sont généralement plus faciles à lire, le diagramme devant contenir le niveau de détails que nous souhaitons généralement lors de la conception du système.

Commencez par décrire le flot de base, qui est le flot d'événements le plus commun ou le plus important. Puis décrivez des variantes comme des flots exceptionnels. Il n'est pas utile de décrire l'intégralité des flots d'événements dans la mesure où vous utilisez et donnez des exemples de toutes les opérations des objets participants. De ce fait, des flots très triviaux peuvent être omis, comme ceux ne concernant qu'un seul objet.

Etudiez le cas d'utilisation pour voir s'il existe d'autres variantes de flot outre celles déjà décrites dans l'analyse et la consignation des exigences, par exemple, ceux dépendant de l'implémentation. En identifiant de nouveaux flots, décrivez chacun d'entre eux dans un diagramme de fonctionnement. Parmi les flots exceptionnels, on peut noter les exemples suivants.

  • Traitement des erreurs. Si une interface signale qu'une erreur a eu lieu dans sa communication avec un système externe, par exemple, le cas d'utilisation doit la traiter. Une solution possible consiste à ouvrir une autre voie de communication
  • Traitement du délai d'inactivité. Si l'utilisateur ne répond pas dans une période donnée, le cas d'utilisation doit prendre des mesures spécifiques.
  • Traitement des entrées erronées dans les objets participant au cas d'utilisation. Des erreurs de ce type peuvent venir d'une entrée incorrecte de l'utilisateur.

Traiter les parties optionnelles du cas d'utilisation

Vous pouvez décrire un chemin alternatif d'un flot en tant que flot optionnel plutôt que comme variante. La liste suivante comporte deux exemples de flots optionnels.

  • En envoyant un signal, l'acteur décide-à partir d'un certain nombre d'options- ce que le cas d'utilisation doit faire ensuite. Le cas d'utilisation a demandé à l'acteur de répondre oui ou non à une question, par exemple, ou lui a fournit une gamme de fonctions que le système doit effectuer dans l'état actuel du cas d'utilisation.
  • Le chemin du flot varie selon la valeur des attributs ou des relations notés. Le flot d'événements qui en découle dépend du type de données à traiter.

Si vous souhaitez qu'un flot optionnel, ou tout sous-flot complexe, soit particulièrement perceptible, utilisez un diagramme de fonctionnement séparé. Chaque diagramme de fonctionnement séparé doit être renvoyé au diagramme de fonctionnement décrivant le flot principal d'événements par le biais de scripts, de texte dans la marge du document ou de commentaires afin d'indiquer où a lieu le comportement optionnel ou sous-flot.

Dans les cas où le comportement de flot optionnel ou exceptionnel peut avoir lieu partout, par exemple un comportement qui s'exécute lorsqu'un événement spécifique a lieu, le diagramme de fonctionnement du flot principal d'événements doit être annoté pour indiquer que lorsque l'événement a lieu, le comportement décrit dans le diagramme de fonctionnement optionnel/ exceptionnel sera exécuté. Dans le cas contraire, si le comportement est événementiel, envisagez l'utilisation d'un diagramme d'état-transition pour décrire le comportement du système. Pour plus d'information, voir Principes et conseils : diagramme d'état-transition.

Simplifier les diagrammes de fonctionnement en utilisant des sous-systèmes (facultatif) Haut de la page

Lorsqu'un cas d'utilisation est réalisé, le flot d'événements est généralement décrit selon les objets exécutants, c'est-à-dire comme une interaction entre les objets de conception. Pour simplifier les diagrammes et identifier le comportement réutilisable, vous devrez peut-être encapsuler un sous-flot d'événements dans un sous-système. Ensuite, d'importantes sous-sections du diagramme de fonctionnement sont remplacées par un seul message au sous-système. Dans le sous-système, un diagramme de fonctionnement séparé peut représenter les interactions internes du sous-système qui fournissent le comportement requis (pour plus d'information, voir Activité : Conception de sous-système).

Des sous-séquences de messages dans les diagrammes de fonctionnement doivent être encapsulées dans un système quand :

  • La sous-séquence a lieu plusieurs fois lors de différentes réalisations de cas d'utilisation ; c'est-à-dire que les mêmes messages (ou similaires) sont envoyés aux mêmes objets (ou similaires), produisant le même résultat final. Le terme "similaire" est utilisé car un certain travail de conception peut être nécessaire pour rendre le comportement réutilisable.
  • La sous-séquence a lieu dans une seule réalisation de cas d'utilisation, mais il est prévu de l'exécuter plusieurs fois dans des itérations futures, ou dans des systèmes similaires dans le futur. Le comportement peut représenter un bon composant réutilisable.
  • La sous-séquence a lieu dans une seule réalisation de cas d'utilisation, elle est complexe mais facilement encapsulée, doit être sous la responsabilité d'une personne ou d'une équipe, et produire un résultat bien défini. Dans ce type de situation, le comportement complexe nécessite généralement des connaissances techniques spécifiques, ou une connaissance spécifique du domaine, et il est ainsi adapté de l'encapsuler dans un sous-système.
  • La sous-séquence est déterminée pour être encapsulée dans un composant remplaçable (voir Concepts : Composant). Dans ce cas, un sous-système est la représentation adaptée du composant dans le modèle de conception.

Diagramme décrit dans le texte d'accompagnement.

Une réalisation de cas d'utilisation peut être décrite, si nécessaire, à différents niveaux de la hiérarchie du sous-système. Les lignes de vie du diagramme du milieu représentent des sous-systèmes ; les interactions dans les cercles représentent l'interaction interne des membres des sous-systèmes en réponse au message.

Les avantages de cette approche sont les suivants:

  • Les réalisations de cas d'utilisation sont moins encombrées, particulièrement si la conception interne de certains sous-systèmes est complexe.
  • Les réalisations de cas d'utilisation peuvent être créées avant la création des conceptions internes des sous-systèmes ; c'est utile par exemple dans des environnements parallèles de développement (voir "Comment travailler en parallèle").
  • Les réalisations de cas d'utilisation deviennent plus génériques et faciles à modifier, particulièrement si un sous-système doit être remplacé par un autre sous-système.

Exemple :

Examinez le diagramme de fonctionnement suivant, qui fait partie d'une réalisation du cas d'utilisation appel local :

Diagramme décrit dans le texte d'accompagnement.

Dans ce diagramme, les classes en gris appartiennent au sous-système de prise en charge réseau ; les autres classes appartiennent à un sous-système de prise en charge de la souscription. Cela implique qu'il s'agit d'un diagramme de fonctionnement à multi-sous-systèmes, c'est-à-dire un diagramme dans lequel tous les objets participant au flot d'événements sont inclus, que leurs classes se situent dans des sous-systèmes différents ou non.

Une alternative consiste à montrer l'appel d'un comportement dans le sous-système de prise en charge réseau, et l'exercice d'une interface spécifique sur ce sous-système. Supposons que le sous-système de prise en charge réseau fournit une interface ICoordinator, utilisée par le sous-système de prise en charge des souscriptions :

Diagramme décrit dans le texte d'accompagnement.

L'interface ICoordinator est réalisée par la classe Coordinator dans la prise en charge réseau. De ce fait, nous pouvons utiliser le sous-système de prise en charge réseau lui-même et son interface ICoordinator dans le diagramme de fonctionnement, plutôt que des instances de classes dans la prise en charge réseau :

Diagramme décrit dans le texte d'accompagnement.

Notez que les instances de classes Coordinator, informations numériques et réseau sont remplacées par le sous-système les contenant. Tous les appels au sous-système passent ainsi par l'interface ICoordinator.

Montrer les interfaces sur les lignes de vie

Pour que les sous-systèmes réalisant la même interface puissent se substituer véritablement, seule leur interface doit être visible dans les interactions (et dans les diagrammes en général) ; sinon les interactions (ou les diagrammes) doivent être changées lorsque les sous-systèmes sont substitués l'un à l'autre.

Exemple :

Nous pouvons inclure uniquement l'interface ICoordinator, et non le sous-système qui la produit, dans un diagramme de fonctionnement :

Diagramme décrit dans le texte d'accompagnement.

L'envoi d'un message à une ligne de vie d'interface signifie que tout sous-système réalisant l'interface peut être remplacé par l'interface dans le diagramme. Notez qu'aucun message ne part de la ligne de vie de l'interface ICoordinator, dans la mesure où différents sous-systèmes réalisant l'interface peuvent envoyer différents messages. Cependant, si vous souhaitez décrire quels messages doivent être envoyés (ou doivent être autorisés à l'envoi) de n'importe quel sous-système réalisant l'interface, ces messages peuvent partir de la ligne de vie de l'interface.

Comment travailler en parallèle

Dans certains cas il peut être approprié de développer un sous-système plus ou moins indépendamment et parallèlement au développement d'autres sous-systèmes. Pour ce faire, nous devons d'abord trouver des dépendances de sous-systèmes en identifiant les interfaces entre elles.

Cette tâche peut être effectuée ainsi :

  1. Concentrez-vous sur les exigences influençant les interfaces entre les sous-systèmes.
  2. Décrivez rapidement les interfaces requises, en montrant les messages passant au-delà des frontières du système.
  3. Dessinez des diagrammes de fonctionnement en terme de sous-systèmes pour chaque cas d'utilisation.
  4. Affinez les interfaces nécessaires pour produire des messages.
  5. Développez chaque sous-système en parallèle, et utilisez les interfaces en tant qu'instruments de synchronisation entre les équipes de développement.

Vous pouvez aussi décider d'organiser les diagrammes de fonctionnement en terme de sous-systèmes ou seulement en terme de leurs interfaces. Dans certains projets, il peut même nécessaire d'implémenter les classes fournissant les interfaces avant de continuer avec le reste de la modélisation.

Décrire le comportement lié à la persistance Haut de la page

Le but du paradigme orienté objet est d'encapsuler les détails d'implémentation. Ainsi, en ce qui concerne la persistance, nous souhaitons qu'un objet persistant ait le même aspect qu'un objet transitoire. Nous ne devons pas être conscients que l'objet est persistant, ni le traiter différemment de tout autre objet. Du moins, c'est notre objectif.

En pratique, dans certains cas l'application doit contrôler divers aspects de la persistance :

  • quand les objets persistants sont en lecture et en écriture
  • quand les objets persistants sont supprimés
  • comment les transactions sont gérées
  • comment le contrôle du verrouillage et de la simultanéité est effectué

Ecrire des objets persistants Haut de la page

Vous devez prendre en compte deux cas : le moment initial où l'objet est écrit dans la mémoire d'objet persistante, et les moments ultérieurs où l'application souhaite mettre à jour la mémoire d'objet persistante en changeant l'objet.

Dans les deux cas, le mécanisme spécifique dépend des opérations prises en charge par l'infrastructure préfabriquée de persistance. Généralement, le mécanisme utilisé consiste à envoyer un message à l'infrastructure préfabriquée de persistance pour créer l'objet persistant. Une fois qu'un objet est persistant, l'infrastructure préfabriquée de persistance est suffisamment intelligente pour détecter les changements ultérieurs faits sur l'objet persistant et pour les écrire dans la mémoire d'objet persistante si nécessaire (généralement lorsqu'une transaction est exécutée).

Vous trouverez ci-dessous un exemple d'un objet persistant créé :

Diagramme décrit dans le texte d'accompagnement.

L'objet PersistenceMgr est une instance de VBOS, une infrastructure préfabriquée de persistance. Le coordinateur de commande crée une commande persistante en l'envoyant comme argument à un message "créer objet persistant" au PersistenceMgr.

Il n'est généralement pas nécessaire de le modéliser de façon explicite à moins qu'il ne soit important de savoir que l'objet est stocké à un point spécifique d'une séquence d'événements. Si des opérations ultérieures doivent interroger l'objet, celui-ci doit exister dans la base de données, et il est donc important de savoir que l'objet existera à cet endroit.

Lire les objets persistants Haut de la page

Il est nécessaire de récupérer des objets de la mémoire d'objet persistante avant que l'application puisse envoyer des messages à cet objet. Rappelez-vous que le travail dans un système orienté objet est effectué en envoyant des messages aux objets. Mais si l'objet auquel vous souhaitez envoyer un message est dans la base de données mais pas encore en mémoire, c'est problématique : vous ne pouvez pas envoyer de message à quelque chose qui n'existe pas encore !

En résumé, vous devez envoyer un message à un objet qui sait comment interroger la base de données, récupérer l'objet correct, et l'instancier. Ensuite, et pas avant, vous pouvez envoyer le message d'origine de votre choix. L'objet qui instancie un objet persistant est parfois appelé une classe d'objets. Une classe d'objets est responsable de la création d'instances d'objets, y compris des objets persistants. Après être interrogée, la classe objet peut être conçue pour renvoyer un ensemble d'un ou plusieurs objets correspondant à la requête.

Les objets sont généralement largement connectés les uns aux autres par le biais de leurs associations, il est donc généralement suffisant de récupérer l'objet racine dans un graphique d'objet ; les autres sont essentiellement "retirés"de la base de données de façon transparente par leurs associations avec l'objet racine. (Un bon mécanisme de persistance permet d'effectuer cette action intelligemment : il ne récupère que les objets requis ; sinon, nous pourrions tenter d'instancier un grand nombre d'objets sans que cela ne soit nécessaire. Récupérer des objets avant qu'ils ne soient nécessaires est l'un des principaux problèmes de performance dus à des mécanismes de persistance simplistes.)

L'exemple suivant montre comment la récupération d'objets à partir de la mémoire d'objet persistante peut être modélisée. Dans un véritable diagramme de fonctionnement, le SGBD ne sera pas affiché, car il sera encapsulé dans la classe objet.

Diagramme décrit dans le texte d'accompagnement.

Supprimer les objets persistants Haut de la page

Le problème des objets persistants est très simple : ils persistent ! Contrairement aux objets temporaires qui disparaissent lorsque le processus qui les a créé meurt, les objets persistants existent jusqu'à ce qu'ils soient supprimés explicitement. Il est donc important de supprimer l'objet lorsqu'il n'est plus utilisé.

Le problème, c'est que c'est difficile à déterminer. Le fait qu'une application a fini d'utiliser un objet ne signifie pas que toutes les applications, présentes et futures, en ont terminé. De plus, dans la mesure où les objets peuvent avoir et ont effectivement des associations dont ils ne sont même pas conscients, ce n'est pas toujours facile de déterminer s'il faut supprimer un objet.

Pendant la conception, on peut représenter ce fait de façon sémantique en utilisant des diagrammes d'état : lorsque l'objet atteint l'état de fin, on peut le désigner comme libéré. Les développeurs responsables de l'implémentation des classes persistantes peuvent ensuite utiliser les informations du diagramme d'état-transition pour appeler le comportement de mécanisme de persistance approprié afin de libérer l'objet. Le concepteur de la réalisation du cas d'utilisation est chargé d'appeler les opérations appropriées pour que l'objet atteigne son état de fin lorsqu'il doit être supprimé.

Si un objet est largement connecté à d'autres objets, il peut être difficile de déterminer si cet objet doit être supprimé. Dans la mesure où une classe d'objets connaît la structure de l'objet ainsi que les objets auxquels il est connecté, il est souvent utile de charger la classe d'objets d'une classe de déterminer si une instance spécifique peut être supprimée. L'infrastructure préinstallée de persistance peut aussi prendre en charge cette capacité.

Modéliser les transactions Haut de la page

Les transactions définissent un ensemble d'interrogations d'opérations qui sont atomiques ; soit elles sont toutes effectuées, soit aucune d'entre elles n'est effectuée. Dans le contexte de la persistance, une transaction définit un ensemble de changements effectuée sur un ensemble d'objets qui sont soit tous exécutés soit aucun d'entre eux. Les transactions permettent une cohérence, en garantissant que des ensembles d'objets se déplacent d'un état cohérent à l'autre.

Il y a plusieurs possibilités pour afficher les transactions dans les réalisations de cas d'utilisation :

  • Textuellement. En utilisant des scripts dans la marge du diagramme de fonctionnement, les frontières de transactions peuvent être documentées comme montré ci-dessus. Cette méthode est simple, et permet d'utiliser un certain nombre de mécanismes pour implémenter la transaction.

Diagramme décrit dans le texte d'accompagnement.

Représenter les frontières de transaction en utilisant des commentaires textuels.

  • En utilisant des messages explicites. Si le mécanisme de gestion de la transaction utilisée utilise des messages explicites pour commencer et terminer les transactions, ces messages peuvent être affichés de façon explicite dans le diagramme de fonctionnement, comme ci-dessous :

Diagramme décrit dans le texte d'accompagnement

Un diagramme de fonctionnement montrant des messages explicites pour débuter et terminer les transactions.

Traiter les conditions d'erreurHaut de la page

Si toutes les opérations définies dans une transaction ne peuvent pas être exécutées (généralement parce qu'une erreur a eu lieu), la transaction est abandonnée, et tous les changements faits pendant la transaction sont annulés. Les conditions d'erreurs prévues représentent souvent des flots d'événements exceptionnels dans les cas d'utilisation. Dans d'autres cas, les conditions d'erreur ont lieu à cause d'une défaillance du système. Les conditions d'erreur doivent être également documentées dans les interactions. Les erreurs et les exceptions simples peuvent être montrées dans l'interaction lorsqu'elles ont lieu ; les erreurs et les exceptions complexes peuvent nécessiter leurs propres interactions.

Les modes de défaillance d'objets spécifiques peuvent apparaître dans les diagrammes d'état. Le flot conditionnel de traitement du contrôle de ces modes de défaillance peut être montré dans l'interaction dans laquelle l'erreur ou l'exception a lieu.

Traiter le contrôle de la simultanéité Haut de la page

La simultanéité décrit le contrôle de l'accès à des ressources systèmes vitales lors d'une transaction. Pour que l'état du système demeure cohérent, une transaction peut demander à ce que celui-ci ait un accès exclusif à certaines ressources clé du système. L'exclusivité peut inclure la capacité de lire un ensemble d'objets, d'écrire un ensemble d'objets ou à la fois de lire et d'écrire un ensemble d'objets.

Voici un exemple simple des raisons pour lesquelles nous pouvons être amenés à restreindre l'accès à un ensemble d'objets. Supposons que nous exécutons un simple système de saisie des commandes. Les clients appellent pour prendre commande, et nous traitons les commandes et les expédions. Nous pouvons considérer la commande comme un type de transaction.

Pour illustrer le besoin d'un contrôle de la simultanéité, supposons que j'appelle pour commander une nouvelle paire de chaussures de marche. Lorsque la commande est saisie dans le système, celui-ci vérifie que le type de chaussures de marche que je souhaite et que la taille correcte est en stock. Si c'est le cas, il faut réserver cette paire, afin que personne d'autre ne puisse les acheter avant que la commande ne soit envoyée. Une fois que la commande est envoyée, les chaussures sont supprimées du stock.

Entre le moment où la commande est prise et où elle est envoyée, les chaussures sont dans un état particulier&#151elles sont en stock, mais "portées" à ma commande. Si ma commande est annulée pour quelque raison que ce soit (j'ai changé d'avis, ou ma carte de crédit est périmée), les chaussures retournent en stock. Une fois la commande envoyée, nous supposons que notre petite entreprise ne souhaite pas garder de trace du fait qu'elle possédait les chaussures auparavant.

L'objectif de la simultanéité, comme des transactions, est de s'assurer que le système passe d'un état cohérent à un autre. De plus, la simultanéité s'attache à s'assurer qu'une transaction possède toutes les ressources nécessaires pour terminer son travail. Le contrôle de la simultanéité peut être implémenté de nombreuses différentes façons, y compris le verrouillage de ressource, les sémaphores, les verrous de mémoire partagée, et les espaces de travail personnalisés.

Dans un système orienté objet, il est difficile de déterminer, uniquement à partir des patterns de message, si un message spécifique entraînera un changement d'état dans un objet. De plus, les diverses implémentations peuvent prévenir le besoin de restreindre l'accès à certains types de ressources ; par exemple, certaines implémentations fournissent à chaque transaction sa propre vue de l'état du système au début de la transaction. Dans ce cas, d'autres processus peuvent changer l'état d'un objet dans affecter la "vue" de toute autre transaction exécutante.

Pour éviter d'entraver l'implémentation, pendant la conception nous souhaitons seulement indiquer les ressources auxquelles la transaction doit avoir un accès exclusif. En utilisant notre exemple précédent, nous souhaitons indiquer que nous avons besoin d'un accès exclusif aux chaussures que nous avons commandées. Une alternative simple consiste à annoter la description du message envoyé en indiquant que l'application requiert un accès exclusif à l'objet. L'implémenteur peut ensuite utiliser cette information pour déterminer la meilleure façon d'implémenter l'exigence de simultanéité. Un exemple de diagramme de fonctionnement montrant une annotation indiquant quels messages nécessitent un accès exclusif est montré ci-dessous. On suppose que tous les verrouillages sont supprimés lorsque la transaction est terminée.

Diagramme décrit dans le texte d'accompagnement.

Exemple montrant un contrôle d'accès annoté dans un diagramme de fonctionnement.

On ne limite pas l'accès à tous les objets nécessaires à une transaction car dans bien des cas seuls quelques objets doivent avoir des restrictions d'accès ; restreindre l'accès à tous les objets participant à une transaction gâche des ressources de valeur et pourrait créer, plutôt que d'éviter, des goulots d'étranglement de performance.

Affiner la description du flot d'événements Haut de la page

Dans le flot d'événements de la réalisation du cas d'utilisation vous devrez peut-être ajouter des descriptions supplémentaires aux diagrammes de fonctionnement, lorsque le flot d'événements n'est pas suffisamment clair à partir du simple examen des messages envoyés entre les objets participants. Des exemples incluent des cas où des commentaires au sujet du calendrier ou du comportement conditionnel ou des éclaircissements sur le comportement d'opération sont nécessaires afin de faciliter la lecture des diagrammes pour les observateurs externes.

Le flot des événements est initialement décrit dans l'Activité : Analyse de cas d'utilisation. Dans cette étape vous affinez le flot d'événements selon les besoins afin de clarifier les diagrammes de fonctionnement.

Souvent, le nom de l'opération ne suffit pas pour comprendre pourquoi l'opération est effectuée. Des commentaires textuels ou des scripts dans la marge du diagramme peuvent être nécessaires afin de clarifier le diagramme de fonctionnement. Il peut être également nécessaire d'utiliser des commentaires textuels et des scripts pour représenter le flot de contrôle comme les étapes décisionnaires, la mise en boucle et l'ébranchage. De plus, des balises textuelles peuvent s'avérer nécessaire afin de mettre en corrélation les points d'extension du cas d'utilisation et des emplacements spécifiques des diagrammes de fonctionnement.

Des exemples précédents de cette activité ont illustré un certain nombre de façons d'annoter les diagrammes de fonctionnement.



Unifier les classes et les sous-systèmes de conception Haut de la page

Au fur et à mesure que les cas d'utilisation sont réalisés, vous devez unifier les classes et les sous-systèmes de conception identifiés pour garantir l'homogénéité et la cohérence du modèle de conception.

Eléments à prendre en compte :

  • Les noms des éléments de modèle doivent décrire leur fonction.
  • Evitez les noms similaires et les synonymes car ils compliquent la distinction entre les éléments de modèle.
  • Fusionnez les éléments de modèles définissant des comportements similaires ou représentant le même phénomène.
  • Fusionnez les classes d'entité qui représentent le même concept ou possèdent les mêmes attributs, même si leur comportement défini diffère.
  • Utilisez l'héritage pour extraire les éléments modèles, ce qui rend généralement le modèle plus robuste.
  • Lors de la mise à jour d'un élément de modèle, mettez également à jour la description du flot correspondant d'événements des réalisations de cas d'utilisation.

Evaluer vos résultats Haut de la page

Vérifiez le modèle de conception à ce stade pour vous assurer que votre travail va dans la bonne direction. Il est inutile de réviser le modèle en détails, mais prenez en compte les Points de contrôle pour le modèle de conception lorsque vous travaillez sur celui-ci.

Voir en particulier points de contrôle pour les réalisations de cas d'utilisation dans l'Activité: Réviser la conception.

Représentation UML 1.xHaut de la page

Vous pouvez utiliser une classe mandataire pour représenter le sous-système dans des diagrammes de fonctionnement. Cette classe mandataire est contenue dans le sous-système et est utilisée pour représenter le sous-système dans des diagrammes ne prenant pas en charge l'utilisation directe de packages et de sous-systèmes en tant qu'éléments comportementaux. Utilisez la classe mandataire dans les cas où vous souhaitez montrer qu'un sous-système spécifique répond à un message. Dans ce cas, vous pouvez montrer des messages envoyés du sous-système mandataire à d'autres objets.

Référez-vous à Différences entre UML 1.x et UML 2.0 pour plus d'informations.

RUP (Rational Unified Process)   2003.06.15