Glossaire

Acteurs Cas d'Utilisation Controles Domaine Flots d'évènements Entité Extend Interfaces Objets du domaine Langage du Domaine scénario stéréotypes Uses

Acteurs

Un acteur est une personne ou un système extérieur au système en cours de modélisation qui
interagit avec notre système. Pour plus de détails voire la page Acteurs.

Cas d'Utilisation

Les cas d'utilisations décrivent les fonctionnalités fournies par le système à un acteur . Pour plus de détails voire la page Cas D'utilisation.

Controles

Nous avons partitionné nos services en Interface et Entité. Il est parfois possible pour certains services que l'ensemble du service soit défini par des objets de ces types. Dans ce cas, aucun Contrôle n'est nécessaire dans ce service. Mais dans les cas complexes, il reste des comportements qui n'ont pu être placés dans aucun des deux types d'objets. Ces comportements sont placés dans les Contrôles. Il est possible de distribuer ces comportements dans les deux autres types d'objet mais cela n'est pas idéal pour l'adaptation au changement et le principe de localité. Un changement de comportement défini sur plusieurs objets demande un gros travail de correction. Nous étudirons ce problème plus en détail dans la construction du modèle de conception.
Le rôle des Contrôles est de servir de ciment pour relier les autres objets de façon à réaliser le service en entier. Ils sont en général très éphémères, et leur durée est souvent celle du service.
Nous allons donner ici quelques heuristiques pour le découpage souvent délicat des services sur nos trois types d'objets.
Comme les autres objets, c'est la description du service qui va nous permettre de trouver la première génration de Contrôles. Nous avons déjà extrait de nos services les Interface et les Entité , les comportements restant doivent être alloués à des Contrôles.
De cette règle initiale quelques déviations peuvent être réalisées.
Premièrement : il ne reste plus de comportement à modéliser.
Ensuite : si le comportement qui reste est extrèmement complexe, plus d'un Contrôle sera nécessaire. Ces Contrôles auront des tâches limitées et seront donc plus simples à décrire et comprendre. Si par exemple un Contrôle est connecté à plusieurs acteurs, il est possible que ce soit une preuve que le comportement est différent pour les différents acteurs, il est donc nécessaire de multiplier les Contrôles. Le but est d'attacher un seul Contrôle à chaque acteur. La raison est que les changements sont souvent liés à un seul acteur, d'où une meilleure localisation du travail (meilleure détection des zones) en cas de changement.
Les compoprtements les plus typiques liés à un Contrôle sont les comportements transactionels, des contrôles de séquences liés à un ou plusieurs services, ou des fonctionalités qui séparent les interfaces des entités. Les Contrôles relient des suites d'évènements et réalisent ainsi les communications entre les différents objets.
La description des Contrôles est trouvée de façon indirecte à partir des services en vérifiant comment les services consomment les autres types d'objets. Là où un Contrôle est trouvé on explicite par une description le rôle et ce qu'implique ce rôle.
Les associations d'utilisation entre services sont souvent associées à des communications à travers les objets correspondants. Si les services ont une relation d'extention elles se retrouvent dans une relation d'extention entre les objets.

Domaine

L'environnement dans lequel le système doit être construit, c'est l'environnement dans lequel le client est le spécialiste, on parle des Objets du domaine, c'est à dire les entités réelles ou conceptuelles que manipule le client et le système, il est plus facile en effet de travailler avec ces objets pour le clients et il vous seras plus facile de concevoir le système si vous connaissez et comprenez les Objets du Domaine.

Flots d'évènements

Associé a un cas d'utilisation, le flot d'évènements est une description dans le langage du domaine avec les Objets du Domaine de la suite des évènements qui permettent d'accomplir la fonctionnalité requise du cas d'utilisation.

Entité

Les Entités sont les objets qui modèlisent les informations que le système doit manipuler sur une longue periode de temps. Ces informations survivent aux Cas d'Utilisation. Aux information nous associons évidement le comportement qui va avec ces informations.
Les Entités sont identifées à partir des Cas d'Utilisation, comme les Interfaces. La plus part des Entités sont trouvés dès le début et sont souvent apparants dans Les Objets du Domaine. D'autre peuvent être plus coriaces. Les Entités sont en général associé a des concept extérieur au système, mais ce n'est pas toujour le cas. La plus grande difficulté est de modulisé la bonne quantité d'Entités seulment ceuxc qui sont necéssaires. Seuls les Entités qui sont utiles aux Cas d'Utilisation doivent apparaitrent.
Pour stoker des informations les objets utilisent un ou plusieurs attributs . Chaque attribut à un type soit prédéfini soit plus complexe et spécialement défini. Un attribut est défini comme une association de l'objet avec (étiquette d'un nom et d'une cardinalité) un type.
Une des difficultés est en général de trouver la limite entre Entité et Attributs.
Les attributs d'un objet Entité évoluent avec l'analyse des Cas d'Utilisation.

Extend (Stéréotype)

XXX a définir Voir Diagrammes de Cas d'utilisation

Interfaces

