Software-Engineering / UML / Historie
Seminar, Schulung, Training

Historie

Die Idee der Objektorientierung ist über 30 Jahre alt und fast ebenso lange liegt die Entwicklung objektorientierter Programmiersprachen zurück. Während es etwa solange bereits Publikationen zur objektorientierten Programmierung gibt, erschienen die ersten Bücher über objektorientierte Analyse- und Designmethoden erst Anfang der 90er Jahre.

Zu ihnen gehören die von Booch, Coad und Yourdon, Rumbaugh u.a., Wirfs-Brock und Johnson, Shlaer und Mellor, Martin und Odell, Henderson-Sellers, Firesmith. Wichtige Impulse gaben auch Goldberg und Rubin sowie Jacobson. Viele Methoden sind auf bestimmte Anwendungsbereiche spezialisiert und begrenzt.

Die Methoden von Grady Booch und James Rumbaugh haben sich Anfang der 90er Jahre zu den deutlich beliebtesten Methoden entwickelt. Die Methode von Rumbaugh war dabei eher an die strukturierten Methoden angelehnt. Die von Booch deckte die Bereiche kommerzieller, technischer und vergleichsweise gut auch zeitkritischer Anwendungen ab. 1995 begannen Booch und Rumbaugh dann, ihre Methoden zunächst in Form einer gemeinsamen Notation zur Unified Method (UM) zusammenzuführen. Die Unified Method wurde jedoch schon bald in Unified Modeling Language (UML) umbenannt, was auch eine angemessenere Bezeichnung darstellte, weil es sich im wesentlichen nur um die Vereinheitlichung der grafischen Darstellung und Semantik der Modellierungselemente handelte, jedoch keine Methodik beschrieben wurde. Modeling Language ist hauptsächlich eine vornehmere Umschreibung für Notation.

Abb. 1.1: Historische Entwicklung objektorientierter Programmiersprachen.

Kurze Zeit später stieß auch Ivar Jacobson dazu, so daß die von ihm geprägten Use Cases (dt. Anwendungsfälle) integriert wurden. Die drei nannten sich fortan "Amigos". Weil die Methoden von Booch, Rumbaugh und Jacobson bereits sehr populär waren und einen hohen Marktanteil hatten, bildete die Zusammenführung zur Unified Modeling Language (UML) einen Quasi-Standard. Schließlich wurde 1997 die UML in der Version 1.1 bei der Object Management Group (OMG) zur Standardisierung eingereicht und akzeptiert. Die Versionen 1.2 bis 1.5 enthalten jeweils einige Korrekturen. Die Version 2.0 ist bei der OMG in Vorbereitung und wird ca. 2003/2004 erscheinen. Aktuelle Informationen hierzu finden Sie unter http://www.omg.org/uml/.

Die UML ist in erster Linie die Beschreibung einer einheitlichen Notation und Semantik sowie die Definition eines Metamodells. Die Beschreibung einer Entwicklungsmethode gehört nicht direkt dazu, sie wurde erst Anfang 1999 mit der Publikation des Buches [Jacobson99, The Unified Software Development Process], dem sogenannten Unified Process (UP) auf einem sehr abstrakten Niveau nachgeliefert. Eine konkretere Methodik findet sich in der 5. Auflage des Buches "Objektorientierte Softwareentwicklung, Analyse und Design mit der UML" von Bernd Oestereich. Zu dem von den Amigos publizierten Vorgehen Unified Process gibt es ebenfalls verschiedene Ausprägungen, beispielsweise den Rational Unified Process (RUP) und den Object Engineering Process (OEP).

Die UML ist sehr vielfältig und integriert auch interessante Ideen und Konzepte anderer Autoren. Neben den Gedanken von Booch, Rumbaugh und Jacobson finden sich zum Beispiel auch die von Harel (Zustandsdiagramme) wieder.

Abb. 1.2: Historische Entwicklung objektorientierter Methoden und der UML.

Erdrückende Vielfalt? Die Grundkonzepte objektorientierter Softwareentwicklungsmethodik sind ausgereift und bewähren sich in der Praxis. Andererseits bietet gerade die UML einen beachtlichen Detailreichtum und ist daher durchaus mit Bedacht anzuwenden.

Die Vielfalt der Beschreibungsmöglichkeiten kann sehr erdrückend wirken, ein tieferes Verständnis für die UML-Konstrukte in allen Facetten erfordert einigen Aufwand. In einer ersten Annäherung kann man sich deshalb auf die grundlegenden Elemente beschränken. In unseren Seminaren berücksichtigen wir diese Erkenntnisse explizit und vermitteln auch, welche UML-Konstrukte in der Prxais problematisch und welche wichtig sind. Es bleiben dadurch gegebenenfalls zwar semantische Lücken in der Modellierung, dennoch kann die Arbeit auf diesem Niveau in der Praxis ausreichen. Ganz abgesehen davon wird vielerorts überhaupt keine Systematik angewendet.

Seminar, Schulung, Training