Après la réussite du cours, les étudiants seront en mesure : 
• de maîtriser et d'appliquer des patrons de conception logicielle;
• de concevoir un logiciel orienté objet en appliquant un ensemble de principes et de méthodes heuristiques de génie logiciel; 
• de réaliser un logiciel en suivant un processus itératif et évolutif incluant les activités d'analyse et de conception par objets.

Les objectifs seront atteints par un enseignement hebdomadaire, sous la forme de séances de cours de trois (3) heures portant sur les concepts de l’analyse et de la conception par objets, et de laboratoires de trois (3) heures par semaine permettant à l’étudiant d’appliquer les concepts théoriques vus en classe.

• Introduction à l’analyse et à la conception par objets et le développement itératif (3 heures[1])
  • Conception par objets
  • Processus unifié
• Modèles de cas d’utilisation (3 heures)
  • Éléments d’un cas d’utilisation
  • Cas d’utilisation et les exigences logicielles
• Modèles de domaine (6 heures)
  • Analyse du domaine d’application
  • Détermination des classes conceptuelles
• Conception par responsabilités (« Design by contract ») (3 heures)
• Notation UML (6 heures)
  • Diagrammes d’interaction
  • Diagrammes d’activité
  • Diagrammes d’état
• Modèle de conception suivant les principes GRASP (6 heures)
  • Expert en information
  • Créateur
  • Contrôleur
  • Faible couplage
  • Forte cohésion
  • Polymorphisme
  • Fabrication pure
  • Indirection
  • Protection des variations
• Modèle de conception, diagrammes de classes et codage (6 heures)
  • Réalisation de cas d’utilisation
  • Tests unitaires
• Conception avec les patrons GoF (6 heures)
  • Familiarisation avec plusieurs patrons de conception et utilisation de ces patrons dans le modèle de conception.

[1]    Ces heures sont des heures approximatives d’enseignement pour chaque sujet et incluent le temps alloué à l’examen intra trimestriel.

Pour l’analyse orientée objet, les étudiants utilisent une liste de catégories de classes conceptuelles pour identifier les classes conceptuelles dans un le domaine de l’application. Ils utilisent également une liste de catégories d’associations pour identifier les associations éventuelles entre ces classes.

Quant à la conception orientée objet, les étudiants utilisent plusieurs heuristiques (General Responsability Assignment Software Patterns, GRASP) pour créer, évaluer et améliorer les conceptions de classes logicielles. 

Pour le développement de logiciels, les étudiants utilisent éventuellement un environnement de développement intégré (IDE) avec des outils supportant les tests unitaires et le réusinage, ainsi que des compilateurs et débogueurs de langage orienté objet.

NOTE : Pour les difficultés techniques avec le matériel des laboratoires du département, s.v.p. communiquer le problème à gus@etsmtl.ca.

Quatre (4) plans d'itération et rapports sur les travaux de laboratoire et une évaluation finale des fonctionnalités réalisées. Les travaux de laboratoire sont effectués en équipe. L'enseignant décide de la composition de chaque équipe.

Chaque membre d'équipe est responsable de la totalité du travail réalisé et remis par son équipe. Toutefois, les membres de l'équipe ayant réalisé un travail peuvent décider de ne pas mettre sur le rapport le nom d’un ou de plusieurs autres membres qui n'ont pas fait une contribution (conception et codage) significative à l’itération. Avant la remise du travail, un courriel doit être envoyé en copie conforme à tous les membres de l’équipe, aux chargés de laboratoire ainsi qu’à l’enseignant pour indiquer les raisons du retrait du nom. Un membre de l'équipe dont son nom n'est pas sur un travail de laboratoire reçoit une note de "0" pour le travail.

Série de jeux-questionnaires et devoirs (à réaliser individuellement) en dehors du cours et d’exercices (à réaliser individuellement ou en équipe) durant les heures du cours.

À noter qu’une moyenne inférieure à 50% dans les évaluations à caractere individuel entraine automatiquement un échec au cours.

La date de l’examen final sera annoncée par l'administration plus tard pendant le trimestre.

Politique de révision d’examen intra

Pour un processus transparent, efficace et clair, une personne inscrite à ce cours ayant des questions à propos de l’évaluation de son examen intra doit

1. écrire les questions sur le dos de l'examen intra lors de la consultation de ce dernier en classe;
2. informer l’enseignant par courriel qu’il a écrit des questions sur son examen intra.

L’enseignant doit

1. réviser l’examen en tenant compte des questions écrites sur l'examen;
2. répondre à l’étudiant par courriel pour communiquer tout changement de note le cas échéant.

Les travaux de laboratoire n'impliquant pas de démonstration qui sont remis en retard de moins de 24h seront évalués avec une note de "-20%".

Les travaux de laboratoire n'impliquant pas de démonstration qui sont remis en retard de plus de 24h seront évalués avec une note de "0".

Tous les autres travaux qui sont remis en retard seront évalués avec une note de "0". 

Il y a un livre obligatoire, mais les étudiants peuvent choisir la version française ou anglaise:

LARMAN, C., UML 2 et les design patterns. 3e édition, Pearson Éducation, 2005.

LARMAN, C., Applying UML and patterns: an introduction to object-oriented analysis and design and the unified process. 3rd edition, Upper Saddle River (NJ), Prentice-Hall PTR, 2005.

GAMMA, E., Design patterns: Elements of reusable object-oriented software. Reading (Mass.), Addison-Wesley, 1995.

GRAND, M., Patterns in Java: A Catalog of Reusable design Patterns Illustrated with UML. Vol. 1, 2nd Ed., New York, John Wiley, 2002.

GRAND, M., Patterns in Java: A Catalog of Reusable design Patterns Illustrated with UML. Vol. 2, New York, Wiley, 1998.

FOWLER, M. et K. SCOTT, UML distilled: Applying the Standard Object Modeling Language. Reading (Mass.), Addison Wesley Longman, 1997.

FITZPATRICK, B. W. et COLLINS-SUSSMAN, B., Team Geek: A Software Developer's Guide to Working Well with Others. O'Reilly Media, 2013. 

Sans objet.

Sans objet.