Discussion :

[subrms]

J'en suis à l'étape de l'étude de l'existant de mon projet de stage. Dans ma formation, j'ai déjà eu affaire à Merise et UML. Je constate que UML ne me serait pas d'une grande utilité à cette étape de réalisation de mon projet. En effet, je ne trouve aucun diagramme qui puisse m'aider à modéliser les flux de données et avoir une vue globale de ce qui se fait dans l'entreprise. Sachant que je prévois l'utilisation de UML plus tard dans les étapes Analyse des besoins et Conception, peut-on utiliser la méthode Merise (MCC, MCT, MOT) pour la modélisation des données et des traitements existants et faire une critique du système actuel, puis par la suite enchaîner avec la modélisation des cas d'utilisations et d'autres diagrammes avec le langage UML ?

Ou bien, simplement s'aider d'un diagramme des flux de données et ne pas recourir à Merise ?

[Rhona Maxwel]

Bonjour,

D'abord on peut tout modéliser avec UML.
En effet le langage est extensible avec le concept de profil qui est un ensemble de stéréotypes + tagged value + contraintes OCL.
Pour tout savoir sur les profils UML, voir l'article : https://www.urbanisation-si.com/quel...ion-pour-togaf

D'autre part, je vous cite :

"En effet, je ne trouve aucun diagramme qui puisse m'aider à modéliser les flux de données et avoir une vue globale de ce qui se fait dans l'entreprise".

Je vous recommande de vous intéresser à l'Architecture d'Entreprise ou Urbanisation du Système d'Information, par exemple sur le site : https://www.urbanisation-si.com/

Et tout particulièrement le framework TOGAF : https://www.urbanisation-si.com/togaf-pour-les-nuls

Une étude de cas complète illustre la méthode, vous trouverez en annexe de l'article suivant toutes les étapes de modélisation :
https://www.urbanisation-si.com/le-d...xemple-modelio

Et tout spécialement, pour les flux échangés voir : https://www.urbanisation-si.com/comm...-letude-de-cas

[subrms]

Bonsoir, je vous remercie pour votre réponse intéressante.

J'ai pris le temps de lire et de parcourir les liens que vous avez partagés avec moi et quelques autres articles de votre blog très riche. Malheureusement, je ne m'y connais pas du tout en Urbanisation du Système d'Information et c'est une découverte pour moi. J'ai été aussi surpris par le nombre interminable de normes.

Pour mon étude de l'existant et la modélisation des flux de données, j'ai opté par un diagramme qui au final ressemble beaucoup à la modélisation de la phase B architecture métier de TOGAF, corrigez-moi si je fais erreur, il s'agit bien d'un profil UML correspondant aux concepts TOGAF qui est utilisé ?
Ce qui m'amène à vous poser la question suivante : est-il intéressant de recourir à l'utilisation de la méthode TOGAF dans mon cas ?

Je vous explique ma démarche :
-J'essaye d'élaborer le MOT de mon cas d'étude. Cela m'aide à comprendre le déroulement de chaque procédure dans l'entreprise.
-Je modélise le schéma de circulation des informations. Je ne suis pas une norme précise, mais cela comme je vous l'ai dit, ressemble beaucoup au profil UML utilisé dans la modélisation de la phase B.
-J'essaye d'établir une critique organisationnelle et informationnelle pour chaque procédure.

Que va m'apporter la méthode TOGAF (pour l'amélioration de mon étude de l'existant et par la suite, pour la conception de l'application) et l'utilisation d'un profil UML dans ce cas précis sachant que l'utilisation d'une norme n'est pas obligatoire (je parle pour l'étude de l'existant) ?

Une autre question aussi :
Si la génération de code avec UML ne me serait pas d'une grande utilité parce que je déciderais d'utiliser une technologie pour la réalisation de l'application, qui ne la permettrait pas, serait-il alors plus intéressant de se tourner vers des solutions comme ArchiMate pour la conception de l'application ?

Pour l'utilisation d'un profil UML, je vous avoue que je ne sais pas du tout sur quel critère doit se faire le choix d'un profil. Je ne pourrai pas consacrer beaucoup de temps à la création d'un nouveau profil qui répondrait à mes besoins, si j'en suis capable.

