Ici, nous allons apprendre à faire le diagramme de classe. Ce dernier a pour but de détailler la modélisatin du domaine ainsi que d'aider à la conception.

Pour aborder les différentes notions, nous diviserons le diagramme de classe en 3 niveaux : 

• Débutant
• Intermédiaire
• Avancé

 Cela nous permettra de ne pas vous surcharger avec de nombreuses notions.

Pour tous nos diagrammes, nous utiliserons le même cas que nous approfondirons (plus ou moins en fonction du niveau que vous étudiez). Elle sera basée sur un sujet disponible ici (de Mme Blay, ensaignante à l'IUT de Nice).
Il y aura une correction des différents niveaux mais retenez bien qu'il n'y a pas une unique solution lors de la modélisation. Cependant, lorsque l'on a un sujet écrit comme ici, il ne faut pas imaginer des informations qui ne nous sont pas fournies par le sujet.

• Débutant
• Intermédiaire
• Avancé

• Débutant

  Étude de cas niveau débutant

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  Pour fonctionner correctement, MyWaze a besoin d'avoir des informations minimales sur le conducteur comme son nom, son age, la date de fin de validité de son permis de conduire, son numéro de téléphone. Il a aussi besoin de savoir sur que quelle voiture (marque et modèle) il est actuellement pour pouvoir récupérer des informations sur cette dernière. Du côté de l'utilisateur, ce dernier peut se connecter au système à l'aide de son identifiant ainsi que son mot de passe. Le système lui repondra alors si ce dernier est bien connecté ou non.

  Analyser le sujet

  Lors de la lecture du sujet, il faut réussir à filtrer les informations est à garder seulement les informations nécessaire. Nous allons donc essayer d'épurer le sujet. Je vais donc vous montrer ce qu'il faut retenir du sujet.
  
  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.
  
  Pour fonctionner correctement, MyWaze a besoin d'avoir des informations minimales sur le conducteur comme son nom, son age, la date de fin de validité de son permis de conduire, son numéro de téléphone. Il a aussi besoin de savoir sur que quelle voiture (marque et modèle) il est actuellement pour pouvoir récupérer des informations sur cette dernière. Du côté de l'utilisateur, ce dernier peut se connecter au système à l'aide de son identifiant ainsi que son mot de passe. Le système lui repondra alors si ce dernier est bien connecté ou non.
  
  Nous retenons donc que les éléments barrés sont juste de la mise en contexte. Pour ce qui est des parties en gras, cela représente ce que l'on va devoir modéliser dans notre diagramme de cas d'utilisation.
  Maintenant, nous allons construire ensemble votre premier diagramme de classe.

  Ici, nous pouvons observer une première classe "conducteur"  que nous nommerons utilisateur (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici. 
  Notre utilisateur possède différents attributs comme son nom qui est une chaine de caractère (string), son age, la date de fin de validité de son permis de conduire, son numéro de téléphone qui est une chaine de caractère (string). On lui ajoute donc dans sa classe ces différents attributs. On remarque aussi qu'à la fin du texte, on apprend que l'utilisateur peut se connecter. On traduit donc cela par une opération "seConnecter". On apprend que cette opération prend deux paramètres, id et mdp qui sont des chaines de caractère (string) et qu'elle renvoie un booléen (car elle indique si la connexion a réussi). Il faut aussi ajouter ces deux paramètres dans les attributs de notre utilisateur car ces derniers lui appartiennent.

  Maintenant que nous en avons fini avec notre première classe, cherchons donc une autre classe. Dans le texte, on nous parle aussi de voiture. Cela repésente donc une classe voiture contenant deux attributs, modèle et marque. 

  À présent, vérifions qu'il n'y ai pas de liaisons entre ces deux classes. Même si ce n'est pas explicitement écrit dans le texte, une voiture est forcément liée à un utilisateur. Nous avons donc une association entre ces deux classes. En ce qui concerne les multiplicités, cela peut être interprété de plusieurs manière. Nous retiendrons donc qu'une voiture appartient à un seul utilisateur et que ce dernier peut en posséder plusieurs.

  Nous arrivons donc au diagramme de classe suivant : 

  

• Intermédiaire

  Étude de cas niveau intermédiaire

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  Pour fonctionner correctement, MyWaze a besoin d'avoir des informations minimales sur le conducteur comme son nom, son age, la date de fin de validité de son permis de conduire, son numéro de téléphone. Il a aussi besoin de savoir sur que quelle voiture (marque et modèle) il est actuellement pour pouvoir récupérer des informations sur cette dernière. Du côté de l'utilisateur, ce dernier peut se connecter au système à l'aide de son identifiant ainsi que son mot de passe. Le système lui repondra alors si ce dernier est bien connecté ou non.

  Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif ». Dans tous les cas de modèles de messages, un intitulé est associé (par exemple, Retard), un identifiant pour la reconnaissance vocale (par exemple, Late), une icône graphique (par exemple, un fichier Jpg correspondant à montre cassée), une destination. Le message en lui même contient un contenu (par exemple, «je suis en retard») et l’ensemble des informations qui devront être associées au message parmi un ensemble prédéfini : heure d'envoie du message, ... (par exemple, à un message correspondant à un Retard, la position courante et l’heure d’arrivée prévue devront être associées). 

  Analyser le sujet

  Lors de la lecture du sujet, il faut réussir à filtrer les informations est à garder seulement les informations nécessaire. Nous allons donc essayer d'épurer le sujet. Je vais donc vous montrer ce qu'il faut retenir du sujet.

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  Pour fonctionner correctement, MyWaze a besoin d'avoir des informations minimales sur le conducteur comme son nom, son age, la date de fin de validité de son permis de conduire, son numéro de téléphone. Il a aussi besoin de savoir sur que quelle voiture (marque et modèle) il est actuellement pour pouvoir récupérer des informations sur cette dernière. Du côté de l'utilisateur, ce dernier peut se connecter au système à l'aide de son identifiant ainsi que son mot de passe. Le système lui repondra alors si ce dernier est bien connecté ou non.

  Nous retenons donc que les éléments barrés sont juste de la mise en contexte. Pour ce qui est des parties en gras, cela représente ce que l'on va devoir modéliser dans notre diagramme de cas d'utilisation.
  Maintenant, nous allons construire ensemble votre premier diagramme de classe.

  Ici, nous pouvons observer une première classe "conducteur"  que nous nommerons utilisateur (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici. 
  Notre utilisateur possède différents attributs comme son nom qui est une chaine de caractère (string), son age, la date de fin de validité de son permis de conduire, son numéro de téléphone qui est une chaine de caractère (string). On lui ajoute donc dans sa classe c'est différents attributs. On remarque aussi qu'à la fin du texte, on apprend que l'utilisateur peut se connecter. On traduit donc cela par une opération "seConnecter". On apprend que cette opération prend deux paramètres, id et mdp qui sont des chaines de caractère (string) et qu'elle renvoie un booléen (car elle indique si la connexion a réussi). Il faut aussi ajouter ces deux paramètres dans les attributs de notre utilisateur car ces derniers lui appartiennent.

  Maintenant que nous en avons fini avec notre première classe, cherchons donc une autre classe. Dans le texte, on nous parle aussi de voiture. Cela repésente donc une classe voiture contenant deux attributs, modèle et marque. 

  À présent, vérifions qu'il n'y ai pas de liaisons entre ces deux classes. Même si ce n'est pas explicitement écrit dans le texte, une voiture est forcément liée à un utilisateur. Nous avons donc une association entre ces deux classes. En ce qui concerne les multiplicités, cela peut être interprété de plusieurs manière. Nous retiendrons donc qu'une voiture appartient à un seul utilisateur et que ce dernier peut en posséder plusieurs. 

  Nous pouvons continuer l'analyse de notre sujet.
  Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif ». Dans tous les cas de modèles de messages, un intitulé est associé (par exemple, Retard), un identifiant pour la reconnaissance vocale (par exemple, Late), une icône graphique (par exemple, un fichier Jpg correspondant à montre cassée), une destination. Le message en lui même contient un contenu (par exemple, «je suis en retard») et l’ensemble des informations qui devront être associées au message parmi un ensemble prédéfini : heure d'envoie du message, ... (par exemple, à un message correspondant à un Retard, la position courante et l’heure d’arrivée prévue devront être associées). 

  Après avoir lu cela, nous pouvons trouver quatres nouvelles classes : 
  -Message
  -Modèle de message
  -Modèle créatif
  -Modèle prédéfini
  En plus de ces classes, on apprend que la classe message contient différents attributs (contenu, date) ainsi qu'une opération envoyer() qui renvoie un booléen.
  La classe modèle elle aussi comme on l'observe "les cas de modèles de messages, un intitulé est associé (par exemple, Retard), un identifiant pour la reconnaissance vocale (par exemple, Late), une icône graphique (par exemple, un fichier Jpg correspondant à montre cassée), une destination". Elle contient trois attributs (intitulé, identifiant, destination).

  Maintenant relions le tout. Nous avons une associations navigable dans les deux sens entre "Utilisateur" et "Message". En ce qui concerne les multiplicités, un Utilisateur peut envoyer plusieurs messages et un message ne peut être envoyer que par un seul utilisateur. On place donc les multiplicités.
  Passons à la liaison "Message", "Modèle de message". Ici, cette liaison n'est pas navigable dans les deux sens car le Modèle de message n'a pas d'intérêt à savoir quel message l'a utilisé. En ce qui concerne les multiplicités, un message peut avoir un seul modèle et un modèle peut avoir plusieurs messages.

  Il ne nous reste plus qu'à trouver la liaison entre le modèle créatif, prédéfini et le Modèle de message. Dans le texte nous avons "soit prédéfini [...], soit « créatif ».", comme nous avons un Modèle de message qui est soit prédéfini, soit créatif, cela signifie qu'il y a une généralisation entre Modèle créatif, Modèle prédéfini et Modèle de message. On représente donc cela puis nous obtenons le diagramme de classe suivant :

  

• Avancé

  Étude de cas niveau avancé

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  Pour fonctionner correctement, MyWaze a besoin d'avoir des informations minimales sur le conducteur comme son nom, son age, la date de fin de validité de son permis de conduire, son numéro de téléphone. Il a aussi besoin de savoir sur que quelle voiture (marque et modèle) il est actuellement pour pouvoir récupérer des informations sur cette dernière. Du côté de l'utilisateur, ce dernier peut se connecter au système à l'aide de son identifiant ainsi que son mot de passe. Le système lui repondra alors si ce dernier est bien connecté ou non.

  Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif » et dans ce cas nous nous nous limitons aux modèles de messages sur Twitter ou par Email. Dans tous les cas de modèles créatif de messages, un intitulé est associé (par exemple, Retard), un identifiant pour la reconnaissance vocale (par exemple, Late), une icône graphique (par exemple, un fichier Jpg correspondant à montre cassée), un contenu (par exemple, «je suis en retard») et l’ensemble des informations qui devront être associées au message parmi un ensemble prédéfini : itinéraire, position courante, destination, heure d’arrivée prévue, ... (par exemple, à un message correspondant à un Retard, la position courante et l’heure d’arrivée prévue devront être associées). La durée de tentative pour envoyer le message est aussi associée au modèle de messages (par exemple pour un Retard, 5mn, après c’est inutile). Dans le cas d’un modèle de messages correspondant à des emails, l’adresse à laquelle envoyer les emails (par exemple « Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. ») est également définie. Dans le cas d’un modèle de messages correspondant à des tweets, le compte twitter à partir duquel les messages doivent partir doit être précisé (par exemple, @surLaRoute). Si le compte n’a pas encore été paramétré dans MyWaze, il peut l’être en cours de création du modèle de messages. Sur la route, lorsque le conducteur sélectionne le modèle de messages ainsi créé (par exemple Retard), le système envoie automatiquement le message contenant les informations associées (par exemple, dans le cas d’un Retard, un email : A : Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. ; sujet : retard ; contenu : «je suis en retard. Je suis à (Latitude : 43.5ti, Longitude : 7.11). Je dois arriver vers 19h20., date envoi : 19h05 »). Cinq minutes plus tard le conducteur peut renvoyer un message et s’il a pu rouler, le contenu du message sera alors « je suis en retard. Je suis à (Latitude : 43.65, Longitude : 7.11). Je dois arriver vers 19h27., date envoi : 19h10 ». Si le système ne parvient pas à envoyer le message, le message passe alors dans un état en attente. Le système retente l’envoi pendant la durée prévue par le modèle du message, en l'occurrence dans le cas d’un retard, 5mn. Lorsque l’envoi est réussi, le message est détruit. Lorsque l’envoi échoue, le message passe dans l’état Echec. Nous envisageons que les modèles de messages fassent l’objet de jeux dans différentes communautés : #voitureJauneCroisée, #NiceMonacoRecordDeLenteur, etc...

  Analyser le sujet

  Lors de la lecture du sujet, il faut réussir à filtrer les informations est à garder seulement les informations nécessaire. Nous allons donc essayer d'épurer le sujet. Je vais donc vous montrer ce qu'il faut retenir du sujet.

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  Pour fonctionner correctement, MyWaze a besoin d'avoir des informations minimales sur le conducteur comme son nom, son age, la date de fin de validité de son permis de conduire, son numéro de téléphone. Il a aussi besoin de savoir sur que quelle voiture (marque et modèle) il est actuellement pour pouvoir récupérer des informations sur cette dernière. Du côté de l'utilisateur, ce dernier peut se connecter au système à l'aide de son identifiant ainsi que son mot de passe. Le système lui repondra alors si ce dernier est bien connecté ou non.

  Nous retenons donc que les éléments barrés sont juste de la mise en contexte. Pour ce qui est des parties en gras, cela représente ce que l'on va devoir modéliser dans notre diagramme de cas d'utilisation.
  Maintenant, nous allons construire ensemble votre premier diagramme de classe.

  Ici, nous pouvons observer une première classe "conducteur"  que nous nommerons utilisateur (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici. 
  Notre utilisateur possède différents attributs comme son nom qui est une chaine de caractère (string), son age, la date de fin de validité de son permis de conduire, son numéro de téléphone qui est une chaine de caractère (string). On lui ajoute donc dans sa classe c'est différents attributs. On remarque aussi qu'à la fin du texte, on apprend que l'utilisateur peut se connecter. On traduit donc cela par une opération "seConnecter". On apprend que cette opération prend deux paramètres, id et mdp qui sont des chaines de caractère (string) et qu'elle renvoie un booléen (car elle indique si la connexion a réussi). Il faut aussi ajouter ces deux paramètres dans les attributs de notre utilisateur car ces derniers lui appartiennent.

  Maintenant que nous en avons fini avec notre première classe, cherchons donc une autre classe. Dans le texte, on nous parle aussi de voiture. Cela repésente donc une classe voiture contenant deux attributs, modèle et marque. 

  À présent, vérifions qu'il n'y ai pas de liaisons entre ces deux classes. Même si ce n'est pas explicitement écrit dans le texte, une voiture est forcément liée à un utilisateur. Nous avons donc une association entre ces deux classes. En ce qui concerne les multiplicités, cela peut être interprété de plusieurs manière. Nous retiendrons donc qu'une voiture appartient à un seul utilisateur et que ce dernier peut en posséder plusieurs. 

  Nous pouvons continuer l'analyse de notre sujet.
  Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif » et dans ce cas nous nous nous limitons aux modèles de messages sur Twitter ou par Email. Dans tous les cas de modèles de messages, un intitulé est associé (par exemple, Retard), un identifiant pour la reconnaissance vocale (par exemple, Late), une icône graphique (par exemple, un fichier Jpg correspondant à montre cassée), une destination. Le message en lui même contient un contenu (par exemple, «je suis en retard») et l’ensemble des informations qui devront être associés au message parmi un ensemble prédéfini : heure d'envoie du message, ... (par exemple, à un message correspondant à un Retard, la position courante et l’heure d’arrivée prévue devront être associées). Dans le cas d’un modèle de messages correspondant à des emails, l’adresse à laquelle envoyer les emails (par exemple « Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. ») est également définie. Dans le cas d’un modèle de messages correspondant à des tweets, le compte twitter à partir duquel les messages doivent partir doit être précisé (par exemple, @surLaRoute). Nous envisageons que les modèles de messages fassent l’objet de jeux dans différentes communautés : #voitureJauneCroisée, #NiceMonacoRecordDeLenteur, etc...

  Après avoir lu cela, nous pouvons trouver six nouvelles classes : 
  -Message
  -Modèle de message qui est une classe abstraite car il n'y aura aucun modèle qui n'est pas un modèle créatif ou prédéfini.
  -Modèle créatif qui est une classe abstraite car il n'y aura aucun modèle créatif qui n'est pas un modèle Twitter ou Email.
  -Modèle prédéfini
  -Modèle Email
  -Modèle Twitter
  En plus de ces classes, on apprend que la classe message contient différents attributs (contenu, date) ainsi qu'une opération envoyer() qui renvoie un booléen.
  La classe modèle elle aussi comme on l'observe "les cas de modèles de messages, un intitulé est associé (par exemple, Retard), un identifiant pour la reconnaissance vocale (par exemple, Late), une icône graphique (par exemple, un fichier Jpg correspondant à montre cassée), une destination". Elle contient trois attributs (intitulé, identifiant, destination). Il y a aussi Modèle Email et Modèle Twitter qui contiennent respectivement emailRecpteur et compteEmetteur qui sont des chaines de caractères (string).

  Maintenant relions le tout. Nous avons une associations navigable dans les deux sens entre "Utilisateur" et "Message". En ce qui concerne les multiplicités, un Utilisateur peut envoyer plusieurs messages et un message ne peut être envoyer que par un seul utilisateur. On place donc les multiplicités.
  Passons à la liaison "Message", "Modèle de messagee". Ici, cette liaison n'est pas navigable dans les deux sens car le Modèle de message n'a pas d'intérêt à savoir quel message l'a utilisé. De plus, un message ne peut pas exister sans Modèle, c'est donc une composition. En ce qui concerne les multiplicités, un message peut avoir un seul modèle et un modèle peut avoir plusieurs messages.

  Il ne nous reste plus qu'à trouver la liaison entre le modèle créatif, prédéfini et le Modèle de message. Dans le texte nous avons "soit prédéfini [...], soit « créatif ».", comme nous avons un Modèle de message qui est soit prédéfini, soit créatif, cela signifie qu'il y a une généralisation entre Modèle créatif, Modèle prédéfini et Modèle de message. On représente donc cela puis nous obtenons le diagramme de classe suivant :