Tâche: Conception d'opérations
Cette tâche affine les résultats de l'analyse des opérations en réalisations d'opérations détaillées.
Objet
  • Affiner les interactions préliminaires de sous-systèmes en réalisations d'opérations dans le modèle de conception.
  • Affiner et spécifier les opérations de sous-système.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif:
  • Aucun
Externe:
  • Aucun
Sorties
Etapes
Créer des réalisations d'opération

Dans la Tâche : Analyse des opérations, le concepteur a créé des interactions de sous-système (pas très détaillées) dans le modèle d'analyse. Rappelez-vous que vous aviez organisé la granularité de ces interactions pour qu'elles soient regroupées par opération système, c'est-à-dire que vous avez enregistré les interactions qui réalisent chaque opération système. Désormais, en travaillant avec les descriptions de cas d'utilisation système étendus (structurels), le détail des messages, les entités échangées, le séquencement, le flux de contrôle et les données associées sont ajoutés et les réalisations d'opération en résultant sont enregistrées dans le modèle de conception, à nouveau organisées par opération système. Lorsque ce détail est ajouté, le concepteur évalue la qualité des collaborations naissantes, en considérant les possibilités de refaire la conception. Annotez les réalisations d'opérations avec des descriptions de l'action du sous-système lors du traitement d'un message (à partir de la description de l'étape structurelle et en détaillant si nécessaire). Ces descriptions aident à l'étape suivante pour développement des spécifications pour chaque opération de sous-système.

Ajouter des étapes structurelles de sous-système similaires et spécifier des opérations de sous-système

Le concepteur a produit la vue d'ensemble des opérations du sous-système initial lors de la tâche d'analyse des opérations. Le tableau de vue d'ensemble indique également (sur fond gris) la traçabilité vers les étapes fonctionnelles de cas d'utilisation système, en indiquant (dans le tableau) que les étapes fonctionnelles de cas d'utilisation système<id 1> et <id 2> sont réalisées par des appels de <nom de l'opération système 1>.

Sous-système <nom>
Opération système Identificateur d'étape fonctionnelle de cas d'utilisation système Localité Processus Travailleur Description de l'étape structurelle du sous-système Opération du sous-système

<opération système nom1>

<id 1> Identificateur de localité Identificateur de processus Identificateur de l'organisation ou du travailleur système (identificateur de l'étape structurelle) : description d'une action réalisée par un sous-système (partie de la réalisation de l'étape fonctionnelle) sous forme d'entrée, de traitement, de sortie (identificateur d'opération de sous-système) : nom de l'opération de sous-système appelée pour cette étape, par exemple, "«opération de sous-système» Lancer une liste de ventes" (pour le traitement des commandes) du sous-système
... ...   (identificateur de l'étape structurelle) :...  
... ...   ...  
<id 2> ... ...   ...  
<opération système nom2> <id 3> ... ...   ...  
<id 4> ... ...   ...  
... ... ... ...   ...  

Exemple de vue d'ensemble d'opération de sous-système.

Ensuite, en travaillant à partir des étapes structurelles et des réalisations d'opérations, les opérations de sous-système sont identifiées et leur comportement spécifié. Comme pour l'identification des opérations système, il peut ne pas y avoir une seule opération de sous-système pour chaque étape structurelle ; c'est-à-dire, lorsque vous examinez l'ensemble des étapes structurelles et l'échange associé de messages, les entités entrée-sortie, etc., vous trouverez peut-être qu'il est possible de définir un petit ensemble d'opérations de sous-système pour satisfaire leurs besoins.

Notez que le tableau de vue d'ensemble peut également être retrié par localité ou par processus, en indiquant l'association d'un ensemble d'opérations de sous-système avec chaque localité ou processus. Le tri par localité donne une indication de la charge de traitement à une localité (et donc est utile pour réfléchir à la capacité des composants physiques qui prennent en charge la localité). Sous cette forme, la vue d'ensemble triée par localité devient une propriété du modèle de déploiement.

Lorsqu'une opération de sous-système est hébergée à plusieurs localités, ceci indique qu'une partie au moins du sous-système est dupliquée. Rien n'implique que ces portions dupliquées partagent nécessairement des données ou sont conservées en synchronisation. Il s'agit de choix de conception qui dépendent de l'application et du motif de duplication ; par exemple, le traitement requis peut être identique, mais se produire pour un segment métier différent. A l'extrême, toutes les opérations d'un sous-système peuvent être hébergées à plusieurs localités, ce qui signifie qu'effectivement, le sous-système lui-même est dupliqué. Le besoin d'identifier des instances dupliquées dépend également uniquement des motifs de duplication.

Le tri par processus permet au concepteur de réfléchir aux problèmes de l'accès concurrent : si vous deviez visualiser une opération de sous-système comme un élément discret des fonctions disponibles pour les acteurs, alors, à la première estimation, les opérations associées au même processus ne peuvent pas être réalisées en parallèle. Ceci peut amener le concepteur à repenser l'attribution des processus, ou la duplication des processus, ou à examiner le problème de temps d'attente perçu à un niveau de détail inférieur, par exemple, grâce à l'examen d'options de découpage de temps et de partage de processus lorsqu'une opération se bloque (pour une entrée-sortie, par exemple). Ces techniques peuvent donner une réactivité acceptable, alors que différer le lancement d'une opération (uniquement les opérations de sérialisation) peut être intolérable. Sous cette forme, la vue d'ensemble triée par processus devient une propriété du modèle de conception.

Notez vos résultats en pied en page

Pour chaque sous-système, vous avez :

  • défini ses opérations
  • défini les interfaces que le sous-système doit prendre en charge
  • décrit la façon dont le sous-système collabore avec d'autres sous-systèmes pour réaliser les cas d'utilisation système
  • défini le contexte du sous-système : ses acteurs, interfaces et entités E/S

Vous êtes donc en bonne position pour transférer cet ensemble de produits pour un développement indépendant, si c'est ce que vous choisissez, ou pour appeler à nouveau des tâches RUP dans la discipline de recueil des exigences, afin de réaliser une autre décomposition de façon récursive.

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