Aktuelle Version vom 25. September 2013, 15:31 Uhr

Grundlagen der Softwareentwicklung
Objektorientierte Softwareentwicklung mit UML

Vorwort

Hallo und willkommen zu meinem dritten Tutorial. Diesmal geht es um objektorientierte Sofwareentwicklung und UML.

Wieso dieses Thema? Der ein oder andere von euch wird das kennen: Ihr schreibt Programme, die durchaus funktionieren, doch je größer sie werden, desto unübersichtlicher werden sie. Wartung und Codepflege sind nahezu unmöglich, und wehe es will jemand eine neue Funktion eingebaut haben.

Das passiert wenn man "mal eben ein Programm schreibt". Viele Programme werden, vorallem im Hobby-Bereich, ohne ausreichend durchdacht zu werden einfach programmiert. Bei kleinen Programmen, die nur für kurze Zeit im Zentrum eures Interesses stehen mag das gehen, aber sobald mehr als 20 Klassen zusammenarbeiten sollen, ist der Fitz (und das dirty programming) schon vorprogrammiert (im wahrsten Sinne des Wortes).

Mir ging es leider nicht anders. Als ich, naiv wie ich war, ohne Plan(ung) an die Arbeiten am PBall-Manager 2 ging, habe ich wohl so ziemlich alle Vorgaben einer anständigen Programmierung (nicht wissend) ignoriert und habe mir damit selbst eine Lehre erteilt, wie man es nicht machen sollte.

Da mir auch bei meiner Arbeit in der Uni niemand sagte wie man richtig programmiert, habe ich mich selbst auf die Suche nach Quellen gemacht. Ein Arbeitskollege war dann der Schlüssel. Er lieh mir das Buch "Visual Modeling with Rational Rose 2000 and UML" von Terry Quatrani (ISBN 0201699613) und erzählte mir einiges was er selbst auf Schulungen zu diesem Thema gerlernt hatte.

Ich werde versuchen so viel wie möglich von dem wieder zu geben, was ich seitdem gelesen und gelernt habe. Ich orientiere mich dabei an dem oben genannten Buch. Da das Buch allerdings zu groß ist, um ein Tutorial daraus zu machen werde ich das Thema in mehreren Tutorials abhandeln.

Voraussetzungen

Eigentlich gibt es keine.

Um diesen Teil des Softwareentwicklungsprozesses zu verstehen braucht ihr noch nicht einmal einen PC (Vorausgesetzt ihr druckt euch diesen Text hier aus ;) ). Programmiert wird hier nichts. Allerdings werde ich euch einige Tools vorstellen, mit denen ihr die Schritte am Computer nachvollziehen könnt.

Auch tiefgreifendes Verständnis von OOP ist nicht von Nöten.

Ziele

Am Ende dieses Tutorials solltet ihr wissen was UML ist und wie man damit grundlegende Planungsschritte macht.

Ihr werdet wissen, wieso man eine, auf den ersten Blick, so umständliche Herangehensweise wählt und wieso ein Programm ohne Dokumentation irgendwie nicht vollständig ist.

Ihr werdet weiterhin lernen wie man Anforderungen analysiert, daraus Anwendungsfälle macht und diese für weitere Analysen sinnvoll darstellt.

In dieses Tutorials werdet ihr die Grundlagen schaffen, um im zweiten Teil des Tutorials Klassen zu erkennen und deren Beziehnungen untereinander zu modellieren.

UML

1997 wurde UML als Standard für Objekt Orientierte Modellierung festgesetzt. Die Unified Modeling Language ist wie der Name schon sagt eine Sprache zur Modellierung von Software.

Es existieren eine Menge graphischer Editoren, welche es dem Softwaredesigner ermöglichen auf graphischem Wege seine Software zu entwickeln. Diese graphische Darstellung gibt einem Entwickler viel schneller einen Überblick über das System, was er zu entwickeln, pflegen oder zu warten hat.

UML bietet Möglichkeiten um alle im Softwareentwicklungsprozess nötigen Diagramme zu erzeugen. Da UML den Aufbau von Softwaresystemen modelliert ist es möglich aus den erstellten Diagrammen (im besonderen aus den Klassendiagrammen) Code generieren zu lassen. (Nicht jedes Tool beherrscht diese Fähigkeit, und leider werden nicht alle Sprachen unterstützt.)

