3.3. Warum ist ArgoUML anders

In der Einleitung listeten wir vier Dinge auf, die ArgoUML anders machen:

  1. es macht Gebrauch von den Ideen der kognitiven Psychologie,

  2. es basiert auf offenen Standards;

  3. es ist 100% reines Java; und

  4. es ist ein Open-Source-Projekt.

3.3.1. Kognitive Psychologie

3.3.1.1. Theorie

ArgoUML ist teilweise durch die drei Theorien der kognitiven Psychologie inspiriert:

  1. Reflektion-während-Aktion,

  2. Opportunistisches Design und

  3. Verständnis und Problemlösung.

  • Reflektion-während-Aktion

    Diese Theorie unterstellt, dass sich die Designer eines komplexen Systems das vollständig ausgeformte Design nicht vorstellen können. Stattdessen müssen Sie ein Teil-Design entwerfen, evaluieren, es reflektieren und überarbeiten, bis Sie soweit sind, es weiter zu erweitern.

    Da sich die Entwickler sehr intensiv mit dem Design beschäftigen, verbessert sich auch ihr mentales Modell der Problemsituation. Und dies führt zur Verbesserung Ihres Designs.

  • Opportunistisches Design

    Eine Theorie innerhalb der kognitiven Psychologie besagt, dass obwohl Designer ihre Arbeit in einer geordneten, hierarchischen Art und Weise beschreiben, sie in der Realität aufeinanderfolgende Aktivitäten auf der Basis kognitiver Kosten wählen.

    Einfach ausgedrückt, Designer folgen nicht ihrer selbst geplanten Reihenfolge, sondern wählen Schritte, die mental weniger aufwändige Alternativen darstellen.

  • Verständlichkeit und Problemlösung

    Eine Design-Visualisierungstheorie innerhalb der kognitiven Psychologie. Die Theorie beschreibt, dass Designer eine Brücke zwischen Ihrem mentalen Modell des Problemes oder der Situation und dem formalen Modell einer Lösung oder eines Systems überwinden müssen.

    Diese Theorie besagt, dass Programmierer Vorteile haben von:

    1. Mehreren Darstellungsweisen, wie die syntaktische Programmzerlegung, Zustandsübergänge, Steuer- und Datenfluss. Diese erlauben es dem Programmierer, die Elemente und Beziehungen innerhalb des Problemes und der Lösung besser zu identifizieren und daher die Abbildung zwischen deren Situationsmodellen und den funktionierenden Systemmodellen leichter herstellen zu können.

    2. Vertraute Aspekte eines Situationsmodelles, welche die Fähigkeiten des Designers verbessern, Lösungen zu formulieren.

3.3.1.2. Praktische Anwendung in ArgoUML

ArgoUML implementiert diese Theorien durch eine bestimmte Anzahl von Techniken.

  1. Das Design der Anwenderschnittstelle, die es dem Anwender erlaubt, das Design aus unterschiedlichen Sichten zu betrachten und es dem Anwender ermöglicht, Ziele über eine Anzahl alternativer Wege zu erreichen.

  2. Die Verwendung von parallel ablaufenden Prozessen im Designtool, die das aktuelle Design gegen „best practice“-Entwurfsmodelle überprüfen. Diese Prozesse sind als Design-Kritiken bekannt.

  3. Die Nutzung von zu bearbeiten Listen, die dem Anwender Vorschläge aus den Designkritiken unterbreiten und es ihm auch erlauben, Bereiche für künftige Aktionen aufzuzeichnen.

  4. Die Verwendung von Checklisten, um den Anwender durch einen komplexen Prozess zu führen.

3.3.2. Offene Standards

Die UML ist selbst ein offener Standard. ArgoUML hat überall versucht, offene Standards für alle seine Schnittstellen zu verwenden.

