UML
7 - Compléments d’architecture
Bertrand LIAUDET
SOMMAIRE
COMPLEMENTS D’ARCHITECTURE 2
Problématique de l’architecture - UML et RUP 2
Les 4+1 vues de l’architecture 3
La vue de l’implémentation : diagramme des composants « sources » 4
Problématique 4
Méthode d’organisation des composants « sources » 4
Caractères d’un composant source 4
Représentation UML 5
Concrètement, sous ROSE 5
La vue des processus : diagramme des composants « exécutables ». 7
Problèmatique 7
Méthode d’organisation des composants « exécutables » 7
Caractères d’un composant exécutable 7
Représentation UML 8
Concrètement, sous ROSE 9
La vue du déploiement 10
Problématique 10
Méthode d’organisation 10
Précisions sur les noeuds 10
Représentation UML 10
Compléments au diagramme de déploiement et/ou au diagramme des composants 12
Concrètement, sous ROSE 12
La vue des cas d’utilisation : la validation 13
La vue logique 13
COMPLEMENTS D’ARCHITECTURE
Problématique de l’architecture - UML et RUP
• Le succès d’un projet orienté objet est dépendant de l’existence d’une base architecturale solide.
• L’architecture concerne tous les niveaux du développement d’un logiciel : organisation des fonctionnalités, des données, des fichiers sources, des fichiers exécutables, des machines d’exécution.
• UML est un outil qui permet de réaliser la spécification d’un produit logiciel.
Première étape : l’analyse fonctionnelle
ü Diagramme des cas d’utilisation pour montrer tous les usages du système.
ü Diagrammes de séquence des scénarios pour détailler chaque scénario et/ou diagrammes d’activité pour montrer sur un seul schéma toutes les alternatives d’un cas d’utilisation.
ü Diagramme d’activité pour montrer la synchronisation des activités du système (menu général).
Deuxième étape : l’architecture 1. Architecture logique
ü Diagramme de classes et paquetages.
ü Diagramme de séquence et de collaboration pour montrer l’équivalent des graphes d’appel des procédures.
ü Diagrammes d’activités, d’états et d’objet pour montrer des comportements particuliers.
2. Architecture des composants sources ü Diagramme des composants.
3. Architectures des exécutables ü Diagramme des composants.
4. Architecture matérielle
ü Diagramme de déploiement.
• L’architecture d’un système ne peut pas être créée d’un seul coup : elle requiert un processus itératif. Au cours des phases d’opportunité (étude préalable) et d’élaboration, les cas d’utilisation seront recensés et organisés, les principales données manipulées (données
« métier ») seront organisées, un prototype de faisabilité pourra être développé.
Les 4+1 vues de l’architecture
L’architecture concerne tous les points de vue sur le logiciel :
0. Le point de vue de l’utilisateur : c’est le point de vue le plus externe et aussi le plus déterminant : il définit les fonctionnalités attendues.
1. Le point de vue logique : c’est le point de vue du développeur, indépendamment de l’environnement de développement.
2. Le point de vue de l’implémentation : c’est le point de vue du développeur sur l’environnement de développement (l’organisation des fichiers sources).
3. Le point de vue des processus : c’est le point de vue du développeur sur les exécutables du système.
4. Le point de vue du déploiement : c’est le point de vue du développeur sur l’organisation des exécutables et de tous les fichiers nécessaires au bon déroulement du programme, ainsi que des machines qui hébergent où sur lesquelles s’exécutent les programmes.
Vue logique Vue de l’implémentation
Diagramme de classe Diagramme des composants
Paquetages, pattern… « Vue des sources »
Vue des cas d’utilisation
Vue du déploiement Vue des processus
Diagramme de déploiement Diagramme des composants
« Vue machine » « Vue des exé »
La vue de l’implémentation : diagramme des composants « sources »
Problématique
La vue des composants décrit l’organisation des composants logiciels au sein de l’environnement de développement. Ce sont les composants « sources ».
Il s’agit de spécifier, avant la réalisation, ce que seront les fichiers du programme et les dépendances de compilation.
La vue des composants décrit donc l’organisation des fichiers du type :
• Fichier source
• Fichier de données
• Table
• Etc.
La vue des composants ne s’intéresse pas aux fichiers exécutables, ni aux fichiers « dll » (dynamic links library ). C’est la vue des processus qui s’en occupera.
La vue des composants prend en compte les besoins suivants :
• Gestion du logiciel (gestion du développement, des évolutions et de la maintenance). Intervient donc la notion de facilité d’utilisation de l’environnement de développement.
• Réutilisation
• Contraintes du langage de programmation (types de fichiers du langage…)
• Contraintes des outils de développement (dépendances de compilation…)
Méthode d’organisation des composants « sources »
Les composants « sources » peuvent être regroupés dans des paquetages.
Les paquetages peuvent avoir des relations de dépendances entre eux : cette dépendance traduit la dépendance entre les composants.
Les composants « sources » peuvent avoir des relations de dépendances entre eux : ce sont des dépendances de compilation. Par exemple un fichier « .cpp » peut faire appel à un fichier
« .h ». Un fichier « .h » peut faire appel à un autre fichier « .h ».
Caractères d’un composant source
• Un composant est un élément physique qui représente une partie implémentée d’un système.
• En UML, un composant est un classificateur (au même titre qu’une classe). Il peut posséder des attributs et des opérations. Il peut participer à des relations (association, généralisation,
dépendance). Une instance de composant est un élément physique concret (un fichier) qui réside sur une instance de nœud (une machine concrète).
• Un composant peut être composé de plusieurs composants.
Représentation UML Composant
Nom de Composant
Composant stéréotypé
UML définit plusieurs stéréotypes pour les composants de l’implémentation :
<<document>> pour un fichier document
<<bibliothèque>> pour les bibliothèques statiques
<<table>> pour les tables relationnelles
<<fichier>> pour tout autre fichier (source, paramètres, etc.)
<<fichier>>
toto.cpp
Dépendance de compilation entre les composants
<<fichier>>
toto.h
<<fichier>>
toto.cpp
Par défaut, chaque classe du modèle logique est réalisée par deux composants : la spécification et le corps. La spécification contient l’interface de la classe alors que le corps contient la réalisation de cette même classe.
Concrètement, sous ROSE
• Dans le « Main Diagram » du « Component View » on commence par créer les paquetages qui vont regrouper les composants « sources ».
• De même que les composants sources vont correspondre aux classes, les paquetages de composants sources correspondent aux paquetages des classes. Du point de vue de l’environnement de développement, ils peuvent correspondre à un répertoire regroupant les fichiers correspondant aux composants sources.
• Dans chacun des paquetages ainsi définis, on va créer des composants sources. En C++, les composants sources correspondent à des fichiers avec une extension .=h ou .cpp. En Java, ce sont des fichiers avec une extension .java.
La vue des processus : diagramme des composants « exécutables ».
Problèmatique
La vue des processus décrit l’organisation des composants logiciels au sein de l’environnement d’exécution. Ce sont les composants « exécutables ».
Il s’agit de spécifier, avant la réalisation, ce que seront les exécutables du programme et les dépendances d’exécution.
La vue des processus décrit donc l’organisation des fichiers du type :
• Fichier exécutables
• Librairies dynamiques (dll), applets Java, composants ActiveX
• Fichiers de données
• Table
• Etc.
Les fichiers de données sont utilisés par les fichiers exécutables. Cette utilisation peut être montrée dans le diagramme des composants exécutables.
Certains fichiers sont communs à la vue des sources et à la vue des exé : c’est le cas des fichiers de paramètres ou de données qui sont créés pendant le développement.
Méthode d’organisation des composants « exécutables »
Les interfaces des composants exécutables peuvent être représentées. Ces interfaces définissent le comportement offert à d’autres composants.
Les composants « exécutables » peuvent avoir des relations de dépendances entre eux : ce sont des dépendances d’exécution. Par exemple, un exécutable peut utiliser l’interface d’une
« dll ». Un exécutable peut utiliser un fichier de données ou un fichier de paramètres.
Caractères d’un composant exécutable
• Un composant est un élément physique qui représente une partie implémentée d’un système.
• Un composant réside dans un ou plusieurs nœuds (déploiement).
• Un composant peut réaliser des interfaces.
• En UML, un composant est un classificateur (au même titre qu’une classe). Il peut posséder des attributs et des opérations. Il peut participer à des relations (association, généralisation, dépendance). Une instance de composant est un élément physique concret (un fichier) qui réside sur une instance de nœud (une machine concrète).
• Un composant exécutable implémente certaines classes.
• Dépendance d’exécution entre un composant et l’interface d’un autre composant : elle montre qu’un composant utilise une interface d’un autre composant.
• Dépendance d’exécution entre un composant un autre composant : elle montre qu’un composant utilise les données d’un autre composant. C’est le même principe que le cas précédent, mais considéré de façon plus générale.
• Dépendance de manifestation : un composant exécutable <<manifeste>> un composant source.
Représentation UML Composant
Nom de Composant
Composant stéréotypé
UML définit plusieurs stéréotypes pour les composants de l’implémentation :
<<exe>> pour un fichier exécutable
<<dll>> pour les bibliothèques dynamiques
<<thread>> pour les tâches indépendantes
<<processus>> pour les tâches indépendantes etc.
<<exe>>
main
Interface d’un composant et dépendance d’exécution
<<exe>>
programme principal
<<dll>>
patch01
APIpatch01
Autre dépendance d’exécution
<<exe>>
programme principal
<<fichier>>
param.txt
Concrètement, sous ROSE
• Dans « Component View » on va, selon la complexité du programme :
1. Ou bien créer un diagramme de composants supplémentaire (l’équivalent du main) dans lequel on mettra tous les composants exécutables et leurs dépendances ;
2. Ou bien créer un diagramme de composants supplémentaire par exécutable, dans lesquels on mettra chaque composant exécutable et ses dépendances.
La vue du déploiement
Problématique
La vue du déploiement décrit l’organisation des machines et des composants de la vue des processus sur ces machines (les composants « exécutables »).
Il s’agit de spécifier, avant la réalisation, ce que seront les machines du programme et l’assignation des composants exécutables à ces machines.
La vue du déploiement apporte un niveau de concrétisation supplémentaire par rapport à la vue des processus : les processus peuvent désormais être des instances concrètes (et non plus des abstractions), installées sur une ou N machines qui, elles aussi, peuvent être concrètes.
Méthode d’organisation
Les machines, les processeurs, les mémoires sont appelés : « nœud ».
Les nœuds peuvent être reliés entre eux par des connexions qui correspondent à des chemins de communication entre les processus. Ces connexions peuvent être stéréotypées pour préciser la nature du support de la communication (<<RS232>>, <<RNIS>>, etc.). On peut aussi préciser la multiplicité des connexions et le rôle des nœuds dans la connexion.
Les nœuds physiques hébergent les composants exécutables. Ils sont appelés : « artéfact ».
Précisions sur les noeuds
Un nœud est une ressource matérielle qui, en général, possède de la mémoire et des capacités de calcul.
Un ordinateur, des périphériques ou des ressources humaines sont des nœuds.
En UML, un nœud est un classificateur (au même titre qu’une classe). Il peut posséder des attributs (vitesse du processeur, quantité de mémoire, etc.) et des opérations. Il peut participer à des relations (association, généralisation, dépendance). Une instance de nœud est un élément physique concret (par exemple, un PC particulier).
Sur un nœud résident des composants.
Représentation UML Nœud et instance de nœuds
Nœud PC-37 : PC
Nœud stéréotypé
UML définit plusieurs stéréotypes pour les nœuds :
<<processeur>> pour une machine orientée calcul
<<mémoire>> pour une machine orientée mémoire
<<dispositif>> pour les périphériques
<<modem>> pour un fichier exécutable etc.
Nœud et artéfact
Représentation UML 1 :
Un Noeud
<<exe>>
main
Autre représentation UML 1 :
Nœud
<<exe>>
main Représentation UML 2 :
Un Noeud
<<artefact>>
main
Nœud et connexions
1
1
PC * <<RNIS>> 1 Serveur imprimante
<<exe>>
SGBD
Compléments au diagramme de déploiement et/ou au diagramme des composants En général, un seul diagramme de déploiement suffit pour décrire un système.
Les diagrammes de déploiement permettent de donner une entrée dans le logiciel à partir du programme exécutable.
En cas de reverse engineering (pour de la maintenance ou de la mise à jour), il peut être utile de savoir, pour chaque composant « exécutable » :
• le composant « source » qu’il manifeste
• les classes qu’il implémente
Composant « exécutable » et un composant « source »
On peut montrer quel composant « source » est implémenté par un composant « exécutable ».
Le composant « source » est relié à au composant « exécutable » qui le manifeste par une relation de dépendance stéréotypée « manifest ».
Cette possibilité est intéressante à condition de garder le diagramme de déploiement de base et en faisant un diagramme par nœud, afin de maintenir la lisibilité de l’ensemble.
Composant « exécutable » et classes
On peut montrer quelles classes sont implémentées par un composant « exécutable ».
Les classes sont dessinées dans le composant « exécutable ».
Diagramme d’instances de nœud
On peut aussi montrer les instances des relations entre les nœuds dans des diagrammes d’instances de nœuds.
Concrètement, sous ROSE
• Directement dans le « Deployment Diagram », créer les nœuds correspondant aux différents matériels.
• Préciser la liste des composants exécutables assignés à ce nœud.
• Pour créer une connexion entre deux nœuds, utiliser l’ « icône Connexion » de la barre d’outils.
• Préciser si nécessaire les caractéristiques de la connexion (cardinalité, rôle, etc.).
• Pour assigner une classe à un composant exécutable, il faut ouvrir le menu de spécification du composant, aller dans l’onglet « Realizes », choisir la classe puis sélectionner l’option
« Assign » du menu contextuel (bouton droit).
La vue des cas d’utilisation : la validation
Cette vue correspond au diagramme des cas d’utilisation et à l’analyse fonctionnelle.
C’est la vue qui permet de valider les quatre autres vues en déroulant « à la main » les diagrammes de séquences des différents scénarios, et en vérifiant la cohérence des quatre autres vues pour chacun des scénarios.
La vue logique
La vue logique est constituée par les classes et les paquetages.
L’organisation en paquetage est un élément clé de l’architecture.
Les principaux paquetages apparaissent très tôt dans la phase d’analyse.
La vue logique peut aussi présenter des patterns.
Elle peut aussi s’appuyer sur l’architecture du framework utilisé, s’il y en a un.
Les notions de patterns et de framework sont abordées dans le cours sur les classes.