Einige Tools beherrschen sogar den umgekehrten Weg, sie können bestehenden Code analysieren und daraus eine UML Darstellung generieren (round-trip engineering). Damit ist es leicht die Dokumentation auf dem Stand der Software zu halten. Die Planung erspart uns diese Fähigkeit aber nicht.

Neben kommerziellen Editoren die Funktionen wie Codegenerierung in verschiedene Sprachen unterstützen, (z.B. Rational Rose 2000) gibt es auch einige kostenlose Editoren.

Eine Liste mit UML-Editoren findet ihr zum Beispiel hier:

• Englischer Wikipedia Artikel
• Jekle.de

Welchen ihr nehmt sollt hängt von der Plattform auf der ihr entwickelt und dem Code der generiert wird ab. Die Optik der entstehenden Diagramme ist auf alle Fälle immer gleich, weil der UML-Standard dieses vorgibt. Unter Linux ist meist Umbrella vorinstalliert.

(Wer mit Java arbeitet hat sehr viele Möglichkeiten. Ein Blick auf ArgoUML oder Fujaba könnte lohnen. Für letzteren gibt es auch ein Eclipse Plugin.)

Wieso Dokumentation?

Wieso soll ich meinen Code dokumentieren? Ich weiß doch was er macht!

Solche "Argumente" hört man des Öffteren wenn es darum geht Zeit in die Dokumentation des Programmes zu stecken. Allerdings ist dies keinesfalls verlorene Zeit.

Wenn ihr ein Programm, z.B. ein Spiel, entwickelt welches mehr als 15.000 Zeilen Code umfasst, dann gibt es Teile im Code die euch nach einem halben Jahr nicht mehr bekannt sind. Meist ist das kein Problem, denn man kann sich ja einarbeiten. Stellt euch aber nun vor es wäre ein Jahr vergangen und ihr wollte einen Nachfolger programmieren. Kein Problem denkt ihr, ich hab ja den alten Code noch. Stimmt. Aber der Frust ist groß wenn man sich in Code einarbeiten muss, den man heute ganz anders schreiben würde (man hat ja dazugelernt seit damals). Eine Dokumentation wäre toll. Aber sowas wurde ja nie gemacht.

Noch schlimmer ist es, wenn man im Team programmiert. Stellt euch vor, euer KI-Spezialist ist im Urlaub und ein Bug der die komplette Betatestphase blockiert tritt auf. Da wäre eine Dokumentation eine tolle Sache.

Ihr seht Dokumentation hilft euch Zeit zu sparen, auch wenn es am Anfang den Anschein hat, als ob sie nur Zeit kosten würde.

Aber was gehört in die Dokumentation eines Projektes? Ganz einfach: Alles was im Verlauf der Entwicklung an Dokumenten anfällt. Von den Anforderungen, den zig UML-Diagrammen bis zu den Testberichten. Einfach alles. Bei großen Projekten füllt sowas schnell mal ganze Ordner (aber immer noch besser als bei Problemen 250.000 Zeilen Code ab zu suchen).

Aber alle Dokumentation nützt nichts, wenn sie nicht den aktuellen Zustand des Projektes wiedergibt. Im Verlauf der Implementierung passiert es immer wieder, dass Klassen benötigt werden, die in der Planungsphase so nicht verausgesehen werden konnten. Diese Klassen müssen auch in die Dokumentation eingepflegt werden. Denn die Doku dokumentiert immer das aktuelle Programm, nicht das "wies mal geplant war"! Für solche Fälle ist ein Tool welches Code analysieren kann und daraus Klassendiagramme baut wirklich hilfreich.

Wir halten uns in diesem Tutorial weitestgehend am RUP. RUP steht für Rational Unified Process und ist im Kern mit dem Wasserfallmodell vergleichbar. Der positive Nebeneffekt am RUP ist, dass die Dokumentation ein Nebenprodukt des gesamten Planungsvorgangs ist.

Phasen der Entwicklung

Werden wir nun etwas konkreter. Über die Zeit in der ein Programm entwickelt wird, durchläuft es verschiedene Phasen:

