Tâche: Conception de capsules
Cette tâche décrit les caractéristiques de la conception de la capsule.
Objet
  • Pour élaborer et détailler les descriptions d'une capsule.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Description principale

Les capsules sont utilisées pour définir les unités d'exécution simultanées dans le système. Les capsules peuvent être imbriquées à une profondeur arbitraire et comporter des associations pour concevoir des classes (passives). Cette activité est réalisée une fois pour chaque capsule, dont les nouvelles capsules identifiées dans le cadre de cette tâche.

 Représentation UML 2.0

Notez que la représentation actuelle RUP des capsules est basée sur la notation UML 1.5. Une grande partie peut être représentée dans UML 2.0 en utilisant le Concept: classe structurée.

Voir Différences entre UML 1.x et UML 2.0 pour plus d'informations.

Etapes
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éfinir les états

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.

Définir les transitions d'état

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.

Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations