Le sous-package PrimitiveTypes

Il contient simplement quelques types primitifs de données prédéfinis qui sont disponibles aussi bien pour UML que pour le MOF et pour toutes les extensions de UML.
La figure 6 montre les métaclasses définies dans ce package. Il faut noter que outre la définition de la structure de ces métaclasses (dans la spécification officielle), les valeurs possibles des instances de ces classes sont aussi précisées de mêmes que les règles relatives à leur syntaxe.

Le sous-package Abstractions

Le package Abstractions contient en majorité des métaclasses abstraites considérées comme étant les plus finement trouvées pour spécifier les concepts qu’elles représentent. Elles sont destinées à la réutilisation par d’autres métamodèles (du package Constructs notamment). Ce package est subdivisé en plusieurs sous packages comme le montre la figure 7.

Le sous-package Basic

Le package Basic de InfrastructureLibrary::Core constitue un langage minimal de modélisation de diagrammes de classes au dessus duquel d’autres langages plus complexes peuvent être construits. Il est destiné à être réutilisé par la couche Essentiel du MOF (EMOF).
Les métaclasses de ce package sont spécifiées à l’aide de quatre diagrammes : Classes, DataTypes, Packages et Types permettant de représenter les métaclasses séparément. Notons de plus que Basic peut être considéré comme une instance de lui-même, ses concepts sont auto-définis. Notons de plus que ces concepts sont plus précisément spécifiés dans le package Constructs qui ajoute de plus la définition du concept d’association entre les classes (relationships).
Le diagramme Classes représente les concepts nécessaires à la définition de classes. Il comprend les métaclasses Class, Operation, Parameter, Property, Type, et TypedElement.
Le diagramme DataTypes représente les métaclasses (DataType, Type, Enumeration, PrimitiveTypes, EnumerationLiteral et NamedElement) pour représenter le concept de type de données.
Le diagramme Packages définit le concept de package pour spécifier les packages et leur contenu. Il comprend ainsi les métaclasses Package, Type et NamedElement.
Le diagramme Types définit des métaclasses abstraites (NamedElement, Type, TypedElement) relatives au nommage et au typage des éléments.

Le sous-package Constructs

Le package Constructs contrairement au package Abstractions, contient pour la plupart des métaclasses concrètes très souvent utilisées en modélisation orientée objet. C’est un package particulièrement utilisé par UML et MOF, et représente une partie significative du travail réalisé pour aligner ces deux métamodèles.
Comme le montre la figure 8, le package Constructs dépend de nombreux autres packages, notamment les packages de Core::Basic, et de Core::Abstractions.

Le package Profiles

Ce package de l’Infrastructure fournit les mécanismes permettant d’étendre les métaclasses des métamodèles existants et de les adapter à différents contextes. Cela permet d’adapter UML à des plates-formes ou domaines particuliers (J2EE ou .Net, real-time ou business process modeling par exemple) par la définition de profils UML.
Le package Profiles dépend du package Core::Constructs. Les classes qui le composent apparaissent sur la figure 9.

Synthèse de UML 2.0 Infrastructure

UML 2.0 Infrastructure représente donc la partie du standard UML 2.0 définie pour servir de base à bien d’autres standards comme le MOF, CWM, etc. Ses nombreuses classes sont regroupées en packages définis de sorte à en assurer une réutilisation facile. Les parties qui suivent décrivent le standard UML 2.0 Superstructure qui utilise fortement l’Infrastructure.

UML 2.0 Superstructure 

Si comme nous l’avons souligné plus haut le standard UML2.0 Infrastructure explique l’architecture de métamodélisation ainsi que l’alignement avec le MOF du standard UML 2.0, UML2.0 Superstructure définit quand à lui la vision utilisateur du langage. Sa définition est basée sur l’Infrastructure et il peut être vu comme un ensemble de trois grandes parties :
La partie Structure définit les concepts utilisés pour la construction de diagrammes statiques comme les diagrammes de classes, de composants, de déploiement, etc.
La partie Behavior contient les concepts nécessaires à la construction des diagrammes dynamiques tels que les diagrammes d’états, de séquence, d’activités, etc.
La partie Supplements définit quant à elle des concepts additionnels comme les types primitifs, les templates, les modèles et les flots de données.
Nous allons essayer de présenter chacune de ces parties dans la suite immédiate de ce document.

La partie Structure

Cette partie est subdivisée en quatre principaux packages interdépendants : Classes, CompositeStructures, Components et Deployments (chacun de ces packages est dépendant de
son précédant dans cette liste).

