UML - Les uses cases cours 1

Présentation au sujet: "UML - Les uses cases cours 1"— Transcription de la présentation:

1 UML - Les uses cases cours 1
William Kinfoussia Consultant Expert Nouvelles Technologies Internet & Mobile

2 Préface Nous tenons à remercier tous ceux qui nous ont permis d’être aujourd’hui des experts de la mobilité, nos professeurs de l’ESTE/ESIEE et plus particulièrement M. Albert CORNEC et M. Jean CALLOT. Nous remercions également M. Clément AGANAHI pour la confiance qu’il nous accorde.

3 Introduction Le langage UML a été défini à partir des travaux de plusieurs personnes comme Booch, Jacobson et Rumbaugh pour ne citer que les plus connus. Il a été présenté pour la première fois dans sa version 0.8 en octobre Ce qui fait de lui, un langage récent qui intègre par essence les notions d’objets. UML a évolué depuis cette date et en est à sa version 1.3.

4 Introduction UML est un langage de modélisation. Il permet de décrire complètement la problématique d’un système ainsi que les solutions à apporter. Les descriptions sont abstraites et se présentent sous la forme de diagrammes contenant des éléments décomposés dans leur plus simple expression. Cette décomposition est nécessaire pour faciliter la compréhension du problème. Les outils du commerce comme Rational Rose, Rhapsody ou encore Objecttime permettent de travailler avec les différents types de diagrammes des modèles UML.

5 Introduction Les diagrammes de cas d’utilisation
Les diagrammes d’activités Les diagrammes de classes Les diagrammes d’états Les diagrammes de collaboration Les diagrammes de séquence Les diagrammes de composants Les diagrammes de déploiement Les diagrammes d’objets

6 mDictaphone mDictaphone est un dictaphone numérique qui possède les caractéristiques suivantes : Un écran LCD qui permet d’afficher les différents états et options du dictaphone, Un jogger pour activer sélectionner et activer les commandes du dictaphone, Un haut parleur pour restituer les sons enregistrés, Un micro parler pour enregistrer de nouveaux sons. Un bouton contact pour envoyer les sons à des amis inscrits

7 mDictaphone Microphone Jogger Ecran Haut parleur Bouton contact Le Jogger permet de démarrer l’enregistrement des sons et la relecture des sons. Il permet également de faire des pauses sur la lecture ou l’enregistrement, de sélectionner des sons dans le catalogue des sons pour les supprimer, les synchroniser avec une banque de sons ou encore pour les envoyer à un contact.

8 La plate-forme matérielle
L’objectif est de montrer comment réaliser ce dictaphone numérique. Pour ce faire le cours s’appuie sur une plate-forme de développement STPC, équipé d’une carte son Sound Blaster AWE64. Ainsi, les aspects liés à l’électronique, à la mécanique et au design du dictaphone ne sont pas traités. La carte STPC possède les composants suivants : Un processeur compatible avec x86. X DMA pour accélérer les transferts mémoires. Un contrôleur graphique Un contrôleur de bus PCI et de bus ISA 64 Mo de mémoire vive Un port série et un port parallèle. Les 64 Mo de mémoire disponible sur la carte vont contenir à la fois le système d’exploitation temps-réel du dictaphone et son application logicielle. La mémoire restante sera utilisée pour stocker le catalogue sons.

9 Description du contexte
A partir du langage UML, il est fort intéressant de préciser le contexte du dictaphone numérique. Dans le mot contexte, il faut comprendre l’identification des éléments qui interagissent avec le système embarqué.

10 Les acteurs Un acteur est un élément actif externe au système à construire. Il échange des messages avec le système. Il peut également être à l’origine d’événements en destination de ce même système. Un acteur représente un rôle joué par un humain ou un autre système (physique ou logiciel). Il est identifié par les notations graphiques suivants :

11 Les acteurs Mais il est tout à fait possible d’utiliser d’autres formes graphiques. L’utilisation de la notion de stéréotype permet d’étendre le langage UML et sa symbolique. Dans le cas du dictaphone numérique, sa batterie est un acteur. Il peut être représenté par le graphique ci-dessous, avec pour stéréotype « batterie ». L’élève qui participe au cours est également un acteur du dictaphone numérique. Il est à l’origine de l’ensemble des messages échangés.

12 Les acteurs TD TP Identifier tous les acteurs de mDictaphone
Ajouter des stéréotypes pour mieux identifier les acteurs du système

13 Les messages Un message est une ou plusieurs informations envoyées par un objet à un autre objet. L’objet qui reçoit le message, le considère comme un événement. Un événement provoque une action précise. Dans la description d’un contexte, on utilise les messages pour représenter les interactions, le protocole de communication entre un acteur et le système qu’il manipule. L’acteur peut envoyer des messages au système. Et de la même façon un système peut envoyer des messages à un acteur.

14 Les messages Dans les systèmes embarqués et temps réel, il faut être en mesure d’identifier les contraintes temporelles des événements, ainsi que leurs périodicités. Pour l’identification de ces messages ou événements, il est conseillé de dresser au préalable un tableau qui énumère les pré-requis du système.

15 Les messages TD : Dresser le tableau des messages avec les têtes de colonnes suivantes : Evénement Réponse du système Direction Périodicité Temps réel

