Génie → Logiciel

  • Caractéristique du génie

    Génie

    • L'ingénieur est guidé par la rigueur et la recherche de garantie
    • Capacité de répondre aux besoins d'une personne en proposant des solutions innovatrices, durables et adaptés à l'environnement.
    • Utilise des outils et une méthodologie de travail
  • Caractéristique du logiciel

    Logiciel

    • Un logiciel est de nature très complexe et représente un ensemble de comportements.
    • Contrainte accidentelle: limite des outils, imprévus, problèmes transitoires
    • Contrainte inhérente: complexité, conformité, invisibilité, discontinuité

Contenu

  • Génie: Qualités de l'ingénieur
  • Logiciel: Caractéristiques du logicel

Outils + Méthodologie

  • Modèle de développement

    Manière d'organiser et mettre en oeuvre les activités amenant à la réalisation du logiciel.
    Facteurs décisifs: Distance entre acteurs & Contraintes sur ressources.
  • Modèle en cascade Modèle en V

    Modèle linéaire

    Cascade, Modèle en V
    • Plus on avance dans les étapes plus un changement coûte cher.
    • Permet une conception bien pensée.
    • Adapté à des projets dont les exigences sont bien comprises et les ressources limitées.
    • Avantages 👍
      • Simple et facile à suivre.
      • Axé sur la documentation et l'analyse
      • Permet une conception bien pensée
    • Inconvénients 👎
      • Purement linéaire.
      • Trop rigide
      • Pas de feedback du client avant la livraison
      • Vérification tardive
  • Processus itératif

    Modèle itératif

    Prototypage, Code-et-modifie (non recommandé pour projet à livrer)
    • Pertinent pour les projets où les exigences ne sont pas clairement définies/comprises.
    • Chaque version a pour but de se rapprocher du système cible plus que la version précédente.
    • Architecte la coquille du produit complet, puis améliore chaque composant.
    • Avantages 👍
      • Réutilisation de prototypes.
      • Produit visible très tôt
      • Souci de vérification et validation du client anticipé
      • Intégration facilitée, moins de raffinement
    • Inconvénients 👎
      • Retravaille chaque itération.
      • Produit livré à la fin
  • Modèle incrémental Modèle incrémental

    Modèle incrémental

    Phase
    • Pertinent pour les projets d'envergures.
    • Pour gérer de plus grandes information, utiliser le raffinement par étapes.
    • Permet de développer par ordre de priorité (on se concentre ce qui est important à chaque étape).
    • Chaque incrément abouti à une livraison.
    • Avantages 👍
      • Développer par ordre de priorité.
      • Livraison de composants rapides
      • Facile de mesurer le progrès
    • Inconvénients 👎
      • Pas de processus visible et clair à suivre.
      • Tache d'intégration prend plus d'importance
  • Modèle itératif & incrémental (I & I)

    • Tous les flux d’activités (workflow) sont impliqués dans chaque incrément, mais certains vont dominer plus.
    • Plusieurs opportunités de tester, recevoir du feedback et s’ajuster.
    • Robustesse de l’architecture peut être déterminée tôt dans le développement.
    • Livrables spécifiques pour chaque incrément et chaque workflow.
    • On peut atténuer et résoudre les risques plus tôt.
  • Processus Unifié

    Définit un cadre de méthodes de développement en suivant une démarche itérative et incrémentale.
    Définit un processus intégrant toutes les activités de conception et de réalisation au sein de cycles de développement réparties sur plusieurs phases, comprenant chacune plusieurs itérations.
  • Modèle unifié Groupement en paquets (phases)

    Flux de travail

    • Exigences: Déterminer ce dont le client a besoin.
    • Analyse: Analyser et affiner les exigences.
    • Conception: Affiner l'analyse et produire un design implémentable par les programmeurs.
    • Implémentation: Traduire le design dans le langage de programmation choisi.
    • Test: Évaluer les artéfacts produits jusqu'à présent.
    • Déploiement: Installation du logiciel et livraison de tous les artéfacts au client.

    Phase

    • Création: Déterminer les nécessités et la faisabilité du logiciel à développer.
      • Exigences
    • Élaboration: Affiner et élaborer ce qui a été fait durant la phase de création.
      • Exigences (révision)
      • Analyse
      • Conception (architectural)
    • Construction: Produire une première version du logiciel, fonctionnelle et de qualité.
      • Conception
      • Implémentation (itérative)
      • Tests
    • Transition: Implantation du système dans l’environnement de production.
      • Test
      • Déploiement
  • Agile

    Principes de développement organique (plusieurs incréments, plannification flexible) et inclusive (client fait partie de l'équipe) orienté résulat (emphase sur les activités de construction). Plus de détails...
  • Agile manifesto (12 principes)

    Méthodes agiles

    • Scrum: Scrum place comme principe fondamental la capacité de réorienter la réalisation au cours de son avancement pour toujours être en phase avec les attentes des clients.
      Équipe Scrum: Propriétaire du produit (représentant des clients et utilisateurs), Scrum master, Équipe de développement (7±2, pluridisciplinaire)
    • Développement dirigé par les tests (TDD): Processus en petites étapes où les tests sont utilisés comme spécification.
      Écrire chaque test avant d'écrire le code source et remanier le code continuellement.
    • Développement dirigé par les fonctionnalités (FDD): Centré sur le client, il suit un processus d'itération à courte durée composoé de cinq activités de base. Permet de faire un suivi de l'avancement des fonctionnalités dans toutes les activités entreprises.
    • Extreme Programming (XP): Projet divisé en itérations. Chaque jour: réunion debout, formation des paires, rédiger les tests, programmer. Chaque semaine, le client fait des tests à partir des scénarios et on ajuste les prochaines itétations en conséquent
    • Lean Development (ex: Kanban): Traduction du Lean manufacturing développé en gestion de la production (génie industriel). Par exemple, Kanban organise le travail sur un tableau sectionné en phases ou statuts d'avancements. Ceci permet d'avoir une vue d'ensemble de l'avancement et de travailler efficacement en équipe.
  • Gestion de versions

    Gérer l'ensemble des versions (états) d'un ou plusieurs fichiers. Les stratégies employées permettent de suivre et controler l'évolution du code source ou d'un projet, faire des sauts vers différents états et collaborer avec d'autres sans trop d'effort.
  • versionnement centralisé versionnement decentralisé versionnement decentralisé

    Gestion de versions

    • Besoin de sauvegarde sécuritaire du code source (back-up)
    • Conserver une trace
    • Collaborer entre individus
    • Développement incrémental et itératif: plusieurs versions du code
    • Centralisé – SVN (Tortoise), CVS: Source de vérité unique. Tout le monde communique obligatoirement avec le même dépot (repository).
    • Décentralisé – Git (Github, Bitbucket), Mercurian (Atlassian): Source de vérité relative. Tout le monde communique avec le dépot externe de son choix et possède une copie de tout l'historique ou état du dépot sur sa machine.
    • Commandes de base

      • Clone/Check out git clone git@github.com:path/to/repository.git: Récupération du remote dépot pour la première fois
      • Commit git commit -m "commentaire rattaché au commit": Soumet les modifications complétés et enregistrés en créant un identifiant unique rattaché à ce nouvel état.
      • Push git push origin master: Envoie les changements (soumis par commit) dans le working copy (en local) vers un remote dépot (serveur).
      • Pull git pull: Récupération des changements apportés au remote dépot depuis la dernière récupération. Effectue un merge avec le working copy
      • Fetch git fetch: Vérification des changements apportés au dépot. Les changements sont placés dans le local repository et peuvent être comparés au working copy.
  • UML

  • Cas d'utilisation

    • Capture le comportement d'un système tel qu'un utilisateur extérieur le voit. Regroupe les besoins fonctionnels en unités cohérentes (cas d'utilisation), ayant un sens pour les acteurs.
    • Décrit une interaction entre le logiciel et ses utilisateurs (acteurs) qui initient les CUs.
    • Système: Cadre du sytème à développer
    • Acteur: A un but en utilisant le système. Joue un rôle d’interaction
    • But (objectif): Ce que l’acteur veut accomplir en interagissant avec le système. Chaque but est un CU.
  • Diagramme d'activités

    • Permet de mettre l'accent sur les traitements ⇒ Particulièrement adapté à la modélisation du cheminement de flots de contrôle et de flots de données.
    • Représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.
    • Actions: Plus petit traitement en UML qui a une incidence sur l'état du système ou en extrait une information.
    • Activités: Définit un comportement décrit par un séquencement d'actions.
    • Transitions: Passage d’une activité/action à une autre. Elles spécifient l'enchaînement des traitements et définissent le flot de contrôle.
    • Objets: Représente l'existence d'un objet généré par une action dans une activité et utilisé par d'autres actions.
    • Nœuds de contrôle: initial, fin d'activité, fin de flot, décision, fusion, bifurcation, d'union
  • Diagramme ECB (Entité-Controle-Interface)

    • Utilie pour représenter un premier modèle conceptuel du système.
    • Classes d'entité: Concepts et information qui vit et persiste dans le logiciel
    • Classes d'interface: Interactions entre le système et l’environnement/acteurs
    • Classes de contrôle: Calculs et algorithmes complexes
  • Diagramme de classes

    • Permet de décrire la structure statique du logiciel. Indique les contraintes sur les objets et leurs relations.
    • Classes: attributs, opérations
    • Visibilité: private -, protected #, package ~, public +
    • Relations: association, agrégation, composition, généralisation/spécialisation
    • Multiplcité: nombre d’instances participantes ( 0..1 | 1 | 0..* | 0..k | k..* | n..m )
    • Roles: Nom (fonction sémantique) donné à une classe dans une association (indispensable pour les associations réflexives).
  • Diagramme de séquences

    • Décrit les CU en mettant en évidence les interactions entre les instances des classes (objets) du logiciel.
    • Montre la séquence au cours du temps des échanges de messages (numérotés) entre les objets participant à un scénario.
    • Type de messages: envoie d'un signal, invocation d'une opération, création ou destruction d'une instance
    • Messages synchrones: attend la réponse du destinataire avant de poursuivre.
    • Messages asynchrones: poursuit son activité sans attendre la réponse à son message.
    • Fragments: Sections démarquée d’un diagramme de séquence. OPT (optionnel, if), ALT (alternatives, if-then-else), LOOP (répétition, while), REF (référence à une interaction)

Contenu

  • Modèle de développement: Linéaire (Cascade, V), Itératif, Incrémental
  • Processus unifié: Flux et Phase (itératif et incrémental)
  • Agile: TDD, XP, Scrum
  • Gestion de versions: Centralisé (SVN), non-centralisé (Git)
  • UML: Diagramme de CU, diagramme d'activités, diagramme de classes, diagramme de séquence

Processus de développement

  • Exigences

    • Cueillette des besoins: Entrevue, Sondage, Observation
    • Compréhension du domaine: Glossaire, Persona, Prototypage
    • Analyse des besoins et risques
      • Besoins fonctionnels: Spécifie une action que le système doit accomplir sous forme d’interaction entre le système et son environnement.
      • Besoins non-fonctionnels: Spécifie des propriétés du logiciel même (utilisabilité, fiabilité, performance, sécurité, interopérabilité...)
      • Priorisation des besoins: Par valeur d'affaire ou par sévérité de risque.

    Cas d'utilisation

    • Capture le comportement d'un système tel qu'un utilisateur extérieur le voit. Regroupe les besoins fonctionnels en unités cohérentes (cas d'utilisation), ayant un sens pour les acteurs.
    • Décrit une interaction entre le logiciel et ses utilisateurs (acteurs) qui initient les CUs.

    Scénario

    • Séquence spécifique d’interactions entre les acteurs et le système et d’actions subséquentes du système
    • Acteurs: Principal (initie le CU) et secondaires (intervient dans la réalisation du CU).
    • Scénario principal: Décrit ce qui se déroule normalement, quand il n’y a pas d’erreur.
    • Scénario alternatif: Variantes du scénario principal. Exceptions que le système doit traiter.
    • Préconditions nécessaires pour entamer le scénario principal.
    • Postconditions de l’état du système lorsque le CU est complété avec succès.
  • Analyse

    • Analyse des exigences sur un plan technique et définition des contraintes de la conception et de l’implémentation.
    • Pas nécessairement compréhensible par le client. Force le client et les développeurs à prendre des décisions difficiles le plus tôt possible.
    • Déterminer la partie à informatiser, les ressources physiques nécessaires, les exigences conceptuelles et matérielles.
    • Modèle d'analyse complet
      • Modèle fonctionnel: Fonctionnalités du système (CU + scénarios)
      • Modèle dynamique: Comportement du système (Activités + Flux de données)
      • Modèle d'objet: Concepts manipulés par le système et leurs propriétés (Classes, composants)
  • Conception

    • Détermine la structure interne du logiciel: comment il va atteindre ses buts
    • Bonne conception contribue à la qualité du logiciel (Fiabilité, correction et facilité d’évolution).
    • Objectifs
      • Forte cohésion: Éléments ne sont pas réunis dans un même module par hasard, ils forment un tout pour réaliser une tâche
      • Faible couplage: Modules sont relativement indépendants : dépendent le moins possible des éléments d’autres modules
      • Abstraction: Décomposition intuitive exprimée en termes du problème, qui permet de se concentrer sur un module à la fois
      • Encapsulation et dissimulation d’information: Détails d’implémentation propices à changer sont cachés derrière une interface stable
    • Décomposition du système
      • Décomposer le système en petits modules qui sont individuellement plus faciles à concevoir et implémenter
      • Décomposition fonctionnelle: Décomposer le système en modules par fonctionnalité
      • Système est partitionné en modules distincts mis en relation
      • Établir une hiéarchie: Facilite la compréhension de la structure par niveau d’abstraction
    • Diagramme utiles
      • Diagramme de classe Vue détaillée du design. Plus de classes que dans le modèle d’analyse. Identifier et caractériser les attributs et méthodes de chaque classe en pensant à l'implémentation.
      • Diagramme de séquence: Décrit les interactions entre les objets, instances du diagramme de classe. Un diagramme de séquence par CU
  • Implémentation

    • Implémenter le produit logiciel cible.
    • Grand système partitionné en sous-systèmes développés en parallèle. Le développement d’interfaces est crucial pour la programmation distribuée.
    • Implémentation d'un artéfact ou module est toujours suivi de tests.
    • Choix du langage de programmation
      • Spécification du contrat. Langage peut être laissé au choix
      • Environnement cible. Le web (frontend) ne supporte que le Javascript, HTML et CSS
      • Expérience/Préférences de l'équipe de développement. Réutilisation de libraires internes
    • Normes de programmation et bonnes pratiques
      • Utiliser des noms de variables significatifs et cohérents (ambigus ou génériques).
      • Suivre la nomenclature du langage de programmation (ex: camelCase pour Java)
      • Décrire chaque module en utilisant un format reconnu pour générer la documentation (ex: Javadoc)
    • Outils de programmation
      • IDE: Environnement combinant tous les outils nécessaires pour le développement.
      • Éditeur: Outil pour écrire et explorer du code. Peut être augmenté (via extensions, pluggins).
    • Débogage
      • Assertions: Vérifier une condition lors de l'éxecution (if-else). Utiliser des tests unitaires.
      • Exceptions: Détecter une errer logique ou un cas extrèmes (try-catch)
      • Traçage: Produire la trace d’appels (stack trace) retraçant l’historique d’exécution du programme
      • Log manuel: Afficher l’information sur l’état du programme dans un log (ex: fichier texte)
      • Débogueur interactif: Contrôler l'exécution avec des breakpoints et suivre l'état du programme pas à pas. Eclipse debugger
      • Débogage en direct: Modifier le comportement sans quitter le flux d'exécution Démo
  • Tests

    • L’erreur est humaine, les programmes sont développés par des humains
    • Qualités du logiciel
      • Pertinence fonctionnelle: Fonctionnalités du logiciel correspondent aux besoins exprimés et tacites du client et des utilisateurs.
      • Performance: Logiciel présente des performances relatives aux ressources utilisées.
      • Compatibilité: Deux modules peuvent échanger des informations et/ou effectuer leurs tâches, tout en partageant le même environnement (matériel ou logiciel).
      • Utilisabilité: Logiciel peut être utilisé de manière efficace et efficiente par ces utilisateurs (humain), en procurant une expérience satisfaisante.
      • Fiabilité: Logiciel performe des fonctionnalités attendues dans des conditions attendues sur une durée attendue.
      • Sécurité: Logiciel protège l’information pour que les utilisateurs aient les accès requis conformément à leur type/rôle et niveau d’autorisation.
      • Maintenabilité: Logiciel peut être modifié efficacement pour l’adapter aux changements dans l’environnement et dans les exigences.
      • Transférabilité: Logiciel peut être transféré d’un environnement (logiciel ou matériel) à un autre.
    • Inspections
      • Tester le logiciel sans exécuter de cas de test.
      • Révision du logiciel: lire attentivement
      • Métriques d'inspection: Taux d'inspection, densité de fautes, taux de détection de fautes
      • Revue de code (code review)
    • Méthodes formelles
      • Prouver que le code est correct
      • Graphe de flux de controle: Exécution symbolique du programme
      • Démonstration automatique de théorèmes
    • Boite noire vs Boite blanche
      • Boite noire (test fonctionnel): Vérifie si le comportement externe du logiciel est conforme aux exigences.
      • Boite blanche (test structurel): Vérifie si l’implémentation du logiciel est correcte
    • Type de tests
      • Unitaire: Chaque composant implémenté doit être testé individuellement, dès que complété.
      • Intégration: Après chaque itération, combiner les composants et les tester ensemble.
      • Système: Tester le système au complet (par développeur)
      • Acceptation: Tester l'application à chaque livraison (par client)
  • Déploiement

    • Phases d'un logiciel
      • Pré-alpha: Encore en développement, avant les tests formels.
      • Alpha: En mode tests fonctionnels (boite noire et boite blanche).
      • Beta: Logiciel fonctionnel, testé, dans les mains d'un groupe d'utilisateurs controlé.
      • Candidat à la livraison: Potentiellement la version finale à moins d'autres défauts. Code source figé.
      • En production: Disponible au public. Version commercialisée.
    • Stratégie de versionnement Suivre un standard (MAJOR.MINOR.PATCH) comme le Semantic Versioning
    • Environnements
      • Développement: Ordinateur personnel du développeur contenant tout le nécessaire pour le développement.
      • Test (staging): Simule l’environnement de production. Roule souvent sur une machine virtuelle
      • Production: Vrai environnement où le logiciel est installé
    • Virtualisation
      • Machine virtuelle: Abstraction complète de la machine. Interagit avec composantes physiques de l’ordinateur via hyperviseurs.
      • Conteneur: Contient toutes les dépendances nécessaires (services, librairies…) pour exécuter une application. Utilise les fonctionnalités de l’OS hote pour en simuler un autre.
    • DevOps
      • Inclure les Ops tout au long du processus de développement
      • Instaurer un processus (automatisé) de déploiement en continu suivi par tous
    • Intégration continue et Livraison continue (CI/CD)
      • Utiliser des scripts pour automatiser certaines taches
      • Intégration continue (CI): Chacun commit son code fréquemment. Des tests automatisés sont utilisés pour éviter l'introduction de fautes (bugs) ou d'une incompatibilité entre le nouveau code (branche) et le code principal (main).
      • Livraison continue (CD): Infrastructure d'automatisation du déploiement/publication ciblant un ou plusieurs environnements.
  • Maintenance

    • Tout changement de n’importe quel artéfact du logiciel une fois déployé
    • Maintenabilité doit être pensée dès le début
    • Type de changements
      • Perfectif: Accroître la valeur du logiciel suite à des changements demandés par le client.
      • Adaptif: Préserver la valeur du logiciel en répondant aux changements de l’environnement
      • Correctif: Corriger les défauts restants
      • Préventif: Protège le logiciel en facilitant les changements futurs par anticipation
    • Logiciels de suivi de défauts Exemples: Bugzilla, Backlog, BugHerd
      • Création de tickets, assignation et suivi de la résolution
      • Rapport de défauts: Doit inclure assez d’information pour permettre au programmeur de maintenance de recréer le problème pour l’investiguer
    • Recherche des modules cibles
      • Recherche textuelle: Indépendant de la structure du programme, mais dépend des conventions de nommage. Applicable à des concepts explicites seulement
      • Graphe par dépendance (graphe): Utilise la structure des classes du programme et nécessite la compréhension des fonctionnalités locales et composites. Applicable aux concepts implicites et explicites
    • Refactoring
      • Modifie la structure du code sans affecter la fonctionnalité
      • Certains changements sont apportés afin de minimiser l’impact des changements
      • Consiste en une séquence de transformations qui préservent le comportement
    • Test de régression
      • Garantir que le changement est correct. Après un changement, le programmeur re-teste tout le code.
      • Cas de test antérieurs font partie du test de régression. La suite de tests augmente

Contenu

  • Exigences: Élaboration des besoins du client et compréhension du domaine
  • Analyse: Analyse des exigences et définition des contraintes physiques et conceptuelles
  • Conception: Choix d'architecture et modélisation d'une solution implémentable
  • Implémentation: Traduction du design en code exécutable
  • Tests: Vérification et validation des artéfacts produits
  • Déploiement: Installation du logiciel et livraison des artéfacts au client
  • Maintenance: Tout changement de n’importe quel artéfact du logiciel une fois déployé

Architecture + Conception

  • Principes de conception

    • Couplage d'un module: Degré d'interaction entre les modules
    • Cohésion d'un module: Degré d'interaction au sein du module
    • Bonne conception 👍
      • Faible couplage et forte cohésion
      • Réutilisation: Réutilisation d’un composant d’un produit pour faciliter le développement d’un autre produit ayant des fonctionnalités différentes
      • Conception modulaire: Décomposition en modules indépendants et interchangeables qui contiennent tout ce qui leur est nécessaire pour exécuter un aspect d’une fonctionnalité
      • Conception évolutive: Minimiser l’effort d’apporter des modifications au logiciel après le développement initial
    • Mauvaise conception 👎
      • Rigidité: Logiciel difficile à modifier car chaque changement impacte beaucoup trop de parties du système
      • Fragilité: Quand on effectue une modification, des parties imprévues du système ne fonctionnent plus
      • Immobilité: Difficile de réutiliser un composant dans une autre application car on ne peut la démêler de l’application courante
  • Réutilisation

    • Librairie: Ensemble de programmes/modules cohésifs et réutilisables. Utilisateur de la librairie est responsable de la logique de contrôle.
    • Framework: La plateforme incorpore la logique de contrôle générique. Utilisateur personnalise les fonctionnalités génériques pour les besoins de l’application.
    • Programmation orientée composant: Combine les deux approches. Mise en place d’une plateforme applicative et identification des librairies réutilisables que la plateforme peut invoquer.
  • Styles d'architecture

    • Pipes et filtres: Modules organisés en filtres communiquant via des pipes. Traitement batch en plusieurs étapes.
      Usages: Compilateur, Traitement d'image, Lignes de déploiement.
    • En couche (ex: 3-tier): Système organisé en couches hiérarchiques. Chaque couche fournit un service à la couche supérieur et sert de client à la couche inférieure.
      Usages: Réseaux, Application Web.
    • MVC: Divide une application en trois composant: Modèle (contient les données et les services d'accès et manipulation des données), Vue (Affiche l'information à l'utilisateur), Controleur (Effectue le traitemetn des requêtes)
      Usages: Majorité des applications web, Framework
    • Client-serveur: Divise le système en deux parties, serveur et clients. Le serveur fourni des services aux clients qui contacte le serveur.
      Usages: Email, Systèms bancaire
    • Peer-to-peer: Chaque nœud (peer) joue à la fois le rôle du client et du serveur.
      Usages: Blockchain, BitTorrent
    • Microservice Collection de petits services autonomes, indépendants et restraints à une fonction, accessible via une API.
      Usages: Amazon web services (AWS), Azure
  • Paradigme orienté-objet

    • Objet: Représente une entité réelle ou conceptuelle, singulière et identifiable avec un rôle bien défini dans le domaine du problème
    • Classe: Représentation d’un ensemble d’objets qui partagent une structure, un comportement et une sémantique en commun
    • Héritage: Relation de partage de la structure et du comportement
    • Polymorphisme: Une opération définie dans plus d’une classe qui prend différentes implémentations
    • Encapsulation: Regroupement de concepts reliés en une seule unité référée par un seul nom
    • Abstraction: Utilisation de l’encapsulation pour restreindre la perception depuis l’extérieur sur les mécanismes internes au logiciel
    • Généricité: Mécanisme pour que les clients décident du type d’objets dans une classe à travers des paramètres passé lors de la déclaration et qui est évalué lors de la compilation
  • Patrons de conception

    Patron de création

    • Singleton Garantir qu’une classe n’a qu’une seule instance et offre un point d’accès global
      • Contrôle l’accès à l’instance
      • Accès global sans utiliser de variable globale
      • Facilite le raffinement des opérations et représentations
    • Fabrique Permet de dissimuler comment créer les objets.
      • Définir une interface pour créer un objet, mais en laissant les sous-classes décider quelle classe instancier
      • Permet au code d’être indépendant de comment les objets sont créés, composés et représentés
      • Délègue l’instanciation à une sous-classe

    Patron de structure

    • Composite Compose les objets en structures d’arborescence pour représenter des hiérarchies d’ensemble/partie.
      • Permet au client de traiter les objets et les compositions de façon uniforme
      • Définit une hiérarchie claire des objets
      • Composition récursive d’objets simples et complexes
    • Adapteur Communication entre deux objets ayant leurs implémentations incompatibles
      • Donne accès à son implémentation interne sans pour autant coupler les clients à son implémentation interne
      • Adaptateur fournit tous les avantages de la dissimulation de l’information sans avoir à cacher ses détails d’implémentation

    Patron de comportement

    • Patron de méthode Définit le squelette d’un algorithme dans une opération en reportant certaines étapes à des sous-classes.
      • Permet d’affiner certaines étapes d’un algorithme sans changer sa structure
      • Implémente les parties invariantes d’un algorithme et laisse les sous-classes implémenter le comportement qui va varier
      • Évite la duplication de code en factorisant le comportement commun des sous-classes
    • Stratégie Définit une famille d’algorithmes, encapsule chacun et rend-les interchangeables.
      • Algorithme varie indépendamment du client qui l’utilise

Contenu

  • Principes de conception: Couplage, cohésion, module
  • Architecutre: Pipes et filtres, En couche, MVC, Client-serveur, Peer-to-peer, Microservices
  • Paradigme orienté-objet: Encapsulation, Classes et objets, Héritage, Polymorphisme
  • Patrons de conception: Singleton, Composite, Patron de méthode, Stratégie, Adapteur