Claude Belleil Université de Nantes Le langage UML 2.0 Diagramme de Paquetages 1 Introduction En UML, on peut regrouper des éléments en utilisant des paquetages. La plupart des langages orientés objets utilisent un mécanisme analogue aux paquetages UML pour organiser les classes et éviter les conflits de noms. Les paquetages UML peuvent servir à organiser pratiquement n'importe quel élément UML: des classes, des cas d'utilisation, des interfaces, des diagrammes,... et même des paquetages imbriqués. Les éléments contenus dans un paquetage doivent représenter un ensemble fortement cohérent. Ils sont généralement de même nature et de même niveau sémantique. Généralement, il existe un seul paquetage racine qui détient la totalité du modèle d'un système. Les diagrammes de paquetages font partie de la vue de développement, qui s'intéresse à l'organisation des parties du système en modules et paquetages. En général, les AGL UML ne disposent pas d une boîte à outils graphiques dédiée à ces représentations comme c est le cas pour les classes les diagrammes de cas d utilisation et autres. Comme les paquetages sont des structures de regroupement permettant d'organiser pratiquement n'importe quel élément UML, leurs représentations formelles sont souvent réparties dans les différents diagrammes d un AGL. 2 Définition et contenu En UML, un paquetage (package en anglais) est un mécanisme qui permet d organiser des éléments 1
de modélisation en groupes. DAB Figure 1: Exemple de paquetage On peut accéder aux éléments qu il contient grâce aux noms qualifiés. La visibilité d un élément contenu dans un paquetage peut être spécifiée en mettant le signe + (visibilité publique) ou - (visibilité privée) devant le nom de l élément. Lorsque la visibilité n est pas spécifiée, un élément est visible en dehors du paquetage. ============================================================================ «Package 1» Règles de cohérence extraites du document de l OMG «UML2SuperStructure 2» Les éléments contenus dans les paquetages doivent être des PackageableElement [Règle dérivée du méta-modèle] Si un élément contenu dans un paquetage a une visibilité, alors cette visibilité est public ou private. [p.100] ============================================================================ Sur le plan graphique, un paquetage est représenté par un rectangle avec un onglet sur le bord supérieur gauche dans lequel se trouve le nom du paquetage. Il peut regrouper différents éléments UML, qui peuvent être représentés à l'intérieur du paquetage ou à l'extérieur reliées par une ligne. Dans l exemple ci-dessous, le paquetage «DAB» regroupe les classes «Lecteur de carte» et «Ecran» DAB Lecteur de carte Ecran Figure 2: Un paquetage contenant deux classes Actuellement, certains AGL 3 UML ne prennent pas en charge la notation de la figure ci-dessous. 1 Les paragraphes avec ce style (Courier New 8) sont des traductions d extraits du document officiel de définition du langage UML 2 dont vous trouverez la référence web ci-dessous. 2 http://www.omg.org/technology/documents/formal/uml.htm 3 StarUml! 2
Cependant, pratiquement tous les outils peuvent montrer l'appartenance d'une classe à un paquetage en employant l'une des deux notations DAB Lecteur de carte Ecran Figure 3: Un paquetage contenant deux classes (autre notation) Dans ce langage UML, comme dans certain langage de développement, le mot clé <<package>> placé au début d'une classe spécifie qu'elle se trouve dans le paquetage ainsi nommé. Pour indiquer le paquetage auquel appartient une classe, la plupart des outils UML permettent de faire précéder le nom de la classe du nom du paquetage auquel elle appartient. DAB::Lecteur de carte DAB::Ecran Figure 4: Deux classes préfixées du nom de leur paquetage Certains paquetages occupent parfois un espace important et si on souhaite montrer les classes incluses, ces paquetages conteneurs verront leur taille augmenter en conséquence. Pour pallier cette difficulté, il existe une autre notation plus simple à manipuler. On peut «aplatir» les paquetages imbriqués et les écrire sous la forme paquetagea::paquetage8::paquetagec Recherche Indexation Figure 5: Exemple d'emboîtement de paquetages 3
3 Espace de noms Le regroupement des classes en paquetages implique un travail rigoureux d organisation. Par exemple, pour utiliser une ArrayList dans un programme java, on doit indiquer que la classe ArrayList se trouve dans le paquetage java.util. En effet, les paquetages Java définissent leurs propres espaces de noms, ou contextes de nommage. Si un élément ne se trouve pas dans l'espace de noms courant, il faut indiquer son emplacement. De façon identique, un paquetage UML définit un espace de noms. Si un élément d'un paquetage veut utiliser un élément d'un autre paquetage, il est nécessaire de préciser où il se trouve. Pour indiquer le contexte d'un élément UML, on doit fournir le nom complet qui inclut le nom du paquetage et le nom de l'élément séparés par deux caractères deux-points, comme dans nomdepaquetage::nomdeclasse. Ainsi, si deux classes de même nom se trouvent dans des paquetages différents, leur nom complet permet de les distinguer. En revanche, dans un même espace de noms, chaque élément doit avoir un nom unique. Les classes du même paquetage font partie du même espace de noms. Elles peuvent faire référence les unes aux autres sans employer les noms complets. En UML, les éléments d'un paquetage imbriqué peuvent faire référence aux éléments du paquetage conteneur sans utiliser un nom complet. Cet accès automatique des éléments d'un paquetage imbriqué à ceux des paquetages conteneurs n'est pas disponible dans tous les langages d'implémentation. Par exemple, en java, si une classe du paquetage indexationutilise une classe du paquetage rechercheelle doit fournir une portée en utilisant son nom complet ou en important le paquetage recherche Les éléments d'un paquetage peuvent avoir une visibilité publique ou privée. Ceux ayant une visibilité publique sont accessibles depuis l'extérieur du paquetage. Ceux ayant une visibilité privée ne sont disponibles qu'aux autres éléments du paquetage. En UML, la modélisation de la visibilité se fait à l'aide d'un signe plus (publique) ou moins (privée) placé devant le nom de l'élément, comme pour les classes. 4 Dépendance entre paquetages Une classe d'un paquetage a parfois besoin d'utiliser une classe d'un autre paquetage. Cela crée une dépendance entre les paquetages : si un élément du paquetage A utilise un élément du paquetage B alors le paquetage A dépend du paquetage B A B Figure 6: Dépendance entre deux paquetages Dans le cadre d une modélisation constituée de quelques classes, il n est pas indispensable d'organiser ces classes en paquetages. A l inverse, dès que le système présente un certain volume, les paquetages apportent une structuration permettant de répartir le travail de développement entre différentes équipes. Par exemple, le code concernant l'interface homme-machine (ihm) peut appartenir à un paquetage ihmcelui mettant en oeuvre les fonctionnalités de recherche peut appartenir à un paquetage rechercheet les utilitaires communs peuvent se trouver dans un paquetage utilitaires 4
Ainsi, il est plus facile de retrouver les classes lorsque qu on examine le contenu d une API complexe. Par exemple, pour trouver une boîte de dialogue de l'ihm, on voit qu il est nécessaire de chercher dans le paquetage ihm La plupart du temps, les développeurs travaillent dans leur propres paquetages. Ceux qui développent le contenu du paquetage ihmne modifient pas celui du paquetage rechercheet vice versa. Tout le monde peut utiliser des paquetages communs, comme utilitairesmais ils ne doivent pas être modifiés à la légère car cela aurait un impact sur tous les développements. Outre l'organisation des éléments, les paquetages peuvent remplir d'autres fonctions, comme le contrôle d'accès : il est possible de déclarer des éléments privés à un paquetage afin d'empêcher qu'ils soient utilisés par d'autres paquetages. Recherche Utilitaires Ihm Sécurité Compte Utilisateur Figure 7: Organisation de dépendances multiples Les paquetages peuvent aussi servir à organiser les classes en modules de déploiement. Par exemple, si on souhaite inclure des possibilités de recherche dans certains systèmes et pas dans d'autres, il peut être nécessaire de décider d'inclure ou d'exclure le paquetage recherchedans leur mise en oeuvre. La bonne compréhension des dépendances entre les paquetages est indispensable à l'analyse de la stabilité du système. En réalité, les diagrammes de paquetages d'uml sont le plus souvent employés pour donner une vue d'ensemble des principaux paquetages du logiciel et de leurs dépendances. 5 Accéder et importer Quand un paquetage importe un autre paquetage, les éléments du premier peuvent faire référence aux éléments du second sans utiliser leur nom complet. Cette fonctionnalité est similaire au mécanisme d'importation de java, grâce auquel une classe peut importer un paquetage et utiliser son contenu sans préciser le nom du paquetage. Dans une relation d'importation, le paquetage importé est appelé paquetage cible. Pour représenter cette relation, tracez une flèche de dépendance partant du paquetage initial vers le paquetage cible et marquée du stéréotype import 5
Utilisateur «import» Sécurité Figure 8: Une relation d'importation Un paquetage peut également importer un élément particulier d'un autre paquetage et non son contenu complet. Une fois un paquetage importé, seuls ses éléments publics sont accessibles depuis l'espace de noms du paquetage demandant l'importation. Les éléments ne sont pas les seuls à avoir une visibilité. La relation d'importation peut elle aussi être publique (par défaut) ou privée. L'importation publique (ou privée) signifie que tous les éléments importés ont une visibilité publique (ou privée) au sein de l'espace de noms effectuant l'importation. L'importation privée est représentée par le stéréotype «access». La différence entre «import» et «access» apparaît lorsqu'un paquetage importe un paquetage qui en importe ou accède à d'autres. Puisque les éléments importés ont une visibilité publique dans le paquetage effectuant l'importation, ils suivent les importations successives, contrairement aux éléments accédés. La figure ci-dessous illustre que le paquetage B importe C et accède à D. B voit donc les cléments publics de C et de D. Puisque A importe B, A voit les éléments publics de B. A voit également les éléments publics de C car C est importé publiquement dans B, mais A ne voit pas le contenu de D car D est accédé privativement dans B. A B C «import» «import» «access» D Figure 9: Relations successives "import" et "access" Les relations d'importation et d'accès peuvent être utilisées pour modéliser l'importation de classes dans un espace de noms afin que les éléments de l'espace de noms effectuant l'importation puissent faire référence à ceux de l'espace de noms cible sans employer son nom. Des dépendances complexes entre paquetages peuvent conduire à des modélisations ambiguës. En effet, une seule modification de l'un des paquetages peut provoquer le dysfonctionnement des paquetages dépendants. 6
Si des dépendances présentent des cycles, il existe différentes manières, de les rompre. Aller dans le sens de la stabilité signifie qu'un paquetage doit dépendre uniquement de paquetages plus stables que lui-même. Un paquetage instable dépend de nombreux autres paquetages ; un partage stable dépend de quelques paquetages. L'étude des diagrammes de paquetages peut aider à repérer des problèmes de vulnérabilité de la modélisation provenant du fait que les paquetages au coeur du système (comme ceux contenant les interfaces) dépendent de paquetages instables. 7
Index du texte : 1 Introduction... 1 2 Définition et contenu... 1 3 Espace de noms... 4 4 Dépendance entre paquetages... 4 5 Accéder et importer... 5 Index des figures : Figure 1: Exemple de paquetage... 2 Figure 2: Un paquetage contenant deux classes... 2 Figure 3: Un paquetage contenant deux classes (autre notation)... 3 Figure 4: Deux classes préfixées du nom de leur paquetage... 3 Figure 5: Exemple d'emboîtement de paquetages... 3 Figure 6: Dépendance entre deux paquetages... 4 Figure 7: Organisation de dépendances multiples... 5 Figure 8: Une relation d'importation... 6 Figure 9: Relations successives "import" et "access"... 6 8