Une brève discussion sur le modèle de développement du logiciel GRASP

Êtes-vous un bon développeur de logiciels ? Connaissez-vous GRASP? Le modèle de développement logiciel GRASP, dont le nom complet est General Responsibility Assignment Software Patterns, est un autre modèle de développement logiciel aussi célèbre que le célèbre modèle logiciel GoF (Gang of Four, les 23 modèles de développement logiciel que nous appelons souvent modèle). Mais contrairement au GoF, il ne propose pas de structures organisationnelles logicielles spécifiques, mais propose plutôt ce que nous devrions suivre dans le processus d'abstraction des fonctions commerciales du monde réel en objets spécifiques dans le développement de logiciels. . Ce n'est qu'en suivant ces principes de base que nous pouvons développer des logiciels de haute qualité. Pour les projets logiciels que nous souhaitons développer, nous n'avons pas besoin d'utiliser le modèle d'usine, nous n'avons pas besoin d'utiliser le modèle singleton, nous n'avons pas besoin d'utiliser le modèle d'observateur, mais il nous est impossible de ne pas abstraire les fonctions commerciales du monde réel en objets concrets dans le développement de logiciels. De ce point de vue, nous devons améliorer la qualité de notre développement logiciel. Une compréhension approfondie de GRASP est plus importante qu'une compréhension approfondie de GoF. Mais je vois qu'il existe de nombreux articles présentant GoF et quelques articles présentant GRASP. Pour cette raison, je présente maintenant GRASP à tout le monde. GRASP contient 9 modèles, qui sont 9 principes de base. Ceci est expliqué en profondeur dans le livre classique « UML and Pattern Application » du gourou de la conception de logiciels Craig Larman. GRASP est appelé modèle logiciel d'attribution de responsabilités générales. Pour comprendre GRASP, la première question que nous devons comprendre est de savoir pourquoi nous devons attribuer des responsabilités pendant le processus d'analyse et de conception des objets.

1. Allocation des responsabilités et conception axée sur les responsabilités

