Afin de bien comprendre et d'appliquer la matière des sujets avancés présentés dans ce cours, les personnes inscrites dans le cours doivent avoir une bonne expérience en programmation dans un environnement moderne, de préférence avec un langage orienté objet (Java, C#, C++, TypeScript, etc.). Par exemple, il y a des travaux à réaliser individuellement où il faut appliquer des principes dans un code source de langage orienté objet.

Une personne ayant réussi ce cours sera en mesure :

• de comprendre et de distinguer entre les différentes sources de complexité dans un logiciel;
• de comprendre et de distinguer les bonnes et mauvaises pratiques de conception;
• de comprendre et d’appliquer de différentes pratiques de réusinage (refactoring) de logiciel orienté objet.
• d'identifier, de critiquer et de corriger quelques antipatrons de conception orientée objet;
• de concevoir et appliquer une étude empirique sur la conception orientée objet;
• de comprendre et de distinguer entre les différentes métriques de qualité de conception, telles que le couplage, la cohésion et la stabilité;
• de comprendre l’impact de ces métriques de qualité sur la conception de logiciels;
• de connaître les notions de fiabilité essentielles pour concevoir un logiciel tolérant aux fautes;
• d’utiliser une notation telle que le langage UML pour modéliser, décrire et communiquer les éléments d’une conception.

La pédagogie du cours est basée sur les méthodes suivantes :

• Lectures individuelles et exposés magistraux permettant de traiter le contenu
• Jeux-questionnaires en ligne pour valider des connaissances
• Exercices en petits groupes durant les séances
• Analyse critique d’article traitant un sujet pertinent
• Réalisation de plusieurs travaux pratiques pertinents au contenu
• Rencontres avec la personne qui enseigne le cours durant les séances

Charge d’enseignement : 39 heures de séances; Charge de travail de la personne inscrite au cours : environ six heures de travail hors séances par semaine.

Sur une base hebdomadaire, cela correspond à trois heures (séance) plus six heures de travail (hors séance). Ceci est un mème créé par la communauté étudiante de l'ÉTS à ce propos.

Contenu

• Outils de détection de patrons de conception, études empiriques sur les bénéfices des patrons de conception.
• Visualisation du logiciel (Roassal, PlantUML)
• Plate-formes d'analyse de logiciels Moose et Glamorous Toolkit (GT), environnement et langage Pharo, utilisation des métamodèles avec Fame/FAMIX, Langage de schéma (pattern language) pour le Développement Malléable (GT).
• Outils d'analyse statique de code source (arbre syntaxique, analyseur syntaxique, etc.)
• Principes de conception (langage de principes, études empiriques, GRASP, SOLID, etc.) 
• Réusinage (refactoring) des antipatrons de conception (Refactoring de Fowler)
• Langages de domaines spécialisés (domain-specific languages) et outils légers pour les concevoir et implémenter (Parsing Expression Grammars)

Cette liste est fournie à titre d'information comme planification initiale et est sujette à changement selon la cadence réelle du cours.

• Jeux-questionnaires en ligne : 10% (individuel)
• Travaux pratiques : 35% (équipe)
  • Laboratoire 1: 10%
  • Laboratoire 2: 10% 
  • Laboratoire 3: 15%
• Analyse, présentation et discussion d’article scientifique portant sur un sujet pertinent au cours : 15% (équipe)
• Examen final : 40% (individuel) - l'examen aura lieu pendant la dernière séance du cours.

