[L. DUCROCQ, H. EL GHARBAOUI, B. CHAINANE – Fi14]

 

1/ Modélisations des données : MERISE et UML

1) Intérêt de modélisation des données

Le principal intérêt de modéliser les données est de conceptualiser les processus métiers d’un logiciel ou d’un SI. Le fonctionnement de ces processus est alors schématisé et permet aux lecteurs de comprendre facilement et sans connaissances poussées les interactions entres les acteurs et les fonctionnalités du système. On procède alors à un découpage en sous-système. Un problème complexe devient alors une somme de petits problèmes plus facile à résoudre.

2) Comparatif Merise et UML

    Dans cette partie nous allons décrire les deux outils. Dans un premier temps : MERISE, puis UML.

MERISE est une méthode d’analyse et de conception utilisée dans les projets informatique. Elle a été créée par un Français dans les années 70-80. On l’utilise dans les projets complexes et de grandes ampleurs, mais aussi pour modéliser les SGBD relationnelles.

MERISE va décrire le schéma de données, la persistance. Il s’agit des données sauvegardées en base de données lorsque le système n’est plus en marche. De son côté, UML est plus un “langage” de diagramme Objet. On représente les objets métiers et les traitements (méthodes) associés.

MERISE possède deux modèles :

• Données (données enregistrées en base de données)

• Traitements (traitements fait sur les données, calculs, …)

• Flux (échange des flux (messages) entre acteurs internes et externes et le système étudié)

On retrouve trois modèle dans le modèle de données :

• MCD (adstrait) : Modèle Conceptuel de Données

• MLD : Modèle Logique de Données

• MPD : Modèle Physique de Données : ensemble de script SQL qui automatise la génération de la base de données

Le modèle de traitement de MERISE n’étant plus utilisé dans le monde de l’entreprise, on ne le décrira pas ici. Nous allons détailler la partie “données”.

Modèle de flux

Le modèle de flux représente les échanges d’informations entre les acteurs (qu’ils soient internes ou externes) et le système étudié. Ainsi on peut avoir un fichier en entrée d’une fonction d’importation et un fichier de sortie pour une fonction d’exctration. Les fichiers seront les flux. Il n’y a pas de représentation des actions dans le temps. On sait juste qu’à un moment un fichier peut être importé ou exporté, ni de description et activité de ces flux. De manière générale le diagramme représente le système et les acteurs avec qui il échange des informations.

Prenons l’exemple d’un document type “specifications techniques”. Mettons nous dans la position du sytème d’information. Nous allons envoyer le document au client pour validation. Le client nous le retourne avec des remarques, après modification, le document retourne au client pour validation définitive. On aura donc un acteur externe qui sera le client, et trois flèches allant du client au système. Ces flèches représentent les échanges de flux (ici une sepcification) entre le client et le système.

MCD : Modèle Conceptuel de donnée

Le MCD est aussi appelé modèle entité-relation. Le modèle ER (entity relationship) est l’équivalent international du MCD. MERISE est très connue en Europe mais le modèle ER est préféré ailleurs.

Dans les modèles MERISE, on retrouve les entités (ou objet métier) du système. Ces objets sont représentés par des rectangles divisés en deux parties. La partie haute indique le nom de l’entité, et la partie basse ses attributs ou caractéristiques.

On donne un exemple ci-dessous d’une voiture possédant des roues, un volant et une plaque d’immatriculation et une Personne.

        

Chaque entités possède un identifiant unique qui permet de les distinguer entre elles. Ces identifiants sont soulignés.

Les interactions entre entités sont représentés par des “relations”. Elle par un cercle complété avec le nom de la relation :

Les chiffres de part et d’autre des entités indiquent la cardinalité. On pourra alors lire : une personne est propriétaire d’aucune ou plusieurs voitures. Inversement, la voiture n’a aucun propriétaire ou n’en a qu’un seul.

Dans le modèle ER, on retrouve les entités (non décrite par leurs attributs), et les relations qui lie les entités aux autres. Les relations sont nommées dans un losange et non un cercle comme ci après :

MLD : Modèle Logique de Données

Le MLD est moins conceptuel. Il correspond exactement au schéma de la base de données. On peut directement le traduire en SQL.

Généralement on reprend le MCD. Les entités deviennent des tables. Les relations se transforment différemment en fonction des cardinalités et du nombre d’entités qu’elles relient.

• • Pour les relations (1,1 et 0,1) les tables “échangent” les identifiants (voir diagramme suivants)

  • Pour les relations de type (1, n), il s’agit alors d’une collection d’identifiants

  • Pour les relations (N, N) l’association se fait grâce à une table d’association

  

