Fiche de révision : Modèles et Architecture Logicielle

📋 Plan du Cours

1. Diagramme de cas d'utilisation
2. Classes d'analyse
3. Pattern de conception
4. Architecture en couches
5. Domaine Driven Design
6. Modèle UML
7. Persistance des données
8. Frameworks et patterns
9. Gestion des dépendances
10. Refactoring continu

📖 1. Diagramme de cas d'utilisation

🔑 Notions clés & Définitions

• Cas d’utilisation : Représentation d’un ensemble de scénarios décrivant une interaction entre un acteur et le système pour atteindre un objectif précis. Il illustre ce que le système doit faire (voir aussi "Expression du besoin").
• Acteur : Rôle joué par une personne ou un système externe qui interagit avec le système, permettant de modéliser les utilisateurs ou autres systèmes impliqués dans un processus (voir aussi "Diagramme de cas d’utilisation").
• Relation « include » : Relation entre deux cas d’utilisation où le cas source inclut le comportement du cas destination, permettant de réutiliser des scénarios communs (voir aussi "Relations").
• Relation « extend » : Relation où un cas d’utilisation source ajoute ou modifie le comportement d’un autre cas, permettant de modéliser des extensions ou variantes d’un scénario principal (voir aussi "Relations").
• Cahier des charges : Document précisant les besoins et exigences du système, souvent utilisé pour formaliser l’expression du besoin avant la modélisation (voir aussi "Expression du besoin").

📝 Points essentiels

• Le diagramme de cas d’utilisation se situe dans la vue logique, décrivant ce que le système doit faire en termes de scénarios d’interaction.
• Les acteurs représentent des rôles, non des personnes physiques, et se déterminent en observant les utilisateurs directs ou autres systèmes impliqués. La relation de communication est symbolisée par une flèche, indiquant le déclencheur d’un cas d’utilisation.
• Les relations principales sont « include » (inclure) et « extend » (étendre), permettant de structurer la modularité et la flexibilité des scénarios. La relation « include » favorise la réutilisation, tandis que « extend » permet d’ajouter des comportements optionnels ou conditionnels.
• Un cas d’utilisation doit être simple, clair, et décrire une tâche ou un objectif précis de l’acteur, en se basant sur une question fondamentale : "Quelles sont les tâches de l’acteur et qu’attend-il du système ?".
• La décomposition en plusieurs niveaux d’analyse est recommandée si le diagramme devient trop complexe, pour maintenir la lisibilité et la compréhension.

💡 À retenir

Le diagramme de cas d’utilisation est un outil clé pour formaliser l’expression du besoin en illustrant, de manière simple et structurée, les interactions entre acteurs et le système, tout en permettant une modularité grâce aux relations « include » et « extend ».

📖 2. Classes d'analyse

🔑 Notions clés & Définitions

• Classes d’analyse : Représentations abstraites des concepts ou entités du domaine métier, utilisées pour modéliser la structure du système sans entrer dans les détails de la conception (voir diagramme de classe d’analyse).
• Diagramme de classe d’analyse : Outil graphique permettant de représenter les classes d’analyse, leurs attributs, comportements et relations, afin de formaliser la compréhension du domaine (voir UML).
• Attributs et comportements des objets : Les attributs sont les propriétés d’un objet qui décrivent son état, tandis que les comportements (ou méthodes) sont les opérations que l’objet peut réaliser ou répondre.
• Hiérarchie des classes : Organisation structurée des classes selon un ordre d’abstraction, permettant de gérer la complexité en regroupant des classes similaires ou en spécialisant des classes plus générales.
• Spécialisation vs Généralisation : Approches pour construire une hiérarchie de classes ; la spécialisation consiste à créer des sous-classes plus spécifiques à partir d’une classe générale, tandis que la généralisation consiste à factoriser les éléments communs dans une super-classe (voir « Spécialisation vs Généralisation »).

📝 Points essentiels