Der Hauptvorteil am Festhalten an offenen Standards ist, dass es die einfache Zusammenarbeit zwischen Anwendungen erlaubt und die Möglichkeit eröffnet, von einer Anwendung zu einer anderen wechseln, sofern dies notwendig ist.

3.3.2.1. XML Metadaten-Austausch (Metadata Interchange XMI)

XML Metadata Interchange (XMI) ist der Standard für das Speichern von Metadaten, die ein bestimmtes UML-Modell darstellen. Im Prinzip erlaubt er es, das in ArgoUML erstellte Modell in ein anderes Tool zu importieren.

Dies hat klare Vorteile, die es der UML erlaubt, sein Ziel zu erreichen, der Standard für die Kommunikation zwischen Designern zu sein.

Die Realität sieht nicht so gut aus. Vor UML 2.0 enthielten die XMI-Dateien keine Informationen über die grafische Darstellung der Modelle, so dass das Diagramm- Layout verloren ging. ArgoUML umgeht dies, indem es die grafische Information separat vom Modell speichert. (siehes Abschnitt 3.4.3.1, „ Laden und Speichern).

3.3.2.2. Grafik-Formate - EPS, GIF, PGML, PNG, PS, SVG

  • Die Encapsulated PostScript (EPS)-Datei weist zusätzliche Beschränkungen auf. Diese Beschränkungen sind dazu gedacht, es der Software einfacher zu machen, eine EPS-Datei in ein anderes PostScript-Dokument einzubetten.

  • Das Graphics Interchange Format (GIF) verwendet eine verlustlose Kompression und erhält scharfe Kanten, wodurch es für ArgoUML gut geeignet ist. Das GIF-Format ist ein patentgeschütztes Format. Aber aktuell sind alle Patente abgelaufen.

  • Precision Graphics Markup Language (PGML) ist eine XML-basierte Sprache zur Darstellung von Vektorgrafiken. Sie war ein W3C-Entwurf, der aber nicht als Empfehlung übernommen wurde. PGML und VML, andere XML-basierte Vektor- Grafik-Sprachen, wurden später miteinander verknüpft und verbessert, um daraus SVG (siehe unten) zu erzeugen.

  • Portable Network Graphics (PNG) ist ein ISO/IEC-Standard (15948:2004) und auch eine W3C- Empfehlung. PNG ist ein Bitmap-Bildformat, das eine verlustlose Datenkompression verwendet. PNG wurde eingesetzt, um das GIF-Format durch ein Bildformat zu ersetzen, das die Nutzung einer Patentlizenz entbehrlich macht. PNG wird offiziell "ping" ausgesprochen, wird aber auch sehr oft buchstabiert - wahrscheinlich, um eine Verwechslung mit dem Netzwerktool ping zu vermeiden. PNG wird durch die libpng-Referenzbibliothek unterstützt, eine plattformunabhängige Bibliothek, die C-Funktionen für die Anwendung von PNG-Bildern enthält.

  • PostScript (PS) ist eine Seitenbeschreibungs- und Programmiersprache, die primär in elektronischen und Desktop-Publishing-Bereichen eingesetzt wird.

  • Scalable Vector Graphics (SVG) ist eine XML-Markup-Sprache für die Beschreibung zweidimensionaler Vektorgrafiken, die sowohl statisch als auch animiert und entweder deklarativ oder beschreibend. Sie ist ein offener Standard, der durch das World Wide Web Konsortium erstellt wurde. Der Verwendung von SVG im Web befindet sich noch im Anfangsstadium. Es gibt eine grosse Trägheit aufgrund der langjährigen Nutzung reiner Raster- und anderer Formate wie Macromedia Flash oder Java-Applets. Aber auch die Browserunterstützung ist uneinheitlich, mit eingebauter Unterstützung in Opera und Firefox, während Safari und der Internet Exlorer ein Plugin benötigen. Siehe PGML oben.

3.3.2.3. Objekt-Bedingungs-Sprache (Object Constraint Language OCL)