UML

Les diagrammes UML sont utilisés pour décrire les traitements et les données d’un système. Le diagramme d’état explique les différents états d’un objet (données), le diagramme de séquence mettra en évidence les enchaînements et communications entre les classes et les objets du système (traitements). Les diagrammes de classes sont appréciés par les développeurs qui peuvent baser l’architecture du programme sur ce diagramme. Il est semblable au MCD. Chaque entité est une classe. On y retrouve le nom des relations ainsi que les cardinalités. On y retrouve aussi les attributs qui caractérisent l’objet.

On voit ci dessous le diagramme de classe (UML) de l’exemple précédant.

Nous avons vu que MERISE, avec le MCD et le MLD, était un outil très puissant pour modéliser les données. UML de son côté propose une multitude de diagramme permettant de modéliser les données et les traitements. Quels diagramme choisir ? UML ou MERISE ? Nous répondrons dans les parties suivantes quels sont les outils utilisés pour réaliser les diagrammes et surtout est ce que ce sont des méthodes de modélisation efficace ou non.

2/ Modélisation des données en utilisant l’UML

1) Comment les outils de modélisation traitent la modélisation des données?

Nous nous sommes intéressés aux outils, utilisés principalement par les entreprises, pour faire de la modélisation de données.

Pour la modélisation UML, l’ensemble de ces outils fournissent des assistants de modélisation intelligent, généralement représentés en barres d’outils qu’on peut facilement utiliser en faisant de simples “drag and drop”.

L’outil utilisé dans l’illustration est Modeliosoft:
Grâce à ces outils, les analystes métiers peuvent commencer la modélisation de données pendant leur analyse. Il peuvent ainsi intégrer leur travail aux autres activités de modélisation métier (Business Process Management, architecture…). Parallèlement, ils peuvent utiliser la modélisation UML ainsi que le Business Process Management et Notation (qui représente une notation graphique standardisée pour modéliser des procédures d’entreprise ou des processus métier).

L’outil peut également transformer les modèles en diagramme de classe pour des raisons de persistance.

Une des fonctionnalités les plus intéressantes que nous avons pu répertorier lors de notre étude est la possibilité de retransformer le modèle précédent en diagramme de table SQL, permettant ainsi aux développeurs de travailler sur ce modèle physique et de générer des schémas SQL. Ainsi les classes se transforment en tables, les attributs en champs, les objets en instances et les associations en relations entre tables.

2) Modélisation de données relationnelles

Grâce aux diagrammes UML et aux diagrammes destinés à la modélisation de données, les outils existants sur le marché fournissent aux concepteurs le niveau d’abstraction ou de précision nécessaire à la génération des schémas de données.

La synchronisation est faite sur les différents niveaux de modèles, afin de garantir leur cohérence permanente. Des contrôles de cohérence dédiés vérifient que le modèle est correct pour la modélisation de données.

L’illustration suivante montre la répercution des changements au niveau du diagramme de classe sur le MLD

    3) Reverse engineering

Le reverse engineering est souvent utilisé par les entreprises pour garantir que le code et l’architecture UML soient constamment à jour. En effet, l’outil UML se base sur le code source pour délivrer le modèle de données et le diagramme UML. Cependant cette méthode présente certaines difficultés:

• Le code source a souvent des informations beaucoup plus détaillées que l’on voudrait voir dans les schémas de conception. Ce problème est résolu par la reconstruction de l’architecture logicielle.

• Il existe certaines particularités linguistiques à chaque langage informatique qui sont parfois difficile à convertir automatiquement dans le diagramme UML

Toutefois, cette méthode permet aux analystes de comprendre les schémas de bases de données, et aide à moderniser le système d’information actuel en inversant ces schémas, fournissant ainsi une modélisation et une abstraction de haut niveau pour l’analyse métier. Du code on peut retrouver le diagramme de classe, et à partir du diagramme de classe on peut alors retrouver le MLD, et donc le schéma de la base de donnée.

    4) Framework Hibernate et mapping objet-relationnel

La tendance actuelle est à l’utilisation du langage-objet et d’une base de données relationnelle.

Le concept du mapping objet relationnel vient résoudre les problèmes de cohabitation entre les mondes objets et relationnels. En effet celui-ci vient transformer les modèles objets en modèles relationnels.

a) Qu’est ce que l’Object Relational Mapping?

Le mapping objet relationnel peut être définit comme étant une technique de programmation permettant de faire correspondre des données entre les systèmes de types incompatibles dans les bases de données relationnelles et les langages de programmation orientés objet. Cela créé une « base de données d’objet virtuelle » (correspondante à la base de données réelle associée) qui peut être utilisée dans le langage de programmation.