Au début d'un projet logiciel, nous devons généralement effectuer une analyse des exigences pour comprendre quel type de logiciel le client doit concevoir et quelles fonctions le logiciel aurait dû. L'analyse des exigences comprend les fonctions métier requises par les clients dans le monde réel. Chaque fonction métier est souvent un processus métier, c'est-à-dire le processus métier que les clients continuent d'exécuter dans leur travail quotidien. En même temps, dans le monde problématique de l'utilisateur, il doit y avoir des choses ou des choses liées les unes aux autres.
Prenons l'exemple d'un système de gestion des avis logiciels. Les exigences commerciales du système de gestion des avis sont les suivantes :
1. L'organisateur de l'évaluation élabore un plan d'évaluation, le soumet au responsable pour approbation, puis informe les évaluateurs par e-mail.
2． Les réviseurs sont invités à réviser respectivement les objets à réviser, à remplir le formulaire de révision et peuvent poser des questions sur les objets à réviser.
3． L'organisateur de l'examen résume les questions des évaluateurs et organise une réunion d'examen pour discuter de ces questions. Lors de la réunion, certaines questions sont devenues des problèmes, d'autres n'ont pas posé de problèmes et d'autres n'ont toujours pas pu être confirmées.
4． Après la réunion, l'organisateur de l'évaluation triera les questions et rédigera un rapport d'évaluation, puis les évaluateurs voteront pour savoir si l'évaluation est réussie ou non. Enfin, l'organisateur de l'examen résume les résultats du vote et formule une conclusion de l'examen.
5． Les organisateurs de l’examen suivent la résolution des problèmes.
Grâce à la description des exigences ci-dessus, il ne nous est pas difficile de trouver des éléments connexes dans l'ensemble du monde des problèmes : organisateur d'évaluation, plan d'évaluation, réviseur, objet d'évaluation, formulaire d'évaluation, questions, rapport d'évaluation, conclusion d'évaluation et questions. Il n'est pas difficile pour nous d'analyser la relation entre ces éléments. Par exemple, le plan d'examen et les évaluateurs sont un à plusieurs, tandis que le rapport d'examen et les conclusions de l'examen sont un à un.
Dans RUP, les exigences métier formeront des cas d'utilisation dans le modèle et ses documents de description, et les objets et leurs relations formeront des objets dans le modèle de domaine. Bien sûr, comment créer des modèles de cas d'utilisation et un domaine. Les modèles vont au-delà de cet article. Concernant la portée de la discussion, les amis intéressés peuvent lire les articles pertinents.
Les objets du modèle de domaine deviendront la base pour former des objets spécifiques dans le développement logiciel (les objets formés dans le développement logiciel sont déterminés en fonction des besoins spécifiques du développement logiciel et ne doivent pas nécessairement être cohérents avec les objets du modèle de domaine). Les cas d'utilisation du modèle de cas d'utilisation seront implémentés en attribuant des comportements à ces objets. La question se pose maintenant de savoir comment attribuer les fonctions du modèle de cas d’utilisation, ou une série de comportements, à ces objets. En d’autres termes, pour accomplir la même tâche, je peux attribuer le comportement A à l’objet X ou à l’objet Y. Bien que mon implémentation spécifique du comportement A soit différente lorsque je le remets à l'objet X et lorsque je le remets à l'objet Y, les deux peuvent accomplir la tâche du comportement A. Alors, dois-je le remettre à l’objet X ou à l’objet Y ? Y a-t-il un principe de base ? Oui, il s’agit de répartir les tâches en fonction des responsabilités. Bien qu'en théorie, je puisse définir l'objet de manière arbitraire, lui donner un sens ou terminer n'importe quel travail, mais généralement nous ne le concevons pas de cette façon. Habituellement, nous connectons des objets à des objets du monde réel, tels que la conception d'un objet de plan de révision et d'un objet de réviseur. Et nous devrions parvenir à une « faible différence de représentation » lors de la conception des objets. Une faible différence de représentation signifie que les objets que nous concevons doivent être aussi cohérents que possible avec les objets du monde réel. Par exemple, nous concevons un objet appelé « réviseur » car nous avons des réviseurs dans le monde réel. Dans le même temps, les comportements que nous attribuons aux objets réviseurs doivent être aussi cohérents que possible avec le monde réel, comme l'ajout de réviseurs, la modification de réviseurs et l'obtention d'informations sur les réviseurs. Les comportements à attribuer à cet objet doivent donc être déterminés par les responsabilités.
Nous concevons les objets dans le système logiciel grâce à l'analyse du monde réel ou à l'analyse du modèle de domaine. À ce stade, nous devons attribuer des responsabilités à chaque objet. Quelle est la responsabilité d'un objet ? Bien entendu, elle se définit à travers l'analyse du monde réel et des tâches que cet objet doit accomplir. Par exemple, la responsabilité de l'objet réviseur est d'accéder aux données liées au réviseur. Bien entendu, la responsabilité de l'objet n'est pas nécessairement la même. Par exemple, le plan de révision contient les sous-éléments de l'objet de révision et du réviseur, il peut donc gérer l'accès aux informations de l'objet de révision et du réviseur au nom du réviseur. examiner l'objet lorsque le travail n'est pas occupé. Mais un objet ne doit pas avoir trop de responsabilités (seulement 2 ou 3) et doit être fortement lié. Par exemple, si l'objet du formulaire d'évaluation se voit attribuer la responsabilité de traiter le formulaire d'évaluation ainsi que de traiter également les données du plan d'évaluation, cela est appelé indépendant de la responsabilité.
La répartition des responsabilités est désormais généralement reconnue comme un principe qu'une excellente conception logicielle doit suivre. Elle présente les avantages suivants :
1. De faibles différences de représentation rendent les logiciels clairement structurés et faciles à comprendre, car le développement de logiciels n'est pas l'affaire d'une seule personne. Dans les projets logiciels développés par plusieurs personnes, une structure logicielle claire peut éviter les erreurs inutiles causées par des malentendus des développeurs.
2． Facile à entretenir et à changer. S'il y a un problème avec le plan de révision ou s'il doit être modifié, nous nous adresserons au plan de révision. S'il s'agit d'un problème avec le réviseur, nous nous adresserons au réviseur, et cela n'aura jamais rien à voir avec les autres. fêtes.
Ce type d'approche de conception d'objets et de composants qui prend en compte les objets, les responsabilités et la collaboration est appelé « Responsibility Drive Design (RDD) ». La conception axée sur la responsabilité implique d'abord de concevoir des modèles de cas d'utilisation, des descriptions de modèles de cas d'utilisation, des contrats d'exploitation, des diagrammes de séquence de système, des modèles de domaine et des glossaires, puis de créer étape par étape des modèles d'analyse et des modèles de conception, et d'écrire des diagrammes d'interaction et des diagrammes de classes pour chacun. fonction. Je n’entrerai pas ici dans les détails du processus compliqué. Mais faites attention à un détail très important. Comme nous l'avons dit plus tôt, les objets dans les systèmes logiciels sont abstraits du monde réel. L'attribution des responsabilités des objets est basée sur la définition de l'objet, en lui attribuant quelques tâches très liées. Cependant, même si nous suivons ces principes, nous disposons toujours d’une flexibilité de conception considérable. Différentes personnes ont toujours des conceptions différentes pour la même fonction, en fonction de leur propre compréhension. GRASP est traduit par « Modèle logiciel d'attribution de responsabilité générale » en chinois, qui propose plusieurs principes de base pour la question de l'attribution des responsabilités dans l'analyse et la conception d'objets. Dans le même temps, ces principes de base doivent également être compris dans une certaine mesure, c'est-à-dire qu'ils ne sont pas applicables dans toutes les situations et ne constituent pas non plus un indicateur absolu. Par exemple, un faible couplage ne signifie pas un non-couplage absolu. Sans couplage, un logiciel ne peut pas être conçu. Une cohésion élevée ne peut pas être infiniment élevée, sinon le système sera compliqué et anormal.

2. Analyse des modèles GRASP un par un

Logiciel GRASP Modèle de conception comprend 9 modèles : Créateur, Expert en information, Faible Couplage, Contrôleur, forte cohésion, polymorphisme, pure fiction, indirection, prévention de mutation.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!