Université de Nantes Licence d Informatique (Année L3) Faculté des Sciences et des Techniques Module S6I0500 Année 2006/2007 Outils de modélisation Examen première session Corrigé NB : Il s'agit d'un corrigé et non pas DU corrigé. D'autres sont possibles, notamment pour les questions dans lesquelles une modélisation est demandée. I- Partie I a) Les quatres contraintes C1, C2, C3 et C4 n apparaissent pas sur le schéma de l annexe 1. Pour les rendre visibles, il faut d abord s interroger sur leur nature et sur les objets concernés. - C1 est clairement une contrainte d exclusion entre Appartement et Maison, les deux spécialisations de Logement. Il est possible de la marquer : {disjoint} APPARTEMENT MAISON NB : la position des contraintes (au MILIEU des associations) est voulue. Tout autre positionnement serait faux. - C2 correspond à une exclusion entre le locataire et le cautionneur, rapportée à un bail précis. Nous allons donc placer une exclusion entre les deux associations : PERSONNE {disjoint} LOCATAIRE ceci étant possible puisque le locataire est une personne. - C3 est encore une exclusion entre le gestionnaire d un logement et LES locataires de celui-ci. Il ne faut en effet pas perdre de vue le fait qu un logement peut avoir plusieurs locataires successifs. Le gestionnaire ne peut être aucun de ceux-là. PERSONNE COLLABORATEUR LOCATAIRE C3 Aucune contrainte (au sens des deux précédentes) ne peut être placée sur ce schéma. Il nous faut donc recourir à une note.
Page 2 / 6 - C4 est la version propriétaire de C2. Nous aboutissons au même type de résultat. PERSONNE PROPRIETAIRE COLLABORATEUR {disjoint} b) Respecter la loi revient à mémoriser les différentes charges et les associer, soit à un logement, soit au bail. Les deux sont possibles, dans la mesure où le texte de l énoncé n est pas assez précis à ce sujet. Dans les deux cas, on va crééer une classe Charge, avec les attributs Nature et Montant : 0..* au choix 0..* CHARGE Nature : String 1..* Montant : Float 1..* L attribut charges de la classe Logement n est plus un réel, mais un vecteur d objets de type Charge. c) Pour rendre les schémas cohérents entre eux, il faut satisfaire la définition fournie dans l énoncé. Cela entraîne les modifications suivantes du diagramme de classes : - renommage de l opération totalagence() de la classe Collaborateur en totalloyersagence() ; - ajout des classes ContrôleurGestionLocation, ContrôleurGestionCollaborateur, EnsLogements et ContratLocatif ; - ajout des opérations suivantes : Classe «réceptrice» Opérations ContrôleurGestionLocation libre(), rdvvisite(), filtrelibre(), filtrepiece(), filtreville(), filtrebudget() ContrôleurGestionCollaborateur portefeuille() ContratLocatif surface(), partagence(), loyer(), telephone(), courriel() Adresse ville() Logement situé() EnsLogement listelogements() d) La notation erronée est la composition. Il est abusif de dire qu un logement est composé de baux. La destruction du logement n entraîne pas, en outre, celle des baux. Une «simple» association binaire entre les deux classes suffit largement : 1 0..* concerne
Page 3 / 6 III- Partie II (notation envisagée : 8 points, 2, 3 et 3) a) Il nous faut d abord enregistrer, dans une classe Prospect, les informations que l on souhaite conserver : Un prospect est une personne. Nous pouvons donc faire «migrer» trois des quatre propriétés de Prospect vers Personne ou, plutôt, relier par une relation d héritage les deux classes et supprimer dans la classe-fille les attributs existant dans la classe-mère : Il faut ensuite nous occuper des visites. Un prospect peut visiter un ou plusieurs logements, ceux-ci n ayant qu un visiteur à la fois. Nous avons le choix de la structure (entité ou association). Nous préférerons l association, dans la mesure où la file d attente des prospects se fait «sur» le logement, pas sur les visites. - solution avec une classe-association : - solution avec une «vraie» classe : Il nous reste à regarder d un peu plus près ce qui se passe en cas d annulation. Le texte n est guère précis sur ce point. Nous supposons donc qu annulation veut dire suppression physique. Ceci a l avantage de ne pas nous contraindre à gérer une file d attente qui soit composée de deux types de prospects, des futurs visiteurs et des anciens. De ce fait, le résultat d une visite ne peut être «négative». Lors du retour de visite, il y a soit création d un bail (et destruction de toutes les visites attachées au logement), soit destruction de la visite et appel du prospect suivant. Celui-ci est déterminé non pas sur la date prévue de la visite mais bien sur la date d entrée du prospect dans la file d attente. Il nous faut donc deux dates, une correspondant au dépôt et une à la réalisation de la visite elle-même.
Page 4 / 6 b) Nous supposons ici que la liste des logements fournis en paramêtre du message demandevisite(listelog) ne contient pas d erreur. Nous devons, pour chaque élément de cette liste, mettre en place les traitements suivants : Ce schéma introduit deux nouvelles classes, EnsVisites et ContrôleurGestionVisites, avec les opérations demandevisite() dans ContrôleurGestionVisites, créervisite() dans la classe Visite, ajouter() dans la classe EnsVisites et ajoutervisite() dans les classes Logement et Prospect. NB : il reste une ambiguïté à lever, celle concernant le choix des dates de visite. Sans information plus précise dans le texte, nous ne développons pas plus ce choix. c) Au retour de visite du prospect, il y a création du bail ou non. La visite est satisfaisante ou non. Dans le premier cas, la visite en cours passe dans l état «OK». Il y a ensuite «passage» du statut de Prospect à Locataire (il faut saisir son adresse), suppression de l objet Prospect, saisie du cautionnaire, création du bail (avec saisie des informations le décrivant) puis suppression de toutes les visites pour le logement. Il faut, juste auparavant, recueillir la liste des prospects en attente et les prévenir par SMS. En dernier (?) lieu, il faut sans doute (CECI DOIT ETRE CONFIRMÉ PAR LE CLIENT) supprimer les prospects qui se retrouvent sans visite programmée.
Page 5 / 6 Ce schéma va entraîner la création d une classe EnsProspect, EnsLocataire et le «stockage» de toutes les opérations mentionnées dans les classes réceptrices : Nom classe Logement Visite EnsVisites Locataire EnsLocataires Prospect EnsProspects Opération détruirevisite() supprimer() changerok() existe?() enlever() transfertlp() ajouterl() infos?() supprimer() enlevertout() Il faudra aussi relier les classes ContrôleurGestionVisite et ContrôleurGestionLocation, placer visiteconcluante() dans la première et nouveaubail() dans la seconde. IV- Partie III (notation envisagée : 5 points, 3 et 2) a) «un logement est vacant, réservé ou loué» dit le texte. Nous avons donc une première ébauche de notre diagramme états-transitions : NB : nous n avons pas envisagé la destruction physique du logement, qui pourrait être modélisée par un état final atteint à partir des trois états Vacant, Réservé et Loué. Voic le nom détaillé des transitions : 1 : miseenlocation 2 : arrêtlocation 3 : volontédesignature 4 : [délai < 8j] rétractation 4 : [délai 8j] rétractation 6 : libération ou acceptation
Page 6 / 6 L état Vacant est lui-même composé de deux sous-états, Inactif et Visité : On peut regrouper le tout en un seul diagramme : NB : la transition volontédesignature part bien de la frontière du super-état Vacant ; elle s impose en effet à tous les états internes. b) Rendre ce diagramme états-transitions cohérent avc les autres schémas, c est : 1) fournir une variable état dans la classe Logement qui permette de mémoriser l état courant du logement ; 2) vérifier que toutes les actions mentionnées dans le D.E.T. sont présentes dans la classe Logement. Les événements correspondant, quant à eux, à la réception d un message. Il y a, ici, assez peu de mise en cohérence possible. Tout au plus peut-on noter qu il faut changer volontédesignature() en visiteconcluante(). Les deux autres messages (annulationautresvisites() et miseenplacebail() ) peuvent être considérés comme des activités de l état Réservé.