OOAD - Conception orientée objet
Après la phase d'analyse, le modèle conceptuel est développé en un modèle orienté objet utilisant la conception orientée objet (OOD). Dans 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, ce qui donne un modèle pour le domaine de la solution. En un mot, une description détaillée est construite spécifiant 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 suit:
- Définition du contexte du système
- Conception de l'architecture du système
- Identification des objets dans le système
- Construction de modèles de conception
- Spécification des interfaces d'objets
Conception du système
La conception de système orientée objet consiste à définir le contexte d'un système, puis à concevoir l'architecture du système.
Context- Le contexte d'un système a une partie statique et une partie dynamique. Le contexte statique du système est conçu à l'aide d'un simple schéma de principe de l'ensemble du système qui est développé 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é en utilisantuse case diagrams.
System Architecture- 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 que des connaissances du domaine. En règle générale, 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 signifie diviser un grand système complexe en une hiérarchie de composants plus petits avec moins de complexités, sur les principes de diviser pour vaincre. Chaque composant majeur du système est appelé un sous-système. La décomposition orientée objet identifie les objets autonomes individuels dans un système et la communication entre ces objets.
Les avantages de la décomposition sont -
Les composants individuels sont moins complexes et donc plus compréhensibles et gérables.
Il permet la division des effectifs ayant des compétences spécialisées.
Il permet aux sous-systèmes d'être remplacés ou modifiés sans affecter les autres sous-systèmes.
Identifier la concurrence
La concurrence permet à plusieurs objets de recevoir des événements en même temps et à plusieurs activités à exécuter simultanément. La concurrence est identifiée et représentée dans le modèle dynamique.
Pour activer la concurrence, chaque élément concurrent se voit attribuer un thread de contrôle distinct. Si la concurrence est au niveau de l'objet, deux objets concurrents se voient attribuer deux threads de contrôle différents. Si deux opérations d'un même objet sont de nature simultanée, 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. Une stratégie claire doit donc être élaborée chaque fois que la concurrence est requise. En outre, la concurrence doit être identifiée au stade de la conception elle-même et ne peut être laissée au stade de la mise en œuvre.
Identification des modèles
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 modèles de conception. Un modèle peut être défini comme un ensemble documenté de blocs de construction pouvant être utilisés dans certains types de problèmes de développement d'applications.
Certains modèles de conception couramment utilisés sont -
- Motif de façade
- Modèle de séparation de la vue du modèle
- Modèle d'observateur
- Modèle de modèle de contrôleur de vue
- Publier le modèle d'abonnement
- Modèle proxy
Contrôle des événements
Lors de la conception du système, les événements susceptibles de 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'un événement significatif qui a un emplacement dans le temps et l'espace.
Il existe quatre types d'événements qui peuvent être modélisés, à savoir -
Signal Event - Un objet nommé lancé par un objet et capturé par un autre objet.
Call Event - Un événement synchrone représentant l'envoi d'une opération.
Time Event - Un événement représentant le passage du temps.
Change Event - Un événement représentant un changement d'état.
Gestion des conditions aux 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 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 stationnaire.
La fin du système, c'est-à-dire la fermeture de tous les threads en cours d'exécution, le nettoyage des ressources et les messages à envoyer.
La configuration initiale du système et la reconfiguration du système si nécessaire.
Prévoir des pannes ou une interruption indésirable du système.
Les conditions aux limites sont modélisées à l'aide de cas d'utilisation aux limites.
Conception d'objets
Une fois la hiérarchie des sous-systèmes développée, 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 passe des concepts du domaine d'application vers les concepts informatiques. Les objets identifiés lors de 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 des objets
- Représentation d'objets, c'est-à-dire construction de modèles de conception
- Classification des opérations
- Conception d'algorithmes
- Conception des relations
- Mise en place du contrôle des interactions externes
- Package des classes et des associations dans des modules
Identification d'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 affinés afin qu'ils conviennent à une implémentation réelle.
Les fonctions de cette étape sont -
Identifier et affiner les classes dans chaque sous-système ou package
Définition des liens et 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 d'agrégations
Représentation d'objets
Une fois les classes identifiées, elles doivent être représentées à l'aide de techniques de modélisation d'objets. Cette étape consiste essentiellement à construire des diagrammes UML.
Il existe deux types de modèles de conception à produire -
Static Models - Décrire la structure statique d'un système à l'aide de diagrammes de classes et d'objets.
Dynamic Models - Décrire la structure dynamique d'un système et montrer l'interaction entre les classes à l'aide de diagrammes d'interaction et de diagrammes d'états.
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, modèle objet, modèle dynamique et 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 au sein des actions sont identifiées.
Les actions principales sont étendues aux diagrammes de flux de données.
Conception d'algorithmes
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 les algorithmes alternatifs 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.
Flexibility - La flexibilité détermine si l'algorithme choisi peut être mis en œuvre de manière appropriée, sans perte de pertinence dans divers environnements.
Understandability - Cela 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 définie lors de la phase de conception de l'objet. Les principales relations abordées comprennent les associations, les agrégations et les héritages.
Le concepteur doit faire ce qui suit concernant les associations -
Identifiez si une association est unidirectionnelle ou bidirectionnelle.
Analysez le chemin des associations et mettez-les à jour si nécessaire.
Implémentez les associations en tant qu'objet distinct, dans le cas de relations plusieurs à plusieurs; ou comme lien vers un autre objet dans le cas de relations un-à-un ou un-à-plusieurs.
En ce qui concerne les héritages, le concepteur doit faire ce qui suit -
Ajustez les classes et leurs associations.
Identifiez les classes abstraites.
Prenez des dispositions pour que les comportements soient partagés au besoin.
Mise en œuvre du contrôle
Le concepteur d'objets peut incorporer des raffinements dans la stratégie du modèle de diagramme d'état. Dans la conception du système, une stratégie de base pour réaliser le modèle dynamique est élaborée. Lors de la conception d'objet, cette stratégie est bien embellie pour une mise en œuvre appropriée.
Les approches de mise en œuvre du modèle dynamique sont:
Represent State as a Location within a Program- Il s'agit de l'approche traditionnelle axée sur les procédures dans laquelle l'emplacement du contrôle définit l'état du programme. Une machine à états finis peut être implémentée en tant que 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 vers l'arrière forment les boucles ou itérations.
State Machine Engine- Cette approche représente directement une machine d'état via une classe de moteur de machine d'état. Cette classe exécute la machine à états via un ensemble de transitions et d'actions fournies par l'application.
Control as Concurrent Tasks- Dans cette approche, un objet est implémenté en tant que 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. Il préserve la concurrence intrinsèque des objets réels.
Classes d'emballage
Dans tout grand projet, le partitionnement méticuleux d'une implémentation en modules ou packages est important. Lors de la conception des objets, les classes et les objets sont regroupés dans des packages pour permettre à plusieurs groupes de travailler en coopération sur un projet.
Les différents aspects de l'emballage sont -
Hiding Internal Information from Outside View - Il permet à une classe d'être considérée comme une «boîte noire» et permet de modifier l'implémentation de classe sans que les clients de la classe modifient le code.
Coherence of Elements - 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 que toutes ses parties sont intrinsèquement liées de manière à servir un objectif commun.
Construction of Physical Modules - Les instructions suivantes aident lors de la construction de modules physiques -
Les classes d'un module doivent représenter des éléments ou des composants similaires dans le même objet composite.
Les classes étroitement connectées doivent être dans le même module.
Les classes non connectées ou faiblement connectées doivent être placées dans des modules séparés.
Les modules doivent avoir une bonne cohésion, c'est-à-dire une coopération élevée entre ses composants.
Un module doit avoir un faible couplage avec d'autres modules, c'est-à-dire que l'interaction ou l'interdépendance entre les modules doit ê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 permettre un accès efficace aux informations. Avant qu'une conception ne soit mise en œuvre, elle doit être optimisée afin de 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 paramètres.
Cependant, l'optimisation de la conception ne doit pas être excessive, car la facilité de mise en œuvre, la maintenabilité et l'extensibilité sont également des préoccupations importantes. On voit souvent qu'un design parfaitement optimisé 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:
- Ajouter des associations redondantes
- Omettre les associations non utilisables
- Optimisation des algorithmes
- Enregistrer les attributs dérivés pour éviter le recalcul d'expressions complexes
Ajout d'associations redondantes
Lors de 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 n'apportent aucune information, elles peuvent augmenter l'efficacité du modèle global.
Omission des 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 des données et des algorithmes se fait de manière collaborative. Une fois la conception de classe en place, les opérations et les algorithmes doivent être optimisés.
L'optimisation des algorithmes est obtenue par -
- Réorganisation de l'ordre des tâches de calcul
- Inversion de l'ordre d'exécution des boucles par rapport à celui défini dans le modèle fonctionnel
- Suppression des chemins morts dans l'algorithme
Enregistrement 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 entraîner des anomalies de mise à jour, c'est-à-dire un changement des valeurs des attributs de base sans changement correspondant des valeurs des attributs dérivés. Pour éviter cela, les étapes suivantes sont suivies -
À chaque mise à jour de la valeur d'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 logiciel qui enregistre la procédure de création du logiciel. Les décisions de conception doivent être documentées pour tout système logiciel non trivial pour transmettre la conception à d'autres.
Domaines d'utilisation
Bien qu'il s'agisse d'un produit secondaire, une bonne documentation est indispensable, en particulier dans les domaines suivants -
- Lors de la conception de logiciels développés par un certain nombre de développeurs
- Dans les stratégies de développement logiciel itératives
- Lors du développement de versions ultérieures d'un projet logiciel
- Pour évaluer un logiciel
- Pour trouver les conditions et les zones de test
- Pour la maintenance du logiciel.
Contenu
Une documentation utile devrait essentiellement inclure le contenu suivant -
High–level system architecture - Diagrammes de processus et diagrammes de modules
Key abstractions and mechanisms - Diagrammes de classes et diagrammes d'objets.
Scenarios that illustrate the behavior of the main aspects - Diagrammes comportementaux
traits
Les caractéristiques d'une bonne documentation sont -
Concis et en même temps, sans ambiguïté, cohérent et complet
Traçable selon les spécifications des exigences du système
Well-structured
Diagrammatique au lieu de descriptif