• Les classes d’analyse sont des modèles conceptuels qui reflètent la réalité métier, facilitant la compréhension et la communication entre analystes et parties prenantes.
• Le diagramme de classe d’analyse sert à représenter graphiquement ces classes, leurs attributs, comportements et relations, en utilisant la notation UML adaptée à la phase d’analyse.
• Les attributs décrivent l’état d’un objet, tandis que les comportements (méthodes) décrivent ses actions ou réactions face à des événements.
• La hiérarchie des classes permet d’organiser ces classes en arborescences, simplifiant la gestion de la complexité et favorisant la réutilisation.
• La spécialisation (du haut vers le bas) permet de capturer des particularités spécifiques, alors que la généralisation (du bas vers le haut) permet de factoriser des éléments communs dans une super-classe.
• La hiérarchie peut inclure des relations d’héritage simple ou multiple, selon la complexité du domaine modélisé.

💡 À retenir

Les classes d’analyse, représentées dans un diagramme de classe d’analyse, permettent de modéliser la structure conceptuelle du domaine métier en organisant les objets selon une hiérarchie, en distinguant spécialisation et généralisation pour mieux gérer la complexité et favoriser la réutilisation.

📖 3. Pattern de conception

🔑 Notions clés & Définitions

• Pattern de conception : Une solution réutilisable à un problème courant rencontré lors de la conception de logiciels orientés objet, permettant d’améliorer la modularité et la maintenabilité (analyse et conception orientés objet).
• Réutilisabilité : La capacité d’un pattern à être appliqué dans différents contextes pour résoudre des problèmes similaires, favorisant la réduction des coûts et la cohérence dans le développement logiciel.
• Encapsulation comme pattern : La pratique de cacher les détails internes d’un objet (attributs, méthodes) pour ne révéler qu’une interface publique, assurant ainsi la protection des données et la modularité (voir également "Pattern" dans cette section).
• Modularité appliquée aux patterns : La décomposition d’un système en modules indépendants, chaque pattern pouvant être considéré comme un module cohérent, facilitant la compréhension, la maintenance et la réutilisation (Grady Booch).
• Abstraction dans les patterns : La capacité à représenter des concepts génériques et simplifiés, en éliminant les détails non essentiels, pour concevoir des solutions plus flexibles et adaptables aux différents contextes (voir aussi "Abstraction" dans cette section).

📝 Points essentiels

• La conception orientée objet privilégie l’utilisation de patterns pour favoriser la réutilisation et la modularité, en s’appuyant sur des solutions éprouvées.
• La réutilisabilité des patterns permet d’appliquer une même solution dans plusieurs projets ou modules, réduisant ainsi la duplication et améliorant la cohérence.
• L’encapsulation, en tant que pattern, est une technique clé pour protéger l’intégrité des données et limiter l’impact des changements, en masquant les détails d’implémentation derrière une interface publique.
• La modularité appliquée aux patterns consiste à découper un système complexe en composants indépendants, chaque pattern pouvant être intégré comme un module autonome.
• L’abstraction dans les patterns permet de concevoir des solutions génériques, indépendantes des détails spécifiques, facilitant leur adaptation et leur évolution dans différents contextes.

💡 À retenir

Les patterns de conception sont des solutions réutilisables qui favorisent la modularité, l’encapsulation et l’abstraction, permettant de concevoir des systèmes plus flexibles, maintenables et adaptables.

📖 4. Architecture en couches

🔑 Notions clés & Définitions

