urbanisation-si.com

urbanisation-si.com

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 9ème partie - Domaines métiers – UML – Diag. Package

 

blog-modelisation-uml-pack.gif

 

 

Détails Domaines métiers – UML – Diag. Package

blog-modelisation-uml-pack2.gif

 

L'urbanisme des Systèmes d'Information impose d'organiser la vue fonctionnelle en blocs autonomes communiquant par messages. Une zone avec un quartier spécifique pour les données à cycle de vie court (comme des prestations d'assurance) et un quartier référentiel de données pour celles à cycle de vie long (des produits commercialisés), doit être représentée dans le Plan d'Occupation des Sols (POS).du SI.

Si on zoom sur ces 2 quartiers, on obtient des diagrammes de classes modélisant les entités métiers (voir l'article sur le modèle métier dans la méthode ultime de modélisation des besoins). Ces entités métiers sont regroupées par appartenance à des domaines fonctionnels (référentiel Individus, référentiel contrats, domaine prestation, cotisation, ...). En UML on représente ces domaines métier par des packages.

Les packages peuvent contenir n'importe quels éléments UML (acteurs, cas d'utilisation, classes, ...) et il appartient au modélisateur de leur donner une sémantique. En modélisation métier ce sont bien sur les domaines fonctionnels et en conception ce sont les packages de compilation et d'exécution.

A part rassembler des entités d'un même domaine fonctionnel, le diagramme de package permet de représenter les dépendances.

Par exemple, le domaine contrat dépendra du domaine produits, le domaine prestation dépendra du domaine contrat, ...

Cette vue offre la possibilité aux experts métiers de vérifier les dépendances entre les domaines fonctionnels. Par exemple les référentiels constituent des socles, ils ne peuvent pas dépendre de domaines fonctionnels qui ne soient pas référentiels..

Ce modèle peut aussi faire apparaître les dépendances  bidirectionnelles ou cycliques (A dépend de  B ; B dépend de C et C dépend de A). Il faudra alors déplacer les entités ambigües situées aux frontières des domaines pour diminuer le couplage. On constate souvent qu'une dépendance entre 2 domaines peut être uniquement la cause d'une relation entre 2 entités situées dans chaque domaine. Cela aurait peut être un sens métier de déplacer une de ces entités dans l'autre domaine ce qui aurait pour effet de supprimer complètement la dépendance entre les 2 packages. En pratique il y a des entités pour lesquelles dés le départ on hésite à les mettre dans tel ou tel domaine. La bonne pratique est donc de les mettre dans le package qui aura pour effet d'introduire le moins de dépendance possible et surtout de supprimer les bidirectionnelles ou les interdépendances.

Le diagramme de packages est donc l'outil de base du cartographe dans la démarche d'urbanisation. La notion d'échelle est donnée par la hiérarchie de packages, limitée par les règles d'urbanisme à 3 ou 4 niveaux. 

Les packages permettent aussi de regrouper les exigences en domaines fonctionnels c'est ce que nous verrons dans un prochain article.

 

"La connaissance s'élabore en détruisant une connaissance antérieure."

Gaston Bachelard

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/



14/05/2015
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 769 autres membres