Le package Classes

Le package Classes contient des sous packages offrant les concepts de base de la modélisation UML et en particulier les classes et leurs relations.
Le sous-package Kernel du package Classes regroupe les concepts centraux de la modélisation UML comme les classes, les associations, et les packages. Cette partie est principalement une réutilisation de l’Infrastructure et nombre des concepts qu’elle définit sont les mêmes que ceux utilisés par le MOF par exemple. Le Kernel est la partie centrale de UML, il merge† le package InfrastructureLibrary::Core::Constructs et certains packages de InfrastructureLibrary::Core::Abstractions comme Generalizations, Literals, MultiplicityExpressions et Instances.
Les sous packages du package Classes sont les suivants : Kernel, AssociationClasses, Dependencies, PowerTypes qui mergent tous le Kernel, et le package Interfaces qui quant à lui merge Dependencies.
– Le sous-package Kernel se compose de plusieurs diagrammes :
Le Root Diagram est pratiquement le même que celui du noyau de Infrastructure::Core::Constructs. Le diagramme des Namespaces comprend les métaclasses Element, NamedElement, PackageableElement, Namespace, NamedElement, DirectedRelationship, ElementImport, PackageImport, et Package.
Le diagramme des Multiplicities comprend les métaclasses Element, MultiplicityElement, ValueSpecification, NamedElement, TypedElement, Type et PackageableElement.

Le package CompositeStructures

Ici le terme “structure” désigne un ensemble d’éléments interconnectés représentant des instances en exécution qui interagissent à travers des liens de communication pour réaliser un objectif commun. Ce package est subdivisé en sous packages comme l’indiquent les lignes qui suivent.
– Le sous-package InternalStructures fournit le mécanisme de spécification des structures d’éléments interconnectés d’un classifier. Ce package merge le sous-package Interface du package Classes et se compose des métaclasses StructuralClassifier, ConnectableElement, Property, Connector, et ConnectorEnd.
– Le sous-package Ports définit le concept de liaison d’un classifier avec son environnement par la définition de «conduits» (ou ports) d’interaction entre l’intérieur d’un classifier et son environnement. Ce package merge les packages Communication du package Classes et InternalStructures et comprend les métaclasses Port, EncapsulatedClassifier et ConnectorEnd.
-Le sous-package Collaborations introduit le concept de collaboration entre objets d’un système. Il merge le package InternalStructures et comporte les métaclasses Collaboration,
Parameter, CollaborationUse et Classifier.
-Le sous-package StructuredClasses permet de définir des classes pouvant disposer de ports de la même manière qu’un internalStructure, il se compose de la seule métaclasse Class.
-Le sous-package Actions définit des actions comme l’envoi de message via un port. Il comprend les métaclasses Trigger et InvocationAction et merge le package Ports.

Le package Components

Le package Components est créé pour permettre la représentation des concepts relatifs à la notion de composants logiciels d’un système. Cette notion est une grande nouveauté dans UML2 Superstructure. Un composant est une unité logicielle modulaire autonome et réutilisable avec des interfaces bien définies qui le caractérisent dans son environnement. La notion d’interface de composant devient alors très importante, et un composant dispose d’interfaces offertes et d’interfaces requises. La structuration interne d’un composant est inconnue de son environnement. Une application à base de composants est composée de composants connectés entre eux.

La partie Behavior

La partie Behavior de UML 2.0 Superstructure contient les concepts nécessaires à la construction des diagrammes dynamiques tels que les diagrammes d’états, de séquence, d’activités, etc. Les packages UML qui supportent la modélisation des aspects liés aux «comportements» dépendent des packages de la partie Structure. Ses packages sont : CommonBehaviors (qui est le package de base et qui dépend du package Classes de la Structure), Activities, Interactions, StateMachines, UseCases (qui dépendent du package de base précédent) et enfin le package Actions (qui dépend du package Activities). Nous décrirons le contenu des ces différents packages dans les parties suivantes du document.

Le package CommonBehaviors

Il spécifie les concepts de bases nécessaires pour la construction de diagrammes dynamiques. Tout behavior (comportement) est la conséquence directe d’une action d’au moins un objet, il décrit l’évolution de l’état de ces objets selon leur structure qui change selon le temps. On distingue deux type de behaviors: les emergent behaviors et les executing behaviors. Ce package est découpé en trois principaux sous-packages: BasicBehaviors qui merge le package Kernel de la Structure, Communications qui merge les packages Interfaces de la Structure et BasicBehaviors, et SimpleTime qui merge le package IntermediateActions de Actions.