Uml : diagramme de contexte [Résolu]

Salut Vader,
Je suis un peu plus fière de l'expication que vous avez fait sur ce sujet, j'aimerai avoir votre contact pour que vous m'éclairecisser sur certains point concernant UML car j'ai un projet à réaliser en UML. J'ai appris UML juste à l'école mais comme vous pouvez le constater cà ne suffit pas et mes recherche sur le net franchement ne font que m'embrouiller de plus en plus.
Alors si vous avez recu ce mesage et si vous le désirez faites moi signe en me donnant votre mail, je peut vous contacter
Merci d'avance

Il ne me semble pas qu'ils donnent des avis personnel mais qu'ils essaient de me répondre, tel est le but d'un forum pour c'est à dire de partager des informations quitte à dire des bétises parfois.

J'ai trouvé leurs réponses plutôt pertinentes même si certaines datées d'un ou deux ans après ma question.

D'ailleurs je remercie ceux qui m'ont répondu.

Maya

Eh bien voilà un débat instructif, étalé sur plusieurs années, mais toujours d'actualité (je suppose que Maya doit quand même faire autre chose depuis sa question de 2004 !) Je suis certifié par l'OMG en UML2 et je vais essayer de contribuer, dans l'intérêt d'UML et des méthodologues motivés qui alimentent petit à petit cette discussion.

A propos du diagramme de contexte :
Non, il n'y a pas de diagramme dit de contexte en UML2.
Il existe apparemment des diagrammes portant ce nom dans certaines méthodes citées, que je ne connais pas bien. Mais UML n'est pas une méthode, c'est une norme, avec laquelle on peut construire des méthodes, lesquelles définissent diverses manières d'utiliser UML pour construire un modèle.
Ces méthodes donnent souvent des noms particuliers aux diagrammes UML standards utilisés dans tel ou tel contexte ou phase de la démarche. D'où les confusions que je vois apparaitre ici.
Sans que cela remette en question la pertinence des diverses méthodes construites autour d'UML, la préconisation avec le Unified Modeling Langage est de se limiter aux dénominations standards, afin que tout le monde partage le même langage, c'est le sens même du nom donné à la norme...
Les méthodes bien construites, telle que Praxeme par exemple, ne parlent pas de diagrammes de X ou Y mais d'aspects ou vues propres à la démarche et évitent ainsi de surcharger la sémantique d'origine d'UML.

Comment modéliser les flux :
Même si certains outils (Objecteering par exemple) permettent de créer des flux, sous forme de relations orientées ou dépendances, dans les différents diagrammes d'UML2, il n'existe pas non plus de diagramme de flux en UML2.
En effet, représenter les acteurs et les paquetages s'échangeant des flux dans des diagrammes statiques n'est pas conforme à UML, quoique rencontré couramment.
En UML2 les flux doivent être modélisés au moyen du diagramme comportemental dit d'activités. Les flux sont en effet des éléments dynamiques et il ne doivent donc pas figurer dans des diagrammes statiques tels que le diagramme de classes ou de paquetages.
Le diagramme d'activités est donc la seule manière de donner une vue des flux.
Les méthodes, outils ou même extensions d'UML qui dérogent à cette règle ne sont pas en accord avec le métamodèle d'UML2.
Dans une activité, les flux sont supportés par les "Object Flow" et figurent sous forme de flèches entre les activités, mais également de petits carrés accolés aux actions ou de rectangle entre les actions.
Les diagrammes d'activités permettent par ailleurs, au moyen des "Partition", de montrer les acteurs et les éventuels paquetages impliqués.
Enfin, les "Object Flow" exposés dans les diagrammes d'activités peuvent être typés par des classes qui spécifieront le contenu des flux en question, lesquelles classes seront exposées dans un diagramme de classes (statique).

Au delà d'UML2, la norme BPMN de l'OMG est particulièrement adaptée pour montrer les échanges de flux et je la préconise en amont des modélisations, pour définir les Business Process du système. Mais c'est là un autre débat.

Bonne modélisation à tous.