Discussion :

[Matthieu Brucher]

Participez à l'enrichissement de la FAQ UML !

Contribuez à l'évolution de la FAQ en proposant sur ce thread des questions / réponses, corrections de bugs / orthographe ...

Règles importantes pour participer :
-> Si vous proposez une question, vous devez impérativement proposer la réponse qui va avec ... (les questions sans réponses seront supprimées)

-> Un code source/un schéma n'est pas une réponse complète. Il est grandement apprécié de rédiger un paragraphe pour approfondir le sujet, apporter des précisions sur ce qu'on fait, pourquoi on fait comme ça, etc. On peut aussi en profiter pour inviter le lecteur à lire des questions/réponses dans des domaines proches ...

-> En dessous des réponses sont souvent proposés des liens, soit vers l'extérieur, soit vers des questions en rapport. Pensez à indiquer les liens utiles pour que le lecteur puisse approfondir.


Merci à tous pour vos contributions !
Bonne rédaction.

[Cian]

Qu'est-ce qu'un profile UML ?

Les profiles UML sont des spécialisation/adpation du langage UML à un contexte particulier. Les profiles sont utiles autant pour les étapes d'analyse que de conception ou de codage.
Ils introduisent des notions plus adaptées au type de travail courant, des règles de modélisation spécifiques, des règles de production ... bref, des contraintes.
Les profiles peuvent être crées par n'importe qui mais certains proposés par de très éditeurs connues sont quasiment devenus des standards.
Les profiles UML peuvent hériter d’autres profiles, avoir des dépendances
entre eux, ou encore être regroupés. Un modèle UML est construit sous un profile particulier, c’est à dire qu’il
est élaboré relativement à un contexte qui lui apporte une sémantique spécifique.
On peut créeer des profiles UML pour la spécification, pour la représentation d’architectures, pour la
modélisation de bases de données, ou pour toute autre phase de développement ou contexte de travail.

[Cian]

http://www.developpez.net/forums/vie...asc&highlight=

[ego]

Question : Sur un projet, doit-on garder le modèle d'analyse et/ou le modèle de conception ?

Réponse : Difficile de répondre dans l'absolu. Je dirai que cela dépend du type de projet.

Cas 1 : Le domaine fonctionnel est complexe d'un point de vue métier et/ou nouveau et/ou le périmètre du projet est important

Ici, il peut être utile de conserver un modèle d'analyse qui ne sera pas "pollué" par les transformations réalisées en conception dédoublement des classes, ajout des classes techniques des différents frameworks utilisés). Dans ce cas, le modèle d'analyse est une bonne aide à la compréhension que ce soit au cours du projet ou pour les équipes de maintenance.

Cas 2 : Le domaine fonctionnel est peu complexe et/ou le périmètre du projet est peu important

