Documenter l'origine du sous-système
Pendant la Tâche : Analyse de domaine fonctionnel, nous avons identifié un ensemble de
sous-systèmes correspondant à l'entrée provenant d'une mappe de composants métier (voir Concept : Modélisation de composant métier). Pendant la décomposition du processus,
les noeuds d'activité au niveau feuille identifiés (Concept : Décomposition de processus métier) peuvent être placés sur les
sous-systèmes en tant qu'opérations ou services que le sous-système va fournir en tant que façade. La fonctionnalité de
ces opérations est réalisée par les composants fonctionnels du composant de service. Vous pouvez également choisir de
regrouper ces opérations en interfaces proposées par le sous-système. Les exigences non fonctionnelles liées
aux opérations sont utilisées pour rechercher les composants et les services techniques requis au sein du sous-système.
Il est important que la relation entre ces sous-systèmes identifiés et leur source initiale soit conservée. Dans
les cas où les produits de travail de niveau métier et du modèle de services sont en langage UML, les informations de
dépendance peuvent aisément être stockées dans les modèles ; dans les autres cas, ces informations doivent être
stockées dans le Canevas : Modèle de services sous Word ou conservées dans un produit de travail
associé.
Considérations liées aux ISV : Les services peuvent être réalisés à l'aide de sous-systèmes existants tels que
des applications personnalisées, des packages logiciels et/ou des éditeurs de logiciel indépendants (ISV). Comme décrit
dans la section suivante, dans certains cas, l'identification de nouveaux sous-systèmes peut impliquer un regroupement
physique des services en fonction de critères tels que l'affinité des données, le coût, les performances, etc., bien
que l'identification de sous-système soit généralement effectuée selon une approche descendante, pendant l'activité
Analyse de domaine fonctionnel. L'affectation de composants aux niveaux architecturaux afin de répondre aux contraintes
architecturales imposées par les exigences non fonctionnelles est expliquée dans Réalisation des
services.
Exemple
Le résultat de l'analyse de domaine fonctionnel pour un exemple d'agence de location de véhicules est répertorié dans
le tableau suivant :
Domaine
|
Domaine fonctionnel
|
Sous-système
|
Description
|
Marketing et gestion client
|
Service client
|
Service client
|
Fournit toutes les fonctions automatisées pour le domaine fonctionnel.
|
Produits
|
Gestion des promotions
|
Gestion des promotions
|
Fournit toutes les fonctions automatisées pour le domaine fonctionnel.
|
Logistique du parc de location
|
Gestion du parc
|
Gestion du parc
|
Fournit toutes les fonctions automatisées pour le domaine fonctionnel.
|
Gestion des locations
|
Location
|
Location
|
Fournit toutes les fonctions automatisées pour le domaine fonctionnel.
|
Gestion des locations
|
Réservations
|
Réservations
|
Fournit toutes les fonctions automatisées pour le domaine fonctionnel.
|
Gestion des locations
|
Tarification
|
Tarification
|
Fournit toutes les fonctions automatisées pour le domaine fonctionnel.
|
Le modèle UML obtenu pour les sous-systèmes identifiés ci-dessus est le suivant. Notez que les dépendances du
sous-système sont déjà fournies dans le modèle illustré ci-dessous.
Pour chaque sous-système, les détails décrits par l'Artefact : Sous-système de conception doivent être documentés ou
peuvent être capturés dans le modèle de services du format du document (voir Canevas : Modèle de services sous Word) dans un format similaire au format
suivant.
Nom
|
Réservation
|
Description
|
Le sous-système de réservation permet de créer et de gérer les réservations de location de véhicules.
|
Interfaces
|
-
Réserver un véhicule
-
Modifier la réservation
-
Obtenir des informations sur les options
-
Confirmer le contrat de location
-
Localiser la réservation
-
Annuler la réservation
|
Fonctions
|
-
Réserver un véhicule
-
Modifier la réservation
-
Obtenir des informations sur les options
-
Confirmer le contrat de location
-
Localiser la réservation
-
Annuler la réservation
|
Dépendances
|
Aucune
|
Exigences non fonctionnelles
|
Aucune
|
|
Identifier et appliquer les patterns de composant de service
Dans les Instructions : Patterns de composant de service, nous présentons non seulement
les différents types de composant couramment utilisés pour implémenter les sous-systèmes identifiés pendant cette
tâche, mais également un ensemble de patterns qui permettent des implémentations évolutives et flexibles de ces
sous-systèmes. Les patterns, et bien entendu des patterns supplémentaires existent - il ne s'agit pas d'un ensemble
complet - peuvent être spécifiés dans le cadre de l'architecture d'un projet.
La sélection ou la personnalisation d'un pattern spécifique dépend des éléments suivants :
-
Les exigences fonctionnelles et non fonctionnelles de la solution et du sous-système spécifique.
-
Les capacités et les qualités de service fournies par les logiciels intermédiaires sur lesquels les composants vont
être déployés.
-
Le compromis coût/complexité et bénéfices entre différents patterns.
|
Identifier le composant de service
Les sous-systèmes, de par leur nature, ne sont pas des ressources informatiques et ne peuvent pas être déployés dans
l'infrastructure informatique ; ils constituent un pont entre le point de vue métier et le point de vue informatique.
Chaque sous-système est réalisé par un ou plusieurs composants de service où un composant de service est une
ressource à l'échelle de l'entreprise (un élément logiciel géré avec des fonctions garanties de disponibilité,
d'équilibrage de charge, de sécurité, de performances et de gestion des versions). Le composant de service est à son
tour réalisé par plusieurs composants fonctionnels et techniques, conformément au diagramme ci-dessous.
Généralement, chaque service attribué à un sous-système génère un composant de service ; les composants fonctionnels et
techniques peuvent être partagés entre les composants de service au sein du même sous-système.
|
Identifier les composants fonctionnels
Les composants fonctionnels fournissent une fonction métier supplémentaire à un composant de service ; à de nombreux
égards, la capacité fournie par un composant de service dépend intégralement de ses composants fonctionnels et de toute
logique métier supplémentaire qu'il implémente.
Les composants fonctionnels se trouvent souvent parmi les gestionnaires de types - composants gérant un élément de
domaine particulier, par exemple "Véhicule", "Client, "Planning", etc. Il faut préciser que ces éléments de domaine
sont fréquemment des graphiques à granularité élevée de données plutôt que de simples structures.
Exemple
Si l'on considère l'exemple de l'agence de location de véhicules, le composant de service Réservation doit pouvoir
collecter les informations sur le client, l'emplacement où il souhaite prendre possession du véhicule et les véhicules
disponibles dans la classe qu'il a demandée. Nous devons également être en mesure de déterminer le classement du client
de manière à pouvoir lui fournir le niveau de service correct dans l'éventualité d'impondérables tels qu'une
indisponibilité du véhicule. Le diagramme ci-dessous montre le modèle de composant pour Réservation.

|
Identifier les composants techniques
Les composants techniques ou d'infrastructure permettent d'obtenir des fonctions de plateforme horizontales disponibles
; en d'autres termes, les fonctions qu'ils fournissent ne sont pas spécifiques du domaine métier mais traversent les
domaines métier. Ces services techniques sont fréquemment fournis par les progiciels intermédiaires, y compris les
systèmes d'exploitation, et sont utilisés soit directement par le composant de service, soit par les composants
fonctionnels dont ils dépendent.
Exemple
Pour compléter le modèle de composant d'agence de location de véhicules (voir l'étape sur les composants fonctionnels
ci-dessus), nous intégrons deux composants techniques au modèle, un pour la Réservation afin de consigner l'exécution
d'une demande de réservation et un pour indiquer que les composants Véhicule et Emplacement reposent sur des services
EJB pour conserver leurs données métier.
Vous pouvez aussi utiliser un format tabulaire pour représenter les composants requis et leurs relations aux services
précédemment identifiés, comme illustré dans la figure ci-dessous.