Ainsi, l’objectif principal de l’ORM est de modéliser une couche de données avec un modèle entièrement objet. Ceci implique de gérer les concepts d’héritage et autres relations complexes.

Cette méthodologie permet une plus grande souplesse de modification du modèle et de la base de données, les modifications du modèle étant répercutées automatiquement sur la base de données de façon transparente pour le programmeur.

Le code généré doit refléter à l’identique l’architecture modélisée. Chaque classe du modèle trouvera son équivalent dans la couche générée, grâce à une classe métier persistante, et si une classe hérite d’une autre, les objets de la couche d’accès devront eux-mêmes hériter l’un de l’autre.

b) Du modèle objet au modèle relationnel

Comme expliqué précédemment, pour mettre en évidence la correspondance entre le modèle objet et le modèle relationnel, on utilise souvent le diagramme de classe qui est le diagramme le plus utilisé en UML. Ainsi, l’entité principale dans le monde de l’objet, la classe, sera transformée en une table, à laquelle on pourra donner le même nom que la classe. De la même manière qu’une classe est composée de plusieurs attributs, la table est composée de plusieurs champs, tous typés. A son tour, l’instance d’une classe particulière correspondra à un enregistrement de la table correspondante.

c) Data Access Object

Peu importe le système sur le lequel se fait le développement, on pourra toujours accéder à nos données relationnelles. En utilisant des API, nous pouvons exécuter des requêtes SQL ou obtenir des objets représentant les tables et leurs champs. Cependant, ce système n’est pas suffisant pour faire des opérations plus complexe. Par exemple, afin de supprimer des clients nous serions obligé de les supprimer manuellement un par un en saisissant leurs adresses alors que cela peut être fait automatiquement. Pour cela il existe des couches d’accès aux données chargées de communiquer avec le serveur de base de données, c’est ce que l’on appelle les DAO. Ils sont créés pour simplifier le travail du programmeur avec le système de base de données en encapsulant les accès à la base via les Frameworks tels que Hibernate. Les programmeurs utilisent par exemple une méthode Save() pour sauvegarder une entité. Cette méthode créera une requête SQL d’insertion ou de mise à jour si nécessaire. On peut également imaginer que les DAO nous permettent d’accéder à des entités qui sont en relation, effectuant les jointures en base de données automatiquement.

d) Hibernate

Il s’agit d’un framework open source générant la persistance des objets en base de données relationnelle. Il permet ainsi de développer des classes persistantes en suivant les principes de programmation orientée objet, en incluant les associations, héritages, polymorphismes, compositions et collections. Hibernate permet également d’interroger les bases de données avec son propre langage portable d’interrogation HQL (Hibernate Query Language), comme du SQL natif ou avec des objets Criteria (Object-Oriented Criteria).

3/ Est-ce efficace?

Avant de traiter des avantages et limites de l’outil UML dans la modélisation de données, il parait important de catégoriser les projets concernés. En effet la dimension de ces derniers traduit des différences dans l’efficacité de l’utilisation d’UML.

1) Les grands projets

a) Avantages

L’un des principaux atouts de la modélisation UML de donnée tient du fait que celle ci  facilite la compréhension de représentations abstraites complexes. En effet dans le cas de grands projets,  des interlocuteurs de différents niveaux techniques sont amenés  à se côtoyer afin de travailler dessus. Ainsi la modélisation objet des projets, permet de discuter avec des collaborateurs mais aussi des clients sur des thermes qu’ils sont plus à même de comprendre.

Dans le même esprit, une autre utilité d’UML est l’universalité de son langage. Aussi bien les compositions, que les relations entre objets peuvent être comprises par quelque personne que ce soit connaissant le langage UML. Il est important de noter que la plupart des grands projets font appel à une palette de compétences, mais aussi parfois de collaborateurs étrangers ou simple interlocuteur au faible niveau technique. Dans ce cadre ci, l’universalité du langage UML devient un atout prépondérant. Elle contribue donc à chasser les ambiguïtés liées à une mauvaise communication dont les conséquences peuvent vite s’avérer désastreuses dans des projets de grande envergure.

Un autre intérêt de la modélisation de donnée par l’utilisation de diagramme UML s’explique par la procuration d’une vue d’ensemble sur le projet. La prise de recul sur le projet devient beaucoup plus facile et rapide que si les spécifications étaient écrites sur plusieurs paragraphes. Lors d’un changement apporté sur celui-ci, les conséquences peuvent également directement se voir au travers du diagramme.

