Lorsque le système communique avec un autre système, une ou plusieurs classes frontière sont identifiées au niveau de l'activité Analyse de cas d'utilisation pour décrire le protocole de communication. Tout matériel ou logiciel auquel fait appel le système (notamment les imprimantes, les terminaux, les systèmes d'alarme et les détecteurs) peut constituer un système externe. Dans chaque cas, une classe frontière est identifiée, laquelle joue un rôle de médiateur dans le cadre de la communication avec le système externe.

Exemple

Les guichets automatiques (GAB) doivent communiquer avec le réseau GAB afin de vérifier le numéro de compte et le code confidentiel des clients et de s'assurer que ces derniers disposent de fonds suffisants pour effectuer un retrait. Etant donné que le réseau GAB est un système externe (par rapport au guichet), celui-ci est représenté par une classe frontière dans l'analyse de cas d'utilisation.

Si l'interface vers le système est simple et clairement définie, une seule classe peut suffire à représenter le système externe tout entier. Cependant, les interfaces sont souvent trop complexes pour n'être représentées que par une seule classe et nécessitent parfois la collaboration complexe de plusieurs classes. En outre, les interfaces entre systèmes sont fréquemment réutilisables sur plusieurs applications. Ainsi, dans bien des cas, les sous-systèmes permettent de modéliser les interfaces système de façon plus appropriée.

L'utilisation d'un sous-système permet de définir et de stabiliser l'interface associée au système externe en masquant les détails de conception de l'interface système pendant sa définition.

Affinage de la conception

La création d'interfaces vers d'autres systèmes ou périphériques impose un certain formalisme dans la spécification et la réalisation de ces interfaces (UML). Le cas échéant, il est recommandé d'être très précis en ce qui concerne la définition des frontières du système et du contexte dans lequel celui opère. Alors qu'un modèle de cas d'utilisation décrit le contexte comportemental du système, un modèle logique du système dans son environnement montre quant à lui les éléments suivants :

  • Les interfaces à réaliser et celles fournies par le système (en termes de services fournis par ce dernier, comme les opérations ou les réceptions de signaux, protocoles associés pris en charge et informations échangées).
  • Les interfaces requises par le système (devant être réalisées par les systèmes externes qui interagissent avec le système) en vue de garantir une performance satisfaisante. Lorsque le système externe existe déjà, il arrive souvent que ces interfaces requises et fournies reflètent simplement les contraintes imposées par le système externe. Ceci est lié au fait que le comportement du système ne peut être modifié.

Il est possible de créer un diagramme contextuel représentant la collaboration de premier niveau entre le système et les autres systèmes ou périphériques. Cette structure s'apparente au modèle de cas d'utilisation associé au système. Les services système coopèrent afin de prendre en charge les cas d'utilisation. Il est notamment possible de créer un ensemble de diagrammes de séquence décrivant les interactions entre les systèmes externes et le système en construction, afin de représenter les messages échangés dans le cadre de l'exécution d'un cas d'utilisation, et de faire correspondre ces messages avec des opérations (ou des réceptions). Notons cependant que ce type de diagramme se distingue d'un diagramme de séquence illustrant la réalisation d'un cas d'utilisation, dans la mesure où il ne montre pas les structures internes du système. L'exécution d'un scénario de cas d'utilisation implique généralement plusieurs invocations et réponses système.

L'identification des services et leur réalisation au sein du système ne s'effectue pas nécessairement de haut en bas : une analyse de cas d'utilisation (effectuée par le concepteur) inclut la modélisation initiale des classes en cours de réalisation (y compris les classes frontière) et des collaborations. Celle-ci prend en compte le travail effectué par l'architecte logiciel dans l'activité Analyse d'architecture. Il est possible d'itérer cette analyse et d'affiner ultérieurement les classes frontière et les messages qui circulent entre les frontières du système (à condition d'avoir la liberté de le faire). Lorsque l'interface concerne un système externe difficile voire impossible à modifier, les détails de l'interface (et donc les services en assure le support) sont déterminés dès le début et l'utilisateur n'a d'autre choix que d'affiner la réalisation de l'interface.

A ce niveau, le système peut être représenté par un composant (UML) (ou sous la forme d'une classe structurée dans UML 2.0) chargé de réaliser les interfaces précédemment définies dans UML, afin de prendre en charge les périphériques ou les systèmes externes. Ces interfaces peuvent ensuite être affectées, via UML 2.0, à des points d'interaction spécifiques ou à des ports situés aux frontières du système. Ces ports permettent à l'architecte logiciel et au concepteur de montrer comment les composants internes du système ou les classes sont "connectés" en vue de gérer les interfaces. Cette structure forme un pont naturel vers les classes frontière identifiées au cours de l'analyse : dans le plus simple des cas, ces classes peuvent être reliées aux interfaces qu'elles réalisent grâce aux ports situés aux frontières du système. UML 2.0 propose un niveau de précision supérieur grâce aux automates à états : ces derniers peuvent être associés à une interface ou à un port, et permettent de spécifier les séquences légales d'invocation des fonctions comportementales définies par l'interface ou prises en charge par le port.

Dans les cas où, comme nous l'avons décrit ci-dessus, une collaboration est nécessaire à la prise en charge d'une interface complexe, cette collaboration (qui évolue à partir des classes frontière identifiées au départ) peut elle-même être encapsulée en tant que composant (ou classe structurée) interne au fonctionnement du système (à l'instar du sous-système décrit dans la première partie), et connectée au port gérant l'interface en question.

Pour plus d'informations sur la mise à disposition et la réalisation d'interfaces dans une architecture orientée services, voir le document technique "Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications".

RUP (Rational Unified Process)   2003.06.15