Der letzte Beitrag der UML-Artikelserie, in dem es über das Klassendiagramm ging, ist etwas länger geworden, als ich das für diese Kurzserie vorgesehen hatte. Über die Aktivitätsdiagramme habe ich heute nicht so viel wie über die Klassendiagramme zu schreiben, daher sollte es diesmal wieder kürzer werden.

Was ist ein Aktivitätsdiagramm und nützt es mir?

Im Gegensatz zu den bisher vorgestellten Diagrammtypen Anwendungsfalldiagramm und Klassendiagramm, welche unter Strukturdiagramme einzuordnen sind, ist das Aktivitätsdiagramm eine Art der Verhaltensdiagramme. Andere Bezeichnungen, die genau das selbe meinen, sind “Ablaufdiagramm” und für englisch affine Leser auch “flow chart”.

Wie der Name schon andeutet, beschreibt ein Aktivitätsdiagramm einen Ablauf, wobei ein Ablauf zum Beispiel ein Anwendungsfall sein kann, welcher im Detail angeschaut werden soll. Aufgrund der Struktur des Aktivitätsdiagramms lassen sich damit zum Teil sehr komplizierte Abläufe grafisch ansprechend aufbereiten und erklären.

Als “Aktivität” wird seit UML 2.0 das ganze Diagramm mit allen Einzelelementen bezeichnet. Beispiele für eine Aktivität aus dem bereits vorgestellten Anwendungsfalldiagramm wären zum Beispiel “Artikel kommentieren” oder “Artikel schreiben”. Die Darlegung, wie nun ein Artikel im Detail kommentiert wird, welche Aktion welcher folgt, ist die Aufgabe eines Aktivitätsdiagramms. Darin werden die Aktionen als Knoten bezeichnet. Vereinfacht betrachtet besteht eine Aktivität aus Knoten und Flüssen, welche die Knoten miteinander verbinden.

Damit kommen wir auch schon zu einigen Besonderheiten und Details eines Aktivitätsdiagramms: Wenn ein ganzes Aktivitätsdiagramm nun Aktivität heißt, wie wird dann der einzelne Ablaufschritt genannt? Ich habe diesen Begriff bereits im vorherigen Abschnitt verwendet: “Aktion”. Die Aktion stellt im
Allgemeinen die kleinste und simpelste Einheit eines Aktivitätsdiagramms dar. Jedoch kann eine Aktion auch eine weitere Aktivität aufrufen, worin der Informationsfluss genauer gezeigt ist. Jede Aktion hat mindestens einen eingehenden und einen ausgehenden Kontrollfluss. Im Falle mehrerer eingehender Kontrollflüsse müssen alle Flüsse zur gleichen Zeit verfügbar sein, damit die Aktion beginnen kann. Bei mehreren Ausgängen gilt das gleiche in Grün: erst wenn alle Ausgänge “bereit” sind, dann werden auch alle zum selben Zeitpunkt ausgegeben.

Neben der Aktion als Knoten existieren weitere wichtige Knoten: Kontroll -und Objektknoten. Doch dazu später mehr.

Wie bereits erwähnt, werden die Knoten durch Flüsse verbunden. Es werden zwei grundlegende Flussarten unterschieden: die Kontrollflüsse und die Objektflüsse. Aber bevor es zu viel trockene Theorie wird, hier erstmal das Beispiel:

Beispiel: Aktivitätsdiagramm

Das Aktivitätsdiagramm habe ich mit einer tollen Browseranwendung aus der WEB2.0 Ecke erstellt: cacoo.com. Ein Tipp für alle, die schnell ein einfaches UML-Diagramm zusammenklicken wollen und es nicht für zum Beispiel einen Kunden bestimmt ist.

Natürlich lasse ich es mir nicht nehmen, auch diesmal ein Diagramm zu einem Weblog-Thema zu erstellen. Diesmal habe ich den Anwendungsfall “Blogartikel schreiben” ausgewählt und mit einigen Elementen des Aktivitätsdiagramms veranschaulicht.

Elemente eines Aktivitätsdiagramms

Im ersten Abschnitt bin ich bereits etwas auf die wichtigsten Elemente eingegangen, nun möchte ich auch etwas zur Notation und Darstellung in UML loswerden. Fangen wir mit der Aktivität an sich an:

