• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 03/09/2019

Modélisez le domaine fonctionnel

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Maintenant que vous avez vu les bases de l'approche orientée objet et que vous parlez UML seconde langue ;), nous allons attaquer les choses sérieuses : modéliser le domaine fonctionnel !

Pas de panique, je vais vous guider dans les différentes étapes de cette modélisation, de l'ébauche jusqu'au modèle physique de données final.

Suivant la taille du domaine fonctionnel, il n'est pas envisageable d'obtenir une représentation complète du premier coup. La démarche consiste donc à procéder par itération en dégrossissant et affinant le modèle au fur et à mesure de vos échanges avec les autres membres du projet, notamment le client.

Allons-y !

Commencez par une ébauche

Dans un premier temps, imprégnez-vous du domaine fonctionnel. Repérez les principaux concepts et entités de celui-ci.

Vous commencez à dessiner un premier diagramme de classes à partir de ces éléments, en matérialisant et nommant les classes correspondantes. Vous pouvez placer les attributs principaux, mais n'allez pas trop loin.

L'idée est d'obtenir une représentation générale et macroscopique du domaine servant de support pour commencer à échanger avec votre client.

Diagramme de classes ‒ Ébauche
Diagramme de classes ‒ Ébauche

Il est plus efficace de mener une réflexion en commun avec votre client, en s'appuyant sur cette ébauche en support mais sans qu'elle ne soit trop avancée. Sinon, le risque est double :

  • Vous pouvez avoir passé beaucoup de temps à l'élaboration de ce premier jet et après échange avec le client, vous avez beaucoup de changements à faire. C'est du temps perdu.

  • Votre modélisation est déjà très avancée et le client n'ose pas critiquer (objectivement) votre travail, pour diverses raisons :

    • soit parce qu'il ne veut pas vous le faire refaire (et vous payer en conséquence),

    • soit le diagramme est trop complexe pour qu'il puisse pleinement l'assimiler et le critiquer...

    Le risque direct étant que le modèle ne colle pas à la conception du client et que vous en subissiez les conséquences tout au long du projet (voire de la vie de l'application qui va s'appuyer dessus).

Ne modélisez que ce dont vous avez besoin

Une bonne pratique afin d'avoir des échanges efficaces est de ne représenter que ce qui est utile à l'échange.

En effet, lors des premiers retours de votre client, vous allez vous concentrer sur les classes, leur nom, leurs relations. Inutile de mettre toutes les multiplicités, tous les attributs... ceci encombrerait le diagramme et nuirait à l'objectif : avoir une vision générale du domaine.

Rien ne vous empêche d'avoir plusieurs diagramme de classes, contenant plus ou moins de détail en fonction de l'objectif de ceux-ci.

Vous pouvez par exemple avoir 2 diagrammes :

  • un diagramme avec les classes et les associations (avec les multiplicités nécessaires à la compréhension) permettant d'avoir une vision globale du domaine

  • un diagramme contenant tous les attributs, les types, les multiplicités... donnant la représentation précise des informations manipulées.

Modélisez précisément le domaine

Après discussion avec votre client, les règles s'affinent :

  • Un article peut avoir plusieurs variantes (couleur ou taille...). Le client commande une variante particulière et pas simplement un article.

  • Les factures sont établies à l'expédition. Une commande pouvant faire l'objet de plusieurs expéditions, il peut y avoir plusieurs factures par commande.

  • Un même article peut être assigné dans plusieurs catégories.

  • Le prix des articles peut évoluer entre la prise de commande et l'expédition. Il faut dans ce cas facturer le client au prix en vigueur au moment de la commande.

Voici, ci-dessous, une version affinée du diagramme du domaine où les nouvelles règles sont prises en compte. J'y ai également apposé les multiplicités.

Diagramme de classes ‒ Étape intermédiaire
Diagramme de classes ‒ Étape intermédiaire

Quelques remarques concernant cette version du diagramme :

  • L'association entre les classes Expedition et Facture est de type « un à un ». Il est possible de fusionner les deux classes en une seule. Mais je conserve volontairement les deux classes ici car ce sont 2 notions bien séparées pour le client. De plus, cela permettra dans le temps de « purger » la table des expéditions sans supprimer les informations des factures.

  • L'association entre les classes Commande et Adresse est aussi de type « un à un ». J'envisage de les fusionner en une seule table au moment de la création du MPD. En revanche, je conserverai bien les deux classes dans le code de l'application car cela sera plus clair pour les développeurs.

  • Toujours dans un souci de lever les ambiguïtés, remarquez les noms des attributs :

    • prixUnitaireHT : on sait tout de suite qu'il s'agit d'un prix unitaire hors taxes et non TTC

    • tauxTVA100 : on sait que le taux de TVA utilise le format sur 100 (pourcentage). Ainsi 19,6 % est enregistré 19.6 et pas 0.196. Il ne faudra pas oublier de diviser ce taux par 100 dans les calculs : prixUnitaireTTC = prixUnitaireHT * (100 + tauxTVA100) / 100.

