Ok, ich möchte die Denkschule über UML-Verhaltensdiagramme in Frage stellen und / oder vielleicht herausfordern.
Ich denke zuerst möchte ich fragen, was zuerst kommt: Use Case oder Activity
Mir wurde beigebracht, dass Use Case-Diagramme zuerst kommen und dann für jeden Anwendungsfall ein oder mehrere Aktivitätsdiagramme zur Darstellung von Erfolgs- und Alternativflüssen. Schließlich können Sie aus den Aktivitätsdiagrammen Substantive identifizieren, um Klassen zu erstellen.
Ich habe jedoch andere Artikel gelesen, die sagen, dass Sie ein Aktivitätsdiagramm für den End-to-End-Prozess erstellt haben und dann können Sie Use Cases identifizieren ???
Ich kann tatsächlich sehen, dass beide Szenarien funktionieren, und jetzt bin ich verwirrt, es scheint ein Fall von Hierarchie zu sein, dh ich habe einen Geschäftsprozess auf hoher Ebene, der "Benotung der Studentenergebnisse" ist. Lassen Sie uns sagen, dass ich es als ein Aktivitätsdiagramm abbilde und innerhalb dessen würde ich swimlanes sehen und in der Lage sein, Use Cases wie 'Notengrenzen festlegen', 'Ergebnisse einreichen', 'Ergebnisse in Noten konvertieren' und so weiter auszugeben.
Sie könnten argumentieren, dass sie dasselbe sind, dh beide Diagramme würden diesen Prozessmodellierungsbedarf erfüllen? Ich möchte dann die nächste Ebene modellieren, dh wie schicke ich Ergebnisse ein?
Kann jemand zu Best Practice beraten, ob ein Use Case-Diagramm zuerst oder nach der Aktivität angezeigt wird?
Erstens:
Es gibt keine Konkurrenz zwischen irgendwelchen UML-Diagrammen, um "zuerst" zu sein "Manchmal ist es besser, an einigen Diagrammen gleichzeitig (und iterativ) zu arbeiten
Zweitens:
Jedes Diagramm kann in verschiedenen Kontexten für verschiedene Zwecke verwendet werden.
Und Anwendungsfalldiagramm gegen Aktivitätsdiagramm
Kurz Anwendungsfälle sind Szenarien, die zeigen, wie der Benutzer unser System zum Erreichen seiner Ziele verwendet.
Also:
Anstatt dieses "Szenario" mit einem Text [Anwendungsfälle schreiben], Sie zu zeigen kann seinen Schritt mit Aktivitätsdiagramm visualisieren
Aber um Use Cases zu finden, sollten Sie die Systemanforderungen bis zu einem gewissen Grad kennen [den Umfang, die Hauptmerkmale mit grober Beschreibung, Priorität, Kosten usw. voraussetzen]
In einigen Fällen - Geschäftsdomänen [nehmen wir an, dass für Automatisierungsprojekte], um die Anforderungen zu bestimmen, müssen Sie möglicherweise den aktuellen Geschäftsablauf untersuchen. Und manchmal kann dieser Geschäftsablauf komplex sein, sodass Sie ihn möglicherweise mit einem Aktivitätsdiagramm untersuchen können.
Also:
Ein Aktivitätsdiagramm kann verwendet werden, um einen Geschäftsprozess zu untersuchen zu verstehen, den Fluss zu entdecken, um die Anforderungen besser zu verstehen, zu entdecken.
Also ein
Aktivitätsdiagramm kann auf verschiedenen Softwareebenen verwendet werden Entwicklungsstufen für verschiedene Zwecke. Es ist nichts falsch daran es.
Genau wie bei anderen Diagrammen können Sie das Aktivitätsdiagramm jederzeit verwenden - wo auch immer, wenn es Ihnen hilft, die richtige Frage zu stellen, zu verstehen, jedes Problem im Zusammenhang mit Ihren Zielen zu untersuchen.
Hier ist ein kurzer - kurzer - Zweck von Aktivitätsdiagrammen
Der Zweck des Aktivitätsdiagramms besteht darin, den Verfahrensablauf von zu modellieren Aktionen, die Teil einer größeren Aktivität sind . In Projekten, in denen sie verwendet werden Fälle vorhanden sind, können Aktivitätsdiagramme einen spezifischen Anwendungsfall modellieren eine detailliertere Ebene . Es können jedoch Aktivitätsdiagramme verwendet werden unabhängig von Anwendungsfällen zur Modellierung einer Business-Level-Funktion, wie zum Beispiel ein Konzertticket kaufen oder sich für einen College-Kurs anmelden. Aktivitätsdiagramme können auch zum Modellieren von Funktionen auf Systemebene verwendet werden , wie zum Beispiel, wie ein Ticket-Reservierungs-Data-Mart ein Unternehmen füllt Datenspeicher des Vertriebssystems. UML Basics: Das Aktivitätsdiagramm von Donald Bell
Um schnell zu verstehen, welche Diagramme für welche verwendet werden können, rate ich Ihnen, Scott W. Ambler's Minibuch zu lesen: Die Elemente von UML (TM) 2.0 Style
Aktivitätsdiagramm ist einer der Bereiche mit dem breitesten Abstraktionsbereich in UML. Eine Aktivität kann für alles zwischen einem Geschäftsprozess (sehr abstrakt, im Vergleich zum Softwaresystem) und einem einzelnen Methodenalgorithmus (Code-Ebene, praktisch Blue-Print, was Art der Abstraktionsbodenebene bedeutet) verwendet werden.
Use Cases auf der anderen Seite sind in der Praxis sehr begrenzt in ihrer Abstraktion. Sie zeigen die Interaktion zwischen einem Benutzer und dem System und befinden sich irgendwo in der Mitte der Abstraktionsskala. Nicht so abstrakt wie ein Geschäftsprozess und definitiv viel abstrakter als das Implementierungsdiagramm.
Softwareprojekte fangen an, auf einer sehr abstrakten Ebene zu arbeiten (zB Geschäftsziel) und enden mit der Abstraktion 0 (implementiertes System). Während des Projekts arbeiten Analysten, Architekten und Entwickler zusammen, um diese Abstraktion nach und nach zu reduzieren. Dabei werden immer weniger abstrakte Artefakte / Modelle - Geschäftsprozesse, Anwendungsfälle, Architektur, Design, Code - erzeugt.
Nach dieser Einführung ist es nicht schwer, Ihre Frage zu beantworten - eine davon kann zuerst verwendet werden und hängt von der Art Ihres Projekts und seiner Größe ab. Einige Beispiele:
Als Zusammenfassung würde ich feststellen, dass es in der Softwareentwicklung keine unumstößlichen Regeln dieser Art gibt. Jedes Projekt ist einzigartig, jede Entwicklungsmethodik ist einzigartig, jedes Entwicklungsteam ist einzigartig und einzigartig. Über "welches Diagramm" nachzudenken, ist zuerst gerade und einfach falsch! Denken Sie darüber nach, welche Art von Analyse oder Spezifikation Sie in einem bestimmten Moment benötigen - was am einfachsten und am nützlichsten ist, um modelliert zu werden. Wenn das klar ist, müssen 13 UML-Diagramme aufgenommen werden, um das Ziel optimal zu erreichen.
Wahl des UML-Diagramms ist das "WIE". Wichtiger als das ist meistens - das "WAS".
Das Anwendungsdiagramm dient zum Anzeigen der Funktionen und das Aktivitätsdiagramm dient zum Anzeigen von Operationen (1 Funktionalität kann viele Operationen haben). z.B. Anwendungsfall diag. ist Moher (kann viele Kinder haben) und Aktivitätsdiag. ist wie das Kind von Mutter zu beschreiben, d. h. Use Case diag.
Tags und Links android-activity uml diagram