Die Aktivität, bzw. der Aktivitätsname “Blogartikel schreiben” wird, wie im Beispiel gezeigt, in die linke obere Ecke geschrieben. Meist wird die ganze Aktivität von einem Rahmen umgeben, welcher die Aktivität von seiner Umgebung abgrenzen soll. Häufig liegen keine Diagrammelemente auf dem Rahmen, im Beispiel ist es auch kein Fehler. Wird ein rechteckiger Knoten auf den Rahmen gelegt, dann stellt es einen Eingangsparameter dar. Also ist die “Idee” der Eingangsparameter für die Aktivität “Blogartikel schreiben”.

Neben der Funktion als Eingangsparameter, deutet der Knoten “Idee” mit seinem rechteckigen Rahmen an, dass er ein Objektknoten ist. Er gibt an, dass in dem Ablauf Objekte verwickelt sind. Von einem Objekt geht kein Kontrollfluss, sondern ein Objektfluss aus, es werden also Objekte transportiert. Meines Wissens nach wird graphisch zwischen Objektfluss und Kontrollfluss nicht direkt unterschieden.

Verfolgen wir das Diagramm weiter, so stoßen wir auf einen Knoten mit abgerundeten Ecken. Ein solcher Knoten ist eine Aktion. Wie bereits angedeutet, ist die Aktion die einfachste Einheit eines Aktivitätsdiagramms. Jedoch kann sie auch durch ein weiteres Aktivitätsdiagramm beschrieben werden und darauf verweisen, was durch eine kleine “Mistgabel” im Aktionsknoten gekennzeichnet wird. Ein derartige Mistgabel habe ich bei einer der sicherlich schwersten Aktionen hinzugefügt: “Wissen beschaffen”. Dieser Aktion müsste ich nur noch ein Aktivitätsdiagramm hinzufügen und schon könnte jeder Unmengen an Wissen beschaffen .

Eine Raute, wie sie zwischen den zwei Aktionsknoten “Thema prüfen” und “Übersicht erstellen” aufgeführt ist, impliziert eine Entscheidung. Sie ist ein Kontrollknoten und gehört meiner Ansicht nach zu den Elementen, welche ein Aktivitätsdiagramm erst richtig interessant machen.

Elemente: Startknoten, Endknoten, Ablaufende

Weitere ganz wichtige Elemente sind der Startknoten, ein ausgefüllter Kreis, der Endknoten, symbolisiert durch einen ausgefüllten Kreis in einem Ring und ein Ablaufende, einem durchgestrichenem leeren Kreis. Die ersten Beiden erklären sich von selbst. Im Beispiel “Blogartikel schreiben” habe ich kein Startknoten, weil die Idee als Parameter übergeben wird und der Fluss an dieser Stelle beginnt. Ein Endknoten beendet im Gegensatz zum Ablaufende den gesamten Fluss und alle Aktionen, das Ablaufende jedoch nur einen einzelnen Fluss.

Element: Konnektoren im Aktivitätsdiagramm

Möchte man einen komplizierten Ablauf mit Hilfe eines Aktivitätsdiagramms veranschaulichen, so wird es schnell ganz unübersichtlich. Um den Chaos in Grenzen zu halten und ewig lange Kontrollfluss-Linien zu vermeiden, gibt es die Konnektoren. Dabei endet ein Fluss an einem Marker, zum Beispiel einem “A”, und geht an einer anderen Stelle von einem “A” aus weiter. Die Marker werden dafür in einfache Kreise geschrieben. Zudem sind die Konnektoren auch dafür gut, wenn ein Diagramm nicht ganz auf ein Blatt passt und auf einem anderen weitergehen soll, dann können ebenfalls Konnektoren eingesetzt werden.

Es gibt noch viele weitere Elemente von Aktivitätsdiagrammen, die durch ihre Zeichen mehr oder weniger selbsterklärend sind. Für den ersten Einstieg sollten die hier aufgeführten aber zunächst reichen. Ergänzungen und Kommentare können gerne hinterlassen werden.

Ende gut alles gut?

Mit diesem Artikel geht meine Mini-Serie zu UML-Diagrammen zu Ende. Während ich die Artikel geschrieben habe, sind mir etliche weitere Artikelideen eingefallen, die ich eventuell noch verwirklichen möchte.

