Der moderne Softwareentwicklungsprozess mit UML
Kapitel 1: Einführung
Inhaltsverzeichnis
Dieses Buch ist unter einer Creative Commons-Lizenz lizensiert.
1.1 Eine kurze Geschichte der Softwareentwicklung
Höher, schneller, weiter
Wer als Anfänger die ersten Schritte in einer einfach zu erlernenden Programmiersprache wie zum Beispiel Basic macht, freut sich riesig, wenn er nach vielen Stunden sein erstes selbstgeschriebenes Programm zum Laufen bringt, das gerademal aus einer handvoll Code-Zeilen besteht. Natürlich fallen einem prompt Unmengen an Verbesserungen ein, so dass der Umfang des Quellcodes Schritt für Schritt wächst. Da sich unser Programmierneuling darauf konzentriert, Variablen, Operatoren und Kontrollstrukturen richtig einzusetzen, wird der Quellcode da ergänzt, wo es gerade passt. Aus diesem chaotisch-kreativen Prozess, der in Basic vor allem durch das bei Anfängern beliebte Schlüsselwort GOTO unterstützt wird, entsteht Spaghetti-Code: Ein heilloses Durcheinander von auf sich gegenseitig verweisenden Code-Teilen, das ab einer bestimmten Größe nicht mehr zu durchblicken ist.
Auf der Suche nach Ordnung lernt unser Programmierneuling prozedurale Programmiersprachen wie C kennen. Er begreift, dass er seinen Quellcode gliedern muss, indem er Funktionen bildet. Der Quellcode kann dann aus tausenden von Zeilen bestehen und bleibt verständlich, solange die Funktionen überschaubar bleiben. Mit Kenntnissen in der Programmiersprache C ausgerüstet macht er sich dran, sein vormals in Basic entwickeltes Programm nun endlich mit all den Features zu versehen, die ihm im Spaghetti-Code verloren gegangen sind.
Die Entwicklung des Programms in C macht gute Fortschritte. Je größer der Code wird, desto mehr kommt es aber zu Problemen: Immer mehr Funktionen greifen auf globale Variablen zu, lesen sie aus oder speichern Ergebnisse in ihnen. Da immer mehr Funktionen auf diese Variablen zugreifen, geht der Überblick verloren, in welcher Reihenfolge Zugriffe stattfinden, welche Funktionen Werte in den Variablen erwarten und welche Funktionen Werte überschreiben, indem sie neue Werte speichern. Der Zugriff von immer mehr Funktionen auf globale Variablen als auch die vielen kreuz und quer stattfindenden Funktionsaufrufe führen zu steigenden Problemen in der Entwicklung.
Während unser Entwickler darüber nachdenkt, wie er die Probleme in den Griff bekommt, wird er auf die Objektorientierung aufmerksam. Die Programmiersprache C++ scheint die Lösung zu sein: Anstatt globale Variablen ungeschützt allen Funktionen auszuliefern, werden Variablen und Funktionen zu Klassen vereint. Auf einmal spielen nicht mehr Abläufe wie Funktionsaufrufe die tonangebende Rolle, sondern Objekte. Die Objektorientierung als ein Konzept, das zur Problemlösung Objekte aus der Wirklichkeit modelliert, kommt der Denkweise unseres Entwicklers sehr entgegen. Er ist überzeugt, dass die Objektorientierung ihm helfen kann - so portiert er seinen C-Quellcode nach C++.
Dank der Objektorientierung erhält sein Quellcode eine neue Struktur, die ihm hilft, sein Programm mit mehr und mehr Features zu versehen, ohne die Übersicht im immer größer werdenden Quellcode zu verlieren. Er schafft es, sein Programm fertigzustellen und bietet es zum Verkauf - und das Interesse ist riesig. Nach kurzer Zeit ist ein Vertrag mit einem der größten Softwarehersteller der Welt unter Dach und Fach, der ihm viel Geld und einen neuen Job einbringt: Er wird Chef-Entwickler und bleibt verantwortlich für die zukünftige Entwicklung seines Programms. Darüber hinaus bekommt er zur Unterstützung ein Team von Softwareentwicklern zur Seite gestellt und Anforderungen für die nächste Version vom Management genannt - und einen Termin, bis wann die nächste Version fertig sein muss.
1.2 Probleme in der Softwareentwicklung heute
Herausforderungen in der Softwareentwicklung
Die Objektorientierung ist heute das am weitesten verbreitete Programmierkonzept. Sie ist aber nicht die Lösung aller Probleme. Der Blick auf die nächste große Stufe in der Evolution der Softwareentwicklung ist noch etwas verschwommen. Es scheint aber momentan so, als ob die Unified Modeling Language, kurz UML, viele Probleme lösen kann, die wie oben angesprochen in der heutigen Softwareentwicklung existieren.
Wie bei unserem Entwickler, der klein anfängt und nach einiger Zeit ein großes ausgereiftes Programm fertigstellt, wird der Quellcode von allen Programmen mit der Zeit größer und größer. Es wird dadurch automatisch schwieriger, den Überblick zu behalten, weil immer mehr Zeilen an Quellcode zu überblicken sind.
Es ist nicht nur schwierig, sich in einem aus unüberschaubar vielen Zeilen bestehenden Quellcode auszukennen - es stellt sich auch die Frage, auf welche Weise der Quellcode erweitert werden soll, damit die noch vorhandene Übersicht erhalten bleibt und es nicht eines Tages zu einem Spaghetti-Code auf hohem Niveau kommt. Es ist irgendeine Form von Planung notwendig, damit nicht nach Belieben an verschiedenen Stellen im Code Änderungen durchgeführt oder Erweiterungen eingebaut werden.
Während eigene Entwicklungsschritte geplant werden können, fällt dies bei technischen Entwicklungen sehr viel schwerer. So wie unser Entwickler mit Basic angefangen hat, dann auf C gesetzt hat, um letztendlich auf C++ umzusatteln, weiß kein Mensch heute, welche Programmiersprachen und Plattformen morgen wichtig sein werden. Niemand konnte den Erfolg von Java vorhersehen. Und niemand weiß, wie weit verbreitet und wichtig .NET in ein paar Jahren sein wird. Ein andauerndes Portieren von Quellcode von einer Programmiersprache oder Plattform zur nächsten kann keine sinnvolle Lösung sein.
Wer eines Tages in einem Team von Softwareentwicklern arbeitet, muss viel Zeit aufwenden, um sich mit seinen Kollegen abzusprechen. Dieser Koordinationsaufwand ist notwendig, wenn das Team gemeinsam eine Software fertigstellen soll. Schließlich muss jeder wissen, was er zu tun hat und was die anderen tun, damit am Ende alles ineinander greifen kann. Für diese Koordinierungsarbeit braucht man ein Instrument, will man sich nicht alle fünf Minuten zu einer Telefonkonferenz zusammenschalten und sich über neue Probleme beim Schreiben des Quellcodes unterhalten.
Nicht nur die Koordinierung mit Softwareentwicklern, sondern auch mit anderen Gruppen wie dem Management eines Unternehmens kann notwendig sein. Derartige Koordinationsprozesse sind besonders schwer, da Softwareentwickler mit Nicht-Technikern zusammentreffen. Wenn das Management Anforderungen an die Softwareentwicklung weitergibt, kann diese nicht einfach Quellcode zurückschicken und fragen, ob dieser den Anforderungen wie gewünscht entspricht.
Zu all diesen Problemen kommt, dass es meistens feste Termine gibt, zu denen eine Softwareentwicklung abgeschlossen sein muss - und zwar mit allen genannten Anforderungen, natürlich fehlerfrei und in hoher Qualität und selbstverständlich im Rahmen des zur Verfügung stehenden Budgets. Ohne Planung lassen sich all diese Ziele nur schwer erreichen. Die UML soll dem gestressten Softwareentwickler nun zur Seite stehen, um diese Probleme in den Griff zu bekommen.
1.3 Lösungsansätze der Unified Modeling Language
Die UML - ein breit unterstützter Standard
Die Unified Modeling Language, kurz UML, ist eine durch die Object Management Group standardisierte Modellierungssprache. In der Object Management Group, kurz OMG, sind etwa 800 Unternehmen vereint, die gemeinsam Standards entwickeln, die für die objektorientierte Softwareentwicklung von Nutzen sein sollen. All diesen Unternehmen liegen effiziente Softwareentwicklungsprozesse am Herzen, da Software wesentlich über den Erfolg ihrer Produkte und Dienstleistungen entscheidet. Zu den Mitgliedern der OMG zählen daher natürlich Schwergewichte der Softwareindustrie wie zum Beispiel IBM, Borland, Oracle und Sun. Aber auch branchenfremde Unternehmen wie DaimlerChrysler und Nokia sind in der OMG vertreten - sogar die NASA ist mit dabei. Es soll aber nicht unerwähnt bleiben, dass ein wichtiges, da sehr erfolgreiches und in der Softwareindustrie extrem einflußreiches Unternehmen fehlt: Microsoft ist kein OMG-Mitglied.
Einer der von der OMG entwickelten Standards ist die UML. Die UML hat eine lange Entwicklungsgeschichte hinter sich und ist aus verschiedenen anderen Sprachen entstanden, die 1997 vereint und in der UML 1.0 standardisiert wurden. Nach zahlreichen kleinen Verbesserungen, die von der UML 1.0 zur UML 1.5 führten, wurde im Juni 2003 der letzte Teil der Spezifikation der UML 2.0 offiziell verabschiedet. Nach zwei Jahren gründlicher Prüfung, in denen Fehler behoben und sonstige Ungereimtheiten geklärt wurden, ist die UML 2.0 2005 in Kraft getreten und hat die UML 1.x abgelöst.
Eine Bildersprache für eine bessere Verständlichkeit
Was ist nun aber die UML genau? Wie bereits erwähnt handelt es sich bei der UML um eine Modellierungssprache. Wie jede andere Sprache auch legt sie einen Sprachumfang in der Art fest, dass sie sagt, welche Begriffe Teil der Sprache sind und was die Bedeutung dieser Begriffe ist. Das ist nichts anderes als was Sie von Programmiersprachen kennen. Auch hier wird festgelegt, welche Schlüsselwörter zur Programmiersprache gehören und was ihre Bedeutung ist. So definiert zum Beispiel die Programmiersprache C++ ein Schlüsselwort if, mit dem Bedingungen überprüft werden können und in Abhängigkeit dieser Bedingungen unterschiedliche Anweisungsblöcke ausgeführt werden.
Es gibt aber einen entscheidenden Unterschied zwischen einer Programmiersprache wie C++ und der UML: Während in C++ und anderen Programmiersprachen Schlüsselwörter tatsächlich Wörter sind, ist die UML eine Sprache, die aus einfachen geometrischen Formen besteht. Das heißt, ein in der UML definierter Begriff ist kein Wort, sondern zum Beispiel ein Rechteck. Die UML definiert zahlreiche geometrische Formen wie Rechtecke, Pfeile und Ellipsen und legt fest, welche Bedeutung diese Formen haben.
So wie bei einer natürlichen Sprache Wörter zusammengestellt werden können, um Sätze zu bilden, können auch geometrischen Formen der UML kombiniert werden. Die UML legt entsprechende Regeln fest, wie Formen zusammengestellt werden können, damit sie gemeinsam etwas sinnvolles aussagen. Man könnte dieses Regelwerk als die Grammatik der UML bezeichnen.
Die Aussagen, die durch geometrische Formen der UML gemacht werden können, drehen sich natürlich immer um die Softwareentwicklung. Die UML ist keine Sprache, mit der Sie sich beim Bäcker verständigen und Brötchen einkaufen können. Als Modellierungssprache ist in der UML alles daraufhin ausgerichtet, Modelle zu erstellen. Diese Modelle sind nicht natürlich-sprachlich und bestehen nicht aus Wörtern, sondern aus geometrischen Formen - sie sind daher Zeichnungen. Man wählt zur Darstellung dieser Modelle Zeichnungen, weil man der Ansicht ist, dass eine Zeichnung wesentlich schneller verstanden und überblickt werden kann als zum Beispiel ein Text. So wie die objektorientierte Softwareentwicklung versucht, der natürlichen Denkweise eines Entwicklers entgegen zu kommen, sollen grafische Darstellungen als Hilfsmittel in der Softwareentwicklung ebenfalls für den Entwickler von größerem Nutzen sein als andere Darstellungsformen - ganz nach dem Motto: Ein Bild sagt mehr als tausend Worte.
Was haben Modelle aber nun mit Softwareentwicklung zu tun? Ein Modell ist die Betrachtung eines Teilausschnitts, wobei wichtige Aspekte herausgestellt und unwichtige Aspekte vernachlässigt werden. Mit einem Modell soll also ein Teilsystem genau untersucht werden können, wobei dieses Teilsystem nicht vollständig beschrieben wird: Das, was wichtig ist, wird modelliert, der Rest wird weggelassen. Ein Modell ist also kein Nachbau eines Originals, sondern eine vereinfachte Beschreibung des Originals mit dem Ziel, das Original besser verstehen zu können. Wenn Ihnen ein Modell genauso wenig sagt wie das Original, ist es ein schlechtes Modell - es bringt Ihnen keinen Vorteil.
Die UML stellt als Modellierungssprache geometrische Formen zur Verfügung, mit denen Modelle von Software erstellt werden können. Die geometrischen Formen ergeben zusammengesetzt Zeichnungen, die ganz bestimmte Strukturen einer Software oder Abläufe in einer Software darstellen. In der UML ist dabei nicht von Zeichnungen die Rede, sondern von Diagrammen. Je nach Diagramm werden unterschiedliche Aspekte der Software hervorgehoben. Jedes Diagramm stellt also ein Modell dar, das ganz bestimmte Aspekte der Software hervorhebt - eine Software wird durch Diagramme aus verschiedenen Blickwinkeln beschrieben.
Da je nach Blickwinkel unterschiedliche geometrische Formen und Regeln zum Zusammenstellen dieser Formen notwendig sein können, definiert die UML 13 Diagrammtypen. Das ist insofern hilfreich als dass Sie beim Erstellen eines Diagramms nicht mit sämtlichen geometrischen Formen hantieren müssen, sondern nur die Formen verwenden, die für den Diagrammtyp vorgesehen sind. Wenn Sie zum Beispiel ein Diagramm erstellen, um die Struktur einer Software abzubilden, können Sie alles vergessen, was die UML zur Darstellung von Abläufen zur Verfügung stellt. Das erleichtert den Einsatz der UML in der Praxis.
13 Diagrammtypen für unterschiedliche Blickwinkel
Die UML rechnet alle 13 Diagrammtypen entweder den Strukturdiagrammen oder den Verhaltensdiagrammen zu. Strukturdiagramme sind Modelle einer Struktur und somit statisch. Sie stellen Zusammenhänge in einer Software zu einem bestimmten Zeitpunkt dar. Verhaltensdiagramme hingegen erklären Abläufe. Sie sind dynamisch und stellen Zusammenhänge im Zeitablauf dar.
Folgende sechs Diagrammtypen werden zu den Strukturdiagrammen gezählt.
Klassendiagramm: Das Klassendiagramm ist der wichtigste Diagrammtyp der UML. Mit ihm werden Klassen beschrieben und Zusammenhänge zwischen Klassen dargestellt. Es wird ausführlich im vierten Kapitel vorgestellt.
Objektdiagramm: Dieser Diagrammtyp stellt die während der Laufzeit zu einem bestimmten Zeitpunkt existierenden Objekte und deren Zusammenhänge dar. Während Klassen während der gesamten Laufzeit eines Programms existieren, können Objekte erstellt und zerstört werden. Das Objektdiagramm ist daher eine Momentaufnahme, während das Klassendiagramm zeitlos ist.
Komponentendiagramm: Der Name dieses Diagramms geht auf das Konzept von Komponenten zurück, mit dem Einheiten beschrieben werden, die quasi die nächsthöhere Ebene über den Klassen darstellen und vor allem über Schnittstellen beschrieben werden.
Kompositionsstrukturdiagramm: Das Kompositionsstrukturdiagramm könnte als Gegenstück zum Komponentendiagramm bezeichnet werden - es beschreibt die interne Struktur von Kompositionen wie eben zum Beispiel von Komponenten.
Verteilungsdiagramm: Dieser Diagrammtyp ist vor allem für verteilte Software interessant, wenn beschrieben werden muss, auf welchen Geräten welche Programme ausgeführt werden und wie diese Programme miteinander kommunizieren. Verteilte Software sind zum Beispiel Client-Server-Applikationen wie Chat-Systeme oder Online-Spiele.
Paketdiagramm: Im Paketdiagramm werden Klassen zu Paketen gruppiert. Pakete werden in modernen Programmiersprachen wie Java oder C# eingesetzt, um Klassen übersichtlich anzuordnen.
Zu den Verhaltensdiagrammen zählen folgende sieben Diagrammtypen.
Use-Case-Diagramm: Dieser Diagrammtyp beschreibt, wie die Software mit dem Anwender interagiert. Use-Case-Diagramme werden eingesetzt, um Anforderungen an eine zu entwickelnde Software zu beschreiben. Im zweiten Kapitel lernen Sie Use-Case-Diagramme kennen.
Aktivitätsdiagramm: Das Aktivitätsdiagramm ist das All-Round-Diagramm der UML zur Beschreibung von Abläufen. Es beschreibt den Ablauf von Aktionen und ist in seinen Darstellungsmöglichkeiten sehr flexibel. Sie lernen diesen Diagrammtyp im dritten Kapitel kennen.
Zustandsautomat: Der Zustandsautomat beschreibt einen Ablauf nicht als Aneinanderreihung von Aktionen, sondern als Zustandswechsel.
Sequenzdiagramm: Im Sequenzdiagramm liegt der Fokus auf Abläufen, die zwischen mehreren interagierenden Partnern stattfinden. Das können zum Beispiel Klassen oder Objekte sein.
Kommunikationsdiagramm: Das Kommunikationsdiagramm ist eine andere Form des Sequenzdiagramms, wobei der Fokus nun nicht mehr auf den Abläufen zwischen interagierenden Partnern liegt, sondern auf den interagierenden Partnern selbst. Das Kommunikationsdiagramm hat daher etwas von einem Strukturdiagramm.
Timing-Diagramm: Timing-Diagramme werden eingesetzt, wenn nicht nur die Reihenfolge von Abläufen eine Rolle spielt, sondern auch Zeitangaben wichtig sind. So kann im Timing-Diagramm zum Beispiel beschrieben werden, nach wie vielen Sekunden eine Aktion auf eine andere zu folgen hat.
Interaktionsübersichtsdiagramm: Dieser Diagrammtyp mit dem sperrigen Namen Interaktionsübersichtsdiagramm vereint mehrere Verhaltensdiagramme, um deren Zusammenspiel darzustellen. So können zum Beispiel mehrere Aktivitäts- und Sequenzdiagramme in einem Interaktionsübersichtsdiagramm zusammengefügt werden, um Zusammenhänge zwischen den in verschiedenen Diagrammen abgebildeten Abläufen darzustellen.
Der UML-Standard ist mit seinen 13 Diagrammtypen nicht gerade klein. Die 2003 veröffentlichte Spezifikation der UML-Version 2.0 umfasst vier Dokumente mit insgesamt mehr als 1000 Seiten. Dieses Buch kann daher nur eine Einführung sein und einen groben Überblick über die UML geben, ohne dass sämtliche Elemente dieser Modellierungssprache vorgestellt werden können.
Vorteile der UML
Eine Frage bleibt aber noch: Wie will die UML nun mit all diesen Diagrammtypen die heutigen Probleme in der Softwareentwicklung lösen?
Die Modellierung von Software soll helfen, den Überblick zu behalten. Anstatt tausende Zeilen von Quellcode mit unendlich vielen technischen Details vor Augen zu haben soll der Entwickler das Ganze im Blick behalten. Die zahlreichen Diagrammtypen der UML sollen die Software aus unterschiedlichen Blickwinkeln beleuchten und auf diese Weise überschaubar bleiben, zusammengenommen aber ein Gesamtbild der Software abgeben.
Modelle richten sich nach Anforderungen und basieren auf Elementen der UML. Der Sprachumfang der UML ist dabei unabhängig von Programmiersprachen und Plattformen. Die errichteten Modelle der Software sind somit ebenfalls unabhängig von derartigen Technologien. Egal, welche Programmiersprachen und Plattformen in Zukunft für Sie wichtig sein werden - die Modelle Ihrer Software bleiben gültig und müssen nicht an technische Entwicklungen angepasst werden.
Als Koordinierungsinstrument ist die UML ebenfalls geeignet: Jeder Entwickler, der die UML kennt, wird Modelle in Form von UML-Diagrammen verstehen können. Wer für die Entwicklung einer Software ein Modell erstellt und dies mit UML-Diagrammen festhält, kann Softwareentwickler mit diesem Instrument koordinieren und das Entwicklungsvorhaben im Team vorantreiben. Da die UML eine grafische Modellierungssprache ist, eignen sich die Diagramme in eingeschränktem Maße auch, um sich mit Nicht-Technikern wie zum Beispiel dem Management eines Unternehmens zu koordinieren. Wenn das Diagramm ein Modell darstellt, das auf technische Details verzichtet und Anforderungen enthält, die vom Management aufgestellt wurden, kann das Management mit solchen Diagrammen durchaus prüfen, ob alle Anforderungen erfasst und richtig verstanden worden sind.
1.4 Bekannte UML-Software
Rational Rose, Together, Poseidon for UML und viele andere
Um die UML anwenden zu können, brauchen Sie eigentlich nur Stift und Papier. Wenn Sie die von der UML definierten geometrischen Formen aufzeichnen und diese nach den in der UML festgelegten Regeln zu Diagrammen zusammenstellen, sind Sie schon mitten in der Softwaremodellierung. Für Unternehmen kann es sich auch anbieten, Tafeln einzusetzen. So können zum Beispiel während einer Besprechung tatsächlich UML-Diagramme an die Tafel gemalt werden, über die dann diskutiert werden kann.
Wer Stift und Papier abgeneigt ist und Tastatur und Maus vorzieht, kann sich für eines der zahlreichen Modellierungsprogramme entscheiden. Der Markt der UML-Werkzeuge ist bereits so groß, dass er kaum noch überschaubar ist. So bestehen zwischen den verschiedenen angebotenen Programmen große Unterschiede. Eine Übersicht über mehr als 100 UML-Werkzeuge finden Sie hier.
Einer der bekanntesten Anbieter von Modellierungssoftware war Rational Software. Die Firma existiert nicht mehr, nachdem sie 2002 von IBM gekauft und in das Unternehmen integriert wurde. Der Name der Modellierungssoftware blieb aber erhalten: In der Rational Rose-Reihe verkauft IBM verschiedene Editionen seines UML-Werkzeugs, die sich in Entwicklungsumgebungen integrieren lassen und somit die Modellierung besonders einfach machen sollen - Modelle und Quellcode sind schließlich vereint. So richtet sich Rational Rose XDE Developer for Visual Studio an Entwickler, die mit Microsoft Visual Studio .NET arbeiten, während Rational Rose XDE Developer for Java für diejenigen gedacht ist, die Software für die Java-Plattform entwickeln und zum Beispiel Eclipse als Entwicklungsumgebung einsetzen.
Die verschiedenen Editionen von Rational Rose machen jedoch einen Vorteil der UML zunichte: Die Technologieunabhängigkeit von Modellen ist nicht mehr gegeben. Schließlich können Sie im einen Fall nur Software für die .NET-Plattform, im anderen Fall nur Software für die Java-Plattform erstellen. Die Technologieunabhängigkeit der UML ist heute jedoch tatsächlich mehr Wunsch als Wirklichkeit. Eine vollständig von Technologien unabhängige Softwaremodellierung, die aus UML-Diagrammen quasi auf Knopfdruck eine für eine ausgewählte Plattform ausführbare Software erzeugt, ist ein langfristiges Ziel. Um dieses Ziel zu erreichen, arbeiten viele Unternehmen wie bei der Entwicklung des UML-Standards zusammen - und zwar ebenfalls wieder in der OMG. Dieses ganz große Projekt läuft unter dem Namen Model Driven Architecture, kurz MDA.
Ausgewachsene professionelle UML-Werkzeuge wie Rational Rose, die aus UML-Diagrammen auf Knopfdruck Quellcode erstellen können, kosten vier- oder sogar fünfstellige Summen. Grundsätzlich gilt: Je besser die Code-Generierung durch die Modellierungssoftware unterstützt wird, umso teurer ist das UML-Werkzeug. Eine automatische Übersetzung eines Modells in Quellcode nimmt viel Arbeit ab und ist daher heiß begehrt.
Ähnlich teuer ist Together, das von Borland angebotene UML-Werkzeug. Borland ist bekannt für die Programmiersprache Delphi, die von dieser Firma entwickelt wurde und für die auch gleich eine passende Entwicklungsumgebung angeboten wird. Es ist nicht untypisch, dass Anbieter von Entwicklungsumgebungen ihre Produktpalette um Modellierungssoftware erweitern, da immer mehr die Einsicht um sich greift, dass Software entwickeln mehr als Programmieren ist. Anbieter von Entwicklungsumgebungen haben einen direkten Draht zu Softwareentwicklern, so dass es ganz natürlich ist, seinen Kunden zur Entwicklungsumgebung passende Modellierungssoftware anzubieten.
Dieser Trend geht auch an Microsoft nicht vorbei, auch wenn Microsoft kein OMG-Mitglied ist. Microsoft hat seiner Entwicklungsumgebung Visual Studio .NET 2005 erstmals Werkzeuge hinzugefügt, die ähnlich wie die Klassendiagramme der UML einen Überblick über Klassen und ihre Zusammenhänge ermöglichen. Es handelt sich hierbei jedoch nicht um echte UML-Diagramme. Microsoft hat bisher auch keine Pläne angekündigt, die UML in Visual Studio von Haus aus zu unterstützen. Wer in Visual Studio UML-Diagramme einsetzen möchte, muss also auf Erweiterungen wie Rational Rose zurückgreifen.
Die UML-Diagramme in diesem Buch wurden mit Poseidon for UML Professional Edition 3.0 erstellt. Poseidon for UML wird von der in Hamburg ansässigen Firma Gentleware entwickelt und wird aus folgenden Gründen als Referenzwerkzeug in diesem Buch verwendet.
Gentleware bietet eine Edition seiner Modellierungssoftware für 30 Tage kostenlos an. Die Poseidon for UML Community Edition ermöglicht es Ihnen, erste eigene Schritte mit der UML zu tun, ohne Geld für ein UML-Werkzeug ausgeben zu müssen.
Die Poseidon for UML-Reihe basiert auf der Java-Plattform und kann daher auf allen gängigen Betriebssystemen eingesetzt werden. Egal, ob Sie als Betriebssystem Microsoft Windows, Linux oder Mac OS X verwenden - Sie können Poseidon for UML zum Experimentieren einsetzen. Sie benötigen lediglich Unterstützung für Java. Die aktuelle Java Runtime Edition können Sie hier kostenlos herunterladen.
Bestimmte Poseidon for UML-Editionen können seit der Version 3.0 in eine Entwicklungsumgebung integriert werden. Das ist jedoch kein Muss. Sie können Poseidon for UML als unabhängige Modellierungssoftware einsetzen - völlig egal, mit welchen Entwicklungsumgebungen Sie arbeiten. Es ist also keine bestimmte Entwicklungsumgebung notwendig, um Poseidon for UML verwenden zu können.
Poseidon for UML unterstützt XML Metadata Interchange, kurz XMI, in der Version 1.2. XMI ist das für die UML standardisierte Austauschformat für Diagramme. Jede Software, die XMI unterstützt, kann UML-Diagramme in diesem Format speichern und laden. Wenn Sie eines Tages Ihre Modellierungssoftware wechseln möchten, können Sie Ihre UML-Diagramme im XMI 1.2-Format speichern, in einer anderen Modellierungssoftware laden und weiterarbeiten. Das standardisierte Austauschformat ermöglicht also, jederzeit das UML-Werkzeug wechseln zu können, ohne getätigte Investitionen in Softwaremodelle zu verlieren.
Zuguterletzt soll nicht unerwähnt bleiben, dass Gentleware die Arbeit an diesem Buch unterstützt und eine Lizenz für Poseidon for UML Professional Edition 3.0 zur Verfügung gestellt hat.
1.5 Aufgabenstellung
Ihre Mission
Die UML lässt sich am besten an Beispielen darstellen. Da UML-Diagramme Modelle einer Software sind und nicht für jedes Beispiel eine neue Software modelliert werden soll, werden im Folgenden Anforderungen festgelegt, die für alle Beispiele in diesem Buch gelten.
Ihre Aufgabe in diesem Buch ist es, einen Online-Shop zu entwickeln. Sämtliche UML-Diagramme in diesem Buch drehen sich um die Entwicklung des Online-Shops. In diesem sollen beliebig viele Artikel angeboten werden, die von Kunden aus verschiedenen Ländern in Europa bestellt werden können. Im Detail soll der Online-Shop folgendes bieten.
Alle im Online-Shop erhältlichen Artikel besitzen eine eindeutige Artikelnummer, einen Namen und einen Preis. Außerdem sollen Artikel aus dem Angebot entfernt werden können, ohne ihre Daten aus dem System zu löschen.
Während des Bestellvorgangs geben Kunden eine Rechnungs- und Lieferanschrift ein. Grundsätzlich wird zwischen diesen beiden Anschriften nicht unterschieden. Wenn ein Kunde es verlangt, kann er jedoch unterschiedliche Adressen für Rechnung und Lieferung angeben.
Die Rechnungs- und Lieferanschrift bestehen aus der Anrede, die Kunden aus einer Liste wählen, dem Vor- und Nachnamen, der Strasse, Hausnummer, Postleitzahl und dem Ort. Da Bestellungen europaweit ausgeliefert werden, wählen Kunden außerdem ihr Land aus einer Liste aus. Für die Zustellung über einen Paketdienst ins Ausland ist es notwendig, dass Kunden auch ihre Telefonnummer angeben. Darüber hinaus müssen sie ihre Email-Adresse angeben, an die am Ende des Bestellvorgangs eine Bestätigungsmail geschickt wird.
Kunden dürfen wählen, auf welche Weise sie ihre Bestellung bezahlen möchten. Als Zahlungsmethoden stehen Nachnahme, Bankeinzug und Vorauskasse zur Verfügung. Je nach gewählter Zahlungsmethode fallen zusätzliche Kosten an. Außerdem muss beachtet werden, dass je nach Land, in das die Bestellung ausgeliefert werden soll, unterschiedlich hohe Kosten für Zahlungsmethoden anfallen: Zum Beispiel ist die Nachnahmegebühr im Inland geringer als die Nachnahmegebühr bei einem Versand ins Ausland.
Was für Kosten für Zahlungsmethoden gilt, trifft auch auf Verpackungs- und Versandkosten zu: Diese fallen je nach Land unterschiedlich hoch aus.
Es dürfen nur Bestellungen aus Ländern entgegengenommen werden, bei denen die Kosten von mindestens einer Zahlungsmethode bekannt sind. Ist also für ein Land nicht bekannt, was ein Versand per Nachnahme, Bankeinzug oder Vorauskasse an Kosten verursacht, darf für dieses Land keine Bestellung entgegengenommen werden. Dieses Land darf also nicht bei Eingabe einer Lieferanschrift ausgewählt werden können.
Es dürfen für eine Bestellung in ein Land nur die Zahlungsmethoden angeboten werden, für die die Kosten der Zahlungsmethoden für dieses Land bekannt sind. Ist zum Beispiel nicht bekannt, was ein Versand per Nachnahme nach Italien kosten würde, darf die Nachnahme als Zahlungsmethode für Bestellungen aus Italien natürlich nicht angeboten werden. Sind lediglich die Kosten für eine Zahlungsmethode bekannt, hat der Kunde keine Wahl und wird automatisch zu dieser Zahlungsmethode weitergeleitet.
Wenn der Wert einer Bestellung eine festgelegte Grenze überschreitet, werden keine Verpackungs- und Versandkosten in Rechnung gestellt.
Kundendaten müssen bei der Eingabe auf Vollständigkeit und Richtigkeit überprüft werden, soweit dies technisch möglich ist. Fehlen Daten oder sind Daten falsch angegeben, müssen verständliche Fehlermeldungen ausgegeben werden, die gleichzeitig erklären, wie der Fehler behoben werden kann.
In vielen Ländern, in die geliefert wird, gibt es einen Distributor, an den Bestellungen im Online-Shop weitergeleitet werden. Das muss auf sicherem Weg geschehen, da mit Kunden- und Bestelldaten natürlich verantwortungsvoll umgegangen wird. Gleichzeitig soll diese Weitergabe jedoch automatisiert sein, um den Aufwand zur Auslieferung von Bestellungen niedrig zu halten. Da diese Distributoren mit unterschiedlichen Softwaresystemen arbeiten, müssen Kunden- und Bestelldaten im jeweils richtigen Format weitergegeben werden.
Da es nicht für jedes Land, in das geliefert wird, einen dort ansässigen Distributor gibt, sind einige Distributoren für mehrere Länder verantwortlich.
1.6 Übersetzung von UML-Begriffen
Einheitliche Begriffe in deutschsprachigen Texten
Der UML-Standard ist in Englisch verfasst und enthält keine Empfehlungen, wie Schlüsselwörter in andere Sprachen zu übersetzen sind. Wenn nun aber jeder Autor Schlüsselwörter anders übersetzt, geht der Vorteil eines Standards verloren: Der eine sagt A, der andere sagt B, und beide meinen das gleiche.
Um ein derartiges Sprachwirrwarr zu vermeiden, haben sich verschiedene Autoren und Verlage im deutschsprachigen Raum geeinigt, wie wichtige UML-Begriffe zu übersetzen sind. Die deutschsprachigen Übersetzungen dieser Begriffe wurde in der UML-Übersetzungstabelle zusammengefasst.
Die in diesem Buch verwendeten deutschen UML-Begriffe wurden der UML-Übersetzungstabelle entnommen. Sie können daher sicher sein, dass die Werkzeuge, die im UML-Standard definiert sind, in diesem Buch genauso heißen wie in den meisten anderen deutschsprachigen Texten, die sich mit der UML befassen - seien es Artikel in Zeitschriften oder Bücher zur UML.