Diagrammes d'organigramme vs diagrammes d'activité UML
Quelle est la différence pratique entre l'utilisation de diagrammes de flux et les diagrammes d'activités UML? J'ai quelques réflexions, mais peut-être qu'il me manque un éléphant dans la pièce?
Diagramme de l'organigramme:
- Largement utilisé;
- Facilement compris par les non-programmeurs;
- Vieux?
Diagramme d'activité UML:
- Standardisé;
- Prend en charge la simultanéité;
- Syntaxe moins connue, mais toujours assez simple.
Pour mon cas de documentation ad hoc d'un bloc particulier de logique d'application, j'ai décidé d'aller avec les organigrammes. Plus de personnes dans l'entreprise pourront les comprendre.
Cela peut sembler être une préférence, mais si nous avons un langage standardisé pour décrire les systèmes logiciels, pourquoi utilisons-nous autre chose? Cela peut conduire à une mauvaise habitude de surutilisation des organigrammes. Les diagrammes d'activités sont vraiment simples. Mais si vous décidez de décrire un aspect plus compliqué du système ou essayez de changer la partie que vous décrivez, vous devrez peut-être changer de toute façon. Il suffit donc d'utiliser UML et d'éviter toute confusion à l'avenir.
Comme vous le constatez, les diagrammes d'activité peuvent intrinsèquement inclure la simultanéité et le calendrier. Si vous regardez cet exemple cribbed de Wikipedia, montré ci-dessous, vous pouvez observer la section avec deux barres horizontales lourdes, et deux activités parallèles de "idée actuelle" et "idée d'enregistrement". Cela signifie "démarrer ces activités en parallèle et continuer uniquement lorsque les deux sont terminées". Les organigrammes ne peuvent pas exprimer cela dans la notation.
En pratique, l'utilisation de diagrammes d'activités vous permet de penser clairement aux processus simultanés. Je pense que vous constaterez que toute personne capable de lire un organigramme s'adaptera rapidement.
Diagramme d'activité par l'utilisateur espagnol de Wikipédia Gwaur CC BY-SA 3. , via Wikimedia Commons: 
Selon le site Modélisation Agile :
À bien des égards, les diagrammes d'activité UML sont l'équivalent orienté objet des organigrammes et des diagrammes de flux de données (DFD) issus d'un développement structuré.
De IBM :
Cependant, les organigrammes n'incluent pas les états Et et les organigrammes des opérations ne peuvent pas recevoir d'événements.
C'est probablement pourquoi les organigrammes sont plus faciles à comprendre car les diagrammes d'activité ont la notion de développement orienté objet et de concurrence.
Vous pouvez générer du code source à partir d'UML et vice versa; d'où la caractéristique "standardisée" dont vous avez parlé.
UML en soi est utilisé pour partager votre compréhension. Partagez la compréhension d'une manière standardisée. Étant donné que votre cas est ad hoc et que l'utilisation principale d'un diagramme UML est de fournir une esquisse informelle, le diagramme d'activité peut être utilisé ici. Mais il en va de même pour les organigrammes car il n'y a pas de parellisme impliqué ici. J'ai toujours trouvé l'argument suivant utile. L'artefact que je produis va bénéficier à qui? Et puis-je exprimer le flux de manière explicite en utilisant un organigramme. Et si oui, alors vous devriez continuer et utiliser un organigramme. Mais si vos diagrammes de classe, séquence, etc. sont au format UML, il serait logique d'avoir vos diagrammes d'activité en UML également pour des raisons de cohérence (l'argument ici serait que, si les gens peuvent comprendre la classe, séquencer la sémantique UML, alors pas d'activité diagrammes.).