Die Object Constraint Language (OCL) ist eine deklarative Sprache zur Beschreibung von Regeln, die auf UML-Modelle angewendet werden. Sie wurde durch IBM entwickelt, und ist jetzt Teil des UML-Standard. Ursprünglich war OCL nur als formale Spezifikations-Sprach- Erweiterung von UML gedacht. OCL kann jetzt mit jedem Meta-Object Facility (MOF) konformen Metamodell einschliesslich UML angewendet werden. Die Object Constraint Language ist eine präzise Textsprache, die Bedingungen und Objekt-Abfrageausdrücke für jedes MOF- oder Meta-Modell enthält, die nicht auf andere Art durch eine Diagramm- Notation ausgedrückt werden können.

3.3.3. 100% reines Java

Java wurde als interpretierende Sprache erdacht. Es ist kein Compiler, der Code für jede beliebige Zielmaschine erzeugt. Sie übersetzt den Code für sein eigenes Ziel, der Java Virtual Machine (JVM).

Das Schreiben eines Interpreters für eine JVM ist sehr viel leichter, als das Schreiben eines Compilers und, solche Maschinen sind jetzt in fast jedem Web Browser eingebaut. Im Ergebnis können die meisten Maschinen Java, ohne dass es weiterer Arbeiten bedarf.

(Für den Fall, dass Sie sich wundern, warum nicht alle Sprachen so sind wie diese, dann deshalb, weil interpretierende Sprachen langsamer sind als übersetzende Sprachen. Mit der hohen Leistung moderner PC's und dem Handlungszwang nach Portabilität ist diese Einschränkung für viele Applikationen trotzdem lohnenswert. Darüber hinaus können moderne Multi-Cache-Systeme bedeuten, dass interpretierende Sprachen, die dichteren Code produzierenden, aktuell nicht mehr sehr viel langsamer sind.)

Durch die Entscheidung, ArgoUML in reinem Java zu schreiben, wird ArgoUML für sehr viele Anwender mit einem minimalem Aufwand unmittelbar verfügbar.

3.3.4. Offener Quellcode (Open Source)

ArgoUML ist ein Open Source-Projekt. Das bedeutet, jeder kann eine freie Kopie des Quellcodes haben, diesen ändern und für neue Zwecke einsetzen usw.. Die einzige (Haupt-) Bedingung ist, dass Sie Ihren Code auf die gleiche Weise anderen zur Verfügung stellen. Die genaue Ausprägung, was Sie tun können und was nicht, variiert von Projekt zu Projekt, aber das Prinzip ist das gleiche.

Der Vorteil ist, dass ein kleines Projekt wie ArgoUML immer für zusätzliche Unterstützung offen ist. Insbesondere für diejenigen, die Ihre Ideen einbringen, wie das Programm verbessert werden kann. Jederzeit können 10, 15, 20 oder mehr Personen signifikante Beiträge zu ArgoUML leisten. Dies kommerziell zu machen, würde mehr als 1 Mio. $ pro Jahr kosten.

Es ist aber nicht nur der Geist reiner Uneigennützigkeit. Hier mitzuarbeiten ist ein Weg, „nebenbei“ mehr über führende Software zu lernen. Es ist auch ein Weg, viel Aufmerksamkeit (über 1.125.000 Personen haben ArgoUML Ende 2005 heruntergeladen) zu bekommen. In Ihrem Lebenslauf ist das eine sehr gute Erfahrung und eine Menge Arbeitgeber sehen Sie!

Und es ist hervorragend für Ihr Ego!

Open Source schliesst das Geld verdienen nicht aus. Gentleware www.gentleware.com verkauft eine kommerzielle Version von ArgoUML: Poseidon. Deren Angebot ist nicht der Code. Es ist der kommerzielle Support, der das Risiko bei der Nutzung von ArgoUML in einer kommerziellen Entwicklung reduziert und es dem Kunden erlaubt, die Vorteile von ArgoUML's führender Technologie zu nutzen.