Je devine à partir des diagrammes que vous êtes aligné sur une approche * Unified Process.
à mon humble avis:
- Cas d'utilisation - sans aucun doute - susciter des exigences de niveau entreprise et du système est mise en œuvre agnostique
- Architecture du système - sans aucun doute - couches, processus, réseau, db et modules/packages.
- diagrammes d'activités - certainement - utiliser pour décrire flux de processus pour les processus clés
- diagrammes d'états - applicable, bien que généralement associé à l'état et la durée de vie d'une instance unique de l'objet, mais il est encore sur le plan conceptuel utile si vous maintenez l'état par d'autres moyens
- diagramme de séquence - applicable, bien que vous aurez probablement besoin de fournir un nom de classe arbitraire pour attacher vos fonctions (? si vous utilisez les espaces de noms, alors peut-être total à ces ceux-ci à la place)
Cependant, vous pourriez rencontrer des problèmes si vous voulez générer et le code aller-retour de votre dia grammes, par exemple à partir d'un outil CASE tel que Rational Rose - la plupart supposeront un langage d'implémentation OO (notant que les trois Amigos sont fortement associés à OO!)
Je suppose que cela soulève la question de savoir pourquoi vous auriez besoin de développer une application procédurale utiliser un langage OO et le documenter avec des techniques OO?
HTH
Essayez de dessiner chacun pour voir si c'est possible. – Oded
bien que certains disent que vous ne pouvez pas dessiner un diagramme de séquence si vous n'avez pas de classes. – Haxed
Certaines personnes disent n'importe quelle vieille chose stupide. Ne les rend pas bien.L'astuce consiste à * scinder le code * en modules ou en composants ou quelque chose comme ça qui a * des responsabilités distinctes *. Vous pouvez faire des diagrammes de séquence pour les appels/messages entre ces modules. –