Objet
  • Analyser les interactions des classes d'analyse pour identifier les éléments du modèle de conception
Rôle :  Architecte logiciel 
Fréquence : Une fois par itération  
Etapes
Artefacts d'entrée :   Artefacts de sortie :   
Guides d'utilisation de l'outil : 
Plus d'informations : 

Détails sur l'enchaînement d'activités :   

L'activité d'analyse de cas d'utilisation permet d'obtenir des classes d'analyse, qui représentent des éléments conceptuels pouvant reproduire un certain comportement. En termes de conception, les classes d'analyse permettent d'obtenir différents éléments de conception :

  • les classes, chargées de représenter un ensemble de responsabilités détaillées ;
  • les sous-systèmes, chargés de représenter un ensemble de responsabilités non détaillées, éventuellement composés d'un autre ensemble de sous-systèmes, mais ultimement ensemble de classes ;
  • les classes actives, chargées de représenter les unités d'exécution de contrôle au sein du système ;
  • les interfaces, chargées de représenter les déclarations abstraites de responsabilités émanant d'une classe ou d'un sous-système.

En outre, au cours de la conception, seront également identifiés :

  • les événements, qui constituent des spécifications d'occurrences intéressantes en termes de temps et d'espace, et qui nécessitent habituellement une réponse du système ;
  • les signaux, chargés de représenter les mécanismes asynchrones utilisés pour communiquer certains types d'événements au sein du système.

Ces distinctions supplémentaires permettent d'examiner différents aspects de la conception :

  • Les événements et les signaux qui sont utilisés pour la communication permettent de décrire les déclencheurs asynchrones de comportement auxquels le système doit répondre.
  • Les classes et les sous-systèmes permettent de regrouper les responsabilités associées en unités qui peuvent être développées en relative indépendance ; les classes répondent à un ensemble de responsabilités associées, alors que les sous-systèmes sont des ensembles composites qui intègrent eux-mêmes des classes ou d'autres sous-systèmes. Les sous-systèmes sont utilisés pour représenter les produits d'une équipe de développement sous forme d'une unité intégrale de fonctionnalités ; ils sont donc utilisés comme unités de contrôle et de gestion de la configuration, ainsi que comme éléments de conception logique.
  • Les classes actives sont utilisées pour représenter les unités d'exécution de contrôle du système et permettent d'effectuer la modélisation de la simultanéité. Les classes actives sont souvent utilisées en association avec d'autres classes généralement passives : ce type de composition peut alors être utilisé pour la modélisation de comportements complexes, et représente une sorte de collaboration.
  • Les interfaces permettent d'examiner et de capturer les différentes couches du système, définissant en des termes précis l'interfonctionnement entre les parties du système.

En séparant les thèmes et en traitant séparément chaque question représentée par ces concepts, nous simplifions le processus de conception et clarifions notre solution.

Si une traçabilité doit être effectuée entre plusieurs modèles de systèmes, elle doit être documentée au cours de cette activité. Pour plus d'informations sur la façon de documenter la traçabilité entre le modèle de conception et les autres modèles de systèmes, voir Principes et conseils : Modèle de conception.

Identifier les événements et les signaux Haut de la page

Objet Identifier les événements externes et internes auxquels le système doit répondre. 

Les événements sont des occurrences externes et internes qui entraînent l'exécution d'une action au sein du système. Les événements et leurs caractéristiques peuvent aider à identifier les éléments de conception clés, comme par exemple les classes actives.

La liste initiale des événements externes peut être dérivée du modèle de cas d'utilisation, des interactions des acteurs avec les cas d'utilisation. Les événements internes peuvent être dérivés de texte de cas d'utilisation ou peuvent être identifiés au fur et à mesure de l'évolution de la conception.

Les caractéristiques importantes des événements sont les suivantes :

  • interne/externe - L'événement est-il interne ou externe ?
  • priorité - Le traitement de cet événement doit-il entraîner l'arrêt d'autres traitements ?
  • fréquence - Quelle est la fréquence de cet événement ?
  • répartition de la fréquence - Cet événement se produit-il à intervalles réguliers, ou observe-t-on des pointes ?
  • exigences en matière de réponse - A quelle vitesse le système doit-il répondre à l'événement (nécessité de faire la distinction entre la moyenne et la valeur la plus basse) ?
  • type - S'agit-il d'un événement d'appel, d'heure, de signal ou de modification (pour obtenir les définitions correspondantes, voir Concepts : événements et signaux) ?