Nun hoffe ich, dass es euch gefallen hat und würde mich über Kommentare und Anregungen freuen.

Deine Stadt - Dein Preis
Mit CityDeal und vielen Anderen den Preis drücken!

© Muvik for muvik-multigrid, 2010. | Permalink | ein Kommentar | Teile es mit deinen Freunden: del.icio.us MisterWong Twitter
Tags: Modellierung, Tutorial, UML

Nachdem es im zweiten Teil der UML-Artikelserie um die Anwendungsfälle ging, die dem Programmierer die Anforderungen an ein Programm darlegen, wird es diesmal mit den Klassendiagrammen etwas technischer.

Was ist ein Klassendiagramm und wofür brauche ich es?

Die Aussage, dass das Klassendiagramm das liebste Kind des Programmierer ist, fällt mir nicht schwer, obwohl ich dafür keinen stichhaltigen Beweis habe. Betrachtet man jedoch die Struktur, den Aufbau und die Funktion eines Klassendiagramms, worauf ich noch eingehen werden, so merkt man, dass dieser Diagrammtyp dem Code objektorientierter Programmiersprachen sehr ähnlich ist. Daher wird jeder, der objektorientiertes Programmieren beherrscht, auch mit dem Klassendiagramm auf Anhieb zurechtkommen.

Gehen wir davon aus, dass die oben getroffene Aussage wahr ist, so ist das Klassendiagramm das wichtigste Diagramm der UML. Es gehört zu den Strukturdiagrammen, zu welchen auch das Anwendungsfalldiagramm gezählt wird. Was Klassendiagramme können lässt sich grob im folgenden Satz zusammenfassen:

Das Klassendiagramm zeigt, welche Klassen existieren, wie sie aufgebaut sind und in welchen Beziehungen sie zu einander stehen.

Somit ist die Struktur der einzelnen Klassen, die gemeinsame Struktur und das daraus resultierende gemeinsame Verhalten aus einem Klassendiagramm erkennbar. Die Betrachtung auf dieser abstrakten Ebene ermöglicht es, sich den Aufbau des Modells klarer zu machen.

Das wohl bekanntest Anwendungsfeld für Klassendiagramme ist wahrscheinlich die objektorientierte Modellierung als Vorarbeit für die Programmierung. Jedoch ist auch der umgekehrte Weg möglich: Liegt eine objektorientierter Code vor, so kann daraus ein UML-Klassendiagramm erstellt werden. Für beide Wege existieren automatische Generatoren, die entweder aus einem Klassendiagramm die Code-Struktur einer objektorientierter Programmiersprache erzeugen oder aus dem Code das Diagramm generieren.

Im folgenden Bild habe ich versucht, ein einfaches Klassendiagramm für den Inhalt eines Weblogs zu erstellen:

Beispiel: Klassendiagramm des Inhalts eines Weblogs

In dem Beispiel sind bereits folgende Elemente zu sehen:

• abstrakte Klasse: Content
• diverse Klassen: Datum, Autor, Artikel…
• Vererbungsbeziehung
• Assoziationsbeziehung
• Aggregationsbeziehung

Das ist nur eine kleine Auswahl der möglichen Elemente eines Klassendiagramms, welche ich unter anderem im nächsten Abschnitt näher erläutere.

Elemente eines Klassendiagramms

Das wichtigste Element des Klassendiagramms steht schon im Namen drin: die Klasse. Manchmal wird statt Klasse auch einfach Typ gesagt, was das gleiche meint. Eine Klasse bzw. ein Typ ist im Grunde eine Zusammenfassung der Eigenschaften (Attribute) und des Verhaltens (Operationen) der Objekte dieser Klasse. Symbolisiert wird eine Klasse mit einem Rechteck, welches im oberen Feld den Namen der Klasse enthält. Werden Attribute und Operationen angegeben, so stehen sie jeweils durch ein horizontalen Strich getrennt unter dem Namen. Jedoch ist es keine Pflicht, Attribute und Operatoren anzugeben. In dem Beispiel hat lediglich die Klasse “Content” ein Attribut und eine Operation.

Möchte man Attribute aufführen, dann kann man dies unterschiedliche Arten tun:

• nur Name
• Name und Typ
• Name, Typ und Anfangswert

