Use-Case-Diagramm und Aktivitätsdiagramm, Huhn und Ei?
Ich hinterfragen wollen und/oder vielleicht Herausforderung an die Schule des Denkens auf UML-Verhaltens-Diagramme.
Erstens möchte ich Fragen, was zuerst kommt: Anwendungsfall oder eine Aktivität?
Mir wurde beigebracht, dass Use-Case-Diagramme kommen zuerst und dann für jeden Anwendungsfall haben Sie einen oder mehrere Aktivitätsdiagramme darstellen, erfolgreich und alternativen Strömungen. Aus den Aktivitätsdiagrammen, die Sie identifizieren können Substantive zu etablieren Klassen.
Habe ich aber andere Beiträge gelesen, die sagen, dass Sie erstellen Sie ein Aktivitätsdiagramm für die Ende-zu-Ende-Prozess und dann können Sie systemanwendungsfälle identifizieren.
Kann ich sehen, dass beide Szenarien arbeiten, und bin verwirrt, wie mir scheint, ein Fall von Hierarchie. Zum Beispiel, sagen, dass ich eine high-level-business-Prozess, der "Grading Student der Ergebnisse". Wenn ich eine Karte als Aktivitätsdiagramm, in dem ich sehen würde, swim-lanes. Ich wäre in der Lage, herausgreifen, Use-Cases, wie 'Bestimmt Grad Grenzen,' 'Submit Ergebnisse,' 'Konvertieren Ergebnis an die Klasse," und so weiter.
Könnte man argumentieren, Sie sind ein und dasselbe, D. H. die beiden Diagramme entsprechen würde diesen Prozess Modellierung müssen. Dann möchte ich das Modell der nächsten Ebene, zum Beispiel, wie Sie den 'Submit Ergebnisse.'
Kann jemand beraten über die beste Praxis: ob ein Use-Case-Diagramm kommt vor oder nach einem Aktivitätsdiagramm?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ersten:
Zweite:
Use-Case-Diagramm vs. Aktivitätsdiagramm
"Use Cases" sind Szenarien, die zeigen, wie der Anwender das system nutzen, um Ihre Ziele zu erreichen.
So:
Aber um das zu finden, verwenden Sie Fällen sollten Sie entdecken Sie die Systemanforderungen zu einem gewissen Grad, (z.B. Rahmen, der breiten feature-set, Priorität, Kosten, etc.).
In einigen Geschäftsbereichen, wie für ein Automatisierungs-Projekt, um zu entdecken, Anforderungen/use cases, die Sie haben können, zu untersuchen, aktuelle business-flow. Manchmal ist dieses Geschäft fließen kann Komplex sein, so möchten Sie vielleicht, um es zu untersuchen mit einem Aktivitätsdiagramm.
So:
So:
Wie andere Grafiken, die Sie verwenden können, die Aktivität, Diagramm zu jeder Zeit, an jedem Ort, so schnell wie es kann Ihnen helfen, die richtige Frage zu stellen, zu verstehen und zu erforschen Fragen, die im Zusammenhang zu Ihrem Zweck.
Hier ist eine Zusammenfassung, Zweck der Aktivität Diagramme:
Bekommen eine schnelle Auffassungsgabe von denen Diagramme verwendet werden können, für welche Zwecke, empfehle ich Ihnen, check out Scott W. Ambler ' s mini-Buch: Die Elemente von UML(TM) 2.0 Stil
Aktivitätsdiagramm ist eine von denen mit der weitesten Abstraktion Bereich in der UML. Eine Aktivität kann verwendet werden, für alles, was zwischen einem Geschäftsprozess (sehr Abstrakt, zu vergleichen mit software-system) und einer einzigen Methode Algorithmus (code-level, praktisch, blau-Druck, Bedeutung Art der Abstraktion Boden).
Anwendungsfälle auf der anderen Seite sind in der Praxis nur sehr begrenzt in Ihrer Abstraktion. Sie zeigen die Interaktion zwischen einem Benutzer und dem system und würden irgendwo in der Mitte der Abstraktion Skala. Nicht so Abstrakt wie einem business-Prozess, und definitelly viel abstrakter als die Umsetzung-Diagramm.
Software-Projekte neigen dazu, zu arbeiten auf einem sehr abstrakten Niveau (Unternehmensziel zum Beispiel) und schließen mit der abstracion 0 (implementierte system). Während der Projekt-Analysten, Architekten und Entwickler arbeiten zusammen, um allmählich niedriger dieser Abstraktion produzieren immer weniger abstrakten Artefakte/Modelle - business-Prozesse, use-cases, Architektur, design, code.
Nach dieser Einführung ist es nicht schwer, Ihre Frage zu beantworten - jeder von denen kann zuerst verwendet werden, und das hängt von der Art Ihres Projekts und der zugehörigen Größe. Einige Beispiele:
Als Zusammenfassung würde ich schlussfolgern, dass es keine unverrückbaren Regeln, Wann diese Art in der software-Entwicklung. Jedes Projekt ist einzigartig, jede Entwicklung, die Methodik ist einzigartig, auch jedes Entwicklerteam ist besonders und einzigartig. Zu denken "das Diagramm", um zuerst tun ist gerade und einfach FALSCH! Denken Sie darüber nach, welche Art von Analyse oder Angabe, die Sie brauchen, in einem gegebenen moment - was ist am einfachsten und die meisten sinnvoll modelliert werden. Wenn dies klar ist - es gibt 13 UML-Diagramme zu pick-up aus, um optimal zu erfüllen das Ziel.
Wahl des UML-Diagramm ist das "WIE". Wichtiger als das ist mehr als oft nicht das "WAS".
Use-case-Diagramm wird zur Darstellung der Funktionalität und Aktivität-Diagramm ist für das zeigen von Operationen(1-Funktionalität können viele Operationen haben).
zB. Use-case-diag. ist Moher (kann haben viele Kinder) und
Aktivität diag. wie beschreibt das Kind der Mutter, d.h. der Use-Case-diag.