La personne qui enseigne le cours peut décider la composition de chaque équipe pour les raisons pédagogiques. Chaque personne dans une équipe est responsable de la totalité du travail réalisé et remis par son équipe. Toutefois, les personnes dans l'équipe ayant réalisé un travail peuvent décider de ne pas mettre sur le document de présentation (rapport, plan de l'itération, diapos, etc.) le nom d’une ou de plusieurs autres personnes qui n'ont fait aucune contribution (conception, programmation, analyse, etc.) significative pendant la période documentée. Avant la remise de ce travail, un courriel doit être envoyé en copie conforme à toutes les personnes de l’équipe, aux auxiliaires de laboratoire (le cas échéant) ainsi qu’à la personne qui enseigne le cours pour indiquer les raisons du retrait du nom. Une personne exclue de l'équipe (dont son nom n'est pas sur un travail) reçoit une note de "0" pour le travail.

Toutes les remises doivent être faites électroniquement et doivent être reçues par la personne qui enseigne le cours avant le délai de la remise indiqué sur le calendrier électronique du cours. Certains travaux ne peuvent pas être remis en retard (le système ne le permet pas et donc la note sera zéro). Pour les autres travaux où une remise en retard est possible, la date (comprenant l’heure et un fuseau horaire) de la remise est donc celle du système électronique. Tout travail remis en retard par rapport au délai se verra automatiquement attribuer une pénalité selon le tableau suivant :

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

L'utilisation des SIAG est permise dans le cours seulement si vous respectez les conditions suivantes:

• Indiquer la requête (prompt) utilisée ainsi que la réponse du SIAG dans :
  • le rapport (ou document remis pour le travail), et
  • le formulaire Google Forms disponible sur Moodle.
• Indiquer précisément la tâche réalisée (exemple : Exercice 3 du TP1, refactoring de la classe xyz.java provenant de l’exercice 2).
• Ajouter, si possible, le lien public (URL) de l’interaction avec le SIAG (optionnel)

Le non-respect de ces conditions constitue une infraction de nature académique (tel que mentionné ci-haut).

Les SIAG peuvent produire des informations erronées et vous devez vérifier vous-même les résultats. Si vous utilisez un SIAG pour un travail et vous avez respecté les conditions d'utilisation, vous demeurez tout de même responsable des erreurs qu’il pourrait générer.

Notes de cours de MGL843 (en ligne)

Pharo MOOC: Live Object Programming in Pharo. (s. d.). Consulté 23 décembre 2020, à l’adresse http://mooc.pharo.org/

Moosetechnology/moose-wiki. (2020). moosetechnology. https://github.com/moosetechnology/moose-wiki

The Moose Book. (s. d.). Consulté 23 décembre 2020, à l’adresse http://www.themoosebook.org/book/

feenk.com, & Girba, T. (s.d.). Glamorous Toolkit. gtoolkit.com. Repéré à https://gtoolkit.com//

Fowler, Martin. 2018. Refactoring: Improving the Design of Existing Code. 2 edition. Boston: Addison-Wesley Professional.

Guéhéneuc, Yann-Gaël, et Foutse Khomh. (2019). « Empirical Software Engineering ». Dans Handbook of Software Engineering, édité par Sungdeok Cha, Richard N. Taylor, et Kyochul Kang, 285-320. Cham: Springer International Publishing. https://doi.org/10.1007/978-3-030-00262-6_7.

McConnell, S. (2004). Code complete, 2^e édition. Redmond, Wash., Microsoft Press.

Juristo, N. and M. Moreno A. (2010). Basics of Software Engineering Experimentation, Springer

Freeman, E., E. Freeman, et al. (2004). Head First design patterns. Sebastopol, CA, O'Reilly.

Horstmann, C. (2006). Object-Oriented Design and Patterns, 2^e édition. Wiley.

Schmidt, D. C., F. Buschmann, et al. (2007). Pattern-oriented software architecture, On Patterns and Pattern Languages (Vol. 5). Chichester England ; New York, Wiley.

Fitzpatrick, B. W. et B. Collins-Sussman (2013). Team Geek: A Software Developer's Guide to Working Well with Others. O'Reilly Media, 2013.

• Site Moodle (visible à partir de SIGNETS)
• Site Google Classroom: Voir le site Moodle pour le lien du site Google Classroom.
• Serveur Teams  (pour exercices, encadrements, rencontres pour les travaux pratiques): Voir le site Moodle pour le lien du serveur Discord.

Il est essentiel que chaque personne inscrite dans le cours ait un ordinateur moderne pendant les séances pour participer aux activités et pour travailler sur les projets. Si vous n'avez pas d'ordinateur moderne, vous ne pouvez pas suivre ce cours.

Politique sur les animaux de compagnie et les enfants

Lorsque la classe se réunit par vidéoconférence et qu'un animal de compagnie ou un enfant apparaît devant la caméra, il convient de le présenter.