Les caractéristiques des événements doivent être capturées selon les besoins pour identifier les éléments de conception qui permettent de les traiter. La capture des caractéristiques d'événements est généralement plus importante sur des systèmes réactifs (utilisant les événements), mais elle peut être utile sur d'autres systèmes tels que ceux qui intègrent les messages asynchrones et/ou simultanés.

Les événements de communication asynchrone peuvent être modélisés sous forme de signaux pour spécifier les données contenues ou les relations entre les signaux, comme par exemple la généralisation. Pour certains systèmes (les systèmes réactifs tout particulièrement), il est important de signaler les signaux reçus provenant d'unités externes (interruptions ou messages de sondage spécifiques, par exemple).

Identifier les classes, les classes actives et les sous-systèmes Haut de la page

Objet Redéfinir les classes d'analyse en éléments de modèle de conception appropriés 

Identifiez les classes. Lorsque la classe d'analyse est simple et représente déjà une abstraction logique, elle peut être directement mappée (1:1) à une classe de conception. Généralement, les classes entité demeurent relativement intactes. Puisque les classes d'entité sont souvent persistantes, déterminez si la classe de conception doit l'être également et notez-le dans la description de classe.

Lors de l'identification des classes, celles-ci doivent être regroupées en Artefact : package de conceptions, à des fins d'organisation et de gestion de configuration. Pour plus d'informations sur la prise de décisions concernant le package, voirPrincipes.

Identifiez les classes actives. Considérez les exigences de simultanéité du système dans le contexte des objets d'analyse identifiés : le système doit-il répondre à des événements générés de façon externe, et si oui, quelles classes sont 'actives' lorsque l'événement survient ? Dans le modèle de cas d'utilisation, les événements externes sont représentés par les stimuli émis par les acteurs qui interagissent avec un cas d'utilisation. Recherchez les réalisations de cas d'utilisation correspondantes pour déterminer les objets qui interagissent lorsqu'un événement survient. Commencez par regrouper les objets en ensembles autonomes d'objets collaborant : ces regroupements représentent un découpage initial de groupe susceptible de former une classe active composite.

Si les événements sont associés à des attributs importants nécessitant d'être capturés, vous pouvez les modéliser en classes, stéréotypée sous le nom de <<signal>>.

Les instances de classes actives représentent des unités d'exécution indépendantes logiques. Ces unités d'exécution 'logiques' ne doivent pas être confondues avec ou mappées à des unités d'exécution situées dans le système d'exploitation (elles seront toutefois mappées à certains points avec quelques-unes d'entre elles). En réalité, elles représentent des unités d'exécution conceptuelles indépendantes dans l'espace de solution. A ce stade de la conception, notre objectif d'identification consiste à être capable de partitionner la solution en unités indépendantes en prenant comme base les couches de simultanéité naturelles du système. Grâce à cette division du travail, le traitement conceptuel de la simultanéité est simplifié, car les unités d'exécution indépendantes peuvent faire l'objet d'un traitement séparé (dans la mesure où elles partagent des classes passives sous-jacentes).

En règle générale, une classe active doit être envisagée chaque fois qu'il existe une simultanéité et des conflits de simultanéité dans le domaine correspondant. Une classe active doit être utilisée pour représenter un objet externe simultané ou une activité simultanée au sein de l'ordinateur. Cela permet de surveiller les activités simultanées.

Vous pouvez également utiliser les classes actives comme des représentants internes d'unités physiques externes connectés à un ordinateur, car ces entités physiques sont de façon inhérente des entités simultanées. Ces classes de "périphériques" ne sont pas uniquement utilisées pour surveiller les unités physiques correspondantes, mais elles permettent également d'isoler le reste du système des éléments spécifiques des unités. Cela signifie que le reste du système peut ne pas être affecté, même si la technologie correspondante évolue.

Il existe une autre méthode d'utilisation des classes actives, qui consiste à les représenter sous forme d'activités simultanées logiques. Une activité logique représente un "objet" simultané conceptuel (comme par exemple une transaction financière ou un appel téléphonique). Même si elles ne sont pas directement représentées sous forme d'entités physiques, elles sont souvent traitées comme telles. Par exemple, il peut être nécessaire de retenir une transaction financière pour éviter un conflit de simultanéité, ou encore de l'abandonner en raison de défaillances système. Puisque ces objets conceptuels doivent être manipulés comme une unité, il convient de les représenter sous forme d'objets dotés de leurs propres interfaces et offrant des capacités fonctionnelles appropriées.

Un exemple de ce type d'objet conceptuel est le contrôleur d'objets actif. Son objectif consiste à gérer simultanément plusieurs autres objets actifs. Cela implique normalement l'affectation à chaque objet de l'état opérationnel souhaité, le maintien à cet état en dépit d'interruptions (défaillance partielle, par exemple) et la synchronisation de son fonctionnement avec celui d'autres objets. Ces contrôleurs d'objets actifs sont souvent à l'origine des objets de contrôle identifiés au cours de l'activité d'analyse de cas d'utilisation.

En raison de leur capacité à résoudre simplement et de façon appropriée les conflits de simultanéité, les classes actives sont aussi utilisées comme gardiennes des ressources partagées. Dans ce cas, une ou plusieurs ressources requises par des activités simultanées sont encapsulées au sein d'une classe active. En s'appuyant sur leur sémantique d'exclusion intégrée, elles protègent automatiquement ces ressources de tout conflit de simultanéité.

Identifiez les sous-systèmes. Lorsque la classe d'analyse est complexe (et intègre par exemple des comportements qui ne peuvent pas être placés sous la responsabilité d'une seule classe autonome), elle doit être mappée à un sous-système de conception. Le sous-système de conception est utilisé pour l'encapsulage de ces collaborations de telle sorte que les clients du sous-système peuvent ne pas connaître sa conception interne, même s'ils utilisent les services fournis par le sous-système.