Si vous avez des conseils pour l'élaboration d'une bonne analyse et critique d'un système existant, je serai preneur.

Passez une bonne soirée.

[Rhona Maxwel]

Bonjour,

1)
TOGAF est un cadre pour l''Architecture d'Entreprise.
Pour être synthétique, l'AE est une méthode globale qui a pour principal objectif l'entreprise agile.
Elle permet de structurer, documentet, toutes les strates de l'entreprise depuis la vision, la stratégie, les processus et règles métiers, les composants applicatifs, les technologies, le matériel, ...
L'intérêt est de gérer la traçabilité de bout en bout, de pouvoir justifier la réalisation d'un composant en remontant la chaîne jusqu'aux objectifs stratégiques.
Sans oublier la gestion des impacts dans la cas de changements ou d'evolutions.

Si c'est votre but alors TOGAF est fait pour vous.

Si vous désirez juste cartographier les flux isolément alors utilisez n'importe quel diagramme.
Si vous n'utilisez pas de référentiel, vous pouvez même utiliser un beau schéma PowerPoint.

2)
Pour le choix du langage, voir l'article :

https://www.urbanisation-si.com/quel...ion-pour-togaf

Qu'est ce qui motive l'entreprise à vouloir modéliser les flux de données ?
Y a t'il une tactique sous jacente ?

Si cela vous intéresse étudiez notre étude de cas TOGAF avec UML, BPMN et SysML dont vous trouverez toutes les étapes dans l'annexe de l'article :

https://www.urbanisation-si.com/le-d...xemple-modelio

Tout y est depuis le schéma directeur jusqu'au déploiement des applications.

Pour information, nous commençons une série d'articles sur ArchiMate :

https://www.urbanisation-si.com/articles/archimate

Bon courage

[CinePhil]

je ne trouve aucun diagramme qui puisse m'aider à modéliser les flux de données

Merise : MCT et MOT
UML : Diagramme de séquence (je connais moins UML ; il y en a peut-être d'autres qui ne me viennent pas à l'esprit immédiatement).

peut-on utiliser la méthode Merise (MCC, MCT, MOT) pour la modélisation des données et des traitements existants et faire une critique du système actuel, puis par la suite enchaîner avec la modélisation des cas d'utilisations et d'autres diagrammes avec le langage UML ?

Pour la modélisation des données, rien ne vaut un MCD merisien ! C'est plus rigoureux qu'un diagramme de classes UML.
Pour les traitements, MCT et MOT sont bien mais les diagrammes UML sont davantage utilisés.

Donc oui, on peut mélanger les deux, ou plus exactement appliquer la méthode Merise avec des diagrammes UML.

[subrms]

Mon étude ne porte que sur un seul service de l'entreprise (le service Patrimoine). Je ne crois pas que l'utilisation de TOGAF soit appropriée ici. Actuellement en 4e année, il y a un module optionnel Urbanisation des systèmes d'information et je me suis inscrit. J'espère que nous allons parler TOGAF.
L'étude de l'existant s'est portée sur l'étude des postes de travail mobilisés, l'étude des différents documents échangés et l'étude des procédures de travail. Le modèle utilisé est le modèle Castellani. Je ne trouve pas de documentation sur ce modèle dans la littérature, je me suis inspiré d'un mémoire que mon maître de stage m'a donné pour exemple à suivre. Si vous avez des informations au sujet de ce modèle n'hésitez pas à m'en faire part. Un diagnostic a été établi par la suite pour dégager les anomalies observées liées à l'organisation et au schéma de circulation de l'information, auxquelles ont été apportées des solutions et suggestions.
J'en suis aujourd'hui au recensement des cas d'utilisation. L'article que vous y avez consacré dans votre blog est excellent. Tout particulièrement ce passage :

D'après l'ouvrage culte d'Alistair Cockburn "Writing effective use case", on peut définir 3 niveaux de use case qui sont pour reprendre son allégorie : le niveau nuage, le niveau de la mer et le fond de la mer.

Le niveau nuage correspond à des use case à fortes granularités, stratégiques comme par exemple "Gérer un prêt bancaire". Ces use case sont trop "gros", ils doivent être décomposés en use case du niveau de la mer.