• Architecture en couches : Modèle structurant un système logiciel en plusieurs couches hiérarchisées, où chaque couche a une responsabilité spécifique et communique uniquement avec la couche adjacente. Elle favorise la séparation des préoccupations et la modularité (analyse Robin, 2026).
• Répartition dans des packages : Organisation logique du code source en regroupements cohérents de classes ou modules, facilitant la gestion, la maintenance et la réutilisation du logiciel. Elle permet de structurer le système en unités logiques distinctes (analyse Robin, 2026).
• Namespace : Espace de noms permettant d’isoler et de différencier des identificateurs (classes, fonctions, variables) dans un même projet ou entre plusieurs modules, évitant ainsi les conflits de noms. Il facilite la gestion de la portée et la modularité du code (analyse Robin, 2026).
• Déploiement en couches : Processus de distribution physique ou logique des différentes couches du système sur des serveurs ou environnements distincts, permettant d’optimiser la performance, la sécurité et la scalabilité. La séparation physique ou virtuelle des couches est essentielle pour l’architecture distribuée (analyse Robin, 2026).
• Communication inter-couches : Mécanismes par lesquels les différentes couches échangent des données ou des commandes, généralement via des interfaces ou des protocoles définis, pour assurer la cohérence et la cohésion du système. Elle doit respecter le principe de dépendance unidirectionnelle pour préserver l’indépendance des couches (analyse Robin, 2026).

📝 Points essentiels

• L’architecture en couches repose sur une hiérarchie claire où chaque couche ne doit interagir qu’avec ses couches adjacentes, ce qui facilite la maintenance et l’évolution du système (Robin, 2026).
• La répartition dans des packages, associée à l’utilisation de namespace, permet de structurer efficacement le code source, en isolant les responsabilités et en évitant les conflits de noms (Robin, 2026).
• Le déploiement en couches peut être physique (sur différents serveurs) ou logique (dans des conteneurs ou modules séparés), ce qui améliore la scalabilité et la sécurité du système (Robin, 2026).
• La communication inter-couches doit respecter un protocole ou une interface précise, souvent via des API ou des messages, pour garantir la cohérence et la robustesse du système (Robin, 2026).
• La séparation en couches permet également de faciliter la réutilisation des composants et l’intégration de nouvelles fonctionnalités sans impacter l’ensemble du système (Robin, 2026).

💡 À retenir

L’architecture en couches organise un système logiciel en niveaux hiérarchiques distincts, où la répartition dans des packages, l’usage de namespace, le déploiement en couches et la communication inter-couches assurent modularité, maintenabilité et scalabilité.

📖 5. Domaine Driven Design

🔑 Notions clés & Définitions

• Domaine Driven Design : Approche de conception logicielle centrée sur la modélisation précise du domaine métier, favorisant une collaboration étroite entre développeurs et experts métier pour créer un modèle cohérent et évolutif.

• Modélisation du domaine : Processus de représentation abstraite des concepts, règles et processus du métier, permettant de créer un langage commun et une compréhension partagée entre tous les acteurs du projet.

• Contextes bornés : Concept selon lequel le modèle du domaine est divisé en sous-domaines autonomes, chacun ayant ses propres règles et langage, afin de limiter la complexité et favoriser une meilleure gestion des différentes parties du système.

• Ubiquitous Language : Langage omniprésent partagé par tous les acteurs du projet (développeurs, experts métier, etc.), utilisé dans la modélisation, la documentation et la communication pour assurer une compréhension claire et cohérente du domaine.

• Entités : Objets du modèle de domaine ayant une identité propre et persistante, indépendamment de leur état ou de leurs attributs, permettant de suivre leur évolution dans le système.

• Agrégats : Modèle de regroupement d’entités et d’objets de valeur (value objects) autour d’une racine d’agrégat, garantissant la cohérence et l’intégrité des opérations effectuées sur l’ensemble, tout en limitant la portée des modifications.

📝 Points essentiels

• Domaine Driven Design insiste sur la nécessité de modéliser le métier avec précision pour aligner le logiciel sur les besoins réels, en utilisant un Ubiquitous Language partagé pour éviter les malentendus.

• La modélisation du domaine doit être itérative, évolutive et collaborative, permettant d’affiner le modèle en fonction des retours des experts métier et des contraintes techniques.

• La division en contextes bornés permet de gérer la complexité en isolant des sous-domaines, chacun pouvant évoluer indépendamment tout en conservant une cohérence globale.

• Les entités sont identifiées par leur identité unique et leur cycle de vie, indépendamment de leur état actuel, ce qui facilite la gestion des modifications et des évolutions.

