Module 3 Flashcards
Base de l’approche orientée-objet
oAbstraction
oHiérarchie
oDécomposition
objectifs du UML (Unified Modeling Langage)
- 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.
+operationXXX()
#operationYYY()
-operationZZZ()
XXX : publique
YYY : protégée
ZZZ : privée
Spécification d’un contrat
▪ 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.
assertions s’appliquant à des méthodes en particulier
❑ préconditions
❑ postconditions
assertions s’appliquant à toutes les méthodes d’une classe en
tout temps.
invariants de classe
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
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
préconditions
▪ 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]
postconditions
▪ 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]
Invariant
▪ 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.
(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.
vrai
Les invariants doivent donc être testés quand ?
o à la fin de tous les constructeurs.
o à la fin de toutes les méthodes non constantes
sortie de assert(!estVide()); si faux
assertion failed!
file: pile.cpp
line: 234
test: !estVide()
(vrai ou faux) Dans une méthide, la condition peut être dans la précondition ET dans le corps de la méthode
faux (jamais dans les deux)
Une méthode ne devrait-elle pas être préparée pour
traiter toutes les entrées possibles ?
Non, plus la précondition est forte, plus la responsabilité du
client sera grande et plus celle du fournisseur sera petite.
Qui devrait s’occuper des valeurs anormales?
➢décision pratique qui a trait à la division du travail.
✓La meilleure solution est celle qui génère l’architecture
la plus simple
les macros pour le contrat
▪ “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();
PRECONDITION sert a XXX
POSTCONDITION sert a YYY
ASSERTION sert a ZZZ
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.
INVARIANTS() fait quoi?
appelle verifieInvariant()
(méthode privée const dans le .h de la classe)
Test unitaire
❑ 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.
On doit tester toutes les méthodes XXX
XXX : publiques
test uniyaire seul test qui assure que ca fonctionne correctement?
non
(vrai ou faux) on peut mettre plusieurs cas dans un test
faux
résultats possibles d’une assertion
➢ success (test réussi),
➢ nonfatal failure (test échoué)
➢ fatal failure (test échoué et arrête la fonction)
2 types d’assertions:
EXPECT_* : assertions non-fatales (continue après échec)
ASSERT_* : assertions fatales (arrête le programme)
ASSERT_THROW(statement,
exception_type);
statement throws an
exception of the given type
exemple de test avec fixture pour une pile
class PileVide : public ::testing::Test
{
public:
Pile f_unePile;
};
TEST_F(PileVide,PileVideEstVide)
{
ASSERT_TRUE(f_unePile.estVide());
}
