Diagramme de Cas d'utilisation et le Diagramme d'Activité, l'Oeuf et la poule?

Je veux remettre en question et/ou peut-être le défi de l'école de pensée sur UML diagrammes comportementaux.

Tout d'abord, je veux vous demander, ce qui vient en premier: Cas d'Utilisation ou de l'Activité?

M'a enseigné que les diagrammes de Cas d'Utilisation viennent en premier et ensuite, pour chaque Cas d'Utilisation, vous avez un ou plusieurs diagrammes d'Activité pour représenter succès et suppléants des flux. À partir des diagrammes d'Activité, vous pouvez identifier les noms pour établir des catégories.

J'ai, cependant, de lire d'autres articles qui disent que vous créez un diagramme d'Activité pour la fin pour terminer le processus et puis, de là, vous pouvez identifier les Cas d'Utilisation.

Je peux voir les deux scénarios de travail, et je suis confus, comme il me semble un cas de la hiérarchie. Par exemple, dire que j'ai un niveau élevé de processus d'affaires qui est "le Classement de l'Étudiant les Résultats". Si je le mapper comme un diagramme d'Activité, au sein de laquelle je voudrais le voir nager des voies. Je voudrais être capable de repérer les Cas d'Utilisation, telles que "Déterminer le Grade Frontières", de "Présenter des Résultats", de "Convertir le Résultat de Grade", et ainsi de suite.

On pourrait dire qu'ils sont la même chose, c'est à dire les deux schémas, permettrait de répondre à ce besoin de modélisation des processus. Je veux modéliser le niveau suivant, par exemple, la façon dont vous " Présenter les Résultats.'

Quelqu'un peut vous conseiller sur la meilleure pratique: si un diagramme de Cas d'Utilisation qui vient avant ou après un diagramme d'Activité?