Complétez votre modèle

Une fois la modélisation générale réalisée, vous devez caractériser les attributs en leur donnant un type et éventuellement une multiplicité (pour les attributs pouvant ne pas être renseignés).

Voici le diagramme de classes final contenant toutes ces informations :

Diagramme de classes final
Diagramme de classes final

Les types de données

UML 2.5 fournit 5 types de base standards (appelés « primitive types ») :

  • Boolean : pour les valeurs booléenne (vrai/faux)

  • Integer : pour les entiers relatifs (ensemble ℤ en mathématiques)

  • Real : pour les nombres réels (ensemble ℝ en mathématiques)

  • String : pour les chaînes de caractères (texte)

  • UnlimitedNatural : pour les entiers naturels (ensemble ℕ en mathématiques) et la valeur infinie (∞)

Selon le logiciel que vous allez utiliser ou le langage dans lequel vous aller coder l'application, vous aurez bien d'autres types à disposition (pour les dates, les heures, ...).

La fondation Eclipse par exemple, en fournit un certain nombre avec Ecore Primitive Types (logiciels UMLDesigner, Papyrus...)

Tous ces types supplémentaires ne sont pas standards, mais ce n'est pas très important. La finalité de votre travail étant de concevoir une base de données, c'est au moment de l'élaboration du MPD que vous devrez choisir les types de données adéquats.

Élaborez le modèle physique de données

Vous allez pouvoir maintenant élaborer le MPD à partir du diagramme de classes final. Si vous vous souvenez des remarques que j'ai faites au cours de la modélisation du domaine fonctionnel, vous savez que cela est assez simple, même s'il ne s'agit pas d'une étape totalement triviale de traduction.

Voici comment je vous conseille de procéder :

  1. Commencez par créer une table par classe, hors classe d'association (ex. LigneCommande)

  2. Ajoutez tous les attributs des classes en tant que colonnes dans les tables du MPD. C'est ici que le choix du type de données est important (nous y reviendrons dans la partie 2 de ce cours)

    MPD avec les classes et attributs
    MPD avec les classes et attributs
  3. Ajoutez les clés primaires dans les tables :

    • soit en créant une colonne dédiée créée de toute pièce (ex. : id)

    • soit en utilisant un attribut étant explicitement une référence unique (ex : l'attribut numero dans la classe Facture). J'avais coloré ces attributs en rouge dans le diagramme de classes

    MPD avec les clés primaires
    MPD avec les clés primaires
  4. Créez les relations entre les tables en fonction du type d'association : un à plusieurs, plusieurs à plusieurs (en orange dans le MPD ci-dessous)...

    Pour chaque association de type un à un poser vous la question de fusionner les classes en une seule table. Dans ce cas vous rapatriez les colonnes (sauf la clé primaire ad hoc) de la table à supprimer dans la table qui va accueillir la fusion en les préfixant du nom du rôle dans l'association (ex. ici avec la fusion de la table adresse dans la table commande).

  5. Vous créez les relations correspondant aux classes d'association (en vert dans le MPD ci-dessous)

MPD final
MPD final

Et voilà !

Bravo, en arrivant jusqu'ici, vous avez vu comment modéliser le domaine fonctionnel et son organisation dans un modèle physique de données.

Vous vous rendez compte que modéliser un domaine fonctionnel, c'est aussi faire des choix (nom des éléments, fusion ou non classes, multiplicités...). C'est pourquoi il est important de prendre le temps de la réflexion car ces choix auront un impact par la suite.

Vous vous rendez compte aussi que le passage du diagramme de classes au modèle physique de données n'est pas qu'une « simple traduction ». En effet, même si une grande part est « mécanique », à cette étape aussi il y a des choix à faire (type de données, fusion de tables...).

Mais rassurez-vous, ces choix ne se font pas au hasard et c'est justement ce que nous allons voir dans les chapitres suivants.

Exemple de certificat de réussite
Exemple de certificat de réussite