Activité :
|
Objet | |
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 :
En outre, au cours de la conception, seront également identifiés :
Ces distinctions supplémentaires permettent d'examiner différents aspects de la conception :
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.
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 :
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).
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.
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'artefact 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.
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)
|