OOAD – Conception orientée objet

Après la phase d’analyse, le modèle conceptuel est développé davantage en un modèle orienté objet en utilisant la conception orientée objet (OOD). Dans l’OOD, les concepts indépendants de la technologie dans le modèle d’analyse sont mappés sur des classes d’implémentation, les contraintes sont identifiées, et les interfaces sont conçues, résultant en un modèle pour le domaine de solution. En bref une description détaillée est construite en précisant comment le système doit être construit sur des technologies concrètes

Les étapes de la conception orientée objet peuvent être identifiées comme –

• Définition du contexte du système
• Conception de l’architecture du système
• Identification des objets du système
• Construction des modèles de conception
• Spécification des interfaces d’objets

Conception du système

La conception d’un système orienté objet consiste à définir le contexte de la conception du système.La conception de systèmes orientés objet implique la définition du contexte d’un système suivie de la conception de l’architecture du système.

• Contexte – Le contexte d’un système comporte une partie statique et une partie dynamique. Le contexte statique du système est conçu à l’aide d’un schéma fonctionnel simple du système entier qui est étendu en une hiérarchie de sous-systèmes. Le modèle de sous-système est représenté par des packages UML. Le contexte dynamique décrit comment le système interagit avec son environnement. Il est modélisé à l’aide de diagrammes de cas d’utilisation.

• Architecture du système – L’architecture du système est conçue sur la base du contexte du système conformément aux principes de la conception architecturale ainsi qu’aux connaissances du domaine. Typiquement, un système est partitionné en couches et chaque couche est décomposée pour former les sous-systèmes.

Décomposition orientée objet

La décomposition consiste à diviser un grand système complexe en une hiérarchie de composants plus petits et moins complexes, selon les principes de diviser pour mieux conquérir. Chaque composant majeur du système est appelé un sous-système. La décomposition orientée objet identifie les objets individuels autonomes dans un système et la communication entre ces objets.

Les avantages de la décomposition sont –

• Les composants individuels sont de moindre complexité, et donc plus compréhensibles et gérables.

• Elle permet la division de la main-d’œuvre ayant des compétences spécialisées.

• Il permet de remplacer ou de modifier des sous-systèmes sans affecter les autres sous-systèmes.

Identifier la concurence

La concurence permet à plus d’un objet de recevoir des événements en même temps et à plus d’une activité d’être exécutée simultanément. La concurence est identifiée et représentée dans le modèle dynamique.

Pour activer la concurence, chaque élément concurrent se voit attribuer un thread de contrôle distinct. Si la simultanéité se situe au niveau de l’objet, deux objets concurrents se voient attribuer deux threads de contrôle différents. Si deux opérations d’un seul objet sont concurrentes par nature, alors cet objet est divisé entre différents threads.

La concurrence est associée aux problèmes d’intégrité des données, de blocage et de famine. Ainsi, une stratégie claire doit être faite chaque fois que la concurrence est nécessaire. En outre, la concurence nécessite d’être identifiée au stade de la conception même, et ne peut être laissée pour le stade de la mise en œuvre.

Identification des patrons

Lors de la conception des applications, certaines solutions communément acceptées sont adoptées pour certaines catégories de problèmes. Ce sont les patrons de conception. Un pattern peut être défini comme un ensemble documenté de blocs de construction qui peuvent être utilisés dans certains types de problèmes de développement d’applications.

Certains patrons de conception couramment utilisés sont –

• Patron de façade
• Patron de séparation modèle vue
• Patron d’observateur

.

• Model view controller pattern
• Publish subscribe pattern
• Proxy pattern

Controlling Events

Durant la conception du système, les événements qui peuvent se produire dans les objets du système doivent être identifiés et traités de manière appropriée.

Un événement est une spécification d’une occurrence significative qui a une localisation dans le temps et l’espace.

Il existe quatre types d’événements qui peuvent être modélisés, à savoir –

• Evénement de signal – Un objet nommé lancé par un objet et attrapé par un autre objet.