OriginalL'auteur darren | 2013-09-30

  1. 19

    Première:

    Il n'y a pas de compétition entre les diagrammes UML pour être le "premier
    ". Parfois, il est préférable de travailler sur certains diagrammes simultanément et de manière itérative.

    Deuxième:

    Chaque diagramme peut être utilisé dans différents contextes et à différentes fins.

    Diagramme de Cas d'utilisation vs Diagramme d'Activité

    "Cas d'utilisation" sont des scénarios qui montrent comment l'utilisateur va utiliser le système pour atteindre leurs objectifs.

    :

    Au lieu de montrer ce "scénario", par écrit, les cas d'utilisation, vous
    peut visualiser ses étapes avec un diagramme d'activité.

    Mais dans le but de trouver des cas d'utilisation, vous devez découvrir les exigences du système à un certain degré, (par exemple, la portée, la vaste ensemble de fonctionnalités, la priorité, coût, etc.).

    Dans certains domaines d'activité, comme pour un projet d'automatisation, afin de découvrir les besoins/les cas d'utilisation, vous pouvez avoir à mener une enquête sur les flux d'affaires. Parfois, ce flux d'affaires peut être complexe, vous voudrez peut-être enquêter sur un diagramme d'activité.

    :

    Un diagramme d'activité peut être utilisée pour étudier un processus d'affaires à
    comprendre et découvrir les flux, afin de mieux découvrir les exigences.

    :

    Un Diagramme d'Activité peut être utilisée à différents niveaux de logiciel
    les stades de développement des fins différentes.

    À l'instar d'autres diagrammes, vous pouvez utiliser le Diagramme d'Activité, à tout moment, n'importe où, dès qu'il le peut vous aider à vous poser les bonnes question, de comprendre et d'étudier toute question relative à votre but.

    Voici un résumé but de Diagrammes d'Activité:

    Le but du diagramme d'activité est à modèle de la procédure de flux de
    les actions qui font partie d'une plus grande activité    . Dans les projets dans lesquels l'utilisation
    les cas sont présents, diagrammes d'activité peuvent modéliser un cas d'utilisation spécifiques à
    a un niveau plus détaillé    . Cependant, diagrammes d'activité peut être utilisée
    indépendamment des cas d'utilisation pour la modélisation d'un travail au niveau de la fonction,
    comme l'achat d'un billet de concert ou en vous inscrivant à un cours à l'université.
    Diagrammes d'activité peut également être utilisé pour le modèle de système de fonctions de niveau,
    que le mode de réservation des billets de données-mart remplit une entreprise
    le système de vente de l'entrepôt de données.
    UML de base : Le diagramme d'activité par Donald Bell

    Pour obtenir une compréhension rapide des diagrammes qui peuvent être utilisés pour quelles raisons, je vous conseille de vérifier Scott W. Ambler mini livre: Les Éléments d'UML(TM) 2.0 Style

    Belle réponse, mais supposons que si nous avons 10 usecases alors nous avons besoin de faire 10 diagrammes ? ou nous pouvons tout expliquer dans 1 diagramme ?
    Si vous avez 10 cas d'utilisation et que vous décidez de les expliquer à l'aide de diagramme d'activité, puis de leur montrer que dans distincts de 10 diagramme d'activité. Pour expliquer 10 cas d'utilisation dans un seul diagramme d'activité ? Pas une bonne idée. Mais le point principal est que vous pouvez comprendre et à d'autres de le comprendre...Alors même que vous pouvez l'afficher sur le papier de toilette...
    Les Cas d'utilisation sont justes exigences [de ce système, sans quoi ]. Donc, si vous montrez de 10 cas d'utilisation d'une seule activité daigram peut-être 10 cas d'utilisation sont juste un cas d'utilisation: peut-être que certains cas d'utilisation ne sont pas réels, ils font partie de ou une étape d'un scénario.

    OriginalL'auteur Hippias Minor

  2. 12

    Diagramme d'activité est l'un de ceux avec le plus large d'abstraction de gamme dans UML. Une activité peut être utilisé pour quoi que ce soit entre un processus d'affaires (en très résumé, la comparaison avec les logiciels système) et une méthode unique de l'algorithme (au niveau du code, pratiquement blue-print, signifiant sorte d'abstraction au niveau du sol).

    Cas d'utilisation de l'autre côté sont en pratique très limités dans leur abstraction. Ils montrent l'interaction entre un utilisateur et le système, et devait être quelque part au milieu de l'abstraction de l'échelle. Pas abstraite, un processus d'affaires, et definitelly beaucoup plus abstraite que la mise en œuvre d'un diagramme.

    Logiciel projets ont tendance à commencer à travailler à un niveau très abstrait (objectif commercial par exemple) et en finir avec les abstracion 0 (le système mis en place). Au cours du projet, analystes, architectes et développeurs travaillent ensemble pour diminuer progressivement cette abstraction produire toujours moins abstraite artefacts/modèles de processus d'affaires, des cas d'utilisation, l'architecture, le design, le code.

    Après cette introduction, il n'est pas difficile de répondre à votre question - tout de ceux-ci peuvent être utilisés en premier, et qui dépend de la nature de votre projet et de sa taille. Quelques exemples:

    1. Un grand projet de développement d'un système ERP. Il est presque certain que, dans ce type de projet, la première chose est le modèle de processus d'affaires. Un long avant même de penser de ses fonctionnalités, l'équipe doit comprendre l'entreprise arrière-plan. Le meilleur diagramme UML pour ce qui est naturellement le diagramme d'activité. Quelque temps après, lorsque le processus est clair et le haut niveau reqs connu, le cas d'utilisation la modélisation peut commencer.
    2. Une taille moyenne de relativelly petit projet, sans complexe des processus en arrière-plan (par exemple, développement d'applications mobiles) peuvent démarrer directement avec les cas d'utilisation, d'identifier les utilisateurs et de leurs caractéristiques. Plus tard, ceux-ci peuvent être affinés à l'aide activités.
    3. Un très faible développement de l'interface, pilote de la passerelle de communication, highely technique, où même l'interaction de l'utilisateur est minime, la modélisation pouvez commencer avec la activités de nouveau, montrant l'algorithme concret trop être mis en œuvre. Les cas d'utilisation peuvent être completelly sauté.

    En résumé, je voudrais conclure qu'il n'y a pas incassable règles de ce genre dans le développement de logiciels. Chaque projet est unique, chaque méthode de développement est unique, de même que chaque équipe de développement est spécial et unique. Penser à "qui" diagramme de faire en premier est de droite et tout simplement FAUX! Penser à ce genre d'analyse, de spécification dont vous avez besoin dans un moment donné - ce qui est plus facile et plus utile d'être modélisé. Lorsque cela est clair - il y a 13 diagrammes UML pour ramasser partir afin de bien remplir le but.

    Choix de diagramme UML est le "COMMENT". Plus important que celui qui est le plus souvent pas le le "QUOI".

    OriginalL'auteur Aleks

  3. 0

    Diagramme de cas d'utilisation est pour montrer les fonctionnalités et le diagramme d'Activité est pour montrer opérations(1 fonctionnalité peut avoir de nombreuses opérations).
    par exemple. Cas d'utilisation diag. est Moher (peut avoir de nombreux enfants) et
    L'activité diag. c'est comme décrivant l'enfant de la Mère, c'est à dire de Cas d'Utilisation diag.

    OriginalL'auteur Susheel