Module 3

Question 1

Base de l’approche orientée-objet

Answer 1

oAbstraction
oHiérarchie
oDécomposition

Question 2

objectifs du UML (Unified Modeling Langage)

Answer 2

• Modélisation des systèmes utilisant les techniques orientées
  objet, depuis la conception jusqu’à la maintenance
• Création d’un langage abstrait compréhensible par l’homme et
  interprétable par les machines.

Question 3

+operationXXX()
#operationYYY()
-operationZZZ()

Answer 3

XXX : publique
YYY : protégée
ZZZ : privée

Question 4

Spécification d’un contrat

Answer 4

▪ Spécification d’une interface
➢peut être vue comme un contrat entre un client (l’utilisateur du
composant/classe) et un fournisseur (le composant/classe).
▪ Le contrat dit ce qui doit être rencontré par le client
➢pour pouvoir appeler une opération de l’interface :
précondition.
▪ Le contrat dit aussi ce qui doit être réalisé par le fournisseur
➢de fait, ce qui est garanti au client
➢pour rencontrer ce qui est prévu par l’opération
postcondition.

Question 5

assertions s’appliquant à des méthodes en particulier

Answer 5

❑ préconditions
❑ postconditions

Question 6

assertions s’appliquant à toutes les méthodes d’une classe en
tout temps.

Answer 6

invariants de classe

Question 7

La prototype d’une opération comprend: (3 trucs)

on ne sait pas: (2 trucs) (c’est pour ça qu’on ajoute precondition et postcondition

Answer 7

comprend :
o le nom de l’opération
o le type et l’ordre des paramètres entrants/sortants
o le type de retour
sait pas :
o dans quel contexte l’opération peut être appelée
o quels résultats sont escomptés

Question 8

préconditions

Answer 8

▪ conditions devant être remplies avant
d’exécuter une méthode.
➢Si le contrat n’est pas rempli, la méthode n’a pas
à s’exécuter. [Erreur de programmation]

Question 9

postconditions

Answer 9

▪ conditions devant être remplies après
l’exécution d’une méthode.
➢Si le contrat n’est pas rempli, la méthode ne doit
pas retourner. [Erreur de programmation]

Question 10

Invariant

Answer 10

▪ représente l’ensemble des conditions logiques devant
être respectées pour assurer un comportement correct
d’une classe.
➢Immédiatement après la création d’un objet de cette classe,
➢doit être respecté et préservé tout au long de la vie de
l’objet.

Question 11

(Vrai ou faux) Au milieu d’une méthode, les invariants peuvent
être violés mais doivent être rétablis à la fin de
celle-ci.

Answer 11

vrai

Question 12

Les invariants doivent donc être testés quand ?

Answer 12

o à la fin de tous les constructeurs.
o à la fin de toutes les méthodes non constantes

Question 13

sortie de assert(!estVide()); si faux

Answer 13

assertion failed!
file: pile.cpp
line: 234
test: !estVide()

Question 14

(vrai ou faux) Dans une méthide, la condition peut être dans la précondition ET dans le corps de la méthode

Answer 14

faux (jamais dans les deux)

Question 15

Une méthode ne devrait-elle pas être préparée pour
traiter toutes les entrées possibles ?

Answer 15

Non, plus la précondition est forte, plus la responsabilité du
client sera grande et plus celle du fournisseur sera petite.

Question 16

Qui devrait s’occuper des valeurs anormales?

Answer 16

➢décision pratique qui a trait à la division du travail.
✓La meilleure solution est celle qui génère l’architecture
la plus simple

Question 17

les macros pour le contrat

Answer 17

▪ “fonction” définie par un #define.
▪ Remplacement textuel, fait par le
préprocesseur.
▪ Dans le fichier ContratException.h,
1. Définition de ces classes
2. + définition des MACROs suivantes:
➢ PRECONDITION(test);
➢ POSTCONDITION(test);
➢ ASSERTION(test);
➢ INVARIANT(test);
➢ INVARIANTS();

Question 18

PRECONDITION sert a XXX
POSTCONDITION sert a YYY
ASSERTION sert a ZZZ

Answer 18

XXX : pour valider les données en entrée
YYY : pour valider le bon fonctionnement de la méthode avant le
retour de celle-ci
ZZZ : pour valider un état quelconque au milieu de l’algorithmique.

Question 19

INVARIANTS() fait quoi?

Answer 19

appelle verifieInvariant()
(méthode privée const dans le .h de la classe)

Question 20

Test unitaire

Answer 20

❑ Pour s’assurer qu’un composant logiciel se
comporte tel que prévu et spécifié.
❑ Teste les cas normaux et les cas anormaux.
❑ Utilise toujours de façon systématique
l’interface publique de la classe.
❑ Première ligne de défense contre les défauts
du logiciel.
❑ Permet de détecter toute anomalie le plus tôt
possible.

Question 21

On doit tester toutes les méthodes XXX

Answer 21

XXX : publiques

Question 22

test uniyaire seul test qui assure que ca fonctionne correctement?

Answer 22

non

Question 23

(vrai ou faux) on peut mettre plusieurs cas dans un test

Answer 23

faux

Question 24

résultats possibles d’une assertion

Answer 24

➢ success (test réussi),
➢ nonfatal failure (test échoué)
➢ fatal failure (test échoué et arrête la fonction)

Question 25

2 types d’assertions:

Answer 25

EXPECT_* : assertions non-fatales (continue après échec)
ASSERT_* : assertions fatales (arrête le programme)

Question 26

ASSERT_THROW(statement,
exception_type);

Answer 26

statement throws an
exception of the given type

Question 27

exemple de test avec fixture pour une pile

Answer 27

class PileVide : public ::testing::Test
{
public:
Pile f_unePile;
};
TEST_F(PileVide,PileVideEstVide)
{
ASSERT_TRUE(f_unePile.estVide());
}