Conception des classes, traduction des associations en attributs - réponses

Instructions pour le QCM :
Pour chacune des questions, plusieurs réponses peuvent être correctes, vous pouvez donc cocher plusieurs cases !
Les questions sont de trois niveaux de difficultés. Les niveaux « intermédiaire » et « difficile » sont précédés des signes « * » et « ** », respectivement.

  1. L'affirmation suivante est-elle correcte ? Étant donné une classe « A » contenant l'attribut « a » et une classe « B » contenant la méthode « b », si « a » est « protégé » et « b » est « publique », « b » peut utiliser « a ».
  2. FAUX : OUI ( « a » est « protégé », donc accessible depuis une classe enfant. Sans savoir si « B » est une classe enfant, il n'est pas possible d'affirmer que « b » peut utiliser « a ». )
    VRAI : NON

  3. L'affirmation suivante est-elle correcte ? Une multiplicité « 0..* » se traduit par un attribut tableau de références sur la classe à l'autre extrémité de l'association binaire.
  4. VRAI : OUI
    FAUX : NON ( Il est nécessaire de mémoriser un ensemble de valeurs, mais un tableau de référence n'est pas très approprié car la taille du tableau n'est pas connue. C'est donc une collection que nous choisissons. )

  5. L'affirmation suivante est-elle correcte ? Un message d'un diagramme de séquence est la plupart du temps traduit en une opération « privée ».
  6. FAUX : OUI ( Le message est bien traduit par une opération. Mais, comme il est la plupart du temps émis par un objet d'une autre classe, l'opération est la plupart du temps « publique ». )
    VRAI : NON

  7. Voici le diagramme de classes utilisé par les questions qui suivent.

     

    Pendant la phase de conception, les associations liées à la classe « Projet » sont traduites en les attributs suivants :

  8. VRAI : - licence : Licence. ( L'association est binaire, la multiplicité est « 1..1 », et l'attribut est privé pour favoriser la règle de l'encapsulation de l'orienté objet. )
    FAUX : + licence : Licence. ( Il n'y a pas de raison pour mettre l'attribut en visibilité « public ». )
    FAUX : - groupes : Collection Groupe. ( La multiplicité de l'association vue par la classe « Projet » est « 1..1 », et non « * ». L'attribut est bien privé. )
    VRAI : - groupe : Groupe. ( La multiplicité est « 1..1 », et l'attribut est privé. )

  9. Les associations liées à la classe « Groupe » sont traduites en les attributs suivants :
  10. FAUX : - sousGroupe : Groupe. ( La multiplicité est « * », et non « 1..1 ». La multiplicité exprime « une collection de ». )
    VRAI : - sousGroupes : Collection Groupe. ( La multiplicité est bien « 0..* » et l'attribut est privé. )
    FAUX : - utilisateur : Utilisateur. ( La multiplicité de l'association vue par la classe « Groupe » est « 0..* », et non « 1..1 ». Il faut une collection. )

  11. Les associations liées à la classe « Groupe » sont traduites en :
  12. FAUX : 2 attributs. ( Non, il y en a 4. )
    FAUX : 3 attributs. ( Non, il y en a 4. )
    VRAI : 4 attributs. ( 1 pour l'association vers la classe « Projet », 1 pour l'association vers la classe « Utilisateur », et 2 pour l'assocation réflexive. )

  13. La classe « Libre » :
  14. VRAI : ne possède aucun attribut d'association. ( L'association est factorisée dans la classe parente « Licence ». )
    FAUX : possède 1 attribut d'association. ( L'association est factorisée dans la classe parente « Licence ». )
    FAUX : possède 2 attributs d'association. ( L'unique association est factorisée dans la classe parente « Licence ». )

  15. La classe « Propriétaire » :
  16. FAUX : ne possède aucun attribut d'association. ( L'une des associations est factorisée dans la classe parente « Licence », l'autre est gérée par la classe « Propriétaire ». )
    VRAI : possède 1 attribut d'association.
    FAUX : possède 2 attributs d'association. ( L'une des associations est factorisée dans la classe parente « Licence », seule la seconde est gérée par la classe « Propriétaire ». )

  17. Voici le diagramme de communications utilisé par les questions qui suivent.

     

    L'algorithme de l'opération « proposerProjet » de la classe « Picoforge » est :

  18. FAUX :
    void proposerProjet(...) {
      rechercher()
      createProjet()
      ajouter()
      envoyerCourriel()
    }
    
    ( Les opérations « rechercher » sont appelées sur des classes, donc avec le nom de la classe puis un point avant le nom de l'opération. Par ailleurs, le diagramme de communications montre six messages dans la séquence de l'opération « proposerProjet » de la classe « Picoforge ». En outre, les opérations renvoient des valeurs de retour. Enfin, l'opération « ajouter » n'est pas appelée par l'opération « proposerProjet » mais par le constructeur de la classe « Projet » : c'est un message imbriqué qui ne fait pas partie de l'opération « proposerProjet ». )
    FAUX :
    void proposerProjet(...) {
      util=Utilisateur.rechercher(...)
      t=Type.rechercher(...)
      th=Theme.rechercher(...)
      l=Licence.rechercher(...)
      p.createProjet(...)
      g.envoyerCourriel()
    }
    
    ( Les appels aux opérations sur les classes et les objets sont corrects, excepté que l'objet « p » est la valeur de retour de la création du projet et non un objet sur lequel est appelée l'opération « createProjet ». Par ailleurs, certains appels doivent être conditionnels. )
    FAUX :
    void proposerProjet(...) {
      util=Utilisateur.rechercher(...)
      t=Type.rechercher(...)
      th=Theme.rechercher(...)
      l=Licence.rechercher(...)
      createProjet(util,nom,...)
      g.envoyerCourriel()
    }
    
    ( Les appels aux opérations sur les classes et les objets sont corrects. Mais, certains appels sont conditionnels. )
    FAUX :
    void proposerProjet(...) {
      util=Utilisateur.rechercher(...)
      t=Type.rechercher(...)
      th=Theme.rechercher(...)
      l=Licence.rechercher(...)
      p=createProjet(util,nom,...)
      if (p!=null) {
        g.envoyerCourriel()
      }
    }
    
    ( Les appels aux opérations sur les classes et les objets sont corrects. L'appel a l'opération « envoyerCourriel » est bien conditionnel. Mais, l'appel au constructeur de la classe « Projet » doit aussi être conditionnel. )
    VRAI :
    void proposerProjet(...) {
      util=Utilisateur.rechercher(...)
      t=Type.rechercher(...)
      th=Theme.rechercher(...)
      l=Licence.rechercher(...)
      if (util!=null et t != null et th != null et l!=null) {
        p=createProjet(util,nom,...)
      }
      if (p!=null) {
        g.envoyerCourriel()
      }
    }
    
    ( Bonne utilisation des classes et des objets pour les appels. Bon séquencement des appels. Bonnes conditions pour les deux derniers messages. )
    FAUX :
    void proposerProjet(...) {
      util=Utilisateur.rechercher(...)
      t=Type.rechercher(...)
      th=Theme.rechercher(...)
      l=Licence.rechercher(...)
      if (util!=null et t != null et th != null et l!=null) {
        p=createProjet(util,nom,...)
        g=createGroupe(nom)
        if (g!=null) {
          ajouter(util)
        }
      }
      if (p!=null) {
        g.envoyerCourriel()
      }
    }
    
    ( Pour que l'algorithme soit correct, il faut retirer la construction de l'objet « g » et l'appel à l'opération « ajouter » : ces deux dernières opérations sont appelées non pas dans l'opération « proposerProjet », mais dans le constructeur de la classe « Projet ». En effet, les deux messages sont des messages imbriqués qui ne font pas partie de l'opération « proposerProjet ». )

  19. L'algorithme du constructeur de la classe « Projet » est :
  20. FAUX :
    constructeur(util,nom...) {
    }
    
    ( Le constructeur n'est pas vide, il crée le groupe « g » et appelle l'opération « ajouter ». )
    FAUX :
    constructeur(util,nom...) {
      createGroupe(nom)
      ajouter(...)
    }
    
    ( Les deux messages sont bien présents mais mal traduits : il manque la récupération de la valeur de retour du constructeur et la référence de l'objet pour l'appel de l'opération « ajouter ». )
    FAUX :
    constructeur(util,nom...) {
      createGroupe(nom)
      if (g!=null) {
        ajouter(...)
      }
    }
    
    ( La condition sur l'appel de l'opération « ajouter » est bien présente. Les deux messages sont bien présents mais il manque la récupération de la valeur de retour du constructeur et l'objet sur lequel est appelé l'opération « ajouter ». )
    VRAI :
    constructeur(util,nom...) {
      ...
      g.createGroupe(nom)
      if (g!=null) {
        g.ajouter(...)
      }
    }
    
    ( Bonne traduction des messages et de la condition. )
    FAUX :
    constructeur(util,nom...) {
      ...
      g.createGroupe(nom)
      if (g!=null) {
        g.ajouter(...)
      }
      if (p!=null) {
        g.envoyerCourriel(...)
      }
    }
    
    ( L'appel à l'opération « envoyerCourriel » n'est pas dans ce niveau d'imbrication ; elle est en trop. )