Analyse et conception orientées objet - Object-oriented analysis and design

Développement de logiciels
Activités principales
Paradigmes et modèles
Méthodologies et cadres
Disciplines de soutien
Les pratiques
Outils
Normes et corpus de connaissances
Glossaires
Grandes lignes

L'analyse et la conception orientées objet ( OOAD ) est une approche technique permettant d'analyser et de concevoir une application, un système ou une entreprise en appliquant une programmation orientée objet , ainsi qu'en utilisant la modélisation visuelle tout au long du processus de développement logiciel pour guider la communication avec les parties prenantes et la qualité du produit.

OOAD en génie logiciel moderne est généralement mené de manière itérative et incrémentale. Les résultats des activités OOAD sont respectivement des modèles d'analyse (pour OOA) et des modèles de conception (pour OOD). L'intention est que ceux-ci soient continuellement affinés et évolués, motivés par des facteurs clés tels que les risques et la valeur commerciale.

L'histoire

Au début de la technologie orientée objet avant le milieu des années 1990, il existait de nombreuses méthodologies concurrentes pour le développement de logiciels et la modélisation orientée objet , souvent liées à des fournisseurs d'outils spécifiques de génie logiciel assisté par ordinateur (CASE). Aucune notation standard, des termes cohérents et des guides de processus étaient les principales préoccupations à l'époque, ce qui a dégradé l' efficacité de la communication et allongé les courbes d'apprentissage.

Certaines des premières méthodologies orientées objet bien connues étaient inspirées de gourous tels que Grady Booch , James Rumbaugh , Ivar Jacobson (les Trois Amigos ), Robert Martin , Peter Coad , Sally Shlaer , Stephen Mellor et Rebecca Wirfs-Brock. .

En 1994, les trois Amigos de Rational Software ont commencé à travailler ensemble pour développer le langage de modélisation unifié (UML). Plus tard, avec Philippe Kruchten et Walker Royce (fils aîné de Winston Royce ), ils ont mené une mission réussie consistant à fusionner leurs propres méthodologies, OMT , OOSE et la méthode Booch , avec diverses idées et expériences d'autres leaders de l'industrie dans le processus unifié rationnel. (RUP), un guide et un cadre de processus itératifs et incrémentiels complets pour l'apprentissage des meilleures pratiques de l'industrie en matière de développement de logiciels et de gestion de projet. Depuis lors, la famille Unified Process est probablement devenue la méthodologie et le modèle de référence les plus populaires pour l'analyse et la conception orientées objet.

Aperçu

Le cycle de vie du logiciel est généralement divisé en étapes allant des descriptions abstraites du problème aux conceptions, puis au code et aux tests et enfin au déploiement. Les premières étapes de ce processus sont l'analyse et la conception. La phase d'analyse est aussi souvent appelée «acquisition des besoins».

Le modèle de la cascade .
OOAD est conduit de manière itérative et incrémentale, comme formulé par le processus unifié .

