L’OOAD est une méthode d’analyse et de conception qui exploite les principes de décomposition et les notations orientées objet pour représenter les modèles logiques, physiques, à états et dynamiques d’un système. Dans le cadre du cycle de vie du développement logiciel , l’OOAD concerne deux étapes initiales : l’analyse des exigences et la conception.


Bien que la conception orientée objet (COO) puisse être employée dans une méthodologie en cascade, où les étapes du cycle de vie sont séquentielles et clairement délimitées, la COO privilégie souvent des approches itératives. Ces méthodologies ont été conçues pour apporter de la flexibilité au processus de développement. Au lieu de travailler sur chaque étape du cycle de vie individuellement, une approche itérative permet de progresser simultanément sur l'analyse, la conception et le codage. Contrairement à la méthodologie en cascade qui considère toute modification à une étape antérieure du cycle de vie comme un échec, une approche itérative admet que de tels changements sont normaux dans un processus à forte intensité de connaissancesprincipe d'ouverture modèle objet . Un cas d'utilisation décrit un scénario pour les fonctions standard du domaine que le système doit accomplir. Un modèle objet décrit les noms, les relations entre les classes, les opérations et les propriétés des principaux objets. Des maquettes ou des prototypes d'interface utilisateur peuvent également être créés pour faciliter la compréhension.
Contrairement à l'analyse orientée objet (OOA) qui organise les exigences autour d'objets intégrant processus et données, d'autres méthodes d'analyse considèrent les processus et les données séparément. Par exemple, les données peuvent être modélisées par des diagrammes entité-relation et les comportements par des organigrammes ou des diagrammes de structure .
Artefacts
Les résultats de l'OOA servent d'entrées à l'OOD. Dans une approche itérative, un artefact de sortie n'a pas besoin d'être entièrement développé pour servir d'entrée à l'OOD. L'OOA et l'OOD peuvent être réalisées de manière incrémentale, et les artefacts peuvent être enrichis continuellement au lieu d'être entièrement développés en une seule fois. Les artefacts d'OOA comprennent :
- Modèle conceptuel
- Un modèle conceptuel capture les concepts du domaine du problème . Ce modèle est explicitement choisi pour être indépendant des détails d'implémentation, tels que la concurrence ou le stockage des données.
- Cas d'utilisation
- Un cas d'utilisation décrit une séquence d'événements qui permettent à un système d'accomplir une tâche utile. Chaque cas d'utilisation propose un ou plusieurs scénarios illustrant comment le système doit interagir avec les utilisateurs (appelés acteurs) pour atteindre un objectif métier ou réaliser une fonction spécifique. Les acteurs d'un cas d'utilisation peuvent être des utilisateurs finaux ou d'autres systèmes. Dans de nombreux cas, les cas d'utilisation sont détaillés dans des diagrammes de cas d'utilisation . Ces diagrammes permettent d'identifier les acteurs (utilisateurs ou autres systèmes) et les processus qu'ils exécutent.
- Diagramme de séquence du système
- Un diagramme de séquence système (SSD) est une image qui montre, pour un scénario particulier d'un cas d'utilisation, les événements générés par les acteurs externes, leur ordre et les événements inter-systèmes possibles.
- Documentation de l'interface utilisateur
- Documentation facultative illustrant et décrivant l' apparence et le fonctionnement de l' interface utilisateur .
- Modèle de données relationnel
- Si aucune base de données orientée objet n'est utilisée, il est généralement conseillé de créer un modèle de données relationnel avant la conception, car la stratégie choisie pour le mappage objet-relationnel découle du processus de conception orientée objet. Il est toutefois possible de développer le modèle de données relationnel et les artefacts de conception orientée objet en parallèle, et l'enrichissement d'un artefact peut stimuler l'amélioration des autres.
Conception orientée objet
La conception orientée objet (COO), une forme de conception logicielle , est le processus de planification d'un système d'objets interagissant pour résoudre un problème logiciel. Un concepteur applique des contraintes d'implémentation au modèle conceptuel produit par l'analyse orientée objet (AOO). Ces contraintes peuvent inclure les plateformes matérielles et logicielles , les exigences de performance, le stockage persistant et les transactions, l'ergonomie du système, ainsi que les limitations budgétaires et temporelles. Les concepts du modèle d'analyse, indépendant de toute technologie, sont transposés en classes et interfaces d'implémentation, ce qui aboutit à un modèle du domaine de solution, c'est-à-dire une description détaillée de la manière dont le système doit être construit sur des technologies concrètes.
Les activités OOD comprennent :
- Définition des objets et de leurs attributs
- Création de diagrammes de classes à partir de modèles conceptuels
- Utilisation de modèles de conception
- Définition des cadres d'application
- Identification des objets/données persistants
- Conception du mappage objet-relationnel si une base de données relationnelle est utilisée
- Identification des objets distants
Les principes et stratégies de la POO comprennent :
- Injection de dépendance
- L'injection de dépendances signifie que si un objet dépend de la présence d'une instance d'un autre objet, alors l'objet nécessaire est « injecté » dans l'objet dépendant (par exemple, en passant une connexion à une base de données comme argument au constructeur au lieu d'en créer une en interne).
- Principe des dépendances acycliques
- Le principe des dépendances acycliques stipule que le graphe de dépendances des paquets ou des composants (la granularité dépendant du périmètre de travail du développeur) ne doit comporter aucun cycle. On parle alors de graphe acyclique orienté . Par exemple, le paquet C dépend du paquet B, qui dépend lui-même du paquet A. Si le paquet A dépendait du paquet C, il y aurait un cycle.
- Principe de réutilisation des composites
- Le principe de réutilisation composite consiste à privilégier la composition polymorphe d'objets par rapport à l'héritage.
Artefacts
- Diagramme de séquence
- Étendez le diagramme de séquence pour y ajouter les objets spécifiques qui gèrent les événements du système. Un diagramme de séquence représente, par des lignes verticales parallèles, différents processus ou objets fonctionnant simultanément, et, par des flèches horizontales, les messages échangés entre eux, dans l'ordre chronologique.
- Diagramme de classes
- Un diagramme de classes est un type de diagramme UML statique qui décrit la structure d'un système en présentant ses classes, leurs attributs et les relations entre ces classes. Les messages et les classes identifiés lors de l'élaboration des diagrammes de séquence peuvent servir d'entrée à la génération automatique du diagramme de classes global du système.