La modélisation objet avec

 

A propos de cette page 

Introduction à UML v1.0

Pourquoi utiliser UML ?

Modélisation des données : Diagramme de classe

Note
Classe
Visibilité
Associations
Cardinalités
Contraintes
Les éléments dérivés
Généralisation et héritage

Comparaison des méthodes de modélisation de donnée

Points communs




A propos de cette page

Cette page est dédiée à la modélisation objet et plus particulièrement UML. Elle est actuellement en construction (i.e. de nombreuses informations devraient être ajouter dans les prochains mois) et tous les commentaires visant à l'améliorer seront appréciés. De même, tous les documents (fichiers, liens, références ...) complémentaires sur le sujet sont les bienvenus.

Pour tout renseignement complémentaire, me contacter à ronaldfr@hotmail.com.

Introduction à UML v1.0

Pourquoi utiliser UML ?

Alors que je cherchais de la documentation sur OMT à travers Internet, j'ai abouti à un site qui présentait la méthode UML. Voici une traduction d'extraits du document "UML Summary" qui explique pourquoi utiliser UML :

Booch, Rumbaugh, and Jacobson ont joint leurs forces :

Le développement d'UML a commencé en octobre 1994 quand Grady Booch et Jim Rumbaugh de Rational Software Corporation ont débuté leur travail sur l'unification des méthodes Booch et OMT (Object Modeling Technique). Étant donné que les méthodes Booch et OMT se développait déjà indépendamment l'une de l'autre et étaient mondialement reconnues comme les principales méthodes orienté objet, Booch and Rumbaugh ont joint leurs forces pour réaliser une unification complète de leurs méthodes.

Il faut que ce soit clair, Unified Modeling Language n'est pas un éloignement radical des méthodes Booch, OMT, ou OOSE, mais plutôt le successeur légitime de ceux-ci. Cela signifie que si aujourd'hui vous utilisez Booch, OMT, ou OOSE, votre formation, votre expérience et vos outils seront préservés, car UML est une étape d'évolution naturelle.

UML est plus expressif, plus propre et plus uniforme que Booch, OMT, OOSE, et les autres méthodes. Cela signifie qu'il y a un bénéfice à passer à UML, parce qu'elle permettra aux projets de modéliser des choses qui n'auraient pas pu l'être avant. Les utilisateurs de la plupart des autres méthodes et langages de modélisation auront avantage à utiliser UML, puisqu'elle supprime toutes les différences non nécessaires de notation et de terminologie qui obscurcissent les similarités de bases de ces différentes approches.

Ces extraits ainsi que les documents que j'ai utilisé pour écrire la suite de cet présentation, ont été télécharger (au format Adobe Acrobat) à partir du site Internet de Rational Software Corporation.

Les documents utilisés sont les suivant :

UML Summary (version 1.0, 13 January 1997)

UML Notation Guide (version 1.0, 13 January 1997)

Ils peuvent être télécharger à l'adresse suivante : http://www.rational.com/uml

Modélisation des données : Diagramme de classe

Dans cette partie je vais présenter les notations de bases de la méthodes UML, en considérant que le lecteur est déjà familier avec d'autres méthodes orienté objet (OMT, ...).

Note

Une note est un commentaire placé sur un diagramme. Elle est attachée au diagramme plutôt qu'à un élément du modèle (à moins qu'elle ne soit stéréotypée pour être une contrainte).

Exemple :

Classe

Une classe est le descripteur d'un ensemble d'objets qui ont une structure, un comportement et des relations similaires.

Voici les différentes notations graphiques d'un classe, en fonction du niveau de détail exigé :

Exemple :

Visibilité

Un attribut (ou une opération) est représenté par une chaîne de caractères, qui peut être qualifié par les différentes propriétés d'un attribut d'élément du modèle.

Voici les différents visibilité d'un élément :

+ Public

# Protégé

- Privé

Associations

Les associations binaires sont représentées par des lignes connectant les symboles des classes. Les associations ternaires (et plus) sont représentées par un diamant connecté par des lignes aux symboles des classes.

La terminaison d'une association où elle se connecte à une classe est appelé "rôle d'association". La plupart de l'information intéressante à propos d'une association, est attachée à ses rôles (entre autres, la cardinalité).

Exemple 1


Remarque : ceci n'est pas forcément la meilleur façon de noter la relation entre une voiture et ses roues (voir agrégation / composition - [pas encore écrit])

Exemple 2

Éléments du schéma :

    • Nom d'association : "Travaille pour"
    • Classe d'association : "Travail"
    • Nom des rôles d'association : "Employeur et Employé"

Cardinalités

Exemple de cardinalité

1

0..*

1..*

0..1

2..5

1..3,7..10,15,19..*

Quelques commentaires :

    • Les intervalles doivent être notés en ordre croissant : "1..3,7,10" est préférable à "7,10,1..3".
    • Deux intervalles continus doivent être combinés en un seul intervalle : "0..1" est préférable à "0,1".
    • Les notations suivantes sont équivalentes : "*" , "0..* ", "*..*"

Contraintes

Une contrainte est une relation sémantique entre des éléments du modèle qui spécifie les conditions et les propositions qui doivent être respectées (sinon le système décrit par le modèle est invalide, avec des conséquences qui sont en-dehors des attributions d'UML). Certains types de contrainte (comme une contrainte d'association "ou") sont prédéfinis dans UML, les autres doivent être définis par les utilisateurs.

Une contrainte est représentée par un texte entre crochets ( {} ). UML ne prescrit pas le langage dans lequel la contrainte doit être écrite.

Exemple 1 :

Exemple 2 :

Les éléments dérivés

Un élément dérivé est un élément qui peut être calculé à partir d'un autre, mais qui est montré pour la clarté, ou qui est inclus pour des raisons de conception même si il n'apporte aucune information sémantique.

Notation

Un élément dérivé est représenter en plaçant un `slash` (/) devant le nom de l'élément dérivé, comme un attribut ou un nom de rôle.

Exemple

Généralisation et Héritage

La généralisation est une relation taxinomique (de classification ordonnée) entre un élément plus général, et un élément plus spécifique qui est pleinement consistante avec le premier élément et qui ajoute des informations supplémentaires.

Comparaison des méthodes de modélisation de donnée

Points communs

Avant de montrer les différences qui existent entre les méthodes de modélisation de données, j'ai voulu montré leurs points communs, ce qui servira de base à leurs comparaisons.


Ronald GUÉGAN.

Retour au sommaire


 plusieurs
© 1997, Ronald GUÉGAN.