Einstieg/Konzept (Inception) 

In dieser Phase werden die Anforderungen, die Umgebung des Programms und die zu erreichenden Ziele untersucht.

Ausarbeitung/Spezifikation (Elaboration) 

In dieser Phase werden Aktivitäten und benötigte Ressourcen eingeplant und definiert welche Eigenschaften und Codedesign das Projekt haben soll.

Konstruktion (Construction) 

In dieser Phase wird das Programm über mehrere Programmierzyklen hinweg geschrieben (und getestet).

Übertragung (Transition) 

Das Übertragen und in Betriebnehmen beim Kunden ist auch eine eigene Phase.

Die obige Gliederung ist einsichtig. Leider wird auch niemand wirklich schlauer damit.

Eine andere Einteilung in Phasen ist die, entlang der Aktivitäten die man zu tun hat:

Aufgaben Modellierung (Business Modelling) 

Hier wird geklärt in welchem Umfeld das Programm eingesetzt werden soll und was der Nutzer wirklich will/braucht.

Anforderungen (Requirements) 

Eine schriftliche Schilderung der Vision die man für das Programm hat. Umfasst alle funktionalen und nicht funktionalen Anforderungen.

Analyse und Design 

Eine Beschreibung wie das System später zu implementieren ist.

Implementation 

Schreiben des Codes mit dem Resultat eines funktionierenden Systems

Test 

Prüfen der Funktionen des gesamten Systems

Aufstellen (Deployment) 

Installation des Systems beim Kunden und Anwenderschulung.

Ich gebe zu das ist sehr weit gegriffen, vorallem im Bezug auf Spieleentwicklung. Aber dieses Tutorial soll euch auch dann noch etwas nutzen, wenn ihr mal keine kleinen Spielchen mehr schreibt. ;)

Beide genannten Gliederungen können als Diagramm dargestellt werden.

In diesem Tutorial bewegen wir uns in der Einstiegs und Ausarbeitungsphase. Dabei befassen wir uns vorallem mit Business Modeling, Anforderungsanalyse und den ersten Schritten in Analyse und Design des Programms.

Vor dem Start

Folgende Situation:

Jemand (der Kunde oder ihr selbst) sagt zu euch "Ich brauche ein Programm".

Ihr fragt dann zurück "Was soll es denn können?". Die Antwort wird meist nicht zufriedenstellend sein.

Wenn ihr nur so zum Spaß entwickelt, dann könnt ihr den Kunden einfach weg schicken. Wenn ihr Geld verdienen wollt, dann habt ihr ein Problem: Ihr habt einen Kunden, der euch einen Auftrag gibt, aber ihr wisst nicht was zu tun ist.

Wir befinden uns mitten in der Einstiegsphase. Business Modelling und Anforderungen sind hier Schlagwörter die es umzusetzen gilt.

Im klassischen Fall kommt der Kunde mit einem Lastenheft zu euch und möchte, dass dies umgesetzt wird. In der Realität ist der Wunsch des Kunden eine Software zu besitzen meist eher fertig als das Lastenheft. Ihr müsst also quasi dem Kunden sagen, was er eigentlich will.

Die ersten Frage die ihr euch stellen müsst sind

• "Wird die Software wirklich gebraucht?" und
• "Sind die Probleme die zu lösen sind wirklich dort wo die Software eingesetzt werden soll?"

Hobbymäßig entwickelte Spiele werden gebraucht und lösen Probleme, aber das versteht sich in diesem Falle ja von selbst. ;)

Wenn ihr es mit einem Kunden zu tun habt, dann sind die nächsten Schritte

• Ideen festigen (was will der Kunde eigentlich)
• Einschätzen welche Teilaufgaben am Kompliziertesten sind, bzw. welche Probleme machen könnte. (Risikobewertung)
• Feststellen wer das System einsetzen soll
• Feststellen welche Hauptfunktionen das System haben soll
• Bauen erster Prototypen (Wegwerf-Code!) um Konzepte und Ideen zu testen

Welche Mittel stehen uns zu diesem Zeitpunkt zur Verfügung?

• Brainstorming
• Recherche
• Marktanalysen
• Kosten Nutzen Analyse
• Use Cases
• Prototyping

