Pour le contrôle

Trouver la clé du succès

Maintenant que vous maîtrisez les bases de l’UML, il va falloir se préparer pour votre contrôle. En guise de contrôle, je vous ferai un petit quiz sur toutes les notions que nous avons pu voir ensemble.

Avant toute chose, il est évident qu’il est nécessaire d’avoir lu les différents cours disponibles sur ce site (Glossaire, Diagramme de cas d’utilisation, Diagramme de classe, Diagramme de séquence et Modélisation au code). Si cela est fait, nous pouvons continuer.

Vous trouverez ici un sujet tombée en contrôle à l’IUT de Nice (fait par madame Blay, disponible ici) ainsi que deux autres exercices d'entrainements (ci-dessous).
Une correction est à votre disposition et vous pourrez retrouver des astuces pour bien réussir votre contrôle.

Des exercices d'entrainement
(avec corrigé)

Avant de passer au contrôle, je vais vous donner quelque astuces/erreur à ne pas faire sur les différents diagrammes.

Le glossaire

Little Tips :
  • Vous ne savez pas quoi y mettre ? Vous avez un doute ? Demandez-vous si le terme est clair et compréhensible directement. Attention, n’oubliez pas que le glossaire ne regroupe des termes qui appartiennent au domaine à modéliser.

Le diagramme de cas d'utilisation

Little Tips :
  • Vous avez un doute sur un acteur, demandez-vous que dois modéliser votre système. Ainsi vous saurez si ce pseudo acteur doit être modéliser ou non.
  • Vous ne savez jamais quelle est le sens de l’extend ? Deux possibilités s’offre à vous pour le retenir :
    • Se souvenir que l’extend est dans le sens inverse de l’include.
    • Se souvenir que l’extend se lit dans le sens inverse de la flèche (because it’s English).

Le diagramme de classe

Little Tips :
  • Lors de la lecture de votre sujet, ne vous précipité pas, prenez le temps de bien relire plusieurs fois ainsi que de faire un premier brouillon. 
  • Bien souvent, une association n'est pas bidirectionnelle mais plutôt unidirectionnelle. Esseyer donc de vous demander si les deux classes ont besoin d'intéragir mutuellement ou non. 
  • Dans vos classes, il ne faut pas mettre les opérations "getter" et "setter".

Le diagramme de séquence

Little Tips :
  • Votre diagramme vous semble trop simple ? Posez vous la question : Y-a-t-il des acteurs ou objets que je n’ai pas spécifié ? Cela vous permettra d’avoir un diagramme plus complet mais attention à ne pas trop détailler. Rester un minimum abstrait car vous ne savez sûrement pas comment certaines parties vont être implémentées.

  • Attention, lorsque vous avez une Interface Homme Machine (IHM), il ne doit jamais y avoir de retour jusqu'à l'utilisateur car notre IHM n'imprime pas sur l'utilisateur.

Le sujet

Lisez la description de l’étude de cas en entier et toutes les questions jusqu’au bout avant de commencer. Attention, il s’agit d’une étude de cas. A vous d’établir de l’ensemble de votre lecture, les différents diagrammes demandés. Le barème est donné à titre indicatif, mais il peut être modifié. Chaque fois que vous butez sur un manque de spécification, faîtes un choix et explicitez ce choix par une note.