Les sous-systèmes sont modélisés comme des composants UML dont les éléments publics sont uniquement les interfaces. Les interfaces fournissent une couche d'encapsulage, ce qui permet à la conception interne du sous-système de rester masquée pour les autres éléments de modélisation. Ce sous-système permet la distinction avec les autres packages, qui sont des conteneurs sans sémantique d'éléments de modélisation.

La décision de créer un sous-système à partir de classes d'analyse collaborantes dépend du développement indépendant de la collaboration par une équipe de conception. Si les collaborations peuvent être totalement contenues dans un package avec les classes collaborantes, un sous-système peut offrir un encapsulage plus efficace que celui fourni par un package simple. Le contenu et les collaborations d'un sous-système sont complètement isolés derrière une ou plusieurs interfaces ; par conséquent, le client du sous-système ne dépend que de l'interface. Le concepteur du sous-système est complètement à l'abri des dépendances externes ; il doit spécifier la méthode de réalisation de l'interface, mais il est libre de modifier la conception du sous-système interne sans que cela affecte les dépendances externes. Dans les gros systèmes impliquant de grandes équipes indépendantes, ce niveau de découplage associé à la mise en oeuvre architecturale fournie par les interfaces formelles est un argument de poids pour le choix de sous-système et non de simples packages. Pour plus d'informations sur les facteurs qui affectent le choix d'utilisation de sous-systèmes comme éléments de conception, voir Principes et conseils : sous-système de conception.

Identifier les interfaces de sous-systèmes Haut de la page

Objet Identifier les éléments de conception qui formalisent les différentes couches du système. 

Les interfaces définissent un ensemble d'opérations réalisées pour des classes. Dans le modèle de conception, les interfaces sont principalement utilisées pour définir les interfaces de sous-systèmes. Cela ne veut pas dire qu'elles ne peuvent pas être utilisées pour les classes également, mais il est généralement suffisant pour celles-ci de définir des opérations publiques au niveau de la classe qui définit son interface. Les interfaces sont importantes pour les sous-systèmes car elles permettent une séparation entre la déclaration de comportement (l'interface) et la réalisation du comportement (classes spécifiques du sous-systèmes qui réalisent l'interface). Ce découplage permet d'augmenter l'indépendance des équipes de développement qui travaillent sur différentes parties du système, tout en retenant des informations précises sur les 'contrats' existant entre ces différentes parties.

Pour chaque sous-système, identifiez un ensemble d'interfaces potentielles. A l'aide des collaborations groupées identifiées à l'étape précédente, identifiez la responsabilité activée lorsque la collaboration est initialisée. Cette responsabilité est alors affinée afin de déterminer les informations à fournir par le client et celles qui sont renvoyées lorsque la collaboration est terminée. Ces ensembles d'informations deviennent les prototypes de paramètres d'entrée et de sortie et renvoient une valeur pour une opération réalisée par le sous-système. Donnez un nom à cette opération, à l'aide des conventions d'affectation de noms définies dans l'../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websiteartefact de principes et conseils spécifiques aux projets. Renouvelez cette action jusqu'à ce que toutes les opérations devant être réalisées par le sous-système aient été définies.