• Evénement d’appel – Un événement synchrone représentant l’envoi d’une opération.

• Événement temporel – Événement représentant le passage du temps.

• Événement de changement – Événement représentant le changement d’état.

Gestion des conditions limites

La phase de conception du système doit aborder l’initialisation et la terminaison du système dans son ensemble ainsi que de chaque sous-système. Les différents aspects qui sont documentés sont les suivants –

• Le démarrage du système, c’est-à-dire la transition du système de l’état non initialisé à l’état stable.

• La terminaison du système, c’est-à-dire, la fermeture de tous les threads en cours d’exécution, le nettoyage des ressources et des messages à envoyer.

• La configuration initiale du système et la reconfiguration du système lorsque cela est nécessaire.

• La prévision des défaillances ou de la fin indésirable du système.

Les conditions limites sont modélisées à l’aide de cas d’utilisation limites.

Conception des objets

Après l’élaboration de la hiérarchie des sous-systèmes, les objets du système sont identifiés et leurs détails sont conçus. Ici, le concepteur détaille la stratégie choisie lors de la conception du système. L’accent est mis sur les concepts informatiques plutôt que sur les concepts du domaine d’application. Les objets identifiés pendant l’analyse sont gravés pour l’implémentation dans le but de minimiser le temps d’exécution, la consommation de mémoire et le coût global.

La conception d’objets comprend les phases suivantes –

• Identification d’objets
• Représentation d’objets, c’est-à-dire, construction de modèles de conception
• Classification des opérations
• Conception d’algorithmes
• Conception de relations
• Mise en œuvre du contrôle des interactions externes
• Paquetage des classes et des associations en modules

Identification des objets

La première étape de la conception d’objets est l’identification des objets. Les objets identifiés dans les phases d’analyse orientée objet sont regroupés en classes et raffinés de façon à ce qu’ils conviennent à l’implémentation réelle.

Les fonctions de cette étape sont –

• Identifier et raffiner les classes dans chaque sous-système ou paquet

• Définir les liens et les associations entre les classes

• Concevoir les associations hiérarchiques entre les classes, c’est-à-dire, la généralisation/spécialisation et les héritages

• Conception des agrégations

Représentation des objets

Une fois les classes identifiées, il faut les représenter en utilisant des techniques de modélisation objet. Cette étape consiste essentiellement à construire des diagrammes UML.

Il existe deux types de modèles de conception qui doivent être produits –

• Modèles statiques – Pour décrire la structure statique d’un système en utilisant des diagrammes de classes et des diagrammes d’objets.

• Modèles dynamiques – Pour décrire la structure dynamique d’un système et montrer l’interaction entre les classes en utilisant des diagrammes d’interaction et des diagrammes state-chart.

Classification des opérations

Dans cette étape, les opérations à effectuer sur les objets sont définies en combinant les trois modèles développés dans la phase OOA, à savoir le modèle objet, le modèle dynamique et le modèle fonctionnel. Une opération spécifie ce qui doit être fait et non comment cela doit être fait.

Les tâches suivantes sont effectuées concernant les opérations –

• Le diagramme de transition d’état de chaque objet du système est développé.

• Les opérations sont définies pour les événements reçus par les objets.

• Les cas dans lesquels un événement déclenche d’autres événements dans des objets identiques ou différents sont identifiés.

• Les sous-opérations dans les actions sont identifiées.

• Les actions principales sont étendues aux diagrammes de flux de données.

Conception d’algorithme

Les opérations dans les objets sont définies à l’aide d’algorithmes. Un algorithme est une procédure par étapes qui résout le problème posé dans une opération. Les algorithmes se concentrent sur la façon dont cela doit être fait.

Il peut y avoir plus d’un algorithme correspondant à une opération donnée. Une fois que les algorithmes alternatifs sont identifiés, l’algorithme optimal est sélectionné pour le domaine de problème donné. Les métriques pour choisir l’algorithme optimal sont –

• Computational Complexity – La complexité détermine l’efficacité d’un algorithme en termes de temps de calcul et de besoins en mémoire.