• Les agrégats servent à définir des limites transactionnelles et à garantir la cohérence des opérations en regroupant des objets liés, tout en évitant la propagation des changements à l’ensemble du modèle.

• La pratique du Ubiquitous Language doit être appliquée dans toutes les phases du développement, de la modélisation à la documentation, pour renforcer la compréhension commune.

💡 À retenir

Le Domaine Driven Design privilégie une modélisation précise et collaborative du métier, structurée en contextes bornés, pour créer un logiciel cohérent, évolutif et aligné sur les besoins réels, en utilisant un langage partagé et des agrégats pour maîtriser la complexité.

📖 6. Modèle UML

🔑 Notions clés & Définitions

• UML (Unified Modeling Language) : Langage graphique standardisé permettant de modéliser, visualiser, spécifier et documenter des systèmes logiciels orientés objet, issu de la fusion de plusieurs langages (OMT, SADT, HOOD) pour offrir une notation unique et cohérente (Généralités).
• UML 2.0 : Version améliorée d’UML qui introduit de nouveaux diagrammes et permet de préciser davantage d’informations sur ceux existants, facilitant la transition du modèle au code et renforçant l’industrialisation de l’ingénierie logicielle (UML 2.0).
• Les 4+1 vues : Approche permettant d’observer un système sous cinq angles complémentaires (logique, des composants, des processus, physique, et besoins utilisateurs), chaque vue étant modélisée par un ou plusieurs diagrammes UML spécifiques (Les 4+1 vues).
• Diagrammes UML : Représentations graphiques pour modéliser différents aspects d’un système, notamment :
  • Diagramme de classe : décrit la structure statique (classes, attributs, méthodes, relations).
  • Diagramme d’objet : illustre des instances concrètes de classes à un instant donné.
  • Diagramme de composants : montre l’architecture physique des composants logiciels.
  • Diagramme de séquence : modélise la communication et l’ordre des interactions entre objets dans le temps (Diagrammes UML).
• Modélisation et documentation : Processus de création de modèles graphiques pour représenter la structure, le comportement et l’architecture d’un système, facilitant la communication, la compréhension et la traçabilité des décisions techniques (Modélisation et documentation).

📝 Points essentiels

• UML est un langage graphique basé sur un méta-modèle unique, permettant une description précise et sans ambiguïté des systèmes logiciels orientés objet, tout en étant adaptable à d’autres domaines comme la modélisation de processus métier.
• La version UML 2.0 a été conçue pour renforcer la précision des diagrammes, en intégrant notamment des éléments permettant de rapprocher la modélisation du code, ce qui facilite l’industrialisation et l’automatisation des phases de développement.
• La méthode d’approche recommandée pour l’utilisation d’UML dans l’analyse et la conception est itérative et incrémentale, afin de réduire les risques, améliorer la maîtrise du projet et répondre efficacement aux besoins des utilisateurs (UML 2.0, Les 4+1 vues).
• Les diagrammes UML sont organisés selon les cinq vues : logique (qu’est-ce que le système fait ?), composants (comment le système est assemblé ?), processus (comment le système fonctionne ?), physique (comment le système est installé ?), et besoins utilisateurs, permettant une modélisation complète et cohérente.
• La relation entre acteurs et cas d’utilisation est essentielle pour représenter les interactions avec le système, en utilisant des relations de généralisation, d’inclusion (« include ») et d’extension (« extend ») pour décrire la dynamique des scénarios (Diagramme de cas d’utilisation).

💡 À retenir

UML 2.0 constitue un langage graphique complet et flexible, structurant la modélisation du système sous plusieurs vues complémentaires, afin de faciliter la communication, la conception et la transition vers le code dans une démarche itérative et incrémentale.

📖 7. Persistance des données

🔑 Notions clés & Définitions

• Objet persistant : Un objet dont l’état est sauvegardé dans un système de stockage permanent, permettant sa reconstruction et sa continuité après la cessation de l’application ou la déconnexion. (source : Analyse et Conception Orientés Objet Robin)