Bei kommerziellen Systemen sind eine Menge verschiedener Leute in dieser Phase beteiligt. Vorallem Leute die vom Umfeld der Software mehr verstehen, als das die Programmierer könnten (und müssten). Die Ideen, wie das System einmal aussehen könnte kommen von:

• Kunden
• Experten des Anwendungsgebiets
• Industrieexperten
• andere Entwickler
• Prüfung bereits bestehender Systeme (Analyse der Konkurenz)

Neben den Anforderungen die an den Code gestellt werden (die sogenannten funktionalen Anforderungen) müssen in dieser Phase auch die nicht funktionalen Anforderungen geklärt werden. Das sind z.B:

• Zielplattform für die entwickelt wird (Hardware, Betriebssystem)
• Zu welcher Software es Schnittstellen geben muss, bzw. welche Software noch läuft
• Wie die Software eingesetzt wird (Verteilung auf Rechner)
• Wie lange die Software genutzt wird
• Wie lange die Software am Stück läuft.
• ...

Bei all diesen Punkten kann der Wunschzettel des Kunden schnell größer werden als das Portemonnee. Aus diesem Grunde gilt immer: Der Umfang des Projekts wird beschränkt durch

• den Nutzen den das Projekt für den Kunden bringt
• die Ressourcen die zur Verfügung stehen (Arbeitskräft, IDEs, Hardware, GELD!)
• die Technologien die eingesetzt werden können/dürfen
• die Wünsche der späteren Nutzer bezüglich des Systems

Am Ende der Phase muss eine Produktvision stehen, die Aussage "Das zu entwickelnde System tut ...".

Diese Vision sollte schriftlich festgehalten werden (Sie gehört zum Auftrag!). Bei umfangreichen System kann dies einige Seiten Text bedeuten, aber nichts ist schlimmer als nach 2 Monaten Arbeit vom Kunde zu hören "Schön das ihre SW das kann, aber wir wollten das gar nicht, sondern ...".

Die Mitarbeit des Kunden/Auftraggebers ist ein entscheidender Punkt für den Erfolg/Akzeptanz der Software (siehe auch "IT Projektmanagement Kompakt" von Pascal Mangold; ISBN 3827415020). Vorallem zu Beginn des Projektes ist deshalb Kommunikation das wichtigste. Leider ist dabei nicht auszuschließen, dass es zu Missverständnissen kommt. Aus diesem Grund wird bei großen (und wichtigen) Projekten eine Art "Wörterbuch" mit Begriffen definiert, mit denen man sich unterhalten kann. Man spricht hier von "der Sprache des Anwendungsgebietes" (Domain Language). Es reicht aus, wenn alle Beteiligten wissen, wie man mit dem anderen Reden muss, es ist nicht wichtig dass dies schriftlich hinterlegt wird.

Prototyping und Risikobewertung

Was ist eigentlich "Risikobewertung"?

Jedes Projekt hängt vom Erfolg bzw. von der Realisierbarkeit bestimmter Sachverhalte ab. Zum Beispiel ist es für ein Online Spiel extrem wichtig, dass die Programmierer es schaffen eine Netzwerkverbindung zu bauen und ein Serversystem welches dem erwarteten Nutzeraufkommen gerecht wird. In Firmensoftware könnte wichtig sein, dass die Datenbank von 1967 in die SW integriert werden kann, oder dass eine bestimmte Hardware genutzt werden kann.

Sachverhalte die absolut essentiell für das Gelingen eines Projektes sind, enthalten das größte Risiko. Denn wenn sie fehlschlagen bzw. nicht umgesetzt werden können, dann stirbt meist auch das gesamte Projekt.

An diesem Punkt kommt das Prototyping ins Spiel. Es wird eigentlich nur benötigt, um zu testen, ob die riskanten Sachverhalte umgesetzt werden können oder nicht. Die dabei entstehenden Prototypen sind Wegwerfprodukte. Sie dienen nur dem Nachweis, ob man etwas machen kann oder nicht. Sie sind sind maximal Ideengeber. Der produzierte Code wird aber (weil nicht geplant und dokumentiert) nicht für das spätere System verwendet.