Ici, il est peut être envisageable de ne conserver que le modèle de conception. Bien que "pollué" par des transformations techniques, on peut toujours considérer que le modèle d'analyse se retrouve en partie dans la couche "métier" de votre modèle de conception (encore faut-il que vous fassiez un découpage propre de votre modèle de conception). La compréhension du métier "pur" pourra se faire en consultant cette couche dans le modèle. Cependant, si vos diagrammes de séquences ont été documentés au niveau du modèle de conception, ils seront probablement peu synthétiques pour une compréhension "simple" de leur équivalent d'analyse (que vous n'avez plus !).

Bien que chaque projet soit un cas particulier, je vais m'engager dans une réponse radicale que l'on pourrait adopter quelque soit le type de projet dès lors que le projet puisse être qualifié de projet de type "gestion" (assurance, banque, commerce). Vos commentaires sont les bienvenus
sur ce point.

Réponse "extrémiste"

Je ne garderai que le modèle d'analyse et je ne ferai d'ailleurs que celui là (à quelques petites modifications près).

Pourquoi me diriez-vous ?

Je crois en fait qu'avec une bonne description de l'architecture technique adoptée sur le projet et avec une bonne description des patterns de conception à appliquer au niveau de chacune des couches de cette architecture, cela est suffisant à des concepteurs pour créer leurs classes à partir du modèle d'analyse. Le modèle d'analyse sert à générer le code de la couche métier. Ensuite, s'il est nécessaire d'ajouter des classes/interfaces techniques (et il le faudra c'est sûr, pour le moment), on pourra utiliser des outils comme XDoclet ou les Aspects. Pour comprendre le projet, pour une équipe de maintenance par exemple, il lui suffira de regarder le modèle d'analyse qui ne sera donc pas
"pollué" par les classes techniques. Ensuite, avec les règles de conception et avec le code, la compréhension du niveau conception pourra se faire relativement facilement.

En fait, il faut se poser les questions : A quoi servent mes modèles ? Qu'ai-je besoin de comprendre

Aussi, les modèles servent-ils à comprendre le problème ou servent-ils à comprendre le code ?
Je pense qu'avant tout les modèles servent à comprendre le problème et c'est ce dont j'ai toujours
eu besoin quand j'ai repris un projet fait par d'autres. Pour comprendre le code, il y a le code. S'il est vrai qu'un modèle de conception peut aider à comprendre le code, quand celui-ci en est issu par génération automatique, les outils actuels savent faire du reverse de code. Avec le code "reversé" en UML par exemple, je pourrai toujours interroger l'outil ou faire des diagrammes me permettant d'avoir une vue d'ensemble.

[Cian]

FAQ Merise : Déf d'un dico de données.

http://www.developpez.net/forums/viewtopic.php?t=282642

[NutsFou]

Bonjour à tous!

Je me permet d'apporter mon petit grain de sel sur quelques points, sous forme de questions/réponses qui peuvent, je le pense, permettre de lever un certain brouillard qui plane sur l'UML pour les non pratiquants qui se posent des questions :

1. UML n'est pas une méthode mais un langage duquel on peut se servir en appliquant l'une des diverse méthodes qui existent (RUP, 2TUP,...).
Chaque méthode varie dans la succession des schémas en fonction du but à atteindre.
Ex: La méthode 2TUP vise à développer parallèlement le fonctionnel et l'architectural. Il y donc 2 branches parallèles qui se rejoignent et cela implique donc une organisation spécifique des diagrammes mis à disposotion par l'UML.

2. Pourquoi un langage?
Pour une expression universelle. C'est beau, mais ça signifie quoi au juste? Eh bien, c'est un peu comme l'esperanto (en + efficace tout de même...) : le but est d'avoir une grammaire et une orthographe commune au delà des frontières et de la limite des entreprises.
De cette manière, peu importe le processus suivi, tu débarques sur un projet et tu comprends les schémas. C'est pas balaise, ça?! Après, il ne reste plus qu'à apprendre la méthode appliquée dans le cadre du projet.

3. Grammaire et orthographe en UML?
UML étant un langage, il est naturellement régit par certaines règles permettant de le structurer.
- Grammaire : Ce sont les diagrammes.
De même qu'en français, pour poser une question il faut inverser le verbe et le sujet et terminer par un :, en UML pour décrire le déroulement d'une activité (scénario), on dessine des acteurs et des objets avec leurs lignes de vie respectives et on décrit les flux des uns aus autres par des flèches continues ou pointillées.
- Orthographe : Eh bien ce sont les symboles utilisables dans chacun des diagrammes.
Un ovale pour un use-case, une flèche dont le trait est continu et dont la pointe est gros trizangle pour indiquer un héritage, etc.
- Les deux ensembles : Tout bêtement, les symboles ne sont pertinents que dans un certain cadre.
En effet, le symbole du use-case n'a rien à faire dans un diagramme de classes : ça n'a tout bonnement pas de sens!
L'UML est donc l'art d'associer des symboles précis dans les limites d'un diagramme en vue d'exprimer un concept bien précis.

Conclusion :
Se mettre à l'UML est loin d'être inutile, même si on ne l'utilise pas directement et si on applique pas de méthode particulière. Pourquoi? Parce qu'il met à disposition des "UMLophones" des outils de langage qui permettent de structurer une idée, un concept.
Même en griffonnant sur le coin d'une nappe en papier au milieu d'un resto, un schéma précis et concis avec des symboles compris par tous est + explicite et permet d'aller + loin qu'en improvisant des flèches et des rectangles sans formalisme aucun.
Ce langage permet donc une certaine structuration de l'esprit, qui en + tend à être commune pour tous ses pratiquants, et qui permet de décrire à peu près n'importe quoi qui suit un processus dans la vie de tous les jours.

Re-conclusion :
Que des bonnes raisons de s'y mettre! (même si ce n'est pas à fond)