|
Distribuer le comportement de sous-système aux éléments de sous-système
Le comportement externe d'un sous-système est principalement défini par les interfaces qu'il réalise. Lorsqu'un
sous-système réalise une interface, il s'engage à prendre en charge toutes les opérations définies par l'interface.
L'opération peut ensuite être réalisée par une opération sur un élément de conception (c'est-à-dire une classe ou un sous-système) contenu dans le sous-système ; cette opération peut
nécessiter une collaboration avec d'autres éléments de conception.
Les collaborations des éléments de modèle dans le sous-système doivent être documentées en utilisant des diagrammes de
séquence montrant comment le comportement du sous-système est réalisé. Chaque opération sur une interface réalisée par
le sous-système doit être documentée par un ou plusieurs diagrammes de séquence. Ce diagramme appartient au
sous-système et est utilisé pour concevoir le comportement interne du sous-système.
Si le comportement du sous-système dépend largement de l'état et représente un ou plusieurs fils de contrôle, les
automates à états sont généralement plus utiles pour décrire le comportement du sous-système. Dans ce contexte, les
machines d'état sont généralement utilisées conjointement avec des classes actives pour représenter une décomposition
des fils de contrôle du système (ou du sous-système en l'occurrence) ; elles sont décrites dans des diagrammes
d'état-transition, voir Instructions :
Diagramme d'état-transition. Dans les systèmes en temps réel, le comportement des Produit : Capsules sera également décrit au moyen de machines
d'état.A l'intérieur du sous-système, il peut exister des unités d'exécution
indépendantes, représentées par des classes actives.
Dans les systèmes en temps réel, des Produit :
Capsules seront utilisées pour encapsuler ces unités.
Exemple :
La collaboration des sous-systèmes pour accomplir un comportement requis du système peut être exprimée en utilisant des
diagrammes de séquence :
Ce diagramme montre comment les interfaces des sous-systèmes sont utilisées pour effectuer un scénario. En particulier,
pour le sous-système de Gestion du réseau, nous pouvons voir les interfaces spécifiques (ICoordinator dans ce cas) et
les fonctionnements que le sous-système doit prendre en charge. Nous voyons également que le sous-système Gestion du
réseau est dépendant des interfaces IBHandler et IAHandler.
En examinant le sous-système, nous voyons comment l'interface ICoordinator est réalisée :
La classe Coordinateur joue le rôle de "proxy" pour l'interface ICoordinator, en se chargeant des opérations
d'interface et en coordonnant le comportement de l'interface.
Ce diagramme de séquence "interne" montre ce que les classes apportent à l'interface, ce qui doit se produire de façon
interne pour apporter la fonctionnalité du sous-système et quelles classes envoient des messages à partir du
sous-système. Le diagramme clarifie la conception interne, et il est essentiel pour les sous-systèmes possédant des
conceptions internes complexes. Il permet aussi au comportement sous-système d'être facilement compris, ce qui peut
permettre de le réutiliser d'un contexte à l'autre.
Lors de la création de ces diagrammes de "réalisation d'interface", la création de nouvelles classes et de nouveaux
sous-systèmes peut s'avérer nécessaire pour effectuer le comportement requis. Le processus est similaire à celui qui
est défini dans l'analyse du cas d'utilisation, mais nous travaillons avec des opérations d'interface et non plus avec
des cas d'utilisation. Pour chaque opération d'interface, identifiez les classes (ou dans certains cas, lorsque le
comportement requis est complexe, un sous-système contenu) du sous-système actuel qui sont nécessaires pour effectuer
l'opération. Créez de nouvelles classes ou de nouveaux sous-systèmes lorsque les classes/ sous-systèmes existants ne
peuvent pas fournir le comportement requis (mais essayez tout d'abord de réutiliser ces éléments).
La création de nouveaux éléments de conception implique généralement de reconsidérer le contenu et les limites du
sous-système. Veillez à éviter d'avoir la même classe dans deux sous-systèmes différents. Si c'est le cas, cela
implique que les limites du système ne sont pas bien définies. Réexaminez de façon périodique la Tâche : Identification des éléments de conception pour rééquilibrer
les responsabilités du sous-système.
Il est parfois utile de créer deux modèles distincts internes du sous-système - une spécification destinée au client du
sous-système et une réalisation destinée aux implémenteurs. La spécification peut inclure des classes et des
collaborations "idéales" permettant de décrire le comportement du sous-système en terme de classes et de collaborations
idéales. La réalisation, par contre, correspond de façon plus étroite à l'implémentation et peut évoluer afin de
devenir l'implémentation. Pour plus d'informations sur la spécification et la réalisation du sous-système de
conception, voir les Instructions relatives au produit : Sous-système de conception, spécification et
réalisation du sous-système.
|
Documenter les éléments de sous-système
Objet
|
Documenter la structure interne du sous-système.
|
Pour documenter la structure interne du sous-système, créez un ou plusieurs diagrammes montrant les éléments contenus
par le sous-système, et comment ils sont associés les uns aux autres. Un diagramme de classe devrait suffire, mais
plusieurs peuvent être utilisés pour réduire la complexité et améliorer la lisibilité.
Vous trouverez ci-dessous un exemple de diagramme de classe :
Exemple de diagramme de classe pour un système d'entrée de commande.
Modélisé en tant que composant, le contenu interne d'un sous-système peut être représenté de façon alternative dans le
cadre du rectangle de composant d'un diagramme de composants. Cette représentation nous permet également d'inclure les
points d'interaction de ce sous-système avec d'autres parties du système, ce qui est fait par le biais de ses
interfaces.
Vous trouverez ci-dessous un exemple de diagramme de composants décrivant le sous-système Classement, son contenu
interne, ainsi que ses interfaces fournies et requises.
Exemple de diagramme de composants pour le sous-système Classement
Dans la mesure où un composant est une classe
structurée, il peut être étroitement encapsulé en forçant les communications extérieures à passer par des ports
obéissant à des interfaces déclarées, ce qui apporte plus de précisions dans la spécification et l'interconnexion de ce
composant. Cette représentation permet de "câbler" les instances des parties au moyen de connecteurs pour qu'elles
jouent un rôle spécifique dans l'implémentation du composant (reportez-vous au Concept : Classe
structurée pour plus d'informations).
Vous trouvez ci-dessous un exemple de diagramme de structure composite pour le sous-système Classement utilisant les
interfaces et les ports.
Exemple de diagramme de structure composite pour le sous-système Classement
De plus, un diagramme d'état-transition peut s'avérer nécessaire pour documenter les états potentiels que le système peut
adopter (voir Technique : Diagramme d'état-transition).
La description des classes contenues dans le sous-système lui-même est traitée dans la Tâche : Conception de classe.
|
Décrire les dépendances du sous-système
Objet
|
Documenter les interfaces dont dépend le sous-système.
|
Lorsqu'un élément contenu dans un sous-système utilise un comportement d'un élément contenu dans un autre sous-système,
une dépendance est créée entre les deux sous-systèmes. Pour améliorer la réutilisation et réduire les dépendances de
maintenance, nous souhaitons exprimer ceci en termes de dépendance à une interface
particulière du sous-système, et non au sous-système lui-même ou à l'élément contenu dans le sous-système.
La raison de ce choix est double :
-
Nous souhaitons pouvoir remplacer un élément de modèle (y compris les sous-systèmes) par un autre dans la mesure où
ils proposent le même comportement. Nous précisons le comportement requis en terme d'interfaces, ainsi, toute
exigence comportementale qu'un élément de modèle a par rapport à un autre doit être exprimée en termes
d'interfaces.
-
Nous souhaitons donner au concepteur une liberté totale dans la conception du comportement interne du
sous-système tant que celui-ci fournit le comportement externe correct. Si un élément de modèle dans un
sous-système fait référence à un élément de modèle d'un autre sous-système, le concepteur n'a plus la liberté de
supprimer cet élément de modèle ou de redistribuer le comportement de cet élément de modèle à d'autres éléments.
Ainsi, le système est plus fragile.
Lorsque vous créez des dépendances, assurez-vous qu'il n'y a pas de dépendances ou d'associations directes entre les
éléments de modèles contenus dans le sous-système et les éléments de modèles contenus dans d'autres sous-systèmes.
Assurez-vous également qu'il n'existe pas de dépendance circulaire entre les sous-systèmes et les interfaces ; un
sous-système ne peut pas à la fois réaliser une interface et dépendre d'elle.
Les dépendances entre les sous-systèmes et entre les sous-systèmes et les packages peuvent être exprimées comme
ci-dessous. Représentée ainsi, la dépendance montre qu'un sous-système (Gestion des factures, par exemple) dépend
directement d'un autre sous-système (Gestion de la planification du paiement).
Exemple d'une organisation des sous-systèmes en couches en utilisant des dépendances directes
Lorsqu'il est possible de substituer un sous-système à un autre (lorsqu'ils ont les mêmes interfaces), la dépendance
peut être reliée à une interface réalisée par le sous-système, plutôt qu'au sous-système
lui-même. Cela permet d'utiliser tout autre élément de modèle (sous-système ou classe) réalisant la même interface.
L'utilisation de dépendances d'interfaces permet de concevoir des cadres d'application flexibles en utilisant des
éléments de conception remplaçables.
Exemple d'organisation en couches du sous-système au moyen de dépendances d'interface
|
|