• Stockage permanent : Méthode ou système permettant de conserver durablement des données ou des objets, indépendamment de la durée de vie du programme ou de la session en cours, assurant la transcendance dans le temps et l’espace. (source : Analyse et Conception Orientés Objet Robin)

• Sauvegarde d’état : Opération consistant à enregistrer l’état actuel d’un objet ou d’un système dans un stockage durable, afin de pouvoir le restaurer ultérieurement dans le même état ou dans un état proche, facilitant la persistance. (source : Analyse et Conception Orientés Objet Robin)

• Transcendance dans le temps et l’espace : Capacité d’un objet ou d’un système à maintenir son existence et ses données au-delà de la durée de vie d’un processus ou d’un environnement spécifique, en étant accessible à travers différents espaces de stockage ou de temps. (source : Analyse et Conception Orientés Objet Robin)

📝 Points essentiels

• La persistance permet à un objet de continuer d’exister après la fin du processus qui l’a créé, en sauvegardant son état dans un stockage permanent, ce qui assure la transcendance dans le temps et l’espace. La sauvegarde d’état est l’opération clé pour réaliser cette persistance. (source : Analyse et Conception Orientés Objet Robin)

• Un objet persistant est généralement associé à un stockage permanent, tel qu’une base de données ou un fichier, permettant sa reconstruction ultérieure. La persistance est essentielle dans la conception de systèmes nécessitant une continuité des données, comme les systèmes d’information ou les applications métier. (source : Analyse et Conception Orientés Objet Robin)

• La transcendance dans le temps et l’espace garantit que l’objet persistant peut être retrouvé et réutilisé indépendamment du contexte initial de sa création, assurant ainsi une continuité et une cohérence des données dans le système global. (source : Analyse et Conception Orientés Objet Robin)

💡 À retenir

La persistance des données, via la sauvegarde d’état d’un objet persistant, permet à celui-ci de transcender le temps et l’espace, assurant sa continuité et sa disponibilité durable dans le système.

📖 8. Frameworks et patterns

🔑 Notions clés & Définitions

• Frameworks : Structures préétablies composées d’outils, de composants et de règles qui facilitent le développement d’applications en fournissant une architecture réutilisable et cohérente. Robin (2026) souligne qu’un framework guide la conception en imposant une organisation spécifique du code et des interactions.

• Patterns : Solutions réutilisables à des problèmes courants de conception logicielle, décrites sous forme de modèles ou de bonnes pratiques. Robin (2026) précise que les patterns améliorent la modularité et la maintenabilité en proposant des structures éprouvées.

• Utilisation de frameworks : Processus d’intégration et d’application d’un framework dans un projet, impliquant la configuration, l’adaptation et l’extension pour répondre aux besoins spécifiques. Robin (2026) insiste sur la nécessité d’une compréhension approfondie pour exploiter pleinement leurs avantages.

• Intégration de patterns dans frameworks : Approche consistant à insérer des patterns dans la structure d’un framework pour renforcer la réutilisabilité et la flexibilité. Selon Robin (2026), cette démarche permet de combiner la robustesse des frameworks avec la souplesse des patterns.

• Collaboration et maintenabilité : Aspects liés à la facilité avec laquelle une équipe peut travailler sur un projet et assurer sa pérennité. Robin (2026) indique que l’utilisation cohérente de frameworks et patterns favorise une meilleure collaboration et simplifie la maintenance.

• Outils de modélisation (DrawIO, LucidChart) : Logiciels permettant de créer, visualiser et documenter des modèles UML ou autres diagrammes, facilitant la communication et la conception. Robin (2026) recommande leur utilisation pour améliorer la clarté et la collaboration dans la modélisation.

📝 Points essentiels

• Les frameworks offrent une architecture structurée qui accélère le développement et assure la cohérence du code, tout en favorisant la réutilisation. Leur utilisation nécessite une compréhension approfondie pour éviter des adaptations inadéquates.

• Les patterns, tels que le singleton, le factory ou le observer, sont des modèles éprouvés permettant de résoudre efficacement des problèmes récurrents, en améliorant la modularité et la maintenabilité.