• Flexibilité – La flexibilité détermine si l’algorithme choisi peut être mis en œuvre de manière appropriée, sans perte d’adéquation dans divers environnements.

• Incompréhensibilité – Elle détermine si l’algorithme choisi est facile à comprendre et à mettre en œuvre.

Conception des relations

La stratégie de mise en œuvre des relations doit être tracée à la craie pendant la phase de conception de l’objet. Les principales relations qui sont abordées comprennent les associations, les agrégations et les héritages.

Le concepteur doit faire ce qui suit concernant les associations –

• Identifier si une association est unidirectionnelle ou bidirectionnelle.

• Analyser le chemin des associations et les mettre à jour si nécessaire.

• Mettre en œuvre les associations en tant qu’objet distinct, dans le cas de relations many-to-many ; ou en tant que lien vers un autre objet dans le cas de relations one-to-one ou one-to-many.

En ce qui concerne les héritages, le concepteur devrait faire ce qui suit –

• Adapter les classes et leurs associations.

• Identifier les classes abstraites.

• Prendre des dispositions pour que les comportements soient partagés lorsque cela est nécessaire.

Mise en œuvre du contrôle

Le concepteur d’objets peut incorporer des raffinements dans la stratégie du modèle state-chart. Lors de la conception du système, une stratégie de base pour réaliser le modèle dynamique est faite. Pendant la conception d’objet, cette stratégie est embellie de manière appropriée pour une implémentation adéquate.

Les approches pour l’implémentation du modèle dynamique sont –

• Représenter l’état comme un emplacement dans un programme – C’est l’approche traditionnelle dirigée par la procédure par laquelle l’emplacement du contrôle définit l’état du programme. Une machine à états finis peut être implémentée comme un programme. Une transition forme une instruction d’entrée, le chemin de contrôle principal forme la séquence d’instructions, les branches forment les conditions, et les chemins de retour forment les boucles ou les itérations.

• Moteur d’automate à états – Cette approche représente directement un automate à états par le biais d’une classe de moteur d’automate à états. Cette classe exécute la machine à états à travers un ensemble de transitions et d’actions fournies par l’application.

• Contrôle en tant que tâches concurrentes – Dans cette approche, un objet est implémenté comme une tâche dans le langage de programmation ou le système d’exploitation. Ici, un événement est implémenté comme un appel inter-tâches. Cela préserve la concurrence inhérente des objets réels.

Packaging Classes

Dans tout grand projet, le partitionnement méticuleux d’une implémentation en modules ou en packages est important. Pendant la conception des objets, les classes et les objets sont regroupés en packages pour permettre à plusieurs groupes de travailler en coopération sur un projet.

Les différents aspects du packaging sont –

• Cacher les informations internes de la vue extérieure – Il permet à une classe d’être vue comme une « boîte noire » et permet à l’implémentation de la classe d’être changée sans exiger que les clients de la classe modifient le code.

• Cohérence des éléments – Un élément, tel qu’une classe, une opération ou un module, est cohérent s’il est organisé sur un plan cohérent et si toutes ses parties sont intrinsèquement liées de façon à servir un objectif commun.

• Construction des modules physiques – Les directives suivantes aident pendant la construction des modules physiques –

  • Les classes d’un module doivent représenter des choses ou des composants similaires dans le même objet composite.

  • Les classes étroitement connectées devraient être dans le même module.

  • Les classes non connectées ou faiblement connectées devraient être placées dans des modules séparés.

  • Les modules devraient avoir une bonne cohésion, c’est-à-dire, une coopération élevée entre ses composants.

  • Un module devrait avoir un faible couplage avec d’autres modules, c’est-à-dire que l’interaction ou l’interdépendance entre les modules devrait être minimale.

Optimisation de la conception

