|
MODULE No 19 |
|
Titre : Diagramme de séquence (DS) du système avec contrat |
|
But : Présenter les diagrammes de séquence de UML et un gabarit pour les contrats |
|
Antécédents : Module 18 |
|
Corps : Avant tout il faut avoir bien clair en tête la différence entre les diagrammes de structure et diagrammes de comportement. Les diagrammes de structure montrent les liens statiques entre les éléments : entre les classes (concepts) ou entre les objets (individus). Ils peuvent aussi montrer les relations entres classes et objets mais cela est moins communs et moins utile (au moins pour notre cours). Dans le cours on a déjà vu plusieurs diagrammes de structure. Ce que l’on n’a pas vu, par contre, ce sont les diagrammes qui décrivent le comportement : les diagrammes dans lesquels la composante « temps » est fondamentale. Même si on n’a pas vu de diagrammes qui représentent le comportement d’un système on a vu les fiches des CU qui sont un moyen pour décrire en langue naturelle le comportement du système dans ses échanges avec les acteurs. Les DS sont des diagrammes qui montrent les échanges de messages entre des entités. Les DS du système (les seuls que l’on aborde dans ce cours) sont des diagrammes de séquence qui montrent les messages échangés entre les acteurs et le système (la machine dans notre terminologie). Ils sont une représentation alternative des CU par rapport aux fiches des CU déjà vues. Voici la définition de diagramme de séquence du manuel de UML : « Un diagramme qui montre les interactions des objets organisées en une séquence temporelle. En particulier il montre les objets qui interagissent et la séquence des messages échangés. » Les seuls objets que nous considérerons dans notre cours ce sont les acteurs et la machine à réaliser : Résultats dans le TP 1 et le GA pour notre exemple bancaire. À la fin de ce document vous trouvez un DS qui montre les interactions entre un guichet automatique, un client et l’ordinateur de front-end (FE). Pratiquement il s’agit d’une réécriture du CU que l’on a vu pendant le cours précédent, avec l’ajout de quelques messages vers le FE. Les lignes verticales dans un DS représentent le temps (le temps avance du haut vers le bas) et les lignes horizontales représentent les messages échangés. La distance en vertical entre les messages n’est pas proportionnelle au temps écoulé : la seule indication que l’on a, c’est que ce qui est en bas vient après ce qui est en haut (le numéro qui précède les messages indique lui aussi l’ordre temporel). Comme vous pouvez le constater, le DS ci-dessous n’est qu’une manière différente de dire ce que l’on avait vu dans le module 18 (avec quelques détails en plus). Mais qu’est-ce que tout ? Ce que le système doit faire quand il reçoit le message, les antécédents, les conséquents, les exceptions… Pour faire cela on peut définir un contrat qui doit être respecté par le système et par les acteurs. Contrat Qu’est-ce qu’un contrat ? Selon Le Robert : « Convention par laquelle une ou plusieurs personnes s'obligent, envers une ou plusieurs autres, à donner, à faire ou à ne pas faire quelque chose ». Par analogie nous pouvons écrire : « Convention par laquelle un système s’engage à faire ou ne pas faire quelque chose ». Un contrat doit être clair, non ambigu, précis, réaliste, etc. Un contrat avec une machine ne doit surtout pas avoir des éléments tacites car si la machine ne fera pas ce que l’on veut même les meilleurs avocats ne pourront pas nous faire gagner la cause. Voici un gabarit pour les contrats qui fixe comment décrire ce que la machine (surtout) doit respecter : *** Nom : Nom du contrat. Le nom peut avoir associé des paramètres : ce sont les informations passées au système pour lui permettre de faire ce que le contrat demande. Responsabilités : description des responsabilités du système suite à la réception du message. Intrants : Informations véhiculées par le message envoyé par l’acteur (paramètres de l’opération en Rational Rose) Type : type de l’élément responsable (système, classe ou interface). Dans notre cas il s’agit du système. Références : Exigences, CU, etc. Indique la source du contrat Commentaires : commentaires sur les algorithmes, la conception… tout ce qui peut être utile pour comprendre l’opération. Exceptions : cas exceptionnels (erreurs) et dignes d’êtres présentés Extrants : données en sortie vers d’autres systèmes Antécédents (ou pré conditions) : conditions du système qui doivent être vraies avant le début de l’opération de traitement du message. Conséquents (ou post conditions) : conditions du système qui doivent être vraies après l’exécution de l’opération de traitement du message. *** Considérons maintenant comment on peut gérer les
contrats avec un outil comme Rational Rose (RR). Je vous rappelle que dans Si vous représentez les DS en RR toutes les fois que vous ajoutez un message, RR crée une opération dans la classe de l’objet qui reçoit le message. Notre système pour RR est une « classe » : la classe qui contient toutes les classes qui, en s’échangeant des messages, réaliseront les fonctions demandées. Dans le DS du guichet, RR a créé les opérations suivantes dans GA :
Pour chaque opération en plus de son nom vous pouvez (vous devez si les normes de votre entreprise l’impose) saisir :
· Séquentielle : le travail exécuté par la classe est assuré si et seulement si il y a un seul fil d’exécution (Thread) · Synchrone : le travail exécuté par la classe est assuré même avec plusieurs fils d’exécution et c’est la classe qui assure l’exclusion mutuelle · Conditions de garde : le travail exécuté par la classe est assuré même avec plusieurs fils d’exécution. L’exclusion mutuelle doit être réalisée par les clients.
Analyse détaillée de quelques messages
Dans le DS ci-dessous le système (la machine) GA reste « fermé » (on ne dit rien sur ce qui se passe à son intérieur) même si on montre l’interaction avec le FE. Nous avons ouvert le système bancaire mais non le guichet ! Nous avons ouvert le système bancaire car nous avons fait l’hypothèse que le GA devait s’insérer dans un système où il devait respecter les échanges entre le FE et le terminal employé par les employés de la banque. Mais si on veut réaliser le GA il faut, à un certain moment « l’ouvrir » : c’est-à-dire il faut commencer à analyser son intérieur… mais que veut-on dire avec intérieur ? Sa structure ? Quelle structure ? Ses fonctions ? S’il s’agit de sa structure
« informatique » on n’est plus dans
l’analyse mais dans Considérons un contrat pour « entrer montant » du diagramme précédent. Nom : Entrer montant. Responsabilités : donner le montant
demandé s’il y a assez de fonds. Intrant : Montant (chaîne de max 12 caractères de longueur) Type : Système (GA). Références : CU-012. Commentaires : La longueur et le format du montant sont définies dans le document xyz. Exceptions : si le montant
supérieur au fond disponible dans le compte du client alors afficher
le message d’erreur No 23 dans la langue choisie par le client. Extrants : Montant vers le FE Antécédents (ou pré conditions) : client accepté. Conséquents (ou post conditions) : argent dans le guichet = argent à l’origine moins le montant sorti. Note D’habitude on
n’écrit pas un contrat pour chaque message parce que les
informations apparaissent déjà dans le diagramme conceptuel ou
dans la description des exigences… Fin
de la note Pour satisfaire ce contrat le GA demande l’intervention du FE (en réalité le FE n’est qu’une passerelle vers l’ordinateur de la banque qui gère les comptes) : donc ces fonctions sont :
Est-ce que ce détail fait partie de l’analyse ? La réponse n’est pas facile et dépend du contexte et de l’approche dans le développement. Si les concepts de client, de compte, et de montant ont déjà été définis et si les formats et la transaction ont aussi été définis alors on peut dire que pour la réalisation du GA on n’a plus besoin d’analyser le domaine mais seulement d’« analyser » le partage des fonctions entre le matériel et le logiciel du GA. Une fois que le partage a été fait alors il n’y a pratiquement que de la conception et du codage. Ce qui risque d’être compliqué dans la réalisation du GA ce ne sera pas tellement la mise en œuvre des fonctions mais le respect des exigences non fonctionnelles : temps de réponse, fiabilité, sécurité, etc. Si on revient à notre problème du début « concevoir un GA qui simule un employé de la banque et son terminal pour un sous-ensemble des fonctions réalisée par l’employé », il est clair que les CU peuvent être utiles car les frontières sont préfixées (au moins les frontières vers le FE). Mais les vraies difficultés dans l’analyse du GA sont surtout liées à : 1. Conception de l’interface personne-machine. Ce qui demande donc d’introduire un cycle de vie de la facilité d’utilisation. 2. Établissement des exigences non fonctionnelles. Ce qui implique une connaissance des contraintes technologiques pour ne pas demandes « la lune ». |
|
Conséquent : Pouvoir employer les DS pour les CU |
|
Notes : 1) À propos de « la manière de dire les choses » : souvent en génie logiciel la manière compte énormément |
