Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

examenJanvierGL Corrigé

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 8

NOM : N°CIN :

PRENOM : N° inscription :

N° salle : N° Place :

Devoir surveillé Examen x Session: principale x


de contrôle

Matière : UML & Design Patterns….…. Semestre : 1er ………..….


Enseignant(s) : Mme S. Bouzidi……………………….. Date: 07/01/2015…………
Filière(s) : GL3………………………………………… Durée:1heure 30 mn ……..
Barème : Documents: autorisés
Nombre de pages : ………………………………… non autorisés x

Exercice N°1

Nous considérons dans cet exercice une application pour la gestion de locations dans une
agence immobilière. L’équipe responsable de la modélisation a réalisé le diagramme de cas
d’utilisation présenté en Figure 1.

1
NE RIEN INSCRIRE DANS CETTE ZONE

Q1 : Sachant que l’on ne vous demande pas d’y ajouter de nouveaux cas d’utilisation, le
diagramme de cas d’utilisation de la figure 1 est-il correct ? Modifiez-le si besoin est.

30% L’extension n’est pas légitime (extension vs héritage).


20% du coup « Operation dur un contrat » ne se justifie plus
30% L’inclusion entre « Créer un contrat » et « Rédiger le contrat » et « Signer le contrat » n’est pas
légitime (décomposition fonctionnelle)
20% du coup « Rédiger le contrat » et « Signer le contrat » ne se justifient plus.

L’équipe de développement a finalement élaboré le diagramme de classes présenté dans la Figure 2.


L’agence gère un ensemble de biens (appartements ou maisons) à louer. Un bien passe par plusieurs
états. Seul un bien « libre » peut être réservé par un client ; un contrat de location est créé lorsqu’un bien
« réservé » devient « loué ». Un bien « réservé » ou « loué » peut être à tout moment libéré par le client.
Le bien redevient à nouveau « libre ». L’état d’un bien est modélisé par un attribut etat de type entier
(voir la classe Bien) qui peut prendre trois valeurs correspondant aux trois états possibles du bien : 1
pour « libre », 2 pour « réservé » et 3 pour « loué ».

2
NOM : N°CIN :

PRENOM : N° inscription :

N° salle : N° Place :

Q2 : Les classes définies dans le diagramme de classes sont-elles toutes légitimes?

100% Les classes Directeur, Agent et Utilisateur ne sont pas des objets métier. _ il faut les supprimer
du diagramme.
Tout ou rien

Figure2

Dans la modélisation actuelle de l’application « GestionLocations », l’utilisation de l’attribut etat pour


gérer les états du bien engendre une forte utilisation des conditionnelles de type « If-Then-Else » dans
les opérations de la classe Bien pour déterminer dans quel état se trouve l’objet avant de réaliser une
opération (un bien ne peut par exemple être loué que s’il a auparavant été réservé). Une approche plus
élégante serait d’utiliser un design pattern
Q3.
a) Proposez le design approprié à cette solution
b) Mettez en oeuvre cette solution (vous présenterez les classes et les liens ajoutés)

3
NE RIEN INSCRIRE DANS CETTE ZONE

100% Pour le pattern :


- 10% code délégation dans la classe Bien (etat. reserver(this))
- 20% sur la classe abstraite
o 10% classe
o 10% méthodes
- 10% association Bien - EtatBien
- 20% sur Loué
o 10% classe
o 10% code
- 20% sur Reservé
o 10% classe
o 10% code
- 20%sur Loué
o 10% classe
o 10% méthode
20% de bonus sur avantages et désavantages (question sur 120%)
10% Avantage : délégation des traitements aux états : ajouter un état est plus simple que d’ajouter du
comportement à un bloc monolithique, évite les if-then-else
10% Désavantage : création d’une multitude d’objets, dont la destruction n’est d’ailleurs pas gérée par
l’utilisateur

Exercice N°2

Nous considérons dans cet exercice une application StudioMontage fournissant un studio de montage
virtuel (logiciel) permettant à des utilisateurs d’acquérir et de monter des documents multimédia (par
exemple film de vacances, présentation d’entreprise, etc.) au format HD à partir de documents «

4
NOM : N°CIN :

PRENOM : N° inscription :

N° salle : N° Place :

bruts» provenant d’une source multimédia raccordée à l’application. Dans un premier temps nous
considérons que la seule source reconnue est une caméra vidéo.
Le diagramme de classes UML de l’application StudioMontage est fourni en figure 1.

Figure 1 - Diagramme de classes de l'application StudioMontage


La classe DocumentMultimedia représente un document multimédia dans un format manipulable par la
table de montage, c’est-à-dire le résultat de l’acquisition d’un document « brut » enregistré dans la
caméra.
La classe TableMontage représente le coeur de l’application et est dépositaire de l’ensemble des
opérations offertes par l’application:
 acquisition() : permet de créer un document multimédia à partir du document « brut » enregistré
sur la caméra ;
 montage() : permet de créer un nouveau document à partir d’un document existant et
d’appliquer un ensemble d’opérations de montage (suppression, répétition d’une partie du
document, ajout de texte, application de filtres d’image) sur ce nouveau document.
 La propriété nbdocs correspond au nombre de documents multimédia stockés dans la table de
montage.

La Classe BoiteAFiltres fournit des opérations permettant d’appliquer des filtres (nettoyage d’image,
luminosité, etc…) sur des documents multimédia.

Q1. Donnez le diagramme de cas d’utilisation de l’application StudioMontage.

5
NE RIEN INSCRIRE DANS CETTE ZONE

Q2. Donnez le diagramme de séquence correspondant à l’acquisition d’un nouveau document

puis à l’application du filtre F1 lors du montage de ce document.

On souhaite désormais améliorer l’architecture de l’application StudioMontage de manière à ce qu’une


table de montage puisse être liée à différents types de sources multimédia. Outre une caméra, on souhaite
en particulier pouvoir interfacer la table de montage à un téléphone 3G ou un PDA.
Le problème sous-jacent est que l‘algorithme à mettre en oeuvre pour permettre l’acquisition d’un
document « brut » peut varier d’une source multimédia à une autre, du fait de leurs différences (soft,
hard) intrinsèques. Nous souhaitons que notre application puisse utiliser pour chaque source
l’algorithme d’acquisition adéquat, et ce de façon complètement transparente pour l’utilisateur
Q3. Proposez une solution à ce problème en appliquant le Design Pattern Stratégie. Justifiez votre
réponse.

6
NOM : N°CIN :

PRENOM : N° inscription :

N° salle : N° Place :

Exercice N°3

Une application doit utiliser un environnement offrant des widgets1de type Button et Menu. On
voudrait qu’il soit possible de choisir lors du lancement de cette application le type de ceux de la
librairie Motif. Quelle que soit la librairie utilisée, un Button ou un Menu est composé des propriétés
suivantes: color (int), shape (int) et behavior (int).
Utilisez le pattern Abstract Factory pour modéliser ce type d’application. Votre modèle doit
respecter les contraintes suivantes:
1) votre abstract factory doit être un singleton;
2) la production d’un objet Button ou Menu doit s’effectuer en utilisant une Factory Method
3) La classe implantant la Factory Method doit utiliser le pattern Builder pour construire les objets
Button ou Menu (i.e. construire leur différents descripteurs soit color, shape et behavior)
Dessinez le diagramme satisfaisant ces exigences.

7
NE RIEN INSCRIRE DANS CETTE ZONE

Vous aimerez peut-être aussi