Die Modellierung ist einer der wichtigsten Ausgangspunkte für ein neues Softwareprojekt. Zu viele Entwickler starten ohne klare Spezifikation, immer wieder fällt mir dies im Arbeitsalltag mit Entwicklern auf.
Man schreibt eben ein Worddokument und legt mit dem "coden" los. Die Resultate sind meist unzureichend wichtige Details wurden vergessen, das Datenmodell ist unvollständig und der Programmcode übersäht von Fehlern und Inkonsistenzen. Um dies zu vermeiden ist eine Möglichkeit auf die mächtigen Funktionen der heutigen RDBMS zurückzugreifen, selbst das Datenmodell zu gestalten und strickt mit Constraints (Regeln) zu versehen so wird der Programmierer beim Coden eben durch Datenbankfehler auf seine Fehler im Code aufmerksam gemacht.
Doch wenn es um größere Tabellenstrukturen geht verliert man schnell den Überblick dann ist es sinnvoll ein Tool zur Modellierung einzusetzen. Zur Modellierung gibt es viele unterschiedliche möglichkeiten welche auch teils ganz unterschiedliche Ansätze verfolgen. So ist beispielsweise die ER-Modellierung (Entity Relationship Modellierung) sehr beliebt um die Strukturen von Daten darzustellen. ER-Modelle sind noch recht abstrakt und beinhalten die Wichtigsten Entitäten deren wichtigste Attribute und zusammenhänge, daher sind diese geeignet um einen groben Überblick zu geben. Jedoch sind ER-Modelle zu abstrakt um diese automatisch weiterzu verarbeiten hierfür bietet sich UML an UML (Unified Modelling Language) ist eine auf XML basierende Sprache um Datenmodelle, Klassendiagramme, Geschäftsprozesse usw. abzubilden. Auf diese und mögliche Werkzeuge möchte ich im Folgenden gern näher eingehen.
Was ist UML genau?
UML steht für Unified Modelling Language und ist eine sogenannte Markuplanguage welche mittlerweile in 
Version 2.1 existiert. Da UML eine Markuplanguage ist wie auch z.B. HTML, BPEL oder jBMP werden die Daten in Klartext mit XML-ähnlicher Syntax abgespeichert. Das schöne daran da UML klare Standards definiert können diese Daten auch an jedes Werkzeug welches die Standards kennt weitergegeben und von diesem verarbeitet werden. Nun ist es natürlich reichlich uninteressant seine UML Diagramme in XML zu verfassen dafür gibt es Werkzeuge mit welchen man ähnlich wie in Visio seine Modelle gestaltet.
Also brauche ich Visio?
Visio ist klasse ein Programm mit dem ich Netzwerke abbilde, Tabllenbeziehungen abbilden kann, Geschäftsprozesse schön bunt gestalte und nebenher noch einen Grundriss und Einrichtungsplan für mein Wohnzimmer gestalte ja manche nutzen Visio sogar das System zum anfertigen von Produktbroschüren.
Und für viele dieser Zwecke eignet sich Visio auch spitzenmäßig, gerade Netzwerkdiagramme können damit schön übersichtlich dargestellt werden und Visio ist dafür bis zu einer gewissen Größe sicher das Beste.
Jedoch nicht für Daten welche sinnvoll weiter verwendet werden sollen also Datenmodelle, Klassendiagramme oder Geschäftsprozesse diese sollten selbst im kleineren Rahmen UML konform gestaltet werden das entscheidende Detail ist die automatische oder teilautomatische Weiterverarbeitung von Daten welche UML Tools ermöglichen so ist der noch theoretische Idealfall ein Unternehmen bildet seine Geschäftsprozesse und -daten exakt ab und ein weiteres Werkzeug baut den entsprechenden Programmcode. Solche Werkzeuge gibt es bislang nur für kleine Teilausschnitte und dennoch derart komplex dass deren Abhandlung den Rahmen dieses Artikels sprengen würde. Dennoch sehen wir uns doch ganz praktische Vorteile von UML Modellen an. So kann beispielsweise - diese Funktion bringt die Mehrheit von Werkzeugen gleich mit- aus einem Datenmodell in welchem sämtliche Tabellen, Felder und Beziehungen abgebildet wurden, direkt der nötige SQL Code für eine Datenbank erstellt werden, dies minimiert die Gefahr von Inkonsistenzen.
Weitere Beispiele sind Geschäftsprozesse welche z.B. in BPM übersetzt und somit direkt für Workflow Managementsysteme lesbar werden.
Diese Möglichkeiten jedoch, bietet Visio meines Wissens allerdings nicht.
Also welches Werkzeug dann?
Der Markt an UML-Werkzeugen mittlerweile äußerst reich und bietet für jeden wie auch jede Größe die entsprechenden Lösungen im Großeinsatz ist wohl Rational Rose von IBM unschlagbar. Für den Einsatz in kleineren und mittleren Projekten jedoch schlichtweg unrealistisch und wahrscheinlich auch nicht effizient da die Einführung aufwendiger als das eigentliche Projekt wäre. Daher lege ich mein Augenmerk auf übersichtliche und bezahlbare Werkzeuge.
Bei mit im Test ist momentan der Enterprise Architect vom australischen Unternehmen Sparxsystems.
Bisherige Erfahrungen
Bislang habe ich verschiedene Eclipse Plug-in's und eigenständige Freewarelösungen wie AgroUML, StarUML und UMLpad getestet. Am meisten lagen mir dabei StarUML und AgroUML. UMLpad dagegen ist optisch zwar grauenvoll dafür aber nur wenige Megabyte schwer. Doch alle bieten über die Basisfunktionen kaum interessantes an und sind doch recht umständlich zu verwenden.
Enterprise Architect (Sparxsystems)
Der Enterprise Architect ist die Erste Lösung welche mich richtig begeistert hat und erscheint in 3 Versionen beginnend bei 99Euro die Desktop Edition welche sich ausschließlich auf die reine UML Modellierung beschränkt, dann die Professional Version zu 149Euro welche ich derzeit testet und auch schon einige Codegeneratoren und Plug-in's für Visual Studio und Eclipse mitbringt.
Richtig interessant wird es bei der Cooperate-Edition. In dieser kann man als Speicher für die Modelle auch ein RDBMS wie MS-SQL Server nutzen und hat eine Security integriert durch welche man bestimmten Benutzern auch ausschließlich zugriff auf bestimmte Modelle oder Modellausschnitte geben kann.
Die Verwendung von EA ist absolut simple und man findet sich wirklich schnell zurecht.
Und wie wird verfahren?
Modelle sind wenn diese alle wichtigen Fälle eines Unternehmens abdecken schon sehr komplex vor allem wenn diese auch technische Modelle wie Daten und Klassen festhalten daher sollte man Modelle grundsätzlich abstrahieren um die Übersichtlichkeit zu wahren. Dabei wären Möglichkeiten zunächst nur relevante Geschäftsvorfälle zu modellieren und nicht jeden alle paar Jahre Vorkommenden Sonderfall bis ins letzte Detail festzuhalten. Ein weiterer Schritt wäre die Modelle in eigene Entitäten aufzuteilen, folgende wäre eine folgende Unterteilung denkbar:
Organisationsmodell, dieses ist als Grundlage für weitere Modelle anzusehen und stellt vor allem die eigentlichen Geschäftsvorfälle dar welche das wissen liefern um erforderliche Daten und Funktionen zu definieren.
Datenmodell, hier sollte definiert werden welche Daten in welcher Form wohin gespeichert werden, zumeist ist das ziel wohl ein Datenbanksystem aber dies können auch XML Dateien, entfernte Speicherung oder gar eine Mischung aus mehreren Methoden sein.
Auf Basis dieser beiden Modelle können nun Programmabläufe modelliert werden für welche UML verschiedene Modelle anbietet. Diese basieren nun immer einerseits auf den Geschäftsprozessen und andererseits den Daten.
Das interessante dabei ist der symbolische Idealfall in dem ein Business Analyst die Prozesse eines Unternehmens erfasst und Modelliert hierdurch zeigt er seine Probleme auf. Im nächsten Schritt berät er das Unternehmen hinsichtlich der Prozessoptimierung wobei man immer das Augenmerk auf das Geschäft setzt und nicht etwa die technische Realisierung. Sind Berater und Unternehmensführung dann mit dem optimierten Modell zufrieden, werden auf Basis desselben Systems die technischen Modelle gestaltet. Dies sind beispielsweise Datenmodelle, Klassendiagramme, selbst Programmtests können so definiert werden.
Spätere Weiterverarbeitung
Die Modelle werden innerhalb der Programme meist intern in properitären Datenbanken verwaltet und bieten dann wenn es denn erforderlich wird den Export in UML konforme XML-Dateien an. Oder Generieren wie der Enterprise Architect ab der Professional-Edition direkt die erforderlichen Code-Snippets.
Dieser Artikel diente zunächst dem Ziel eine Idee von der UML und deren Zusammenhang mit Datenbank, Quellcode und anderen Modellierungsmethoden zu bekommen. In einem Folgebeitrag plane ich näher auf die Praktische Anwendung der UML am Beispiel von Enterprise Architect einzugehen.
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5