La modélisation des besoins
151
© Groupe Eyrolles
Comme pour les composants, les règles de diffusion et de distribution internes et
externes doivent être définies.
Le Modèle en Couches de Services (MCS)
L’utilité du MCS est de permettre une phase préalable à la définition de l’architecture physique du système cible. En ce sens, ce modèle constitue un apport important aux spécifications d’intégration des matériels, des logiciels et réseaux locaux.
Figure 3.14 : La représentation du MCS
Parmi ses autres rôles essentiels, il permet :
◗ la caractérisation du contexte « système » et de l’architecture applicative générale ;
◗ le détail de l’architecture n-tiers, c’est-à-dire l’explicitation précise, par application, de la nature, du contenu et du contenant de chaque couche ; on précisera
pour chaque service, qui peut être client du service, qui peut être serveur du
service ; on précisera le type de service : de données, d’application, de calcul, de
résolution de règles métier ;
◗ la définition des IHM (nature, technologie, description détaillée), absolument
nécessaire pour une unification des accès aux applications ;
◗ les produits de middleware utilisés pour assurer le fonctionnement coopératif
de l’ensemble des progiciels choisis ;
Application
Module
Sub client
Middleware
Sub serveur
IHM
Progiciel
Interface
Sub client
Middleware
Sub serveur
IHM
151
© Groupe Eyrolles
Comme pour les composants, les règles de diffusion et de distribution internes et
externes doivent être définies.
Le Modèle en Couches de Services (MCS)
L’utilité du MCS est de permettre une phase préalable à la définition de l’architecture physique du système cible. En ce sens, ce modèle constitue un apport important aux spécifications d’intégration des matériels, des logiciels et réseaux locaux.
Figure 3.14 : La représentation du MCS
Parmi ses autres rôles essentiels, il permet :
◗ la caractérisation du contexte « système » et de l’architecture applicative générale ;
◗ le détail de l’architecture n-tiers, c’est-à-dire l’explicitation précise, par application, de la nature, du contenu et du contenant de chaque couche ; on précisera
pour chaque service, qui peut être client du service, qui peut être serveur du
service ; on précisera le type de service : de données, d’application, de calcul, de
résolution de règles métier ;
◗ la définition des IHM (nature, technologie, description détaillée), absolument
nécessaire pour une unification des accès aux applications ;
◗ les produits de middleware utilisés pour assurer le fonctionnement coopératif
de l’ensemble des progiciels choisis ;
Application
Module
Sub client
Middleware
Sub serveur
IHM
Progiciel
Interface
Sub client
Middleware
Sub serveur
IHM