Discussion :

[zupremacy]

je prépare un projet en UML! et pour présentation du projet j'arrive pas a me retrouver sur lé étapes ! ou j'dirai sur l'ordre séquentiel de l'analyse et étude !

DCU, CAS , DSS ......


merci

[ebrosse_fr]

UML ne propose pas d'étapes ou d'ordres pour les diagrammes tout dépend de ton projet, de la méthodologie que tu veux utiliser, des outils disponibles, etc.

Dans un développement suivant le cycle ne V, j'aurais tendance à utiliser classiquement pour la Spécifications les diagrammes de UseCase et Séquence,
pour la Conception Architectural les diagrammes de Classes et/ou Composant et pour la Conception Détaillé les diagrammes de Classes/Composant pour la partie structure et les diagrammes d'état ou d'activité pour la partie dynamique.

Mais encore une fois cela dépend beaucoup de paramètres e.g. domaine d'application, habitudes de travail, etc. UML "ne fournit qu'un" language à toi de voir comment l'utiliser...

[jbrnm]

Une approche possible (inspirée de Unified Process, mais adaptable aussi dans une approche Agile) :

0) Besoins métier (éventuellement en amont du projet) :

- Diagrammes d'activités : Pour décrire les processus et workflows de l'entreprise (avec des partitions/swimlanes pour montrer qui fait quoi).
- Diagrammes d'états "métier" : Pour simplifier la compréhension de certains concepts (les états d'une facture : émise, payée, archivée, en contentieux...).
- Diagramme de classes "métier" : Pour comprendre les grandes familles de données manipulées.
- Diagramme d'objet "métier" : Pour faire comprendre, avec des exemples de données.

1) Recueil de besoins :

- Diagramme d'exigences (pas normalisé en UML, mais souvent ajouté par un "profil" spécifique) : Liste structurée des exigences (règles de gestion, lois, sécurité, temps de réponse...).
- Diagrammes de Cas d'Utilisation : Nommer les limites du système, lister les acteurs, puis les Cas d'Utilisation de chaque acteur, puis brève description de chaque cas d'utilisation.
- Diagramme de séquence système : Pour décrire le scénario nominal de chaque cas d'utilisation, puis chaque scénario alternatif.
- Diagramme d'Activité : Pour comprendre l'enchainement des scénarios (nominal et alternatifs).
- Diagramme global d’interaction : Pour synthétiser encore mieux tous les scénarios d'un cas d'utilisation.
- Diagramme de classes "candidates" (ou "participantes") : Toutes les informations échangées entre les acteurs et le système dans chaque cas d'utilisation, mais uniquement ces informations (pas d'autres).
- Diagramme d'objet "candidats" : Pour illustrer avec des exemples de données et constituer les données des tests d'acceptation.
- Diagrammes d'états des données des Cas d'utilisation : A chaque fois qu'une décision implique un scénario alternatif, en fonction de l'état d'une information échangée dans un scénario.

2) Conception :

- Diagramme de paquetages (packages) : Pour découper le système.
- Diagramme de classes consolidée : Pour concevoir le modèle de données et les comportements et faire apparaitre les classes Frontières (Interfaces avec les acteurs) / Contrôleur (scénarios) / Entités (Base de données).
- Diagramme d'objet consolidés : Pour illustrer avec des exemples de données et constituer les données des tests d'intégration.
- Diagramme de séquence détaillé : "Éclater" le système des diagrammes de séquence système pour le remplacer par les classes Frontières/Contrôleur/Entités.
- Diagramme de communication : Créé à partir des diagrammes de séquence précédents, pour vérifier le faible couplage des classes Frontières/Contrôleur/Entités.
- Diagrammes de Temps : Si besoins, pour montrer les interactions entre des états de différents objets.

3) Développement :

- Diagrammes d'Activités : Pour décrire les algorithmes des méthodes des classes.
- Diagramme de structure composite : Pour faire apparaitre la structure interne des classes et positionner des composants.

4) Déploiement :

- Diagramme de composant : Pour organiser la structure de l'application.
- Diagramme de déploiement : Pour positionner les composants dans l'architecture physique.

Voilà : Avec ça, vous pouvez modéliser un projet tout à fait correctement.

[cymaul]

- Diagramme d'exigences (pas normalisé en UML, mais souvent ajouté par un "profil" spécifique) : Liste structurée des exigences (règles de gestion, lois, sécurité, temps de réponse...).

Bonjour,

En complément de cette réponse, j'ajouterai que le diagramme d'exigences est défini dans le langage SysML, standardisé par l'OMG : http://www.omg.org/spec/SysML/. C'est effectivement sous la forme d'un profil UML que l'on peut définir les exigences.

[jbrnm]

Bonjour,

En complément de cette réponse, j'ajouterai que le diagramme d'exigences est défini dans le langage SysML, standardisé par l'OMG : http://www.omg.org/spec/SysML/. C'est effectivement sous la forme d'un profil UML que l'on peut définir les exigences.

Oui, absolument.

Et dans le même ordre d'idées les processus de l'entreprise peuvent aussi être décrits plus précisément qu'avec un simple diagramme d'activités en ayant recours à la notation BPMN (Business Process Modeling), qui peut aussi se traduire sous forme d'un profil UML.