Le niveau de la mer correspond bien à un use case utilisateur pour l'application cible, l'exemple précédent se décomposerait en 3 use case : "Gérer une demande de prêt bancaire", "Analyser une demande de prêt bancaire" et "Valider une demande de prêt bancaire".

Et le niveau fond de la mer, correspond à une fonction élémentaire simple non décomposable comme par exemple "Imprimer la demande de prêt bancaire". Ces use case correspondent à une simple étape d'un scénario.

Laissez-moi vous exposer un cas. Voici le scénario :
À l'achat d'un nouveau véhicule, le chef de parc procède à son enregistrement. Le chef de parc ajoute le véhicule à la flotte de l'entreprise. Le chef de parc peut supprimer le véhicule en cas de vente de ce dernier, de la liste des véhicules du parc automobile. Le chef de parc peut modifier et consulter le véhicule. Le chef service patrimoine et le responsable structure (directeur) peuvent consulter aussi le véhicule.

Mes questions :
Si on procède comme dans le passage de votre blog que je viens de citer, il y a un cas d'utilisation de haut niveau (niveau nuage) qui est Gérer les véhicules et des cas d'utilisation de niveau inférieur (niveau de la mer) qui sont : Ajouter le véhicule, Modifier le véhicule, Supprimer le véhicule et Consulter le véhicule. Mais voilà, Ajouter, Modifier et Supprimer sont utilisés par un seul et même acteur (Chef de parc) alors que pour Consulter le véhicule il y a trois acteurs différents, à des lieux différents (Chef de parc, chef service patrimoine et le responsable structure). J'ai proposé les deux diagrammes de cas d'utilisation suivants ; lequel selon vous est le plus convaincant ? Il y a certainement des erreurs dans les dépendances, lesquelles ?




Pour le deuxième diagramme :
La dépendance « extend » de Consulter le véhicule à Ajouter le véhicule est-elle correcte ? Pourquoi ? Si oui, faut-il rajouter des dépendances « extend » entre Modifier le véhicule, Supprimer le véhicule et Ajouter le véhicule ? Si toutefois il s'agit de dépendances « extend ».

[subrms]

Très bien, ça répond à ma question.
Mais pourquoi le MCD est plus rigoureux que le diagramme de classes d'UML ?
Pour ce projet de stage, c'est le diagramme de classes qui sera utilisé.
Dans ma formation, on a donné une plus grande importance à la validation du MCD plutôt qu'à sa création. Il n'y a pas de grande différence entre le MCD et le modèle entité-association, je me trompe ?

[CinePhil]

Mais pourquoi le MCD est plus rigoureux que le diagramme de classes d'UML ?

Parce que, par exemple, dans un diagramme de classe, on peut faire des associations entre associations, même par mégarde, ce qui est interdit dans un MCD.
Ce genre de permissivité peut dégrader le modèle de données, une fois implémenté en BDD.

Autre exemple : comme dans un diagramme de classe, on a l'esprit à la programmation orientée objet, on peut mettre en propriété d'une classe une collection d'objets. Dans une base de données, une colonne de table ne doit représenter qu'une information unique pour une ligne. Dans un MCD bien fait, on ne peut pas mettre de collection ou de liste en propriété d'une entité-type ou d'une association-type. Les propriétés sont atomiques.

Dans ma formation, on a donné une plus grande importance à la validation du MCD plutôt qu'à sa création.

Pour valider un MCD, il faut bien le créer d'abord, non ?

Il n'y a pas de grande différence entre le MCD et le modèle entité-association, je me trompe ?