Dans certaines approches de développement de logiciels - connues collectivement sous le nom de modèles en cascade - les frontières entre chaque étape sont censées être assez rigides et séquentielles. Le terme «cascade» a été inventé pour de telles méthodologies pour signifier que les progrès allaient séquentiellement dans une seule direction, c'est-à-dire qu'une fois l'analyse terminée à ce moment-là, la conception commençait alors seulement et c'était rare (et considéré comme une source d'erreur) lorsqu'un problème de conception exigeait une modification du modèle d'analyse ou lorsqu'un problème de codage exigeait une modification de la conception.

Les modèles itératifs sont l'alternative aux modèles en cascade. Cette distinction a été popularisée par Barry Boehm dans un article très influent sur son modèle en spirale pour le développement de logiciels itératifs. Avec les modèles itératifs, il est possible de travailler en parallèle à différentes étapes du modèle. Ainsi, par exemple, il est possible - et non considéré comme une source d'erreur - de travailler sur l'analyse, la conception et même le codage le même jour et d'avoir des problèmes d'une étape qui impactent les problèmes d'une autre. L'accent mis sur les modèles itératifs est que le développement de logiciels est un processus à forte intensité de connaissances et que des choses comme l'analyse ne peuvent pas vraiment être complètement comprises sans comprendre les problèmes de conception, que les problèmes de codage peuvent affecter la conception, que les tests peuvent fournir des informations sur la façon dont le code ou même la conception doit être modifiée, etc.

Bien qu'il soit possible de faire du développement orienté objet à l'aide d'un modèle en cascade, en pratique la plupart des systèmes orientés objet sont développés avec une approche itérative. En conséquence, dans les processus orientés objet, «l'analyse et la conception» sont souvent considérées en même temps.

Le paradigme orienté objet met l'accent sur la modularité et la réutilisation. Le but d'une approche orientée objet est de satisfaire le "principe ouvert-fermé" . Un module est ouvert s'il prend en charge l'extension, ou si le module fournit des moyens standardisés pour ajouter de nouveaux comportements ou décrire de nouveaux états. Dans le paradigme orienté objet, cela est souvent accompli en créant une nouvelle sous-classe d'une classe existante. Un module est fermé s'il a une interface stable bien définie que tous les autres modules doivent utiliser et qui limite l'interaction et les erreurs potentielles qui peuvent être introduites dans un module par des changements dans un autre. Dans le paradigme orienté objet, cela est accompli en définissant des méthodes qui invoquent des services sur des objets. Les méthodes peuvent être publiques ou privées, c'est-à-dire que certains comportements propres à l'objet ne sont pas exposés à d'autres objets. Cela réduit une source de nombreuses erreurs courantes dans la programmation informatique.

Le cycle de vie du logiciel est généralement divisé en étapes allant des descriptions abstraites du problème aux conceptions, puis au code et aux tests et enfin au déploiement. Les premières étapes de ce processus sont l'analyse et la conception. La distinction entre analyse et conception est souvent décrite comme «quoi par rapport à comment». Dans l'analyse, les développeurs travaillent avec les utilisateurs et les experts du domaine pour définir ce que le système est censé faire. Les détails de mise en œuvre sont censés être en grande partie ou totalement ignorés (selon la méthode particulière) à cette phase. Le but de la phase d'analyse est de créer un modèle fonctionnel du système indépendamment des contraintes telles que la technologie appropriée. Dans l'analyse orientée objet, cela se fait généralement via des cas d'utilisation et des définitions abstraites des objets les plus importants. La phase de conception ultérieure affine le modèle d'analyse et fait la technologie nécessaire et d'autres choix d'implémentation. Dans la conception orientée objet, l'accent est mis sur la description des différents objets, leurs données, leur comportement et leurs interactions. Le modèle de conception doit avoir tous les détails nécessaires pour que les programmeurs puissent implémenter la conception dans le code.

Analyse orientée objet

Le but de toute activité d'analyse dans le cycle de vie du logiciel est de créer un modèle des exigences fonctionnelles du système indépendant des contraintes d'implémentation.

La principale différence entre l'analyse orientée objet et les autres formes d'analyse est que, par l'approche orientée objet, nous organisons les exigences autour d'objets, qui intègrent à la fois des comportements (processus) et des états (données) modélisés d'après des objets du monde réel avec lesquels le système interagit. Dans d'autres méthodologies d'analyse ou traditionnelles, les deux aspects: les processus et les données sont considérés séparément. Par exemple, les données peuvent être modélisées par des diagrammes ER et les comportements par des organigrammes ou des organigrammes .

Les modèles couramment utilisés dans OOA sont les cas d'utilisation et les modèles d'objet . Les cas d'utilisation décrivent des scénarios pour les fonctions de domaine standard que le système doit accomplir. Les modèles d'objets décrivent les noms, les relations de classe (par exemple Circle est une sous-classe de Shape), les opérations et les propriétés des objets principaux. Des maquettes ou des prototypes d'interface utilisateur peuvent également être créés pour faciliter la compréhension.

Conception orientée objet

Article principal: conception orientée objet

Pendant la conception orientée objet (OOD), un développeur applique des contraintes d'implémentation au modèle conceptuel produit dans l'analyse orientée objet. Ces contraintes pourraient inclure les plates-formes matérielles et logicielles , les exigences de performance, le stockage et les transactions persistants, la facilité d'utilisation du système et les limites imposées par les budgets et le temps. Les concepts du modèle d'analyse, qui est indépendant de la technologie, sont mappés sur des classes d'implémentation et des interfaces aboutissant à un modèle du domaine de la 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 sujets importants de l'OOD incluent également la conception d' architectures logicielles en appliquant des modèles architecturaux et des modèles de conception avec des principes de conception orientés objet.

Modélisation orientée objet

Article principal: Modélisation orientée objet

La modélisation orientée objet (MOO) est une approche courante de modélisation d'applications, de systèmes et de domaines métier en utilisant le paradigme orienté objet tout au long du cycle de vie du développement . Le MOO est une technique principale largement utilisée par les activités OOD et OOA dans l'ingénierie logicielle moderne.

La modélisation orientée objet se divise généralement en deux aspects du travail: la modélisation de comportements dynamiques tels que les processus métier et les cas d'utilisation , et la modélisation de structures statiques telles que les classes et les composants. OOA et OOD sont les deux niveaux abstraits distincts (c'est-à-dire le niveau d'analyse et le niveau de conception) pendant le MOO. Le langage de modélisation unifié (UML) et SysML sont les deux langages standard internationaux populaires utilisés pour la modélisation orientée objet.

Les avantages de MOO sont:

Communication efficace et efficace

Les utilisateurs ont généralement des difficultés à bien comprendre les documents complets et les codes de langage de programmation. Les diagrammes de modèles visuels peuvent être plus compréhensibles et peuvent permettre aux utilisateurs et aux parties prenantes de donner aux développeurs des commentaires sur les exigences et la structure appropriées du système. Un objectif clé de l'approche orientée objet est de réduire le «fossé sémantique» entre le système et le monde réel, et de faire en sorte que le système soit construit en utilisant une terminologie qui est presque la même que celle utilisée par les parties prenantes dans les affaires quotidiennes. La modélisation orientée objet est un outil essentiel pour faciliter cela.

Abstraction utile et stable

La modélisation facilite le codage. Un objectif de la plupart des méthodologies logicielles modernes est d'abord de répondre aux questions «quoi», puis de répondre aux questions «comment», c'est-à-dire de déterminer d'abord la fonctionnalité que le système doit fournir sans tenir compte des contraintes de mise en œuvre, puis de réfléchir à la manière d'apporter des solutions spécifiques à ces abstraits. exigences, et les affiner en conceptions et codes détaillés en fonction de contraintes telles que la technologie et le budget. La modélisation orientée objet permet cela en produisant des descriptions abstraites et accessibles des exigences et des conceptions du système, c'est-à-dire des modèles qui définissent leurs structures et comportements essentiels tels que les processus et les objets, qui sont des actifs de développement importants et précieux avec des niveaux d'abstraction plus élevés que le code source concret et complexe. .

Voir également

Références

Lectures complémentaires

  • Grady Booch . «Analyse et conception orientées objet avec applications, 3e édition»: http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
  • Rebecca Wirfs-Brock , Brian Wilkerson, Lauren Wiener. Conception de logiciels orientés objet . Prentice Hall, 1990. [ Une introduction terre-à-terre à la programmation et à la conception orientées objet. ]
  • Une théorie de la conception orientée objet : les éléments constitutifs de l'OOD et les notations pour les représenter (en mettant l'accent sur les modèles de conception.)
  • Martin Fowler . Modèles d'analyse: modèles d'objets réutilisables . Addison-Wesley, 1997. [ Une introduction à l'analyse orientée objet avec des modèles conceptuels ]
  • Bertrand Meyer . Construction de logiciels orientés objet . Salle Prentice, 1997
  • Craig Larman . Application d'UML et de modèles - Introduction au développement OOA / D et itératif . Prentice Hall PTR, 3e éd. 2005., mnnm, n, nnn
  • Setrag Khoshafian. Orientation de l'objet .
  • Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Modélisation basée sur l'histoire . Amazon Createspace. p. 333., 2013. ISBN   9781483949253 .

Liens externes