Créer des ports et les associer à des protocoles
Prenez en compte les responsabilités de la capsule, en créant un ensemble initial de classes de ports. Ces classes de
ports représentent les 'interfaces' de la capsule. Les classes de ports représentent la réalisation d'un Produit : protocole, qui représente à son tour un ensemble de signaux
d'entrée et de sortie utilisés pour communiquer avec les capsules.
Lors de la création de ports, prenez en compte la Liste de contrôle :
protocole pour déterminer si le protocole est approprié ou pas. Le port doit refléter un seul ensemble de
responsabilités associées ; un protocole d'une portée similaire permet sa réutilisation dans un certain nombre de
capsules. Une fois que le protocole approprié est sélectionné, associez le port au protocole approprié.
|
Valider les interactions de capsule
Une fois que les ports sont associés à des protocoles, le comportement externe de la capsule doit être évalué et
validé. A l'aide de techniques d'approche manuelles ou d'outils de simulation automatisés, testez le comportement de la
capsule en simulant les événements qui exerceront le comportement de la capsule. La validation prendra également en
compte les capsules qui agissent avec la capsule en conception. A l'aide d'outils automatisés, inscrivez un code de
talon dans la capsule pour permettre le test des ports. Lorsque des erreurs dans la définition du protocole ou du port
ou dans les responsabilités de la capsule sont détectées, apportez les changements appropriés aux définitions de la
capsule, du port et du protocole.
|
Définir la machine d'état de la capsule
Une fois que les ports et les protocoles de la capsule ont été validés, définissez le comportement interne de la
capsule. Le comportement de la capsule est défini à l'aide d'un diagramme d'état-transition. Référence : Instruction : diagramme d'état-transition. D'autres informations générales sur la
capsule peuvent être obtenues à partir de l'Instruction : capsule,
Liste de contrôle : capsule.
D'abord, identifiez les états auxquels la capsule peut exister. Les états doivent être uniques (une capsule ne peut
être dans deux états simultanément) et descriptifs. Voir les instructions et les points de contrôle appropriés pour
plus d'informations.
Une fois que les états sont définis, considérez les transitions entre états. Le code de transition doit ressembler à un
pseudo-code d'application de haut niveau ; il doit comporter principalement des interventions sur appel du système
d'exploitation en temps réel, par exemple, des interventions de trame, des fonctions d'horodatage, des opérations de
port, des opérations de capsule et des opérations de classes passives.
Lors de l'ajout d'un code de détail à une transition de capsule :
-
Si le code peut être utile dans d'autres transitions, envisagez de le déléguer à une opération de capsule.
-
Déterminez si le code implémente des capacités qui sont conformes à la responsabilité de la capsule.
Lors de la définition d'une opération de capsule :
-
Déterminez si la fonction peut être utilisable à tout moment à partir de n'importe quelle transition dans la
capsule, et si le travail effectué (ou une partie) peut être utile ailleurs dans le système. Si c'est le cas,
envisagez de la déléguer à une fonction de classe passive.
-
Si le code est trop spécifique à l'application pour être stocké dans une classe de données particulière, envisagez
la création d'une classe de données supplémentaire comme abstraction de ce code.
-
Si le code gère la manipulation de la structure des données (par ex., gestion de listes), ou effectue des calculs
complexes (de plus d'une ligne), il doit être inséré dans une classe de données.
|
Définir les exigences des classes passives
En fonction des machines d'état de la capsule, examinez les classes passives référencées par la capsule. S'il y a de
nouvelles exigences pour ces classes, des demandes de changement doivent être générées pour effectuer les changements
nécessaires. Si de nouvelles classes ont été identifiées, les exigences de ces classes (en particulier les opérations
requises sur elles) doivent être réunies et les classes doivent être créées. Ces classes seront décrites ultérieurement
dans la Tâche : conception de classe.
|
Introduire l'héritage de capsule
L'héritage de capsule est utilisé pour implémenter une généralisation-spécialisation, pour utiliser le polymorphisme,
pour réutiliser l'implémentation. Le mot clé ici est 'implémentation' : c'est une technique utilisée principalement
pour réutiliser la structure interne des capsules, et non pas le comportement externe de celles-ci.
L'héritage est souvent mal appliqué pour arriver à quelque chose qu'on aurait pu atteindre plus facilement grâce à des
techniques de conception plus simples.
Utilisation de l'héritage pour la généralisation-spécialisation
Il existe trois types d'héritage. Classés par ordre de complexité, de la plus basse (la plus souhaitable) à la plus
élevée (la moins souhaitable), ces trois types sont les suivants :
-
Héritage d'interface - hérite simplement des ports et des protocoles, c'est le type d'héritage le plus
souhaitable
-
Héritage de structure - hérite de l'interface plus des hiérarchies des conteneurs de structure (utile pour
les infrastructures)
-
Héritage de comportement - en plus de l'héritage de l'interface et de la structure, il réutilise également
le code de comportement et les machines d'état
Les héritages de structure et de comportement posent certains problèmes :
-
Le degré très élevé de couplage fourni par l'héritage entraîne des changements en cascade des sous-classes lorsque
des changements sont effectués sur des superclasses.
-
Le besoin de substituer et de supprimer le comportement et la structure de la superclasse dans les sous-classes
indique une utilisation inappropriée de l'héritage (en général pour une réutilisation tactique du code). La
restructuration des classes et des capsules et l'utilisation appropriée de la délégation représentent une stratégie
plus appropriée.
-
L'héritage implique de faire passer les décisions de conception plus haut dans la hiérarchie de classes, ce qui
entraîne des dépendances de conception et de compilation non souhaitables.
Autres problèmes :
-
Les décisions peuvent ne pas être appropriées dans toutes les situations d'utilisation.
-
L'introduction de l'héritage rend en réalité la réutilisation plus difficile, étant donné que les éléments de
conception sont associés de façon plus étroite.
-
La conception se fragilise car toute nouvelle exigence qui rend la décision non valide entraîne des problèmes
importants.
-
La conception doit être extrêmement flexible afin de compenser, ce qui est souvent difficile. C'est la raison pour
laquelle la conception d'infrastructures réutilisables est si difficile!
Toutes les conceptions contenant une structure/un comportement ont des décisions et des hypothèses intégrées
(explicites ou implicites). La question critique à poser est : êtes-vous absolument certain que la décision/l'hypothèse
sera toujours valide? Si ce n'est pas le cas, que pouvez-vous faire pour la supprimer ou pouvoir la modifier?
|
Valider le comportement de la capsule
Enfin, le comportement de la capsule doit être évalué et validé. A l'aide de techniques d'approche manuelles ou
d'outils de simulation automatisés, testez le comportement de la capsule en simulant les événements qui exerceront le
comportement de la capsule. De plus, la structure interne de la capsule doit être validée, en s'assurant que non
seulement le comportement externe mais également l'implémentation interne de ce comportement sont validés. A l'aide
d'outils automatisés, un code de talon devra peut-être être inscrit pour simuler l'implémentation de classes de données
passives et de capsules externes avec lesquelles la capsule agit. Les erreurs détectées doivent être documentées et les
changements de définitions de capsule appropriés doivent être effectués.
|
|