Blind mit UML arbeiten: Unterschied zwischen den Versionen

Version vom 25. März 2011, 23:10 Uhr

Blind mit UML arbeiten

Worum geht's genau

Die Unified Modeling Language (UML) hat sich als Standard im Bereich der Softwareentwicklung und -Designs durchgesetzt. Systeme oder Teile davon werden in UML beschrieben und vor dort aus in die Entwicklung überführt. Allgemein wird unter UML eine grafische Notation verstanden, die blinden Menschen so nicht zugänglich ist. Das bedeutet, sie können an allen Prozessen nicht teilnehmen, bei denen UML-diagramme verarbeitet weren müssen.

Die Lösung in Kurzform

Eine Lösung des Problems findet sich in der freien Anwendung PlantUml [[1]]. Das Programm verarbeitet eine textuelle Notation und erstellt daraus ein Bild in UML-Notation. Kollegen können umgekehrt ein Modell in dieser textuellen Notation abfassen, mit dem Programm verifizieren und dem blinden Kollegen zur Verarbeitung übergeben. Es ist auch möglich, aus einem Verzeichnis mit Java-Klassen ein Klassendiagramme generieren zu lassen - in textueller Notation und damit blindenkompatibel.

Das ganze im Detail

Hintergrund und Motivation

Ich arbeite seit zehn Jahren als Softwareentwickler. Projekte in der professionellen Softwareentwicklung ohne Usecases und detailliertes Design sind eigentlich zum Scheitern verurteilt und werden zumindest bei uns in der Praxis nicht mehr gelebt. Kurzum: Bei jedem Projekt ist ein Entwickler, auch wenn er nur programmiert, immer mit Designs, Usecases und damit mit UML umgeben. Vergleichbar ist das wohl am besten mit dem Musiker, der keine Noten kann. Er kann sicher auch gut spielen, aber wenn er in einem Orchester mitspielen möchte, kommt er um Noten einfach nicht herum. Nun sind es meine Kollegen gewohnt, dass ich viel des Designs im Kopf habe, dem ganz gut folgen kann und meine Gedanken textuell - allso in kryptischem Prosa darlegen kann. Das funktioniert dann nicht mehr, wenn man in vielen Projekten gleichzeitig arbeitet, oder schnell sich in ein Design einarbeiten soll, ohne dass es einem jemand erklärt.

Durch die Erfahrung und der Ausbildung bin ich aber andererseits gut geeignet, um mich mehr um die Architektur von Projekten zu kümmern und damit fleißend UML zu können. In diesem Dilemma nimmt der Druck, eine Lösung für das Problem zu finden massiv zu - man könnte sagen, das meine berufliche Weiterentwicklung blockiert war.

Der Weg =

Das Problem begann damit, dass es keine geeigneten Schulungen, Bücher oder andere Unterlagen über UML gab, die ich verwenden konnte. Die Konzepte kann man zwar verstehen - denn diese sind alles andere als grafisch, aber "Noten" kann ich deswegen immer noch nicht - nur die Theorie. Es ist mir nach wie vor nicht gelungen, auch nur ein Buch aufzutreiben, in dem UML inkl. der grafischen Notation wirklich für blinde Menschen erklärt wird. Damit meine ich die gesamte UML und nicht ein Detail wie Klassendiagramme. Das zweite Problem bestand darin, ein Werkzeug zu finden, mit dem ich meine Gedanken in UML abfassen kann - allso grafisch darstellen kann. Eine Suche bei Google liefert in der Tat viele Ergebnisse und man solte meinen, dass es bei der Fülle von Anwendungen kein unlösbares Problem sein sollte. In dr Praxis sind alle bis auf das o.g. PlantUml gescheitert. Hier ein kurzer Abriß:

• TextUml ist eine Eclipse-Erweiterung, mit der man UML quasi programmieren kann. Allerdings scheiterte der Einsatz daran, dass b bislang nur Klassendiagramme unterstützt werden. Das ist für die praktische Softwareentwicklung nicht genug!
• Metauml ist eine auf metapost basierende Erweiterung für Latex, mit der man UML-Diagramme setzen kann. Zum einen muss man recht viel Layout vorgeben, was in der Praxis recht schwer sein dürfte. Zum anderen ist das Resultat eine Metapostscript-Datei, die nicht ohne Weiteres in z.B. Word-Dokumenten integriert werden kann. Es scheiterte allso an der Einbindung in unsere Prozesse und Problemen bei der praktischen Anwendung. Außerdem wird das Paket seit 2006 nicht mehr gepflegt.
• Andere LateX-Pakete unterstützen nur Sequenz- und Klassendiagramme. Beides nicht ausreichend für den praktischen Einsatz.
• Andere reine textuelle Notationen sind recht komplex in der Syntax und es gibt keinen Parser oder Anwendungen, die den Code in Bilder umwandeln könnten. Sie wären allso ehrer das notwendige Übel, als eine gute Lösung gewesen.

... Fortsetzung folgt.