Avec un support financier du European Research Council, le laboratoire de Geoazur (UMR Université de Nice/CNRS/IRD) et OSEAN ont développé la `Mermaid’ (Sirène), un robot sous-marin capable de reconnaître et transmettre les signaux acoustiques de séismes. Le robot est équipé d’un hydrophone pour l’acoustique et peut accueillir d’autres capteurs pour la surveillance de paramètres physiques ou bio-chimiques. On attend de vous de modéliser une application qui permet d’étendre les capacités de ce robot à d’autres disciplines scientifiques et civiles. Voici les premiers éléments du cahier des charges (très simplifié). Le robot fait partie du système que vous devez modéliser.
En savoir plus sur ce projet : https://geoazur.oca.eu/spip.php?rubrique760

Dans le texte, nous utilisons aussi bien le terme de mermaid ou de robot pour désigner la même chose.

Avant un départ en mission du robot, les scientifiques enregistrent les tâches qu’ils désirent voir réalisées par le robot au travers d’une interface dédiée, qui est déclinée différemment en fonction des domaines : Biologie, Météorologie, Géophysique.

Ensuite, le responsable de la mission, qui est un scientifique, sélectionne les tâches préenregistrées par les scientifiques et prépare un plan de mission (Workflow) par une interface dédiée. Il peut être amené à enregistrer de nouvelles tâches. La préparation du plan exige de demander au système de vérifier que les tâches sont compatibles entre elles et cohérentes par rapport à leurs exigences en énergie par exemple.
En cours de mission, le robot peut recevoir à chaque fois qu’il monte à la surface de nouveaux plans de mission d’un satellite. Sous l’eau, il ne peut ni recevoir ni émettre de signaux.

Le responsable de la mission lâche le robot en mer et le démarre. Il peut pour cela être amené à discuter avec l’équipage du meilleur moment pour cela. Le robot peut alors recevoir son plan de mission d’un satellite puis l’exécuter.

En cours de mission, les scientifiques peuvent alors consulter les données recueillies par ces robots ; elles sont publiques et en libre accès dans un format commun au niveau européen.

Le robot est équipé d’un hydrophone pour l’acoustique et peut accueillir 8 autres capteurs pour la surveillance de paramètres physiques ou bio-chimiques. Il est capable de réaliser des mesures à une profondeur de 3000m et remonte en surface régulièrement pour recevoir des instructions et transmettre ses données par satellite. Pour se faire reconnaître une mermaid a un identifiant unique.

Scénario : Le robot reçoit un plan de mission d’un satellite. Il délègue alors l’exécution du plan de mission au « moniteur » qui lui est associé. Ce dernier lui répond lorsqu’il a terminé d’exécuter le plan de mission (cela peut inclure d’avoir interrompu le plan pour réagir à la détection d’un séisme ou une panne). A la fin de l’exécution du plan, s’il n’est pas déjà à la surface, le robot remonte puis envoie dans tous les cas un message de fin de mission vers le satellite. S’il a suffisamment de batterie, il demande un nouveau plan de mission, sinon, tant qu’il a de la batterie, il émet des signaux à une fréquence préétablie pour signaler sa position. La figure 1 vous donne un exemple typique d’utilisation du robot.

Figure 1 : Le cycle typique d’une Mermaid. En haut (de gauche à droite) : la Mermaid reçoit des instructions du satellite (Iridium), descend vers sa profondeur assignée tout en observant température, salinité et composition chimique de son environnement. En dérivant librement à une profondeur programmée (jusqu’à 3000 m), elle relève des signaux acoustiques, comme ceux de précipitations météorologiques ou d’une baleine. En bas à gauche : dans son plan de mission, elle est programmée pour revenir à la surface lorsqu’elle détecte l'arrivée de l’onde d’un tremblement de terre (ce qui pourrait aussi être la réponse d’un essai nucléaire, ou encore la boîte noire d’un avion). Arrivée à la surface, elle récupère ses coordonnées GPS et ensuite envoie l’ensemble de ses données par satellite. Les ‘scientifiques’ reçoivent ces données par un serveur e-mail. 

Question 1 : 4 pts Représentez acteurs et cas d’utilisation sur un diagramme. Question 2 : 3 pts Représenter le diagramme de séquence correspondant au scénario1 . Faîtes bien apparaitre les objets de votre application.
Question 3 : 7 pts Construire un diagramme de classes qui représente le système en intégrant uniquement les informations données dans ces spécifications.
Question 4 : 3 pts Compléter votre diagramme de classe pour prendre en compte le code suivant :

Correction
Diagramme de cas d'utilisation
UC2017Diagramme de classe
Classe2017Diagramme de séquence
sequence2017