Le modèle d’analyse capture les informations logiques sur le système, tandis que le modèle de conception ajoute des détails pour soutenir un accès efficace aux informations. Avant qu’une conception ne soit mise en œuvre, elle doit être optimisée de manière à rendre la mise en œuvre plus efficace. Le but de l’optimisation est de minimiser le coût en termes de temps, d’espace et d’autres métriques.

Cependant, l’optimisation de la conception ne doit pas être excessive, car la facilité d’implémentation, la maintenabilité et l’extensibilité sont également des préoccupations importantes. On constate souvent qu’une conception parfaitement optimisée est plus efficace mais moins lisible et réutilisable. Le concepteur doit donc trouver un équilibre entre les deux.

Les différentes choses qui peuvent être faites pour l’optimisation de la conception sont –

• Ajout d’associations redondantes
• Omission d’associations non utilisables
• Optimisation des algorithmes
• Enregistrement des attributs dérivés pour éviter le recalcul d’expressions complexes

Ajout d’associations redondantes

Pendant l’optimisation de la conception, il est vérifié si la dérivation de nouvelles associations peut réduire les coûts d’accès. Bien que ces associations redondantes puissent ne pas ajouter d’informations, elles peuvent augmenter l’efficacité du modèle global.

Omission d’associations non utilisables

La présence d’un trop grand nombre d’associations peut rendre un système indéchiffrable et donc réduire l’efficacité globale du système. Ainsi, lors de l’optimisation, toutes les associations non utilisables sont supprimées.

Optimisation des algorithmes

Dans les systèmes orientés objet, l’optimisation de la structure de données et des algorithmes se fait de manière collaborative. Une fois que la conception de la classe est en place, les opérations et les algorithmes doivent être optimisés.

L’optimisation des algorithmes est obtenue par –

• Réarrangement de l’ordre des tâches de calcul
• Inversion de l’ordre d’exécution des boucles par rapport à celui fixé dans le modèle fonctionnel

.

• Suppression des chemins morts dans l’algorithme

Sauvegarde et stockage des attributs dérivés

Les attributs dérivés sont les attributs dont les valeurs sont calculées en fonction d’autres attributs (attributs de base). Le recalcul des valeurs des attributs dérivés chaque fois qu’ils sont nécessaires est une procédure qui prend du temps. Pour éviter cela, les valeurs peuvent être calculées et stockées dans leurs formes calculées.

Cependant, cela peut poser des anomalies de mise à jour, c’est-à-dire un changement dans les valeurs des attributs de base sans changement correspondant dans les valeurs des attributs dérivés. Pour éviter cela, les mesures suivantes sont prises –

• A chaque mise à jour de la valeur de l’attribut de base, l’attribut dérivé est également recalculé.

• Tous les attributs dérivés sont recalculés et mis à jour périodiquement dans un groupe plutôt qu’après chaque mise à jour.

Documentation de conception

La documentation est une partie essentielle de tout processus de développement de logiciel qui enregistre la procédure de réalisation du logiciel. Les décisions de conception doivent être documentées pour tout système logiciel non trivial afin de transmettre la conception aux autres.

Domaines d’utilisation

Bien qu’étant un produit secondaire, une bonne documentation est indispensable, notamment dans les domaines suivants –

• Dans la conception d’un logiciel qui est développé par un certain nombre de développeurs
• Dans les stratégies itératives de développement de logiciels
• Dans le développement des versions ultérieures d’un projet de logiciel
• Pour l’évaluation d’un logiciel
• Pour trouver les conditions et les zones de test
• Pour la maintenance du logiciel.

Contenu

Une documentation bénéfique doit essentiellement comprendre le contenu suivant –

• Architecture du système de haut niveau – Diagrammes de processus et diagrammes de modules

• Attraits et mécanismes clés – Diagrammes de classes et diagrammes d’objets.

• Scénarios qui illustrent le comportement des principaux aspects – Diagrammes comportementaux

Caractéristiques

Les caractéristiques d’une bonne documentation sont –

• Concises et en même temps, non ambiguës, cohérente et complète

• Traçable aux spécifications des exigences du système

• Bien structurée

• Diagrammatique plutôt que descriptive

.