16 Les capteurs et actionneurs
Tout système embarqué possède des actionneurs et des capteurs. Un actionneur est un dispositif d’un système qui permet d’enclencher des actions à travers un moyen physique. C’est un périphérique de sortie du système. Un capteur est un dispositif d’un système qui sert à détecter, sous forme de signal souvent électrique, un phénomène physique afin de le représenter. C’est un périphérique d’entrée du système.

17 Les capteurs et les actionneurs
Dans la définition du contexte,  il est important de représenter la présence des actionneurs et des capteurs par un objet nommé « actionneurs/acteurs ». mDictaphone dispose des actionneurs et capteurs suivants : Le bouton jogger Le bouton contact L’écran LCD Le microphone Le haut-parleur La sonde de mesure de la batterie La sonde du support de synchronisation

18 Les interfaces Tout système embarqué possède des interfaces de communications avec des éléments électroniques. Dans un diagramme de contexte, il est aussi important de représenter les interfaces par un objet nommé « interfaces »

19 Le contexte Le contexte se décrit à partir d’un diagramme de collaboration, sur lequel on retrouve les objets cités ci-dessus et un objet particulier que l’on appelle tout simplement « système ». Ce dernier représente le système embarqué à décrire. Sur le diagramme de collaboration, on exprime les échanges (messages) entre les acteurs et le système sans prendre en compte les aspects temporels.

20 Le contexte Le diagramme suivant montre le diagramme de contexte du dictaphone numérique 

21 Le contexte TP : Réaliser le diagramme de contexte sous votre outil de modélisation UML Remarques : dans les systèmes d’information, il n’existe pas d’actionneurs/capteurs et d’interfaces. On ne les représente pas dans un diagramme de contexte.

22 Un cas d’utilisation Un cas d’utilisation permet de décrire une façon d’utiliser un service ou une fonctionnalité du système que l’on modélise. Il définit les différents scénarii d’interaction entre un acteur et le système. Le cas d’utilisation s’identifie par la représentation graphique suivante :

23 Les cas d’utilisation On utilise le diagramme des cas d’utilisation pour regrouper et structurer l’ensemble des cas d’utilisation d’un système. Sur ces diagrammes on montre l’interaction entre l’acteur et les cas d’utilisation par des relations de communication. Le diagramme suivant montre le système mDictaphone et ses cas d’utilisation de base.

24 Les relations entre les cas d’utilisation
UML offre par le mécanisme des relations la possibilité d’affiner la définition des cas d’utilisation. La première relation est celle de « l’inclusion ». Elle permet de dire qu’un cas d’utilisation intègre dans son cheminement un autre cas d’utilisation. Par contre ce dernier cas d’utilisation ne peut être exécuté tout seul. Pour mDictaphone on rencontre la situation avec les cas d’utilisation « écouter un son » et « envoyer un son à un contact ».

25 Les relations entre les cas d’utilisation
Effectivement, il n’est pas envisageable d’écouter un son si l’on ne l’a pas sélectionné auparavant. Il n’est pas possible, également, d’envoyer un son à un contact si au préalable on n’a pas sélectionné le son et le contact. Ces deux contraintes entre cas d’utilisation se traduisent par des relations de dépendances stéréotypées « include », comme le montre le schéma suivant : (*) La flèche de la relation va de celui qui inclue à celui qui est inclus.

26 Les relations entre les cas d’utilisation
La deuxième relation est celle de « l’extension ». Elle permet de dire qu’un cas d’utilisation étend le fonctionnement d’un autre cas d’utilisation. Le cas d’utilisation étendu peut s’exécuter indépendamment de celui qui l’étend. mDictaphone ne possède aucun dispositif qui permette d’envoyer un message à un contact par internet. C’est pourquoi pour réussir cette opération il faut absolument passer par une procédure de synchronisation afin que l’ordinateur hôte se charge d’envoyer le message.

27 Les relations entre les cas d’utilisation
Ce qu’il faut comprendre c’est que le cas d’utilisation envoyer un son à un contact n’est rien d’autre qu’une forme d’extension du cas d’utilisation synchroniser les données. Cela se représente par une relation de dépendance stéréotypé « extend ». (*) La flèche de la relation va de celui qui est étendu à celui qui étend.

28 Les relations entre les cas d’utilisation
La dernière relation est celle de la « généralisation ». Elle permet de factoriser un cas d’utilisation. Dans mDictaphone, sélectionner un son et sélectionner un contact se relèvent être des tâches identiques. La seule différence réside dans le fait que les sons sont sélectionnés dans un catalogue de sons et les contacts sont sélectionnés dans un catalogue de contacts.

29 Les relations entre les cas d’utilisation
Il est judicieux de factoriser ce comportement dans un cas d’utilisation générique « sélectionner un élément » et de lier les deux cas d’utilisation à cette dernière par une relation de généralisation

30 Les relations entre les cas d’utilisation
TP : Réaliser le diagramme des cas d’utilisation suivant :

31 Un cas d’utilisation Un cas d’utilisation nécessite parfois une description plus détaillée. La façon la plus naturelle de la faire est de passer par un formalisme textuelle. TD : Faire la description d’un cas d’utilisation.