• L’intégration de patterns dans des frameworks permet de tirer parti de leurs avantages combinés, en adaptant la structure du framework pour répondre à des besoins spécifiques tout en conservant une architecture solide.

• La collaboration dans un projet logiciel est facilitée par l’utilisation cohérente de frameworks et patterns, qui standardisent la conception et simplifient la compréhension mutuelle.

• Les outils de modélisation comme DrawIO ou LucidChart jouent un rôle clé dans la conception, la communication et la documentation des architectures, en permettant de représenter graphiquement les structures et interactions.

💡 À retenir

Les frameworks et patterns sont des leviers essentiels pour concevoir des systèmes modulaires, réutilisables et maintenables, en favorisant la collaboration et en simplifiant la modélisation grâce à des outils adaptés. Leur maîtrise permet d’optimiser le développement logiciel dans une démarche structurée.

📖 9. Gestion des dépendances

🔑 Notions clés & Définitions

• Gestion des dépendances : Ensemble de pratiques visant à contrôler et organiser les relations entre différents composants logiciels pour assurer leur cohérence, leur maintenabilité et leur évolutivité. Elle permet de définir comment un module ou une classe dépend d’un autre, facilitant la gestion des changements et la modularité.

• Gestion des packages : Processus d’organisation, de distribution et de versionnage des composants logiciels regroupés en unités appelées packages. Elle facilite la modularité, la réutilisation et la maintenance du code en structurant l’application en ensembles cohérents.

• Namespace : Espace de noms permettant d’isoler et d’organiser les identificateurs (classes, fonctions, variables) pour éviter les conflits de nom. Selon la source, le namespace facilite la gestion des dépendances en séparant les contextes et en contrôlant la visibilité des éléments.

• Gestion des droits : Mécanisme de contrôle d’accès qui définit qui peut utiliser, modifier ou visualiser certains composants ou ressources. Elle est essentielle pour sécuriser les dépendances en limitant leur utilisation aux acteurs ou modules autorisés.

• Conduite du changement : Approche structurée pour accompagner la modification des composants ou des dépendances dans un système, en minimisant les risques et en assurant la cohérence lors de l’évolution du logiciel. Elle implique la gestion des dépendances pour garantir la compatibilité et la stabilité.

📝 Points essentiels

• La gestion des dépendances est cruciale pour maintenir la cohérence entre modules, notamment lors de mises à jour ou de refactorings, en évitant les effets de bord et en facilitant la modularité (voir Gestion des packages et Namespace).
• La gestion des packages permet de structurer le code en regroupant les composants liés, ce qui facilite leur réutilisation et leur distribution, tout en simplifiant la gestion des dépendances.
• Les namespaces jouent un rôle clé dans la prévention des conflits de noms, en isolant les identificateurs dans des contextes distincts, ce qui est particulièrement utile dans de grands projets ou lors de l’intégration de bibliothèques tierces.
• La gestion des droits garantit que seules les entités autorisées peuvent accéder ou modifier certains composants, renforçant la sécurité et la stabilité du système.
• La conduite du changement doit prendre en compte les dépendances pour éviter de briser la compatibilité ou d’introduire des erreurs lors de modifications ou de déploiements.

💡 À retenir

La gestion efficace des dépendances, via les packages, namespaces et droits, est essentielle pour assurer la modularité, la sécurité et la facilité de maintenance d’un système logiciel, tout en facilitant la conduite du changement dans un environnement évolutif.

📖 10. Refactoring continu

🔑 Notions clés & Définitions