Attribute, häufig auch Member genannt, werden an jedes Objekt einer Klasse weitergegeben. Jedoch hat wiederum jedes Objekt seine eigene Identität, was gleichbedeutend ist mit der Aussage, dass jedes Objekt zwar gleich Attribute hat, die Werte der Attribute aber durchaus verschieden sein können. In c++ können mit “static” sogenannte Klassenattribute definiert werden, welche in jedem Objekt verfügbar sind und den gleichen Wert besitzen.

Desweiteren ist es möglich für jedes Attribut die Sichtbarkeit von außen zu beschränken, was oft sehr sinnvoll ist. Dafür stehen grundsätzlich drei Varianten zur Verfügung:

• +: public: für alle sichtbar und benutzbar
• #: protected: sichtbar und benutzbar für die Klasse selbst und ihre Unterklassen
• -: private: nur für die Klasse selbst

In dem Klassen-Rechteck wird entsprechend der Sichtbarkeit eines Attributs das passende Zeichen (+,#,-) angegeben. Generell ist es ein guter Tipp, so zu programmieren, dass nur die Klassen selbst Zugriff auf ihre Attribute hat.

Die Operatoren, auch Memberfunktionen genannt, sind Dienstleistungen des Objekts und werden durch ihre Parameter charakterisiert. Die Parameterliste wird auch Signatur genannt.

Operatoren können wie Attribute auf unterschiedliche Weisen angegeben werden:

• nur Name
• Name und Parameter
• Name, Parameter mit Typ
• Name, Parameter mit Typ und Anfangswert

Außerdem können Operationen als abstrakt bzw. virtuell definiert werden, was bedeutet, dass keine Implementierung vorliegt, sondern nur die Deklaration der Operation. Dadurch wird die Klasse, welche die abstrakte Operation enthält, sofort zur abstrakten Klasse, aber dazu in wenigen Sätzen mehr.

Was nun letztendlich in der Attributen- und Operationenliste aufgeführt ist, ist stets problemspezifisch und hängt stark davon ab, was für das ordentliche Modellieren wichtig ist und was nur störend wirkt.

Der Name der Klasse wird generell in fetter Schrift geschrieben. Ist er fett und kursiv, so handelt es sich um eine abstrakte Klasse. Dieses weitere Element eines Klassendiagramms wird auch als virtuelle Klasse bezeichnet und kann keine eigenen Objekte erzeugen, da sie unvollständig ist. Zum Beispiel enthält sie eine abstrakte Funktion, die wir bereits kennen gelernt haben.
Eine abstrakte Klasse dient oft dazu, zu zeigen, dass es bestimmte Operationen und Attribute gibt, diese werden aber nicht konkret implementiert. Die abstrakte Klasse stellt daher eine Basis für weitere Klassen dar, welche dann die Implementierung beinhalten.

Beispiel: UML-Darstellung einer Template-Klasse

Ein weiteres Element ist die parametrisierbare Klasse. In c++ wird sie Template-Klasse genannt und stellt eine Schablone dar, welche einen formalen Parameter enthält, der bei der Erzeugung weiterer Klassen ersetzt wird. Mit dieser Technik kann leicht wiederverwendbarer Code erzeugt werden. Dargestellt wird die parametrisierbare Klasse durch ein zusätzliches rechteckiges Feld an der rechten oberen Ecke des Klassen-Feldes, welches den Namen des formalen Parameters enthält.

Beispiel: UML-Objekt

Klassen sind im Klassendiagramm nicht die handelnden Elemente, es sind ihre Objekte oder Instanzen. Die Eigenschaften und das Verhalten der Objekte wird durch die Klasse definiert (Attribute und Operationen). In der UML-Darstellung unterscheiden sich Objekte von ihren Klassen dadurch, dass dem Namen des Objekts im obersten Feld nach einem Doppelpunkt der Name der Klasse folgt. Das ganze wird auch noch unterstrichen. Das Objekt-Rechteck stellt nur Attribute mit den aktuellen oder Beispielwerten dar, Operationen sind nicht objektspezifisch und werden daher nicht angegeben.

Soweit zu den Klassen und ihren Objekten. Was noch fehlt sind die Verbindungen zwischen den Klassen, welche sehr vielfältig sind. Ich möchte an dieser Stelle lediglich vier vorstellen:

Die Assoziation beschreibt die Relation zwischen Klassen bzw. ihrer Objekte und wird entweder durch einen einfache Strich oder durch einen Pfeil dargestellt. Im Falle des Pfeils handelt es sich um eine gerichtete Assoziation und die Kommunikation kann nur in eine Richtung stattfinden. Im oberen Beispiel habe ich die Klasse “Artikel” und die Klasse “Kommentar” auf diese Weise verbunden. Berücksichtigt man die Multiplizität, so heißt es gesprochen: “Ein Artikel kann beliebig viele Kommentare enthalten.”

Artikel, Kommentare und Seiten sind in einem Weblog Inhalte und sie besitzen die abstrakten Eigenschaften von Inhalten, hier sind es das Datum und den Autor. Eine derartige Beziehung wird Vererbung genannt. Die Eltern-Klasse (“Content”) wird Oberklasse und die Kind-Klasse (“Artikel”) Unterklasse genannt.

Eine weitere Beziehung ist in dem Beispiel zwischen den Klassen “Datum” und “Content” zu sehen. Das ist ein Sonderfall einer Assoziation und wird Aggregation genannt. Die Aggregation besagt, dass die Beziehung zwischen den Klassen nicht gleichwertig ist. In diesem Fall ist “Datum” ein Teil der Klasse “Content”. Die leere Raute zeigt dabei immer auf das ganze Element, also auf “Content”.

Ist die Raute nicht leer, sondern ausgefüllt, dann handelt es sich um eine Komposition. Die Komposition ist auch ein Sonderfall der Assoziation und eine strengere Form der Aggregation. Wenn das ganze Element, welches die Komposition einnimmt, aus irgendwelchen Gründen verschwindet, dann kann das komposierte Element auch nicht mehr weiter existieren. Das ist bei der Aggregation nicht der Fall. Der Autor lebt immer noch, auch wenn sein Artikel gelöscht wird. Das Gegenteil gibt es nur in Büchern und Filmen .

Das ist ein Klasse-Diagramm

Klassendiagramme sind ein sehr wichtiges und nützliches Werkzeug bei der Programmierung. Und da die Terminologie auch zufällig die gleiche ist, fällt es den Programmierern nicht sehr schwer, sich an die Klassendiagramme zu gewöhnen.

Hast schon Erfahrungen mit Klassendiagrammen gemacht? Und wo wendest du sie an?

Deine Stadt - Dein Preis
Mit CityDeal und vielen Anderen den Preis drücken!

© Muvik for muvik-multigrid, 2010. | Permalink | 2 Kommentare | Teile es mit deinen Freunden: del.icio.us MisterWong Twitter
Tags: Modellierung, Tutorial, UML

Im ersten Teil der UML-Serie ging es vorrangig um die Erläuterung, warum ich in diesem Weblog über UML schreibe und was die Leser zu erwarten haben. Heute geht es ans Eingemachte mit dem ersten Diagrammtyp für Anwendungsfälle.

Was ist ein Anwendungsfalldiagramm und was kann ich damit tun?

In einem Satz zusammengefasst, zeigt das Anwendungsfalldiagramm den strukturellen Zusammenhang und die Abhängigkeiten zwischen sogenannten Akteuren und den Anwendungsfällen. Dabei werden weder das Verhalten der Akteure noch irgendwelche Abläufe beschrieben, sondern nur das Zusammenwirken der Elementen (Akteure und Anwendungsfälle). Was Akteure und Anwendungsfälle sind, dazu komme ich etwas später im Text.

Jeder, der schon einmal etwas komplexeres programmiert hat und dabei einfach drauflos geschrieben hat, musste am Ende wahrscheinlich feststellen, dass hier eine Funktion fehlt und da noch eine Schnittstelle wünschenswert wäre, damit das Gesamtprogramm sinnvoll ist und funktioniert, wie zu Beginn angedacht. Davon abgesehen, dass es meist kein guter Rat ist, ein Programm einfach anfangen zu schreiben, ohne sich zumindest eine grobe Struktur in Gedanken anzulegen, kann ich jedem nur ans Herz legen, die Anforderungen an ein Programm schriftlich oder grafisch festzuhalten. In solchen Fällen eignet sich das Anwendungsfalldiagramm. Im professionellen geschäftlichen Bereich kann es sogar soweit gehen, dass ein Anwendungsfalldiagramm die Grundlage eines Vertrages zwischen einem Softwarehersteller und seinem Kunden wird. Daraus kann eine ganz wichtige Eigenschaft des Anwendungsfalldiagramms heraus gelesen werden: Meist interessiert es den Kunden nicht, wie ein Programm funktioniert, er gibt nur vor, was es leisten soll. Aus dieser Tatsache folgt die Aussage über das Ziel eines Anwendungsfalldiagramms:

Das Anwendungsfalldiagramm hat zum Einen das Ziel den Funktionsumfang des Programms zu definieren und dabei möglichst die Kosten für nachträgliche Veränderungen zu minimieren und zum Anderen eine zielgerichtete, problemorientierte Entwicklung zu unterstützen.

Ein sehr einfaches Beispiel ist im folgenden Bild gezeigt.

Beispiel: Anwendungsfalldiagramm eines Blogs

• Artikel schreiben
• Artikel modifizieren
• Artikel kommentieren
• Artikel lesen

Also beschreiben Anwendungsfälle die Wechselwirkung zwischen den Akteuren und dem System.

Akteure sind die Besucher und der Administrator, folglich in diesem Fall Leute, die vor dem Rechner sitzen und am Blog etwas machen.

Viele weitere Beispiele kannst du mit der Google Bildersuche finden, indem du nach “Anwendungsfalldiagramm” suchst.

Elemente eines Anwendungsfalldiagramms

Die zwei wichtigsten Elemente haben wir schon kennen gelernt: die Anwendungsfälle und die Akteure. Wie im obigen Beispiel dargestellt, werden die Anwendungsfälle mit Ellipsen und einer Bezeichnung symbolisiert. Ein vernünftiger Anwendungsfall besteht meist aus zwei Wörtern, einem Substantiv und einem Verb. Ist das nicht der Fall, dann kann das Diagramm vielleicht noch optimiert werden.

Die Akteure werden als Strichmännchen dargestellt und die Bezeichnung unter das Männchen geschrieben. In der Fachliteratur sind noch weitere Details zum richtigen Darstellen von besonderen Akteuren, worauf ich hier jedoch nicht eingehen möchte.

Die Verbindungslinien zwischen den einzelnen Elementen stehen für die Beziehungen. Eine wichtige Beziehung ist die include-Beziehung. Damit wird ein Anwendungsfall in einen anderen eingebunden. Eine Unterteilung der Anwendungsfälle ist jedoch nur sinnvoll, wenn der ausgegliederte Anwendungsfall mehr als einmal eingebunden wird. Die include-Beziehung wird mit einer gestrichelten Linie und einer Pfeilrichtung hin zum einzugliederndem Anwendungsfall dargestellt.

Würde ich nun in dem Beispiel meiner eigenen Erklärung der include-Beziehung folgen, dürfte ich den Anwendungsfall “Freischaltung anfragen” nicht auslagern. Jedoch kann es an dieser Stelle wichtig sein, um zu verdeutlichen, dass nicht alle Kommentare wahllos zugelassen werden. Es könnte ja Spam dazwischen sein.

Eine ähnliche Funktion hat auch die extend-Beziehung, welche einen Anwendungsfall erweitert, aber im Gegensatz zu include ihn nicht zum Bestandteil des Anwendungsfalls macht.

Ein weiteres wichtiges Element des Anwendungsfalldiagramms ist die Systemgrenze, welche mit einem rechteckigen Rahmen um alle Anwendungsfälle gekennzeichnet wird.

Es gibt noch einige weitere Elemente, welche an dieser Stelle genannt werden können, aber ich denke, dass es für die Verwendung hier im Blog ausreicht, was ich bisher vorgestellt habe. Sollte es im einen oder anderen Fall nicht reichen, dann werde ich direkt im entsprechenden Artikel darauf näher eingehen. Die Ausführungen hier sollten aber für das Grundverständnis ausreichen.

Besonderheiten eines Anwendungsfalldiagramms

Unter den Besonderheiten des Anwendungsfalldiagramms führe ich die Punkte auf, welche beim Erstellen zu beachten sind:

• Beschreibung aus Sicht des Systems
• Beschreibung, was für Anwender sichtbar ist
• kein Verhalten oder Ablauf, nur Interaktion
• Was soll das System leisten?
• Nicht: Wie soll das System die Anforderung erfüllen?
• an jedem Anwendungsfall soll mindestens ein Akteur beteiligt sein
• Bezeichnung von Anwendungsfällen: Substantiv + Verb

Wo hast du bereits ein Anwendungsfalldiagramm gebraucht?

Ja, jetzt ist es wieder soweit: Du, lieber Leser, bist nun an der Reihe deine Erfahrungen darzulegen und etwas aus dem Nähkästchen zu plaudern. Hast du schonmal ein derartiges UML-Diagramm erstellt, hat es dir geholfen oder dich eher bei deiner Arbeit gestört? Kannst du eine Verbesserung vorschlagen?

Deine Stadt - Dein Preis
Mit CityDeal und vielen Anderen den Preis drücken!

© Muvik for muvik-multigrid, 2010. | Permalink | keine Kommentare | Teile es mit deinen Freunden: del.icio.us MisterWong Twitter
Tags: Modellierung, Tutorial, UML

Was ist UML?

UML ist keine Programmiersprache, sondern eine Modellierungssprache. Es stellt standardisierte Begriffe, Bezeichnungen und grafische Notationen zur Verfügung und soll damit die Modellierung von Systemen, Abläufen, Programmen erleichtern. Ich möchte an dieser Stelle nicht auf die Entstehungsgeschichte eingehen, obwohl das ebenfalls ganz interessant wäre. Oft versteht man etwas besser, wenn man weiß, wie es entstanden ist. Naja, eventuell wird aus den drei Artikel zu UML irgendwann auch vier .

Warum schreibe ich über UML?

Das wird sich sicherlich der eine oder andere Leser fragen. Es geht auf diesem Blog doch in erster Linie um Programmieren, Mathematik und Software. Ja, das stimmt auch soweit, aber ich möchte ja diesen Blog auch dazu nutzen mein Wissen auf dem Gebiet nicht nur anderen zur Verfügung zu stellen, sondern auch zu erweitern. UML hat mich schon sein einer längeren Zeit interessiert, da es in meinen Augen einen sinnvollen Zugang zu neuen Projekten bereitstellen kann. Zu Beginn eines Projekts weiß man noch nicht viel und muss doch irgendwie anfangen. Also erstellt man sich zum Beispiel ein Anwendungsfalldiagramm um die Anforderungen zu definieren.

Es ist mir auch klar, dass ich hier keine riesigen Projekte vorstellen werde, für welche die Modellierung fast Gesetz ist. Aber auch kleiner Aufgaben können durch UML besser verstanden und erläutert werden. Vielleicht lässt sich ein Projecteuler-Problem mit UML gut darstellen, was ich dann auch machen werde. Im Vordergrund steht für mich bei der Verwendung von UML das Ziel, eine strukturierte Vorgehensweise zu erlernen und möglichst effizient zu arbeiten. Kurz: Es soll alles besser werden.

Was erwartet den Leser, oder worauf darf sich der Leser freuen?

Die Artikel zu der kurzen Serie sind bereits geschrieben und sollen im Laufe der nächsten Woche nach und nach veröffentlicht werden. Dieser Post hier macht den Anfang, dann folgt ein Artikel zum Thema Anwendungsfalldiagramme. Der zweite Beitrag beschäftigt sich mit einem ganz wichtigen und interessanten Diagramm, nämlich dem Klassendiagramm. Abgerundet wird das ganze durch einen Artikel zu dem Aktivitätsdiagramm. Im Anschluss an diese Serie stelle ich einige Bücher vor, die ich als Quelle für diese Artikel verwendet habe. Ich finde Bücher sind nach wie vor immernoch die wichtigste Wissenquelle.

Viel Spass beim Lesen

Da ich mir durchaus bewusst bin, dass nicht alles richtig sein kann, was in den angekündigten Artikeln so steht, bitte ich die wenigen Leser um rege Beteiligung durch Kommentare. Verbesserungen, Ergänzungen, Erfahrungsberichte – alle konstruktiven Beiträge sind willkommen.

Deine Stadt - Dein Preis
Mit CityDeal und vielen Anderen den Preis drücken!

© Muvik for muvik-multigrid, 2010. | Permalink | ein Kommentar | Teile es mit deinen Freunden: del.icio.us MisterWong Twitter
Tags: Modellierung, Programming, UML