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 la modularité des 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. communiquez le problème à gus@etsmtl.ca.

Un laboratoire d'introduction à l'infrastructure et des outils, trois (3) plans d'itération et rapports sur les travaux de laboratoire et une évaluation finale des fonctionnalités réalisées. Sauf pour le premier, les travaux de laboratoire sont effectués en équipe. L'enseignant décide de la composition de chaque équipe pour les raisons pédagogiques.

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.

À noter qu’une moyenne inférieure à 60% dans les évaluations à caractère individuel entraîne automatiquement un échec au cours.

Les travaux de laboratoire n'impliquant pas de démonstration qui sont remis en retard de moins de 24h seront évalués et la note sera réduite par 50%.

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". 

Afin de faire valider une absence à une évaluation en vue d’obtenir un examen de compensation, l’étudiante ou l’étudiant doit utiliser le formulaire prévu à cet effet dans son portail MonÉTS pour un examen final qui se déroule durant la période des examens finaux ou pour tout autre élément d’évaluation surveillé de 15% et plus durant la session. Si l’absence concerne un élément d’évaluation de moins de 15% durant la session, l’étudiant ou l’étudiante doit soumettre une demande par écrit à son enseignante ou enseignant.

Toute demande de validation d’absence doit se faire dans les cinq (5) jours ouvrables suivant la tenue de l’évaluation, sauf dans les cas d’une absence pour participation à une activité prévue aux règlements des études où la demande doit être soumise dans les cinq (5) jours ouvrables avant le jour de départ de l’ÉTS pour se rendre à l’activité.

Toute absence non justifiée par un motif majeur (voir articles 7.2.6.1 du RÉPC et 6.5.2 du RÉCS) entraînera l’attribution de la note zéro (0).

Un manuel du cours (Analyse et conception de logiciels) est disponible en ligne.

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. (en rupture de stock, mais il est possible de trouver des exemplaires usagés)

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. 

Plusieurs outils seront utilisés dans le cours, car Moodle a plusieurs désavantages dans l'interface pour les enseignants. 

• Moodle sera utilisé pour le matériel du cours et les mini-tests (quiz).
• OneDrive sera utilisé pour le stockage de la matière du cours.
• Github Classroom sera utilisé pour le contenu des laboratoires.
• Microsoft Équipes (Teams) et Discord seront utilisés pour les travaux de laboratoire, pratiques et les exercices.

Sans objet.