Ça dépend ce que tu appelles le "modèle entité-association". Si tu penses au Entity/relationship diagram de MySQL Workbench, il y a des différences significatives :
- Le fait qu'on modélise directement des tables et non pas des entités et associations types comme dans un MCD ;
- Les cardinalités qui sont inversées par rapport au MCD (comme le diagramme de classe UML, d'ailleurs).

On peut modéliser directement avec MySQL Workbench mais il faut avoir une certaine habitude de la modélisation si on ne veut pas faire de bêtises.

[subrms]

Il me semble que dans le modèle entité-association il est possible de faire des associations entre associations, ce qu'on appelle agrégation. J'apprends que cela peut dégrader donc le modèle de données une fois implémenté en BDD.

Pour ce qui est de la validation, on nous donne un MCD prêt et une situation. Valider un MCD c'est s'assurer qu'il prend en compte tous les traitements à effectuer, énoncés dans la situation. Ça nous a permis de comprendre le MCD.

Ça dépend ce que tu appelles le "modèle entité-association". Si tu penses au Entity/relationship diagram de MySQL Workbench, il y a des différences significatives :
- Le fait qu'on modélise directement des tables et non pas des entités et associations types comme dans un MCD ;
- Les cardinalités qui sont inversées par rapport au MCD (comme le diagramme de classe UML, d'ailleurs).

On peut modéliser directement avec MySQL Workbench mais il faut avoir une certaine habitude de la modélisation si on ne veut pas faire de bêtises.

Oui, j'avais en tête les cardinalités inversées entre le MCD et le modèle entité-association. Ce n'était pas du tout évident au début d'ailleurs.
MySQL Workbench est un excellent outil mais comme vous dîtes, il faut avoir une certaine habitude de la modélisation.

[subrms]

C'est peut-être une perte de temps de s'attarder sur les relations stéréotypées dans le diagramme de cas d'utilisation, mais je voudrais tout de même éclaircir ce point, d'autant plus que cela va m'aider lors de la description textuelle des cas d'utilisation.

Donc voici l'amélioration des diagrammes précédents :



Et la documentation des cas d'utilisation :

=========================================================

Cas d’utilisation : S’authentifier
Acteurs : Administrateur et autres utilisateurs.
Objectif : Il permet à l’acteur de s’identifier en saisissant son login et mot de passe.
Précondition : L’acteur doit être présent dans la base de données.
Postcondition :
-Acteur authentifié.
-La page d’accueil s’affiche.

Scénario nominal :
1. L’acteur ouvre l’application,
2. Le système affiche la page d’authentification,
3. L’acteur saisit le login et le mot de passe,
4. Le système vérifie l’existence des données,
5. Le système affiche la page d’accueil.

Scénario alternatif :
A. Erreur d’authentification : login ou mot de passe non valide.
Cet enchaînement démarre au point 4.
5. Le système affiche un message d’erreur.
Le scénario reprend au point 2.
B. Champs obligatoires vides.
Cet enchaînement démarre au point 4.
Le scénario reprend au point 2.

==========================================================

Cas d’utilisation : Ajouter véhicule
Acteurs : Chef de parc
Objectif : Il permet au chef de parc d’ajouter un véhicule.
Précondition : Succès d’authentification.
Postcondition : Véhicule ajouté.
Scénario nominal :
1. Le chef de parc choisit l’ajout d’un nouveau véhicule,
2. Le système affiche le formulaire à remplir,
3. Le chef de parc saisit les informations à remplir sur le nouveau véhicule,
4. Le système vérifie les données,
5. Le système enregistre le véhicule dans la base de données.
Scénario alternatif :
A. Champs obligatoires non valides ou vides.
Cet enchaînement démarre au point 4.
5. Le système affiche un message d’erreur.
Le scénario reprend au point 2.

============================================================

Cas d’utilisation : Modifier véhicule
Acteurs : Chef de parc
Objectif : Il permet au chef de parc de modifier un véhicule.
Précondition :
-Succès d’authentification.
-Succès de consultation de la liste des véhicules.
Postcondition : Véhicule modifié.
Scénario nominal :
1. Le chef de parc choisit d’affiche la « Liste des véhicules »,
2. Le système affiche la liste,
3. Le chef de parc choisit la modification d’un véhicule,
4. Le système affiche le formulaire de modification,
5. Le chef de parc modifier les informations de véhicule,
6. Le système demande la validation de modification,
7. Le chef de parc valide la modification,
8. Le système vérifie les données,
9. Le système enregistre la modification dans la base de données.
Scénario alternatif :
A. Champs obligatoires non valides ou vides.
Cet enchaînement démarre au point 8.
9. Le système affiche un message d’erreur.
Le scénario reprend au point 5.

===========================================================

Cas d’utilisation : Supprimer véhicule
Acteurs : Chef de parc
Objectif : Il permet au chef de parc de supprimer un véhicule.
Précondition :
-Succès d’authentification.
-Succès de consultation de la liste des véhicules.
Postcondition : Véhicule supprimé.
Scénario nominal :
1. Le chef de parc choisit d’afficher la « Liste des véhicules »,
2. Le système affiche la liste,
3. Le chef de parc choisit la suppression d’un véhicule,
4. Le système demande la validation de la suppression,
5. Le chef de parc valide la suppression,
6. Le système procède à la suppression du véhicule de la base de données.
Scénario alternatif :
A. Le chef de parc annule la suppression.
Cet enchaînement démarre au point 4.
9. Le système affiche une notification.
Le scénario reprend au point 2.

================================================================

Cas d’utilisation : Consulter la liste des véhicules
Acteurs : Chef de parc, Chef service patrimoine, Responsable structure
Objectif : Il permet aux acteurs de consulter la liste des véhicules.
Précondition : Succès d’authentification.
Postcondition : Aucune.
Scénario nominal :
1. L’utilisateur choisit d’afficher la liste des utilisateurs,
2. Le système affiche la liste des véhicules,
3. Le système vérifie le type d’utilisateur connecté (si chef de parc ou chef service patrimoine ou responsable structure),
4. Si l’utilisateur est le chef de parc, le système fait appel aux cas d’utilisation interne « Modifier véhicule » et « Supprimer véhicule ».
Scénario alternatif : Aucun.

=====================================================================

Cas d’utilisation : Gérer les véhicules
Acteurs : Chef de parc
Objectif : Il permet au chef de parc de gérer les véhicules.
Précondition : Succès d’authentification.
Postcondition : Aucune.
Scénario nominal :
1. Le système fait appel au cas d’utilisation interne « Ajouter véhicule ».
Scénario alternatif : Aucun.

=======================================================================

Mes questions portent principalement sur les deux derniers cas d'utilisation documentés ; sont-ils bien documentés ? est-il intéressant de les garder ?
Quelles améliorations apporter au diagramme de cas d'utilisation ?
La documentation des cas d'utilisation est-elle bien faite ?

[Rhona Maxwel]

Bonjour,

J'en suis aujourd'hui au recensement des cas d'utilisation. L'article que vous y avez consacré dans votre blog est excellent.




Pour le deuxième diagramme :
La dépendance « extend » de Consulter le véhicule à Ajouter le véhicule est-elle correcte ? Pourquoi ? Si oui, faut-il rajouter des dépendances « extend » entre Modifier le véhicule, Supprimer le véhicule et Ajouter le véhicule ? Si toutefois il s'agit de dépendances « extend ».

Merci pour vos compliments.
Dans vos questions il y a tous les aspects de la modélisation.
Pour commencer, un modèle est faux par nature !

Les fondamentaux de la modélisation sont résumés ici :

https://www.urbanisation-si.com/les-...ge-des-modeles

Pour une modélisation efficiente il faut déterminer les parties prenantes concernées et cerner leurs préoccupations afin de concevoir les vues avec le bon niveau de granularité.

Pour plus de détails sur les vues, voir les articles :

https://www.urbanisation-si.com/les-...ises-en-compte

https://www.urbanisation-si.com/arch...ints-de-vue-11

Au niveau stratégique vous vous adressez à la direction générale, sa préoccupation c'est de savoir qu'on peut gérer le parc de véhicules (haut niveau).
Il y aura donc un seul use case "Gérer le parc" déclencher par un gestionnaire.

Au niveau applicatif, le use case "Gérer le parc" disparaît car on va préciser les actions du gestionnaire du parc : ajouter un véhicule, supprimer un véhicule, ...

Conclusion :
Au niveau applicatif, vous devez créer un rôle (à ne pas confondre avec la fonction dans l'entreprise comme "chef service patrimoine"), par exemple "Utilisateur de la gestion de parc" qui déclenche "Consulter le véhicule".
Le chef de parc , le chef service patrimoine et le responsable structure héritent du rôle "Utilisateur de la gestion de parc" et peuvent donc consulter.

De même, il y a un rôle "gestionnaire de parc" qui peut ajouter, supprimer, modifier.
Le chef de parc hérite de ce rôle et peut donc ajouter, supprimer, modifier.

La factorisation des étapes d'authentification est réalisée par la dépendance <<include>> des 4 use case vers "s'authentifier". Elle signifie que les 4 use case doivent obligatoirement déclencher "s'authentifier".
La dépendance <<extend>> indique que le use case "Consulter" étend de manière facultative un autre use case.

Donc faire apparaître les héritages des acteurs et pas d'héritage de use case.

Voici encore 2 articles sur les cas d'utilisation :

https://www.urbanisation-si.com/urba...-diag-use-case

https://www.urbanisation-si.com/sysm...e-case-diagram

[Rhona Maxwel]

Bonjour,

Parce que, par exemple, dans un diagramme de classe, on peut faire des associations entre associations, même par mégarde,

Dans un diagramme de classe UML, il existe des associations n-aire et des classes d'association, faites-vous allusion à cela quand vous évoquez le fait de pouvoir créer des associations entre associations ?

Sinon pouvez-vous donner un exemple et une référence par rapport à la norme de l'OMG ?

Autre exemple : comme dans un diagramme de classe, on a l'esprit à la programmation orientée objet, on peut mettre en propriété d'une classe une collection d'objets. Dans une base de données, une colonne de table ne doit représenter qu'une information unique pour une ligne. Dans un MCD bien fait, on ne peut pas mettre de collection ou de liste en propriété d'une entité-type ou d'une association-type. Les propriétés sont atomiques.

Un modèle est une vue destinée à des parties prenantes avec des préoccupations.
Un diagramme de classe peut être réalisé par exemple pour modéliser les principales entités métier et destiné aux experts métier qui ne sont pas concernés par des aspects techniques comme des tables d'une base de données.

Si le modèle est destiné à des concepteurs/développeurs, on raffinera le diagramme en ajoutant des patterns de conceptions, des classes techniques (Collection), des stéréotypes (méta-information) comme par exemple <<entity>> pour signifier que la classe est persistance voir d'autres stéréotypes encore plus précis comme <<primary_key>> ou <<foreign_key>> permettant à l'outil de générer MLD, MPD et autre schéma de SGBD.

[subrms]

Vous avez raison de m'inciter à penser aux rôles joués par les acteurs. Je me suis en effet trop intéressé aux postes de travail en essayant de tous les inclure dans mon modèle.
Il y a donc deux rôles :
-Le gestionnaire de parc qui hérite du chef de parc,
-L'utilisateur de la gestion de parc qui hérite du chef de parc, responsable structure et le chef service patrimoine.

Voici la nouvelle version :



Je m'interroge sur les relations stéréotypées maintenant. Est-il intéressant d'utiliser un « extend » entre Consulter un véhicule et Ajouter/Supprimer/Modifier un véhicule ?
Je n'ai pas très bien compris la distinction que vous faîtes entre le niveau stratégique et le niveau applicatif. Au niveau stratégique le cas d'utilisation Gérer les véhicules est présent alors qu'au niveau applicatif ce n'est pas le cas ? Mais alors quelle est la relation stéréotypée entre Gérer le parc et Ajouter/Modifier/Supprimer un véhicule ?

Pour la description textuelle :

Peut-on parler d'enchaînement, Ajouter/Modifier/Supprimer un véhicule ? À ce moment-là, modéliser un seul cas d'utilisation Gérer le parc et dans la description textuelle de ce dernier documenter les enchaînements Ajouter un véhicule, Modifier un véhicule et Supprimer un véhicule ?

Excusez-moi d'insister là-dessus, mais la gestion des véhicules n'est pas le seul besoin de ce projet, il y a aussi la gestion des réparations, des entretiens, des assurances, des fournisseurs/prestataires, des accidents et des utilisateurs ; besoins assez similaires à la gestion des véhicules. Cette première étape de modélisation en respectant les bonnes pratiques m'aidera beaucoup dans le reste.

[CinePhil]

Dans un diagramme de classe UML, il existe des associations n-aire et des classes d'association

Je suis très loin d'être un spécialiste UML mais à ce que j'en ai compris...

Dans un DC UML, pour faire une association n-aire, on n'a pas d'autre solution que de créer une classe d'association puisque l'association simple (binaire) n'est représentée que par un trait.

Association binaire :
A -*--------1..1- B

Association ternaire :
A -*----1..1- association -1..1----*- B
C -*----1..1--------|

Dès lors, du fait de la représentation graphique de l'association ternaire ci-dessous, rien ne m'interdit, en UML, d'y ajouter une association binaire entre une classe D et l'assocation :
D -1..1-------0..1-|
A -*----1..1- association -1..1----*- B
C -*----1..1--------|

Dans un MCD merisien...
Assocation binaire :
A -1,1----associerA_B----0.n- B

Association ternaire :
A -0,n----association----0,n- B
C -0,n-----------|

Et je n'ai pas le droit de représenter ceci :
D -0,1----associer----1,1----|
A -0,n----------------------association----0,n- B
C -0,n----------------------------|

=> Je n'ai pas le droit de faire une association à partir d'une association. Si j'ai vraiment besoin de ça, je dois d'abord transformer l'association en ce que j'appelle une "entité-type-associative" :
A -0,n----associer----(1,1)- entite-type-associative-(1,1)----associer---0,n- B
C -0,n----associer----(1,1)---------------|

Et puisque mon association a été transformée en entité type, j'ai le droit maintenant d'en faire partir la nouvelle association avec D :
D-0,1----associer--------1,1------------|
A -0,n----associer----(1,1)- entite-type-associative-(1,1)----associer---0,n- B
C -0,n----associer----(1,1)---------------|

Il découlera logiquement de ce MCD que la clé primaire de la table issue de l'entité-type associative sera composée des clés étrangères référençant A, B et C.
Avec le diagramme de classes UML, cela semble moins évident.

Un diagramme de classe peut être réalisé par exemple pour modéliser les principales entités métier et destiné aux experts métier qui ne sont pas concernés par des aspects techniques comme des tables d'une base de données.

C'est surtout comme ça que je vois la diagramme de classe ainsi que ce que vous donnez ensuite pour la partie développement de l'application en indiquant les design patterns à utiliser.

des stéréotypes (méta-information) comme par exemple <<entity>> pour signifier que la classe est persistance voir d'autres stéréotypes encore plus précis comme <<primary_key>> ou <<foreign_key>> permettant à l'outil de générer MLD, MPD et autre schéma de SGBD.

C'est là que ça commence à me poser un problème !
Selon moi, une application UTILISE une base de données mais elle ne détermine pas son schéma.
Implémenter une BDD à partir de concepts davantage faits pour le développement logiciel peut conduire à des schémas de base de données pourris qui s'avéreront problématiques en terme de performance avec la croisance du volume de données à traiter ou d'évolutivité du schéma.
Dans l'idéal, une application ne devrait utiliser la BDD que via des vues et des procédures SQL. Les vues peuvent d'ailleurs être très proches des classes métiers de l'application alors que les données seront réparties dans plusieurs tables.

Encore une fois et pour conclure ma réponse, je ne prétends pas être un expert UML et je n'exprime là que mon ressenti.

[CinePhil]

-Le gestionnaire de parc qui hérite du chef de parc,

N'est-ce pas plutôt le contraire ?
Celui qui hérite de l'autre est celui qui a toutes les propriétés de l'autre + les siennes propres.
Le chef de parc n'est-il pas un gestionnaire de parc avec ses propres propriétés ?
Vous l'avez d'ailleurs plutôt représenté dans ce sens dans votre diagramme de cas d'utilisation.

L'utilisateur de la gestion de parc qui hérite du chef de parc, responsable structure et le chef service patrimoine.

Idem, j'ai l'impression que vous raisonnez à l'envers !
Le gestionnaire de parc est un utilisateur de la gestion de parc avec des propriétés et fonctions particulières, plutôt que l'inverse.
Quant aux responsable de structure et chef de service patrimoine, ne sont-ils pas plutôt des utilisateurs particuliers, indépendants des gestionnaires de parc ?
Là encore, pour ce dernier point, c'est ce que vous avez représenté sur votre diagramme UC.

Par contre, vous ne représenter des UC que pour l'utilisateur de la gestion de parc et le gestionnaire de parc. Est-il pertinent de faire figurer les autres acteurs puisqu'ils n'ont rien de particulier ?
Ou bien tous les cas d'utilisation ne sont-ils pas encore présents ?

Je n'ai pas très bien compris la distinction que vous faîtes entre le niveau stratégique et le niveau applicatif. Au niveau stratégique le cas d'utilisation Gérer les véhicules est présent alors qu'au niveau applicatif ce n'est pas le cas ? Mais alors quelle est la relation stéréotypée entre Gérer le parc et Ajouter/Modifier/Supprimer un véhicule ?

"Gérer le parc", c'est trop vague. Dans la réalité, ça englobe l'ajout, la modification et la suppression. Autant détailler les trois. Surtout qu'il est possible, selon la réalité de l'organisation, que, par exemple, seul le chef de parc soit habilité à créer et supprimer un véhicule et que les gestionnaires "de base" ne soient là que pour modifier les véhicules existants en terme d'affectation aux employés, d'envoi en révision ou réparation...
Vous parlez d'ailleurs de ça dans la suite de votre message...

[Rhona Maxwel]

Bonjour,

Merci pour ces explications claires qui serviront aux développeurs en quête de solutions.

Ma meilleure expérience a été comme très souvent un compromis entre la génération du schéma puis l'optimisation si nécessaire par le DBA expert pour le SGBD, chaque éditeur ayant ses propres fonctions d'optimisation.

Dans la majorité des cas le MPD généré par l'AGL est correcte car le diagramme de classe a déjà été préparé par des concepteurs connaissant bien le relationnel, les 3 formes normales, ... et les patterns sont éprouvés.

Comme vous le dites très justement, les association n-aires ont disparus pour être transformées en classe d'association, etc, ...
Il y avait bien sur des cas complexes qui doivent être optimisés par le DBA.

Je ne parle de la partie indexation, optimisation du matériel, allocation mémoire, cache 1er, 2ème niveau, plan de requête et optimiseur de requête spécifique au SGBD, verrous, "optimize lock", ...

Pour tout ce relève du standard la génération fait gagner du temps surtout quand la partie métier est encore instable, vous devez savoir que les parties prenantes disent une chose un jour et son contraire le lendemain

[subrms]

N'est-ce pas plutôt le contraire ?
Celui qui hérite de l'autre est celui qui a toutes les propriétés de l'autre + les siennes propres.
Le chef de parc n'est-il pas un gestionnaire de parc avec ses propres propriétés ?
Vous l'avez d'ailleurs plutôt représenté dans ce sens dans votre diagramme de cas d'utilisation.


Idem, j'ai l'impression que vous raisonnez à l'envers !
Le gestionnaire de parc est un utilisateur de la gestion de parc avec des propriétés et fonctions particulières, plutôt que l'inverse.
Quant aux responsable de structure et chef de service patrimoine, ne sont-ils pas plutôt des utilisateurs particuliers, indépendants des gestionnaires de parc ?
Là encore, pour ce dernier point, c'est ce que vous avez représenté sur votre diagramme UC.

Effectivement, vous avez raison. Dans le diagramme de classes par exemple, le sens de la flèche va de l'élément spécialisé à l'élément plus général et on dit : l'élément spécialisé hérite de l'élément plus général.

[subrms]

J'ai réalisé le diagramme de classes suivant, il n'est pas complet, mais je voudrais vous faire réagir sur les associations et d'éventuelles améliorations à apporter.



Je n'ai pas compris dans quel cas il faut introduire une classe-association et son rôle, d'ailleurs je n'ai utilisé aucune.

[CinePhil]

Vite fait parce qu'il est tard et que c'est le week-end...

User -1-----1..*- Role

Traduction en règle de gestion des données :
Un User assume un à plusieurs rôles et un Role est assumé par un seul user.

Ça commence mal, non ?

[subrms]

C'est vrai que ça commence mal hhh
Je vais rectifier ça. C'est donc : User -1..*-------1..*- Role
Je n'ai pas fait attention ^^' désolé



Mes questions :

Peut-on dire que la relation entre SousDirection et Direction est une composition ? en gardant les multiplicités ?
Peut-on dire que la relation entre Vehicule et Accident, Maintenance, ControleTechnique et Assurance est une agrégation ?
Quelle est la nature de la relation entre Vehicule et Direction selon vous ?