Ensuite, regroupez les opérations en fonction de leurs responsabilités associées. Il est préférable de constituer de petits groupes car ils contiennent un ensemble cohérent de responsabilités communes en raison du nombre réduit d'opérations au sein du groupe. Tenez compte également de la réutilisation (recherchez les similitudes permettant de faciliter l'identification des fonctionnalités réutilisables). Toutefois, ne passez pas trop de temps à rechercher le regroupement idéal de responsabilités. Souvenez-vous qu'il s'agit simplement d'une ébauche de regroupement et que vous l'affinerez lors de la phase d'élaboration.

Recherchez les similitudes entre les interfaces. A partir de l'ensemble potentiel d'interfaces, recherchez les noms, les responsabilités et les opérations similaires. Lorsque des opérations similaires existent dans plusieurs interfaces, incluez les opérations courantes de ces interfaces dans une nouvelle interface. N'oubliez pas de rechercher également les interfaces existantes et de les réutiliser lorsque vous le pouvez. L'objectif consiste à préserver la cohérence des interfaces tout en supprimant les opérations redondantes présentes entre les interfaces. Cela permettra de faciliter la compréhension et l'évolutivité des interfaces par la suite.

Définissez les dépendances entre les interfaces. Les paramètres et la valeur de retour de chaque opération d'interface portent un type spécifique : ils doivent être chargés des opérations d'une interface en particulier, ou encore être des instances d'un type de données. Lorsque les paramètres sont des objets chargés de réaliser les opérations d'une interface spécifique, définissez les relations de dépendance existant entre l'interface et les interfaces dont elle dépend. La définition des dépendances entre interfaces fournit des informations utiles à l'architecte du logiciel, car ces dépendances définissent celles existant entre les différents éléments du modèle de conception.

Mappez les interfaces aux sous-systèmes. Une fois que les interfaces ont été identifiées, créez des associations de réalisations entre le sous-système et les interfaces correspondantes. Une réalisation entre le sous-système et une interface indique qu'il existe un ou plusieurs éléments dans le sous-système réalisant les opérations de l'interface. Une fois que le sous-système est conçu, ces réalisations sont affinées via la spécification des éléments chargés, dans le sous-système, de réaliser les opérations de l'interface. Ces réalisations revues sont uniquement visibles pour le concepteur du sous-système ; seule la réalisation entre le sous-système et l'interface est visible au niveau du client.

Définissez le comportement spécifié par les interfaces. Les interfaces définissent souvent un automate à états implicite pour les éléments qui réalisent les opérations de l'interface. Si les opérations de l'interface doivent être appelées dans un ordre particulier (par exemple, si la connexion de base de données doit être ouverte avant de pouvoir être utilisée), une machine illustrant les états visibles des éléments de conception chargés de réaliser les opérations de l'interface doit être définie. Cette machine aide l'utilisateur de l'interface à mieux comprendre cette dernière ; elle aide le concepteur des éléments chargés de réaliser les opérations de l'interface à obtenir un comportement correct des éléments concernés.

Procédez au package des interfaces. Les interfaces sont la propriété de l'architecte du logiciel ; les modifications apportées aux interfaces ont toujours un impact architectural. Pour pouvoir gérer cela, vous devez regrouper les interfaces en un ou plusieurs packages appartenant à l'architecte du logiciel. Si chaque interface est réalisée par un seul sous-système, les interfaces peuvent être placées dans le même package au sein du sous-système. Si les interfaces sont réalisées par plusieurs sous-systèmes, elles doivent être placées dans un package séparé appartenant à l'architecte du logiciel. Cela permet de bénéficier d'une gestion et d'un contrôle indépendants des sous-systèmes eux-mêmes.

Représentation UML 1.xHaut de la page

Selon UML 1.5, un sous-système correspond à un type spécifique de package qui possède comme uniques éléments publics les interfaces. Les interfaces fournissent une couche d'encapsulage, ce qui permet à la conception interne du sous-système de rester masquée par rapport aux autres éléments de modélisation. Ce sous-système permet la distinction avec les autres packages ordinaires, qui sont des conteneurs sans sémantique d'éléments de modélisation ; il représente une utilisation spécifique de packages possédant des propriétés de comportements.

Pour plus d'informations, voir Différences entre UML 1.x et UML 2.0 .

 

RUP (Rational Unified Process)   2003.06.15