Differences

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

--- 2019_2020:s3:concprogobjet:td:td3 [2019/09/26 14:15] – [Conception d'applications et Principes GRASP et SOLID] blay
+++ 2019_2020:s3:concprogobjet:td:td3 [2019/09/27 11:26] (current) – blay
@@ Line 8: / Line 8: @@
 **Objectifs :**
-   * Modéliser une application un peu plus complexe en mettant en oeuvre les principes GRASP et SOLID et au travers de seulement la conception.
+   * Modéliser une application un peu plus complexe en utilisant à bon escient vos connaissances sur la modélisation en UML.
+   * Mettre en oeuvre les principes GRASP et SOLID au travers de seulement la conception.
-**Etude de cas**
 **Déroulé :**
@@ Line 20: / Line 17: @@
    * Ils s'assurent de la complétude de leur modélisation en regard de l'énoncé.
+Ce travail fera l'objet d'un rendu ultérieur qui sera précisé plus tard.
-Il existe plusieurs types de crises. Certaines sont des accidents, d'autres des inondations, … A un type de crise est associé un guide de résolution qui précise les missions à mettre en place, les numéros de téléphone utiles, etc. Il s'agit d'un document.
-A une crise sont associées des missions. Une mission peut correspondre à plusieurs crises dans le cas où plusieurs crises doivent être simultanément gérées (par exemple, un accident et un incendie). Voici des exemples de missions : alerter les secours, alerter la population, évacuer la population, stopper la circulation.
+**Etude de cas**
-A la création d'une mission sont automatiquement associées les tâches idoines en attente de validation.
-Les tâches peuvent être dynamiquement allouées ou retirées à une mission.
-Aux tâches sont associées des ressources. Une ressource ne peut pas être affectée à plusieurs tâches en même temps. Par exemple, à une tâche de transport sont associés un véhicule et un chauffeur.
-Une tâche de transport ambulancier débute dès que l'ambulance et le chauffeur sont affectés à la tâche.
-Une ressource affectée à une mission est en permanence localisée. S'il s'agit d'un engin, la localisation est obtenue en utilisant le GPS intégré. S'il s'agit d'un être humain, la localisation est la dernière qu'il a renseigné dans le système. Il peut aussi utiliser son téléphone pour se faire localiser automatiquement.
-Lorsqu'une crise est déclarée, en fonction de son type, les missions à réaliser lui sont automatiquement associées.
-Le coordinateur de la crise a alors la charge de contrôler la situation d'urgence en identifiant les missions nécessaires pour faire face à la situation.  Il peut ainsi mettre une mission prévue par défaut en attente, déclencher une mission ou ajouter une mission non prévue initialement.
-Lorsqu'une mission est commencée, la date de début de la mission est automatiquement renseignée. Lorsqu'elle est terminée, la date de fin de la mission est renseignée. Il est possible de connaitre le temps effectif et prévisionnel d'une mission. Le temps prévisionnel de la mission dépend de son type et de la durée prévisionnelle des tâches qui lui sont associées. Elle peut donc varier en fonction de l'avancement dans le traitement de la mission. A la fin de la mission, les durées prévisionnelles et effectives ont la même valeur.
-Une mission est considérée comme commencée dès qu'une tâche est commencée. Une ressource est considérée comme libre dès qu'elle n'est plus associée à une tâche en cours.
-Un système central évalue la fréquence et la durée effective de gestion des crises dans le temps.
-L'expert pour cela
-Questions sous la forme d'une évaluation croisée :
-  * Est-ce que la multiplicité des types de crises est bien représentée?
-  * Est-ce que l'association d'un guide à toute crise est bien modélisé?
-  * Est-ce que l'association Crise et Mission est bien modélisée ?
-  * Est-ce que les tâches sont associées aux missions?
-  * Est-ce que les tâches peuvent être validées?
-  * Est-ce que des ressources sont associées aux tâches?
-  * Est-ce que plusieurs types de ressources sont représentées? Est-ce que la localisation est bien prise en charge ? Est-ce que le modèle présenté respecte le principe Ouvert à l'extension/Fermé aux modifications ? Ajouter des ressources telles que des défibrillateurs qui sont localisés par des composants RFID, tandis que d'autres tel que un bloc opératoire sont toujours localisées au même endroit, est-ce faisable sans modifier les classes existantes?
-  * Est-ce que les différents états d'une mission sont bien prévus?
-   * Est-ce que la date de début de mission est bien prévue ? (attibut ou opération)
-   * Est-ce que la terminaison d'une mission est bien prévue ? La date de fin de mission ?
-   * Est-ce que les durées effectives et prévisionnelles sont bien prévues? Sur les missions? sur les tâches?
-   * Avez-vous un moyen d'identifier comment sera géré : //Une mission est considérée comme commencée dès qu'une tâche est commencée//
-   * Est-ce que la notion de liberté d'une ressource est modélisée ?
-   *
-un diagramme de séquence ...
-https://github.com/prmr/SoftwareDesign/blob/master/modules/Module-01.md
-====== Cards ======
-One of the first problems we will tackle in this module is to design an abstraction that can conveniently represent a single playing card. In a standard deck of cards there are 52 distinct cards and any given card can be completely defined by its suit (Hearts, Spades, Diamonds, Clubs) and its rank (Ace, 2, 3,...,10, Jack, Queen, King).
-In a program we can represent a playing card in many different ways. For example, using a single integer between 0 and 51 where the value of the integer somehow represents the card. Or, we could represent a card using a combination of 6 boolean values (insane but technically possible). Here to apply the principle of information hiding, we would organize our program structure so as to hide the decision of how exactly we represent a card in the program.
-we started to design this type, we would quickly realize that our program also needs to manipulate two other types of values: suits and ranks. These types of values are a bit different because they are more like labels for domain objects than actual objects. What makes them feel like labels are that there are a finite number of them for a particular type of values (e.g., 4 for suits), and it appears to be useless to have two or more instances representing a given suit (e.g., clubs). In fact values of these types would be used more or less as constants in a program.
-<code java>
-public enum Suit
-{
-	CLUBS, DIAMONDS, SPADES, HEARTS
-}
-</code>
-TO DO
-Extend the Suit enumerated type in Card to include a method color() that returns the color of the suit. The return type should be a new enumerated type Color.
-https://github.com/prmr/DesignBook/blob/master/solutions/s-chapter2.md
-Extend version 7 of class Card to support the concept of a "Joker" (a special card that is not in any suit) while keeping the class as well-encapsulated as possible.
-https://github.com/prmr/SoftwareDesignCode/blob/master/module01/ca/mcgill/cs/swdesign/m1/Card7.java
-Add a method getCards() to the Deck class that returns the cards in the deck without breaking encapsulation.
-===== Class Interactions =====
-https://github.com/prmr/SoftwareDesign/blob/master/modules/Module-02.md
-Consider the following program:
-<code java>
-class Game
-{
-   Deck aDeck;
-   ...
-public final class Deck
-{
-   private  Stack<Card> aCards = new Stack<>();
-   ...
-   public Deck( Deck pDeck ) {...}
-   public void shuffle() {...]
-   public Card draw() {...}
-   public boolean isEmpty() {...}
-}
-</code>
-===== Hand class =====
-Design and implement a well-encapsulated abstraction to represent a "hand" of cards in a player's hand as a Java class Hand. A Hand should be able to contain between 0 and N cards, where N is a a parameterizable upper bound that will depend on the card game being played (e.g., 5 for draw poker, 13 for bridge, etc.). Implement the following services on a Hand: add(Card), remove(Card), contains(Card), isEmpty(), size(), and isFull(). Find a way to provide access to the cards in the hand. Ensure that all the rules of encapsulation seen in Module 1 are respected and use Design by Contract to clarify valid and invalid inputs
-http://perso.univ-mlv.fr/ocure/prog2_0809/td3_4_0809S.pdf
+  - Il existe plusieurs types de crises. Certaines sont des accidents, d'autres des inondations, … A un type de crise est associé un guide de résolution qui précise les missions à mettre en place, les numéros de téléphone utiles, etc. Il s'agit d'un document.
+  - A une crise sont associées des missions. Une mission peut correspondre à plusieurs crises dans le cas où plusieurs crises doivent être simultanément gérées (//par exemple, un accident et un incendie//). //Voici des exemples de missions : alerter les secours, alerter la population, évacuer la population, stopper la circulation.//
+  - A la création d'une mission sont automatiquement associées les tâches idoines en attente de validation. //Par exemple, à la mission "évacuer la population" sont associées par défaut les tâches :  déclencher la sirène et notifier les services de polices.// Les tâches peuvent être dynamiquement allouées ou retirées à une mission. //En cas d'inondation, on ajoutera à la mission "évacuer la population", la tâche "déclencher des appels téléphoniques pour alerter directement les personnes du village".//
+  - Aux tâches sont associées des ressources. Une ressource ne peut pas être affectée à plusieurs tâches en même temps. //Par exemple, à une tâche de transport sont associés un véhicule et un chauffeur.//
+  - Une tâche peut être invalidée ou terminée. Selon les types de tâches, elles commencent/terminent sur demande ou  automatiquement quand des conditions sont vérifiées. D//La tâche "envoyer un transport ambulancier" débute dès que l'ambulance et le chauffeur sont affectés à la tâche.//
+  - Une ressource affectée à une mission est en permanence localisée. S'il s'agit d'un engin, la localisation est obtenue en utilisant le GPS intégré. S'il s'agit d'un être humain, la localisation est la dernière qu'il a renseigné dans le système. Il peut aussi utiliser son téléphone pour se faire localiser automatiquement.
+  - Il est possible de connaître les ressources qui sont libres.
+  - Lorsqu'une crise est déclarée, elle est enregistrée dans le système et en fonction de son type, les missions à réaliser lui sont automatiquement associées. Le coordinateur de la crise a alors la charge de contrôler la situation d'urgence en identifiant les missions nécessaires pour faire face à la situation.  Il peut ainsi mettre une mission prévue par défaut en attente, commencer une mission ou ajouter une mission non prévue initialement.
+  - Lorsqu'une mission est commencée, la date de début de la mission est automatiquement renseignée. Lorsqu'elle est terminée, la date de fin de la mission est renseignée. Il est possible de connaitre le temps effectif et prévisionnel d'une mission. Le temps prévisionnel de la mission dépend de son type et de la durée prévisionnelle des tâches qui lui sont associées. Elle peut donc varier en fonction de l'avancement dans le traitement de la mission. A la fin de la mission, les durées prévisionnelles et effectives ont la même valeur.  Une mission est considérée comme commencée dès qu'une tâche qui lui est associée est commencée.
+  - Pour les crises, missions et tâches terminées, il est possible de connaitre le nombre de ressources utilisées.
+  - Une ressource est considérée comme libre dès qu'elle n'est plus associée à une tâche en cours.
+  - La durée effective d'une tâche correspond au temps passé entre le début et la fin de la tâche.
+  - A tout moment un expert peut demander au système quelles sont les crises en cours et obtenir pour chacune la durée prévue. En sélectionnant une crise, il peut alors la visualiser.
+  - L'expert peut visualiser une crise particulière. Dans ce cas, toutes les missions sont affichées avec leur état (en attente, commencée, terminée, etc).
+  - Un système central permet à l'expert d'évaluer la fréquence et la durée effective de gestion des crises dans le temps.
-https://www.irif.fr/~yunes/cours/Java/Java/Supports_files/td3_correction.pdf