Enfin, nous noterons l’évolutivité de cette méthode, dans un premier temps du point de vue contenue, puisque grâce à cette spécification, il devient plus simple de rajouter ou enlever des éléments au projet (comme par exemple une classe JAVA).

Dans un second temps des mises à jour de la spécification UML sont publiées au travers de versions (la dernière en date V 2.4.1 est paru en 2011) ce qui lui permet de s’adapter aux changements constants d’environnements dans lesquels celle-ci est utilisée.

b) Limites

Comme tout système, la modélisation de données sous forme de diagramme UML possède ses limites, à commencer par son niveau de difficulté. En effet l’intégration d’UML à un projet n’est pas triviale. Celle-ci demande des compétences qu’il faut savoir appliquer rigoureusement sans quoi elle n’a plus d’utilité. La mise en pratique d’UML nécessite un apprentissage et passe par une période d’adaptation.

A cela s’ajoute le fait qu’aucune vue dynamique ne peut être représenté puisque qu’un diagramme UML correspond à une photo du projet prise à un instant précis. Le modèle reste donc statique et ne peut être source d’information évolutive.

Pour les plus gros projets, le modèle UML devient vite incompréhensible puisque dans le diagramme s’entrecoupent rectangle et relations de toute part. Sans un oeil expert et avisé, la compréhension du diagramme n’en est que plus laborieuse.

2) Les petits projets

A ) Avantages

Dans certains cas d’utilisation, le principe d’UML est d’expliquer les tâches qui devront être réalisées dans le cadre du projet. La mise en place de ce dernier n’en devient que plus sûre et plus simple. Cette idée peut s’illustrer par l’implémentation de code JAVA dans le cadre d’un petit projet informatique. Ainsi le développeur en charge de la réalisation pourra, grâce au diagramme UML, suivre une ligne conductrice lors de son implémentation. Cette idée s’applique également à une équipe de réalisation dont chaque membre possédera, dans ce cas, la même vue des tâches à réaliser et du rendu final.

L’orientation utilisateur du formalisme en question est  un autre avantage non négligeable. En plus de définir les services accessibles (offerts) aux utilisateurs, celui ci constitue un support du dialogue concepteurs / utilisateurs non négligeable offrant ainsi une plus rapide et plus efficace collaboration et validation par les utilisateurs.

Contrairement à d’autres types de modélisations de données, l’UML à pour avantage d’être indépendant des technologies ce qui lui assure une portabilité et une longévité. Même si certains logiciels sont créés pour mettre en place de tels diagrammes, il reste aisément possible d’en créer un de manière manuscrite.

B) Limites

Pour les plus petits projets, il faut savoir que la modélisation UML est chronophage, elle prend du temps à être réalisée et bien qu’elle facilite la compréhension, il peut s’avérer plus rapide et productif de ne pas en réaliser. Dans ce cas ci la modélisation fait perdre plus de temps qu’elle n’en fait gagner.

3) Synthèse

Comme elle a été présentée lors des parties précédentes, la modélisation de données en diagramme UML doit être utilisé à bon escient, il faut trouver un juste milieu. Il faut bien entendu s’adapter à chaque projet tout en ayant conscience qu’un diagramme UML ne peut tout afficher. Il faut par conséquent ne pas tomber dans le piège de trop s’appuyer dessus.

Le formalisme UML n’ a donc de réelle efficacité qu’à condition de faire quelques concessions et surtout de bien l’utiliser. Une mauvaise construction peut avoir de graves conséquences sur les plus grands projets.

Il est important de savoir qu’il n’est pas possible de tout voir sur un diagramme UML, néanmoins, celui ci permet d’aider les interlocuteurs qui l’utilise dans leur travail.

Enfin, après confrontation des avantages et limites de la modélisation UML, nous retiendrons sa réelle efficacité comme en témoigne sa standardisation et certification. En effet le succès initial de ce langage a contribué à son utilisation dans le milieu professionnel que l’on retrouve de plus en plus fréquemment. La certification, elle, témoigne de l’importance qu’accordent les entreprises au modèle en question. La certification UML existante porte le nom de OCUP (OMG Certified UML Professional) et recouvre trois niveaux successifs de maîtrise.

Sources :

Transparents du cours UV CASI

http://www.modeliosoft.com/fr/products/solutions/presentation-sql-solution.html

http://www.mti.epita.fr/blogs/2008/06/13/hibernate-ou-le-mapping-orm-en-java/

http://fr.wikipedia.org/wiki/Hibernate

http://laurent-piechocki.developpez.com/uml/tutoriel/lp/cours/#LI-C-1

http://www.commentcamarche.net/forum/affich-5037709-avantage-de-uml