Toutes les fonctionnalités des services qui dépendent directement de ce que fait l'extérieur du système doit être placé dans un Interface2.1. C'est à travers ses objets que les acteurs communiquent avec le système. Le rôle des Interfaces est de traduire les entrées de l'acteur en évènements pour le système, et de traduire les évènements qui intéresse cet acteur en sorties. L'interface décrit une communication bi-directionnelle entre les utilisateurs et le
système.
Les objets Interfaces sont assez faciles à identifier. Trois stratégies. Soit il sont clairement identifiés dans les descriptions d'interface fournies dans le modèle d'interfaces, soit nous pouvons partir des acteurs, soit nous pouvons lire les descriptions de services et extraire les fonctionnalités qui sont spécifiques à l'interface.
Commençons par utiliser les acteurs.
Chaque acteur concret nécessite sa propre interface pour communiquer avec le système. Dans de nombreux cas l'acteur utilise plusieurs Interfaces. Dans notre cas les deux acteurs utilise un Interface commun et tous deux ont un ou deux Interfaces spécifiques. Trouver un Interface associé à un acteur Abstrait n'est pas toujours possible. Utilisons maintenant la stratégie qui consiste à lire les descriptions de services pour trouver les Interfaces.
l est évident que les Interfaces ne sont pas indépendants les un des autres, ils doivent se connaitre pour
résoudre certains travaux. Nous introduisons une relation de connaissance2.2, pour modéliser cette information.
Cette relation de connaissance est une relation statique.
Elle ne signifie pas un droit d'échange d'information mais une possibilité de relation dynamique (exemple : Figure
2.4).
Un objet peut associer plusieurs objets du même type d'où une relations défini avec une arité (cardinalité). Cette
cardinalité indique le nombre d'objets du type que l'on peut associer.
Deux grands types d'Interface.

Il faut distinguer entre les Interface vers d'autres systèmes et les Interface pour les utilisateurs humains (I.H.M.).

Protocoles :
     Il faut toujours définir un objet Interface pour les protocoles avec des parties extérieur au système ceci de
     façons à pouvoir changer de protocole facilement (changement de couche OSI par exemple), ceci que l'objet
     ait un gros traitement à réaliser où ne fait que transférer un stimuli. Un cas d'importance est le cas des
     transformations de signaux continus venant de l'extérieur, en informations discrètes pour le système, ceci
     doit être spécifié et géré dans l'Interface2.3.
I.H.M. :
     Les I.H.M. graphiques sont souvent des objets extrêmement complexes et doivent être modélisés par des
     structures complètes internes à nos Interfaces. Le problème de l'I.H.M. peut se révélé été un des points
     fondementaux de votre système jusqu'a 80% pour des applications qui utilisent l'interface intensivement. On
     cherchera alors à utiliser un outil de développement d'interface graphique sur un support graphique bien
     distribué.

Le rôle des différents types d'objet sera discuté plus en détail plus loing, mais il est normal qu'une part de contrôle
et une part d'information apparaissent dans les interfaces. Mais ce qui doit être placé dans les interfaces doit
être étudier cas par cas.
Comment dans un service extraire ce qui doit être placé dans un Interface donné? Tout changement de
fonctionalité dans l'interface doit être local a un Interface. De même les autres changements ne doivent pas
affecté les Interfaces. Les développeur expérimentés sont ingénieux pour trouver des changement possible, c'est
un savoir-faire à développer et à utiliser dans toutes les techniques de modélisation. Toutes les approches d'un
modèle donné doivent être éclairée par les possibilités de changement.

Allocation de fonctionalités aux Interfaces

Pour identifer les partie du service qui sont allouée aux Interfacesnous devons regarder attentivement les
interractions entre les acteurs et le service. Nous cherchons des unités qui ont les caractèristiques suivantes :

     Elles presente des informations à l'acteur ou lui en demande.
     Leurs fonctionnalités changent si le comportement de l'acteur change.
     Leurs parcour est dépendant du type de l'interface.

Contrôle dominé par le Calcul

Les fonctionalités de contrôle sont placées uniquement dans les contrôles et les entités.

Pour

Approche efficasse

Contre

Difficile à prototyper (Comme le contenu de effectif de l'interface n'est connu que tard dans le développement).

Contrôle dominé par le Dialogue

Les fonctionalités de contrôle sont placées dans les interface.

Pour

Prototype aisé, qui modélise une partie importante du système.

Contre

Acroissement de la complexité de l'interface, manque de contrôle sur notre modèle.

Contrôle Mixte

Répartion des deux cotés.

Pour

la flexibilité.

Contre

requière beaucoup de discipline de la part des développeurs pour rester indépendant du dialogue entre interface et calcul.

Contrôle Equilibré

Le contrôle est indépendant de l'interface et du calcul.

Pour

la flexibilité, le contrôle, la réutilisation, la modularité.

Contre
?

Objets du Domaine

Les Objets du domaine sont les entités réelles ou conceptuelles que manipule le client et le système. Il sont utilisé a la fois pour écrire le modèle des besoins mais aussi sont un bon point de départ pour trouver les classes de notre système.

Langage du Domaine

Le langage du domaine est le langage du Clients ou du spécialiste avec lequel on écrit le modèle des Besoins.
Il est en général de bon goût de créer un Glossaire de termes utilisé par tous dans l'écriture du modèle des besoins, ce glossaire défini le langage du domaine.

scénario

Un scénario est un chemin particulier au travers de la description abstraite et général fournie par le cas d'utilisation. Les scénarios traverse le cas d'utilisation, en suivant le chemin nominal des chemins alternatifs et exceptionnels. L'explosion combinatoire fait qu'il est bien souvent impossible de dérouler tous les scénarios (toutes les combinaison du chemin principal avec les chemins alternatifs et exceptionnels).

stéréotypes

XXX

Uses (stéréotype)

XXX a définir Voir Diagrammes de Cas d'utilisation