Génération d’un modèle orienté objet (MOO) à partir d’un MCD

Dans ce tutoriel vous apprendrez à générer un modèle orienté objet (MOO) à partir d’un modèle conceptuel de données (MCD) et à adapter son diagramme de classe sur SAP PowerDesigner.

Version : PowerDesigner 16.6
Application : SAP PowerDesigner
Pré-requis : compte utilisateur avec les permissions nécessaires, avoir crée un MCD en notation Merise et connaître les principes des associations et de l’héritage.

Contexte : le modèle conceptuel de données (MCD) est une représentation abstraite des données de votre système d’information fondée sur le modèle entité – association, avec une représentation par lien de l’héritage dans le cas de la notation Merise. Le modèle orienté objet (MOO) quand à lui est une représentation abstraite du fonctionnement des programmes agissant sur ces données, il est constitué de classes équivalentes aux classes du paradigme de programmation orientée objet ainsi que de diverses interactions possibles entre ces classes : association, composition, agrégation, généralisation.. Les objets manipulés par le programme modélisé sont des instances de ces classes abstraites.

Voici le modèle conceptuel de données en notation Merise que nous allons utiliser. Dans un premier temps vous allez vérifier ce modèle avant de l’utiliser pour générer un modèle orienté objet

Réglez la validation de votre MCD en décochant les options permettant d’avertir si une entité ne possède pas d’identifiant ou de lien d’association. En effet trois entités abstraites sont présentes dans le modèle qui ne sont reliées à d’autres entités que par des relations d’héritage : l’entité PERSONNE dont héritent FABRICANT, EMPLOYE et CLIENT; l’entité CONTACT_ENTREPRISE dont héritent CLIENT et FABRICANT; l’entité CONTRAT dont héritent COMMANDE_PRODUIT et FACTURE. Les entités CLIENT et FABRICANT héritent donc de deux entités différentes, cet héritage multiple va nous permettre à la fin de ce tutoriel de tester sa prise en charge lors du choix du langage de modèle orienté objet. En effet si le langage C++ prend en compte l’héritage multiple, Java le refuse.

La vérification du MCD nous averti que les identifiants primaires sont redéfinis dans les entités filles par rapport à leur entité parente. Il nous informe aussi de l’héritage multiple présent dans notre modèle conceptuel :

Pour générer le modèle orienté objet (MOO) à partir de notre MCD, allez dans Outils puis choisissez « Générer un modèle orienté objet » :

Dans l’onglet général des options de génération choisissez de générer un nouveau modèle orienté objet (MOO) dont vous entrez le nom. Ce modèle sera basé sur le langage C++ :

Dans l’onglet Détails des options de génération choisissez de ne pas vérifier le modèle car nous l’avons déjà fait :

Voici le MOO tel qu’il apparaît juste après sa génération automatique depuis notre MCD par PowerDesigner, dans l’explorateur d’objets vous pouvez voir le modèle cible MOO_Ventes de la génération avec le déroulé de ses constituants :

Regardez les composants disponibles dans la boîte à outils. Les entités de notre MCD sont devenues des classes dans notre MOO. A partir des relations d’héritage dans notre MCD des liens de généralisation ont été générés dans notre MOO, la classe dont les classes filles héritent est appelée superclasse. D’autres part les associations qui étaient présentes dans le MCD en notation Merise ont été transformées en classes (classe Ligne_Produit par exemple). Nous allons devoir supprimer certaines de ces classes (Est_Composé par exemple) pour les remplacer par des composants typiques d’un diagramme de classe.

Il existe en effet dans la boite à outils du MOO des composants relationnels qui n’étaient pas disponibles dans le MCD et n’ont donc pas été générés comme les agrégations et compositions. Nous allons donc devoir les générer à la main pour remplacer certaines associations issues du MCD en notation Merise.

Une agrégation est une forme d’association qui définit une relation tout-partie entre une classe composant et une classe agrégat. L’agrégation est représentée par un trait reliant les deux classes et dont l’origine (la classe agrégat) se distingue de l’autre extrémité (la classe subordonnée) par un losange vide.

Une composition est une forme d’agrégation dans laquelle la notion de propriété et la coïncidence sont fortes entre les parties et le tout : les cycle de vie de la classe composant est lié à celui de la classe agrégat, la classe composée est ainsi détruite lorsque la classe mère disparaît. L’origine de cette association est représentée par un losange plein.

Dans notre modèle la classe « Composant » contient des objets instances correspondant à des types de composants (exemple : Tournevis) et non des composants en particulier (Tournevis numéro X), lorsqu’une instance de la classe PRODUIT disparaît les instances de la classe COMPOSANT qu’elle contient ne disparaissent pas. Nous allons donc utiliser un lien d’agrégation depuis la classe Produit vers la classe COMPOSANT, plutôt qu’un lien de composition.

Cliquez puis déposez donc un lien d’agrégation depuis PRODUIT vers COMPOSANT (losange côté PRODUIT) puis double cliquez dessus pour paramétrer ses propriétés. Dans l’onglet Général donnez lui un nom et spécifiez qu’il s’agit d’une agrégation :