Es wird immer der Sachverhalt mit dem größten Risiko zuerst untersucht. Aus diesem Grund ist die Risikoanalyse von entscheidender Bedeutung.

Ohne Risikoanalyse kann man von Glück reden wenn sich ein Projekt zu einem frühen Zeitpunkt als "nicht durchführbar" herausstellt und nicht nach 6 Monaten Planung und Design.

Von Fall zu Fall - Use Case Diagramme

Wie oben bereits angesprochen sind Use Cases ein probates Mittel um heraus zu finden was das Programm eigentlich tun soll. Auf den ersten Blick sehen Use Case Diagramme (im folgenden UCD) recht harmlos, vielleicht sogar nutzlos aus. Der Schein trügt. Sie sind der Einstiegspunkt in die Entwicklung des System.

Doch der Reihe nach. Use Cases, zu deutsch Anwendungsfälle, bezeichnen Aufgaben und Situationen die das fertige Programm beherrschen muss. Das geht von "Spieler startet neues Spiel", über "Spieler baut Gebäude XYZ" bis hin zu "Gameserver fragt die Clienteinstellungen ab".

UCD bestehen aus den Use Cases und den sogenannten Akteuren, beide betrachten wir im folgenden noch genauer.

Hauptaufgabe eines Use Case Diagramms ist die Kommunikation zwischen Entwicklern und Anwendern über die Funktion des Systems. Aus diesem Grund wird bei der Dokumentation immer die Sprache des Einsatzgebietes (die Sprache des Kunden) benutzt, und nicht eine implementations Orientierte.

Jedes System besitzt mindestens ein UCD, das Haupt Use Case Diagramm (Main UCD). Dieses Diagramm zeigt die Systemgrenzen (Akteure) und Hauptfunktionen.

Zusätzlich dazu sind Use Cases zu folgenden Zwecken angemessen:

• UCD welches alle Use Cases eines Akteurs anzeigt.
• UCD welches alle Use Cases enthält die innerhalb eines Implementationsschrittes implementiert werden sollen.
• UCD welches einen Use Case mit all seinen Beziehungen zu anderen Use Cases zeigt. (Siehe Beziehungen zwischen Use Cases)

Akteure

Akteure sind nicht Teil der Software, sondern bezeichnen alle die Dinge und Personen, welche mit der Software interagieren müssen.

Akteure können nur 3 Funktionen übernehmen:

• Daten entgegen nehmen.
• Daten liefern
• Daten liefern und entgegen nehmen.

Wie findet man heraus, was ein Akteur für unsere Software ist? Zu diesem Zweck gibt es eine Checklist mit Fragen, welche man abarbeiten kann:

• Wer interessiert sich für eine bestimmte Anforderung?
• Wo in der Organisation des Kunden wird das System angewandt?
• Wer profitiert von der neuen Software?
• Wer liefert Informationen in die Software, wer benutzt Informationen aus der SW und wer entfernt Informationen aus der SW?
• Wer wartet und pflegt die SW?
• Nutzt die SW externe Ressourcen? (Die Ressourcen sind dann auch Akteure)
• Interagiert die SW mit einem Uralt-System (legacy System = Systeme die schön seit ewigen Zeiten in Benutzung sind)
• Hat eine Person mehrere Rollen? (Ein Akteur pro Rolle)
• Haben verschiedene Personen die selbe Rolle? (Ein Akteur pro Rolle)

Wenn man die KI eines Spieles als eigenständige Software sieht, wäre sie auch ein Akteur.

Nachdem die Akteure gefunden wurden, sollte man selbige Dokumentieren. Es geht dabei darum kurz verbal zu beschreiben was die Aufgaben des Akteurs sind. Absolut fehl am Platz sind hier Implementationsdetails wie Funktionen oder Propertys.

Use Cases

Use Cases repräsentieren Funktionen des Systems. Die formale Definition lautet: "Ein Use Case ist eine Abfolge von Transaktionen durch das System welche ein messbares Ergebnis von Werten für einen Nutzer bringt."

Auch zum finden von Use Cases gibt es eine Liste von Hilfsfragen:

• Welche Aufgaben hat jeder Akteur?
• Wird ein Akteur Informationen erstellen, speichern, ändern, entfernen oder lesen?
• Durch welche Anwendungsfälle werden Informationen erstellt, gespeichert, geändert, entfernt oder gelesen?
• Wird ein Akteur die Software über plötzliche externe Änderungen informieren?
• Muss ein Akteur über Vorkommnisse im System informiert werden?
• Welcher Use Case pflegt und wartet das System?
• Können alle funktionalen Anforderungen durch die Use Cases abgedeckt werden?

Von guten und schlechten Use Cases

Wann ist ein Use Case gut?

Über die Angemessenheit von Use Cases wurde viel diskutiert. Hauptsächlich bezüglich dem Detailgrad von Use Cases (also wie groß sie sein dürfen).

Als Richtschnur gelten bei solchen Fragen zwei Aussagen:

• Ein Use Case repräsentiert eine Hauptfunktion des Systems und zwar komplett vom Anfang bis zum Ende.
• Ein Use Case muss einem Akteur etwas von Wert zur Verfügung stellen.

Beispiel 1:
Sind Spieler wählt Multiplayerspiel, Spieler wird in die Liste der Teilnehmer aufgenommen und Spieler wählt Spielfigur aus' drei verschiedene Use Cases oder einer?

Laut den oben genannten Richtlinien ist die ein Use Case: Spieler startet Multiplayerspiel. Wieso? Weil alle 3 genannten Fälle Teile eines größeren sind und ohne die anderen nutzlos wären.

Beispiel 2:
Sind Spieler ändert Musikeinstellungen und Spieler ändert Spielauflösung verschiedene Use Cases oder einer?

Auch hier wäre wieder ein Use Case Spieler ändert Spieleinstellungen angebracht. Denn ein Akteur verändert die selbe Entität (Spieleinstellungen. Was eine Entität ist wird im zweiten Teil des Tutorials besprochen.)

Dokumentation von Use Cases

Auch Use Cases müssen Dokumentiert werden. Wie bei den Akteuren geht es darum die Aufgabe/Funktion des Use Cases grob zu erklären. Implementationsdetails sind nicht gefragt. Bei großen mehrstufigen Use Cases kann eine andere Methode angewandt werden:

Use Case Ereignisfluss

Der Ereignisfluss ist eine Beschreibung der Ereignisse stattfinden müssen, um das gewünschte Verhalten eines Use Cases zu erreichen.

Wichtig ist WAS nicht wie etwas gemacht werden soll. Aus diesem Grund wird die Sprache des Anwendungsgebietes benutzt nicht eine Implementationsorientierte.

Der Ereignisfluss enthält:

• Wann und Wie beginnt ein Use Case bzw. endet er.
• Welche Interaktionen hat der Use Case mit den Akteuren.
• Welche Daten benötigt der Use Case.
• Der normale (zu erwartende) Ereignisablauf für den Use Case.
• Eine Beschreibung der Alternativ- bzw. Exception Flüssen.

Um die Flüsse zu erstellen geht man iterativ vor:

• kurzer Abriss aller nötigen Events die für den normalen Fluss wichtig sind.

dann

• Ausbau der Stufen mit mehr Details

dann

• Hinzufügen von Exception Flüssen.

Innerhalb eines Projektes sollte man eine immer gleiche Vorlage(Template) für die Ereignisflüsse benutzen. Eine mögliche Vorlage wäre z.B.:

X. Ereignisfluss für den <NAME> Use Case
X.1. Vorbedingungen
X.2. Hauptfluss
X.3. Unterflüsse (Subflows; falls nötig)
X.4. Alternativflüsse

Die Beschreibung der Flüsse erfolgt verbal. ("Nutzer loggt sich ein und wählt einen Menüpunkt. Wenn Menüpunkt "XYZ" dann Unterfluss S1 sonst [...]")

Beziehungen zwischen Use Cases

Man unterscheidet zwei mögliche Beziehungsarten:

• unidirektionale Beziehungen gehen nur in eine Richtung
• bidirektionale Beziehungen gehen in beide Richtungen

Der Pfeil bei unidirektionalen Beziehungen zeigt auf den genutzen/aufgerufenen Use Case bzw. Akteur.

