Differences

This shows you the differences between two versions of the page.

--- 2011_2012:s2:td:activities [2012/03/11 04:46] – [Exercices d'entraînements] blay
+++ 2011_2012:s2:td:activities [2012/04/20 10:58] (current) – [En savoir plus] blay
@@ Line 1: / Line 1: @@
 ====== Diagrammes d'activité ======
-===== Exercices d'entraînements =====
+===== Exercices d'entraînements (facultatifs) =====
 Attention les exercices qui suivent sont très simples. Ils visent seulement à vous aider à vous remémorer le cours pour être prêt à réaliser les exercices suivants qui exigent un peu plus de réflexions.
@@ Line 52: / Line 52: @@
 Dans les autres cas, le patient règle lui-même
 les honoraires et reçoit en échange un volet de facturation à adresser à sa caisse d'assurance maladie.
-  - Modéliser le Flot de contrôle
+  - Modéliser le Flot de contrôle (uniquement les actions/activités)
-  - Compléter le avec le flot de données, prenez en compte les états de la facture.
+  - Compléter le avec le flot de données (les objets apparaissent), prenez en compte les états de la facture.
   - Enrichissez le en faisant apparaître les entités ou acteurs responsables des actions par des partitions.
@@ Line 61: / Line 61: @@
 Soit le processus de vente d'une oeuvre d'art  :
    - Le client valide le contenu du panier
-   - Le système de vente en ligne émet un bon de retrait ouvert vers le système de stockage pour les oeuvres et dans le même temps consulte le système de livraison pour connaître les temps d'acheminement prévu du colis;
+   - Le système de ventes en ligne émet un bon de retrait ouvert vers le système de stockage pour les oeuvres et dans le même temps consulte le système de livraison pour connaître les temps d'acheminement prévu du colis;
-   - Un bon de commande est émis par le système des ventes pour toutes les oeuvres disponibles et en précisant le temps d'acheminement prévu;
+   - Un bon de commande est émis par le système de ventes pour toutes les oeuvres disponibles et en précisant le temps d'acheminement prévu;
    - Le client valide ou non la commande
    - Si la commande est validée,
-       * un service de paiement externe prend en charge le paiement et prévient le service des ventes que le paiement a été bien été demandé; la commande passe au statut en cours;
+       * un service de paiement externe prend en charge le paiement et prévient le service de ventes que le paiement a bien été demandé; la commande passe au statut en cours;
        * le service de livraison prend en charge l'expédition des oeuvres (cf. ci après) ce qui fait passer la commande dans le mode "en livraison";
-       * le service de livraison (par le transporteur) notifie le service des ventes lorsque la commande a été livrée,
+       * le service de livraison (par le transporteur) notifie le service de ventes lorsque la commande a été livrée,
        * la commande passe alors dans l'état clos.
@@ Line 94: / Line 94: @@
-<box round rgb(185,211,238) rgb(198,226,255) 95%|A rendre : ** Informatisation d'un Garage ** Le Lundi 4/4 8h dernier délai : remis à votre encadreur par mail ayant pour sujet ”[S2] Activité : //Groupe// : //Membres du quadrinôme//" avec en attachement le projet .vpp ”>
+<box round rgb(185,211,238) rgb(198,226,255) 95%|A rendre : ** Gestion de Crise ** Le Lundi 9/4 8h dernier délai : remis à votre encadreur par mail ayant pour sujet ”[S2] Activité : //Groupe// : //Membres du quadrinôme//" avec en attachement le projet .vpp ”>
-Reprendre l'étude de cas de gestion d'un garage, qui vous a été donnée la semaine dernière et représenter par un diagramme d'activité l'enchaînement des tâches consécutives à un rendez-vous pour réparation d'une voiture. Nous modélisons ainsi les échanges d'informations entre les cas d'utilisation.
+Reprendre l'étude de cas de gestion de crise, qui vous a été donnée la semaine dernière et représenter par un diagramme d'activité l'enchaînement des tâches consécutives à un rendez-vous pour réparation d'une voiture. Nous modélisons ainsi les échanges d'informations entre les cas d'utilisation.
 {{:omgl:acsi:cours7.gif|}}
 Vous pouvez rendre plusieurs diagrammes d'activité à votre convenance, mais au moins un des diagrammes doit inclure le flot des données, et un diagramme doit inclure les partitions.
+Voici quelques compléments sur l'étude de cas (Ne pas la compliquer davantage) :
+  - L'enregistrement d'une déclaration donne lieu à la création d'une entité représentant la //crise//.
+  - S'il n'y a pas de concordance entre le numéro de téléphone du témoin et son identité, la crise est considérée comme un canular (Nous simplifions!).
+  - Un expert produit un //plan de missions// sur la base des informations portée par la crise.
+  - Le coordinateur a alors la charge de traiter les missions en allouant des ressources appropriées à chaque tâche du plan de missions. Il produit un ensemble de //missions//, une par travailleur. Une mission est initialement //en cours//.
+  - Chaque travailleur va alors signaler l'évolution de sa mission. Nous considérons uniquement les signalements d'évolution de missions suivants: //Echec//, //Réussite//. Les travailleurs sont tenus de signaler auprès du système l’évolution de leur mission avec une fréquence maximum donnée (par exemple, une 1/2 heure). En cas de non signalement, une alerte est levée, la mission est en //En cours// mais //Erreur//. Une mission en cours ne peut être //close// que par le système, par la levée d'un évènement de "clôture" de la mission.
+  - En même temps que les travailleurs signalent l'évolution de leur mission, le coordonnateur surveille l'ensemble des missions.
+  - La crise est considérée comme close lorsque le coordinateur le décide. Cela a pour conséquence de clore toutes les missions.
 </box>
@@ Line 117: / Line 127: @@
 </box>
 -!
 =====  En savoir plus =====
@@ Line 123: / Line 132: @@
 http://www.sparxsystems.com/resources/uml2_tutorial/uml2_activitydiagram.html
+http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html