Dans l’onglet Détail spécifiez le type de visibilité (private, nous y reviendrons concernant les attributs) et les cardinalités : un type de composants peut être compris dans 0 à n produits et un produit contient de 1 à n composants :

Les associations issues du MCD en notation Merise depuis COMMANDE_PRODUIT et FACTURE vers PRODUIT en passant par les classes générées Ligne_Produit et Ligne_Facture seront remplacées par un double lien d’agrégation : chaque instance de FACTURE contient 1 à n instances de LIGNE_FACTURE qui contient une instance de PRODUIT avec indication de la quantité de cette instance.

Dans le cas des liens depuis LIGNE_FACTURE et LIGNE_COMMANDE vers PRODUIT une agrégation suffira car de même que les instances de COMPOSANT, les instances de PRODUIT identifient des types de produit et non des produit en particulier :

En revanche si une commande ou une facture disparaît, toutes les lignes de commande ou de facture contenues sont détruites, dans ce cas la composition sera nécessaire :

Il faut maintenant que votre MOO respecte les bonnes pratiques de la programmation orientée objet. Pour celà vous devez encapsuler vos attributs dans les classes qui les contiennent en spécifiant qu’ils sont « Private » c’est à dire accessibles seulement depuis l’intérieur de la classe, ce que ne fait pas par défaut la génération du MOO depuis votre MCD .. Les attributs générés sont en effet « public » c’est à dire visible. Allez dans les propriétés de chaque classe, dans l’onglet Attributs puis sélectionnez tous vos attributs et passez leur visibilité à « private » :

Les attributs passés en « private » n’apparaissent plus avec un préfixe + (visibilité « public ») mais avec un préfixe – :

Il existe un troisième type de visibilité qui peut être exploité dans le cas de l’héritage : un attribut « protected » est visible seulement depuis l’intérieur d’une classe et de toutes les classes héritant d’elle. Une fois vos attributs mis en « private » allez dans les options du modèle vérifier que les nouveaux attributs que vous allez créer seront par défaut déjà en « private ». Remarquez que les paramétrages disponibles dans les options d’un modèle orienté objet (MOO) ont complêtement changé par rapport à celles disponibles dans un modèle conceptuel de données (MCD) :

Vous devez ensuite ajouter à vos classes des opérations (aussi appelées « méthodes ») qui permettent d’agir sur les objets instances de vos classes, allez pour celà dans les propriétés de vos classes dans l’onglet Opérations. Comme pour les attributs de classes vous devez décider de la visibilité des opérations d’une classe :

Vous devez ensuite ajouter un constructeur et un destructeur à vos classes, qui sont des méthodes qui vous permettront d’instancier une classe, c’est à dire créer un objet à partir de celle – ci puis ensuite le détruire. Si la classe est origine d’un lien de composition vers une autre classe, les objets contenus seront automatiquement détruits lorsque leur contenant disparaîtra par appel du destructeur de la classe cible.

Pour créer le constructeur/destructeur allez de nouveau dans l’onglet Opération puis cliquez sur l’icône de construction :

Une opération de construction et une autre de destruction sont alors automatiquement ajoutées :

Voici le MOO obtenu à partir du MOO post génération depuis MCD, après transformation d’associations en agrégation et composition, spécification « private » des attributs de classe et ajout d’opération de manipulation, création et destruction des objets instances des classes COMMANDE_PRODUIT et COMPOSANT :

Ce modèle nécessiterait encore quelques ajustements, mais vous pouvez déjà le vérifier en laissant toutes les options de vérification par défaut :

Les seuls avertissements reçus vous informent qu’ils manque des noms de rôle dans certaines associations, c’est à dire les noms assignés à chacune des branches d’une association entre deux classes. Allez par exemple dans les propriétés de l’association Employe_Commande pour ajouter ces noms de rôle :

Allez maintenant dans les conditions de vérification de votre MOO, dans la section « Généralisation » qui concerne les relations d’héritage. Aucune condition n’apparaît générant un signalement d’erreur concernant l’héritage multiple présent dans votre MOO, en effet celui – ci a été généré appuyé sur le langage C++ qui accepte l’héritage multiple :

Générer de nouveau un MOO à partir de votre MCD en notation Merise, mais cette fois – ci choisissez de l’appuyer sur le langage Java :

Puis vérifiez votre nouveau MOO Java avec toutes les conditions de vérification par défaut, voilà ce que vous obtenez :

4 erreurs sont signalées, chacune correspondant à une des 4 associations de généralisation générés dans votre MOO depuis les relations d’héritage présentes dans le MCD Merise source. Allez maintenant dans les conditions de vérification de votre MOO, dans l’onglet Généralisation :

Cette fois – ci une condition déclenchant un signalement d’erreur lors de la vérification du MOO est présent.. Celà reflète le fait que contrairement au C++, Java est plus restrictif et n’accepte pas l’héritage multiple. Si vous voulez utiliser votre MOO Java vous devrez réorganiser ses classes et associations de généralisation.

Vous savez maintenant comment générer le diagramme de classe d’un modèle orienté objet (MOO) à partir d’un modèle conceptuel de données (MCD).