• Refactoring continu : Processus d'amélioration progressive et régulière du code ou de la conception d’un logiciel, visant à optimiser sa structure sans changer son comportement externe, afin d’assurer la qualité et la maintenabilité du système.
• Test-Assess-Learn-Repeat : Approche itérative où chaque cycle consiste à tester une version, évaluer ses résultats, apprendre des erreurs ou des réussites, puis répéter le processus pour améliorer continuellement le produit.
• Amélioration continue : Philosophie ou démarche d’optimisation constante des processus, produits ou services, en intégrant régulièrement des ajustements pour répondre aux besoins évolutifs et augmenter la performance.
• Safe learning environment : Environnement d’apprentissage sécurisé où les erreurs sont perçues comme des opportunités d’apprentissage, favorisant l’expérimentation, la collaboration et la prise de risques contrôlés.
• Débat collectif : Pratique de discussion ouverte et structurée entre membres d’une équipe pour partager des idées, analyser des problèmes et co-construire des solutions, essentielle dans l’amélioration continue et le refactoring.

📝 Points essentiels

Le refactoring continu s’inscrit dans une démarche d’amélioration continue en favorisant une évolution régulière du code pour maintenir sa qualité. Il repose sur des cycles itératifs où chaque étape de Test-Assess-Learn-Repeat permet d’évaluer l’impact des modifications, d’apprendre des erreurs et d’adapter la conception. La pratique s’inscrit dans un safe learning environment, garantissant un cadre propice à l’expérimentation sans crainte de sanctions, encourageant ainsi la collaboration et le débat collectif pour partager les bonnes pratiques et identifier les axes d’amélioration. Cette approche favorise la réactivité face aux changements, la réduction des dettes techniques et la pérennité du logiciel.

💡 À retenir

Le refactoring continu, soutenu par une culture d’amélioration permanente et un environnement d’apprentissage sécurisé, permet d’assurer la qualité, la maintenabilité et l’adaptabilité des systèmes logiciels dans une démarche itérative et collaborative.

📊 Tableaux de Synthèse

⚠️ Pièges & Confusions Fréquentes

1. Confondre « include » et « extend » dans le diagramme de cas d’utilisation, où « include » favorise la réutilisation stricte et « extend » l’ajout conditionnel.
2. Oublier que les acteurs dans un diagramme de cas d’utilisation représentent des rôles, pas forcément des personnes physiques.
3. Confondre spécialisation et généralisation dans les classes d’analyse, en inversant leur sens ou leur application.
4. Négliger la hiérarchie dans les classes d’analyse, ce qui peut conduire à une modélisation plate et peu flexible.
5. Sur-utiliser les patterns sans analyser leur pertinence dans le contexte, menant à une complexité inutile.
6. Confondre encapsulation et abstraction, en pensant que l’un remplace l’autre.
7. Mal distinguer les couches dans une architecture en couches, notamment entre la couche métier et la couche présentation.

✅ Checklist Examen

1. Connaître la définition précise du diagramme de cas d’utilisation selon UML et ses objectifs (Auteurs : Ivar Jacobson).
2. Savoir différencier une relation « include » d’une relation « extend » dans le contexte des cas d’utilisation.
3. Identifier les rôles d’un acteur dans un diagramme de cas d’utilisation, en insistant sur leur nature de rôle, non de personne.
4. Maîtriser la différence entre classes d’analyse et classes de conception, en insistant sur leur niveau d’abstraction.
5. Savoir représenter un diagramme de classe d’analyse, avec ses attributs, comportements et relations principales.
6. Comprendre le concept de hiérarchie dans les classes d’analyse, notamment la spécialisation et la généralisation (Auteur : Barbara Liskov).
7. Identifier et appliquer les patterns de conception courants : Singleton, Factory, Observer, en précisant leur rôle et leur contexte d’usage.
8. Connaître la notion d’encapsulation et ses bénéfices pour la modularité et la sécurité des données (Auteur : Grady Booch).
9. Expliquer le principe de l’architecture en couches, en précisant les responsabilités de chaque couche et leur communication.
10. Savoir comment structurer un système en architecture en couches pour favoriser la séparation des préoccupations.
11. Identifier les pièges courants dans la modélisation UML et la conception orientée objet, notamment la confusion entre relations et concepts.
12. Vérifier la maîtrise du vocabulaire spécifique : acteur, relation « include », « extend », classe d’analyse, pattern, encapsulation, architecture en couches.