Neben diesen normalen Beziehungen gibt es noch zwei Sonderformen.

• Include-Beziehung

Teile/Funktionen welche in mehreren Use Cases benötigt werden, werden als eigenständiger Use Case dargestellt und über eine include-Beziehung einbezogen.

• Extend-Beziehungen

Funktionen welche als optionales Verhalten gelten, oder nur ausgeführt werden, wenn ein besonderes Ereignis eintritt (z.B. ein Alarm) bzw. Funktionen die nur von bestimmten Akteuren ausgelößt werden können, werden durch extend-Beziehungen eingebunden.

Aktivitätsdiagramme

Wir haben nun die Use Cases gefunden, welche unser System ausmachen. Aktivitätsdiagramme sind Flussdiagramme mit denen man den Workflow eines Systems zeigen kann. Man sieht in diesen Diagrammen gut wie der Kontrollfluss von Aktion zu Aktion wandert, was parallel laufen kann und welche Alternativen es gibt.

Nachdem die Use Cases gefunden wurden, können Aktivitätsdiagramme benutzt werden um den Fluss zwischen Use Cases zu zeigen, oder wie der Fluss in einem Use Case aussieht.

In Aktivitätsdiagrammen werden folgende UML Symbole verwendet:

Aktivität 

Repräsentiert ein bestimmtes Verhalten (Funktionalität) im Workflow.

Transition 

Symbolisiert die Übertragung des Kontrollflusses von einer Aktivität zur nächsten, und wird in der Regel durch den Abschluss des Vorgängers ausgelösst.

Entscheidung 

Zeigt alternative Flussmöglichkeiten. Ausgehend von der Entscheidung gehen sogenannte "bewachte" Transitions aus. Diese besitzen eine Bedingung die erfüllt sein muss, damit die Transition benutzt werden kann.

Synchronisationsbalken 

Sind eine Möglichkeit um Paralellität zu zeigen. Synch. Balken können mehrere ein und ausgehende Pfade haben.

Start und Endpunkt 

Sind die definierten Orte, wo ein Fluss startet und endet. Es kann mehrere Endpunkte geben, aber in der Regel nur einen Startpunkt.

Im Bild rechts sieht man ein mögliches Aktivitätsdiagram.

Als Swimlanes bezeichnet man die Linien welche das Diagramm in Bereiche unterteilen. Sie zeigen an, welche Personen oder Organisationen was im Workflow zu tun haben. Mein UML Editor bietet diese Möglichkeit im Moment noch nicht, aber wenn ihr sie seht, werdet ihr sie erkennen und verstehen.

Ausblick

6 Stunden Schreiberei sind vorüber und das Tutorial ist mittlerweile auf eine beachtliche Größe angewachsen. Mit dem Abschluss der Arbeiten an den Use Cases sind wir soweit Klassen zu bestimmen und die Interaktionen der Selbigen. Dies wird aber erst im zweiten Tutorial eine Rolle spielen. Jetzt wird erst einmal ausgeruht und Weihnachten gefeiert.

Wenn ihr das Tutorial einmal an einem eigenen Projekt umsetzt werdet ihr das Gefühl haben viel Zeit zu verbrauchen, ohne etwas produziert zu haben. Wenn ihr aber erst in der Implementationsphase seid, werdet ihr feststellen, dass ihr euch eine Menge Zeit spart, weil ihr sofort wisst wie welche Teile beschaffen sein müssen, damit am Ende eure Software herauskommt.

Außerdem müsst ihr immer daran denken: Die Dokumentation ist kein Extra. Die Dokumentation ist genauso Teil der Software wie der geschriebene Code.

Es ist durchaus realistisch, dass ihr 1-2 Wochen für Planung, Analyse und Design eines 15.000 Zeilen Programms benötigt, bis ihr die ersten Zeilen Code schreibt. (Professionelle Entwickler die einen >8h Tag haben, schaffen es vielleicht auch in der Hälfte der Zeit.) Aber was sind schon 2 Wochen, wenn ihr in den folgenden 4 Monaten in einem ordentlich strukutierten Code programmieren könnt. (Und den Code in einem Jahr noch versteht.)

Euer

Kevin Fleischer aka Flash