Entwicklung eines Klassengraphen

Transkript

1 Johann Wolfgang Goethe Universität Frankfurt am Main Diplomarbeit Entwicklung eines Klassengraphen von Carsten Rudolf Stocklöw Fachbereich Biologie und Informatik Prüfer: Prof. Dr.- Ing. D. Krömker Betreuer: Dipl.-Inform. Tobias Breiner vorgelegt am 30. September 2004

2

3 Inhaltsverzeichnis Kapitel 1 Einleitung Software Engineering Refaktorisierung Sichten auf ein Software-System Aufbau der Arbeit... 5 Kapitel 2 Graphische Darstellungsmöglichkeiten Objektorientierte Analyse- und Designmethoden UML Geschichte Überblick Die Four Layer Modeling Architecture Infrastructure und Superstructure Erweiterungsmöglichkeiten Diagramme und Views Klassen- und Objektdiagramm Model Management Paketdiagramm Weitere Diagramme...30 Kapitel 3 Stand der Technik Programm: ClassBuilder 2.4 Alpha Programm: Jumli Programm: Metamill v3.1 (build 556) Programm: ObjectDomain R3 (build 292) Programm: objectif Programm: Rational Rose Enterprise Edition ( ) Programm: WithClass 2000 Enterprise Weitere Programme Fazit Kapitel 4 Diskussion und Konzept Die Programmiersprache C Die graphische Darstellung Datentypen, Zeiger und Referenzen Module und Komponenten Klassen Methoden Synchronisation mit Sourcecode Design... 65

4 Kapitel 5 Implementierung Parser, Präprozessor Alternative Darstellungen Präprozessor Symbolische Konstanten und Makros Dateien einfügen Bedingte Kompilierung Weitere Direktiven Unterstützung durch das Programm Analyseverfahren Automatisches Layout Ästhetik Layoutalgorithmen Das Programm DiaClassma Übersicht Externe Komponenten Graphische Benutzungsoberfläche Explorer Klassendiagramm Parser Datenverwaltung...90 Kapitel 6 Bewertung Anhang A Glossar Anhang B Stand der Technik Anhang C Inhalt der beigefügten CD-ROM Anhang D Abbildungsverzeichnis Anhang E Literaturverzeichnis

5 Kapitel 1 Einleitung Heutige Softwaresysteme gewinnen zunehmend an Komplexität. Manche objektorientierte Programme bestehen aus mehreren hundert, wenn nicht sogar tausend Klassen, die üblicherweise in Form einfacher Textdateien vorliegen. Einen kompletten Programmcode aus hunderttausenden von Codezeilen zu verstehen und damit zu arbeiten, während er kontinuierlich weiterentwickelt wird, ist für einen Menschen nicht zu bewältigen. Deshalb entwickeln meist eine große Anzahl von Leuten an einem Software-Projekt und sind nur für bestimmte Bereiche zuständig. Aber auch hier muss man den Überblick behalten, sowohl für das gesamte Software-System als auch für einzelne Teile, die im Zusammenspiel aufeinander abgestimmt werden müssen. Nun kann diese Problematik mit der Natur der Programmiersprachen zusammenhängen, die als Sprachen per se linear orientiert sind. Es stellt sich die Frage, ob graphische Darstellungen besser geeignet wären. Durch das Hinzufügen einer zweiten oder gar einer dritten Dimension könnten Vererbungshierarchien und vernetzte Zusammenhänge wie beispielsweise Funktionsaufrufe besser visualisiert und durch das Ausblenden von Implementierungsdetails auf einen Blick erfasst werden. Im Laufe der Zeit haben sich einige Hilfen für Programmierer entwickelt: Dokumentationserstellung Anhand eines vorhandenen Sourcecodes wird eine Dokumentation erstellt, beispielsweise im HTML-Format Wizards Wizards (engl. für Zauberer) sind kleine Helfer, die überall eingesetzt werden können und üblicherweise durch die kurze Abfrage einiger Informationen eine Aufgabe erfüllen. So kann es beispielsweise einen Wizard geben, der durch Abfrage eines Klassennamens eine neue Klasse erstellt. Editoren Erweiterungen für einfache Texteditoren sind Syntax-Highlighting, Klammerungsanzeige (zu einer Klammer wird die entsprechende andere Klammer im Quelltext markiert), Vervollständigung von Wörtern, Sprung zur Definition eines Elements, Ausblenden von Methoden-Code (selten benutzte Methoden werden nur als Rumpf angezeigt), transparente Kommentare 1

6 Kapitel 1 Einleitung (Graphische) Darstellung von Klassen, Methoden, Attributen und ihren Beziehungen zueinander Quellcodeverwaltung und Versionskontrollsysteme (CVS, RVS, SVN,..) Debugger Automatische Erzeugung von Quellcode für bestimmte Aufgabenbereiche (z.b. Parser- und Lexergeneratoren) Dialogeditoren Metriken Metriken bilden Software auf einen Zahlenwert ab. Beispiel: Lines of Code (LOC) ist die Anzahl der Programmzeilen Profiler... Einige dieser Hilfen sind graphischer Natur und viele andere könnten graphisch visualisiert werden. So könnte beispielsweise die Metrik LOC visualisiert werden durch ein Balkendiagramm, in dem für jede Datei oder jede Programmkomponente angegeben wird, aus wie vielen Codezeilen es besteht. Das Programm Manhatten ([W3-Manhatt]) erzeugt aus Sourcecode eine virtuelle dreidimensionale Stadt, in der jede Methode durch ein Hochhaus dargestellt wird. Die Anzahl der Programmzeilen der Methode bestimmt die Höhe des Hauses und die Menge an Kommentaren wird durch die grünliche Färbung der Rasenfläche um die Häuser dargestellt. Diesen Weg wollen wir hier jedoch nicht beschreiten. In der vorliegenden Arbeit sollen nur Möglichkeiten untersucht werden, bei denen der Programmcode graphisch dargestellt wird und bei denen eine Änderung in der graphischen Darstellung auch zu einem veränderten Sourcecode führt. Dies kann man als graphisches Programmieren bezeichnen. Die Kernfrage, die in dieser Arbeit untersucht werden soll, ist, ob graphisch orientierte Tools die Programmierung wesentlich beschleunigen können. Dabei wird hauptsächlich auf eine wenn möglich automatische Visualisierung der vernetzten Strukturen von Klassen und Methoden Wert gelegt. 2

7 1.1 Software Engineering 1.1 Software Engineering Um Sourcecode graphisch darstellen zu können, muss er zuerst verarbeitet werden. Aus mehreren simplen Textdateien werden so die Konstruktionselemente gewonnen. Dies sind Klassen mit Attributen und Methoden sowie Methodenkörper, die aus einfachen Anweisungen und Kontrollstrukturen bestehen. Weiterhin werden die Beziehungen zwischen diesen Elementen gesucht. Dieses Verfahren wird Reverse Engineering genannt. Das Gegenteil ist das Forward Engineering, bei dem aus den Konstruktionselementen wieder ein Sourcecode entsteht. Nimmt man beide Verfahren zusammen, so erhält man die Möglichkeit, aus Sourcecode Konstruktionselemente zu erhalten, zu verändern und wieder in Sourcecode zu überführen. Dies wird Roundtrip Engineering oder Re-Engineering genannt. Werden keine Veränderungen vorgenommen, so sollte man im Idealfall den ursprünglichen Sourcecode wieder erhalten. 1.2 Refaktorisierung Ist das Reverse Engineering abgeschlossen, kann mit den Konstruktionselementen gearbeitet werden. So ist auch Refaktorisierung möglich. Diese Bezeichnung (engl.: Refactoring) wurde erstmals 1990 von William Opdyke und Ralph Johnson ([OpJo90]) benutzt und beschreibt das Umstrukturieren von vorhandenem Sourcecode ohne dessen Funktionalität zu beeinträchtigen. Die Semantik bleibt also erhalten, aber Lesbarkeit und Struktur des Sourcecodes wird verbessert. Refaktorisierung beinhaltet u.a.: Umbenennen Vorhandenen Klassen, Attributen oder Methoden einen neuen Namen geben Attribute kapseln Es werden neue Methoden eingeführt, so dass ein Zugriff auf Attribute nur über diese Methoden möglich ist Methode extrahieren Ein markierter Teil einer Methode wird extrahiert und als neue separate Methode angelegt Reihenfolge ändern Das Ändern der Reihenfolge der Parameter einer Methode oder der Reihenfolge der Methoden, in der sie im Sourcecode auftauchen 3

8 1.2 Refaktorisierung Schnittstelle extrahieren Anhand einer gegebenen Klasse CGeg wird eine neue Klasse CNeu erstellt, so dass einige der Methoden von CGeg in CNeu als abstrakte Methoden definiert werden. Zusätzlich wird eine Generalisierung eingeführt, so dass CNeu eine Generalisierung von CGeg darstellt. Subklasse extrahieren Entsprechend der Extraktion einer Schnittstelle kann auch Funktionalität in eine neue Subklasse ausgelagert werden. Variable für einen Ausdruck anlegen Wird in einem Codefragment mehrmals ein langer oder jedes mal neu auszuwertender Ausdruck benutzt, so kann eine neue Variable eingeführt werden, die am Anfang den Wert dieses Ausdrucks annimmt. Jedes Vorkommen des Ausdrucks im Codefragment wird durch die Variable ersetzt. 1.3 Sichten auf ein Software-System Ein Software-System kann aus verschiedenen Perspektiven und für unterschiedliche Aufgabenbereiche betrachtet werden. Dabei werden individuelle Aspekte des Systems hervorgehoben und bestimmte Details oder Programmteile unterdrückt. Diese Ansichten können sein: Überblick über das Gesamtsystem Hier ist kein Wissen über einzelne Bereiche oder Implementierungen nötig, sondern es werden einzelne Module und Komponenten betrachtet. Zusammenspiel einzelner Komponenten Mehrere Gruppen von Programmierern arbeiten an einzelnen Modulen bzw. Bereichen; das Zusammenspiel dieser Komponenten muss funktionieren. Hier sind Schnittstellen von besonderem Interesse. Neuer Programmierer oder alter Code Oft ist nur minimale oder keine Dokumentation vorhanden, um sich mit einem neuen Programm oder einem Codefragment, das lange nicht mehr weiterentwickelt wurde, vertraut zu machen. Automatisch generierte Informationen mit hohen Detailgrad über vorhandenen Sourcecode ist von Nutzen. Programmierung Die Unterstützung der Programmierung einzelner Methoden durch 4

9 1.3 Sichten auf ein Software-System Visualisierung von Programmcode erleichtert den verschachtelte Schleifen und bedingte Ausführungen. 1.4 Überblick über Aufbau der Arbeit Im zweiten Kapitel wird der momentane Standard zur Darstellung von SoftwareSystemen vorgestellt: die Unified Modelling Language UML. Es werden die geschichtlichen Hintergründe dieser Notation sowie ein Überblick über die verschiedenen Diagramme gegeben. Das dritte Kapitel beschäftigt sich mit dem Stand der Technik. Dazu werden mehrere konkrete Programme auf ihre graphische Darstellung und die Möglichkeiten zur Modifikation von Sourcecode getestet. Im vierten Kapitel wird ein eigenes Konzept erarbeitet. Dabei werden die Schwachstellen der getesteten Programme berücksichtigt und auf die spezifische Aufgabenstellung angepasst. Im fünften Kapitel werden Möglichkeiten zur Implementierung und der konkreten Umsetzung beschrieben Den Abschluss bildet das sechste Kapitel mit einer Bewertung des Konzepts sowie der Implementierung. 5

10 Kapitel 2 Graphische Darstellungsmöglichkeiten Möglichkeiten zur graphischen Darstellung von Programmcode gibt es schon sehr lange. Dazu zählen einzelne Diagramme genau wie strukturierte Methoden, die den kompletten Entwicklungsprozess beschreiben und einzelne Phasen dieses Prozesses in Form von Diagrammen graphisch darstellen. Nach dem Entstehen der ersten objektorientierten Programmiersprache (Simula-67 aus dem Jahr 1967 gilt als erste objektorientierte Programmiersprache) wurden auch Methoden und Notationen für objektorientierte Systeme entwickelt. 2.1 Objektorientierte Analyse- und Designmethoden Seit den späten 80er Jahren macht man sich Gedanken darüber, wie man bei der Entwicklung komplexer objektorientierter Softwaresysteme vorgehen soll. Über die Jahre hinweg wurden so mehr als 50 Methoden beschrieben (weshalb diese Zeit oft als Methodenkrieg bezeichnet wird). Dabei wird üblicherweise der komplette Entwicklungsprozess beschrieben und in einzelne Phasen unterteilt. Es werden Tätigkeiten definiert und Zeitangaben für einzelne Phasen gegeben. Es werden hauptsächlich zwei Schritte unterschieden: Analyse und Design. Während der Analyse wird untersucht, was erstellt werden soll, und beim Design wird entschieden, wie dies umzusetzen ist. Zur Dokumentation und Visualisierung der einzelnen Phasen und des Programmcodes werden verschiedene textuelle und graphische Darstellungsformen (Notationen) vorgegeben. Die Methoden sind nicht alle unabhängig voneinander entstanden. Es gab immer wieder Beeinflussungen von anderen Methoden, die nicht notwendigerweise objektorientiert sein mussten, und es gab Bemühungen, die Vorteile der verschiedenen Methoden zu vereinigen. Ein solcher Versuch ist mit UML gelungen und manche Methoden benutzen UML als Notation (z.b. UP (RUP), Team Fusion, Catalysis,...), weshalb im Folgenden nur eine Auflistung einiger Methoden erfolgen soll. 6

11 2.1 Objektorientierte Analyse- und Designmethoden Abk. Name und Homepage Autor Jahr Information BON Business Object Notation ( Nerson, Walden 1992 [WaNe95] Booch Booch (Object-Oriented Analysis Booch (OOAD) and Design) (zwei Versionen: Booch'91 und Booch'93) [Booch91] 1993 [Booch94] Catalysis Catalysis ( D'Souza, Wills 1999 [HeEd94a] CRC Class-ResponsibilityCollaboration Wilkinson 1989 [BeCu89] [WiNa95] EROOS Entity-Relationship Based Object-Oriented Specifications Lewi, 1990 Steegmans, Van Baelen [Lewi90] Firesmith [Fire93] Firesmith Firesmith 1993 Fusion Fusion (später Team Fusion unter Coleman Benutzung von UML) [Cole94] 1997 HOOD Hierarchical Object-Oriented Design Robinson 1992 HOORA Hierarchical Object Oriented Requirements Analysis ( European Space Agency (ESA) 1995 [Robi92] MOSES Methodology for Object-Oriented Henderson Software Engineering of Systems Sellers, Edwards [HeEd94b] OBA Object Behaviour Analysis Rubin, Goldberg 1992 [RuGo92] OMT Object Modelling Technique (zwei Versionen: OMT und OMT94) Rumbaugh u.a [Rumb91] OOA / OOD Object-Oriented Analysis / Object-Oriented Design Coad, Yourdon 1991 [CoYo91a] [CoYo91b] OOCM Object-Oriented Conceptual Modeling Dillon, Tan 1993 [DiTa93] OODLE Object-Oriented Design Language Shlaer, Mellor [ShMe92]

12 2.1 Objektorientierte Analyse- und Designmethoden Abk. Name und Homepage Autor Jahr Information OOSA Object-Oriented System Analysis Shlaer, Mellor 1988 [ShMe88] OOSC Object-Oriented Software Construction Meyer 1994 [Meyer97] OOSD Object-Oriented System Development Champeaux, 1993 Lea, Faure [ChLeFa93] OOSE Object Oriented Software Engineering(zwei Versionen: OOSE und OOSE'94) Jacobson [Jaco92] OPEN (OML) Object-Oriented Process, Environment and Notation (OPEN Modelling Language) ( Henderson Sellers, Graham u.a. [Hend96] RDD Responsibility Driven Design (DOOS) (Designing Object-Oriented Software) Wirfs-Brock 1990 [Wirf90] ROOM Real-Time Object-Oriented Modeling Selic, Gullekson, Ward 1994 [SeGuWa94] RUP Rational Unified Process (Unified Jacobson, Process angepasst für Rational Booch, Software) Rumbaugh 1998 [Kruch98] SOMA Semantic Object Modelling Approach Graham 1995 [Graham95] Sully Sully Sully 1993 [Sully93] Syntropy Syntropy Cook, Daniels 1994 [Cook94] UP Unified Process Jacobson, Booch, Rumbaugh 1998 [Kruch98] XP Extreme Programming Beck ( [Beck99]

13 2.1 Objektorientierte Analyse- und Designmethoden OOSA CRC RDD EROOS 1990 OOA / OOD Booch '91 OMT OBA HOOD OOSE OOCM Sully Booch '93 Fusion BON OOSD OODLE Firesmith OOSE 94 OMT 94 Syntropy ROOM MOSES OOSC Unified Method 0.8 SOMA HOORA 1995 UML 0.9 & 0.91 OPEN / OML UML 1.0 Team Fusion UML 1.1 UP (RUP) UML 1.2 UML 1.3 Catalysis XP 2000 UML 1.4 UML 1.5 UML Abbildung 1: Objektorientierte Methoden und Notationen im historischen Kontext 9

14 2.2 UML 2.2 UML Die Unified Modeling Language UML ist keine Methode, sondern eine graphische Notation zur Visualisierung, Dokumentation, Konstruktion und Spezifikation von Software-Systemen. Sie wurde standardisiert von der Object Management Group OMG ([W3-OMG]). Dieses 1989 von elf Gesellschaften gegründete Nonfor-Profit Konsortium besteht mittlerweile aus etwa 800 Mitgliedern mit dem Ziel, die Model Driven Architecture MDA zu etablieren und weiter zu entwickeln. Mit OMG's MDA wird Software plattformneutral und auf einer hohen abstrakten Ebene modelliert, um dann mit Hilfe von Generatoren Quellcode erzeugen zu können. Dadurch soll die Softwarequalität und Handhabbarkeit verbessert, die Wartbarkeit vereinfacht und die Entwicklungsgeschwindigkeit gesteigert werden. Die dazu benutzten Standards sind u.a. UML, Meta-Object Facility (MOF) und XML Meta-Data Interchange (XMI). UML wird unterstützt von namhaften Firmen wie HP, IBM, Microsoft und Oracle. Sie wird seit dem Beginn im Oktober 1994 kontinuierlich weiterentwickelt und ist mittlerweile ein weltweit anerkannter Standard. Detaillierte Informationen und Spezifikationen können unter [W3-UML] nachgesehen werden. Eine Übersicht über die UML-Notation und somit eine gute Referenz wird von [W3-OOSE] zum Download angeboten (dort ist ebenfalls ein Becher mit aufgedruckter UML-Referenz bestellbar; eine Übersetzung ins klingonische ist in Vorbereitung). Eine ausführliche Einführung in das Metamodell, Super- und Infrastructure kann in [SofDevUML2] nachgelesen werden. Einige Beispiele sind [UML2Toolkit] und [Jeckle04] entnommen. Eine Liste mit deutschen Übersetzungen kann unter [W3-JECKLE] eingesehen werden. 10

15 2.2 UML Geschichte UML wurde maßgeblich von den drei Autoren James Rumbaugh, Grady Booch und Ivar Jacobson entwickelt, deren Methoden sich großer Beliebtheit erfreuten. Als im Oktober 1994 Rumbaugh zu Rational Software Corporation wechselte, begann er mit dem dort beschäftigten Booch an einer Vereinheitlichung ihrer Methoden OMT und Booch zu arbeiten. Ein erster Entwurf wurde unter dem Titel Unified Abbildung 2: Die drei Amigos: Grady Booch, James Rumbaugh, Ivar Jacobsen (v.li.n.re.) Method 0.8 im Oktober 1995 auf der OOPSLA veröffentlicht. Etwa zum selben Zeitpunkt wechselte Ivar Jacobsen zu Rational und seine Methode OOSE wurde integriert. Dieses Trio bekannt unter dem Namen Die drei Amigos veröffentlichten das Ergebnis ihrer Arbeit unter dem inzwischen geänderten Titel Unified Modeling Language in den Versionen 0.9 im Juni 1996 und im Oktober Im Januar 1997 wurde die UML Version 1.0 der OMG zur Standardisierung eingereicht als Antwort auf ihren RFP (Request for Proposal) für eine standardisierte Modellierungssprache. Nach der Kombination mit anderen Vorlagen entstand die Version 1.1, die im Juli der OMG offeriert, im September von OMG Analysis and Design Task Force (ADTF) und OMG Architecture Board akzeptiert und schließlich im November 1997 als Standard anerkannt wurde. In den folgenden Jahren erschienen weitere Versionen mit kleinen Änderungen. Aktuelle Version ist UML 1.5. UML 2.0 mit größeren Änderungen ist für Ende 2004 vorgesehen. Da sich diese Version im letzten Schritt des Standardisierungsprozesses befindet, sind keine technischen Änderungen mehr zu erwarten, weshalb die Änderungen bereits in einigen Programmen umgesetzt wurden und auch hier betrachtet werden. 11

16 2.2 UML Überblick Die Four Layer Modeling Architecture Eine Klasse beschreibt eine Menge gleicher Objekte. Die Klasse definiert dabei das allgemeine Aussehen, d.h. die Eigenschaften in Form der Attribute und das Verhalten in Form der Methoden. Eine Instanz einer Klasse ist das Objekt, das spezifische Werte hat. So kann beispielsweise die Klasse Mensch definiert werden mit einer Zahl als Attribut, die das Alter angibt, und einer Methode, die aus diesem Alter und dem aktuellen Datum die Volljährigkeit ermittelt. Ein konkretes Objekt also eine Instanz dieser Klasse ist dann z.b. Paul mit einem Alter von 25 Jahren. Somit ist die Klasse ein Modell von mehreren unterschiedlichen Objekten. Die Klasse gibt eindeutig vor, wie die Objekte aussehen und was sie können. Benutzt man dieses Konzept und abstrahiert weiter, dann erhält man ein Metamodell. Dieses Metamodell beschreibt eindeutig, wie eine Klasse auszusehen hat. Es definiert also, dass eine Klasse Attribute und Methoden hat und dass sie Superklassen/Subklassen durch Vererbung haben kann. Ein Element dieses Metamodells ist Classifier und eine Instanz dieses Elements ist beispielsweise eine Klasse. UML ist ein solches Metamodell. Meta bedeutet in diesem Zusammenhang, das es sich um ein Modell handelt, mit dem man Modelle beschreiben kann. Tatsächlich kann UML mit UML erklärt werden. Nun ist UML nicht nur für eine bestimmte oder eine kleine Gruppe von Programmiersprachen entworfen worden. Es muss also möglich sein, das Metamodell anzupassen. Die Fähigkeit der Mehrfachvererbung beispielsweise ist nicht in allen Sprachen gegeben. In C++ können Klassen von beliebig vielen anderen Klassen erben, in Java ist nur eine Einfachvererbung möglich. Um festzulegen, wie das Metamodell geändert werden darf, wurde eine weitere Schicht eingeführt: das Meta-Metamodell. Auch hier kommt dasselbe Konzept zum Einsatz. Das Meta-Metamodell beschreibt das Metamodell. Instanzen der Elemente aus dem Meta-Metamodell beschreiben ein Metamodell. Natürlich könnte man an dieser Stelle noch weiter abstrahieren und würde ein Meta-Meta-Metamodell usw. erhalten. Nach langen Diskussionen hat man jedoch eingesehen, dass weitere Metaschichten keinen zusätzlichen Abstraktionsgewinn bringen. Somit haben wir insgesamt vier Schichten oder Ebenen. Dies wird VierSchichten-Modellierungsarchitektur oder Four Layer Modeling Architecture 12

17 2.2 UML genannt. Die einzelnen Schichten werden durchnummeriert mit M0 bis M3, wobei das Meta-Metamodell die Schicht M3 darstellt. Zur Beschreibung des Meta-Metamodells kann ein weiterer Standard der OMG benutzt werden. Die Meta-Objects Facility MOF, die auch zur Definition anderer Technologien wie die Komponenten- und Schnittstellenbeschreibungssprache CORBA IDL (Common Object Request Broker Interface Definition Language) eingesetzt wird. MOF definiert das MOF-Modell, das ein Meta-Metamodell darstellt. Instanzen der Elemente des MOF-Modells sind Elemente eines Metamodells. Um einen standardisierten Austausch von Daten zwischen unterschiedlichen Programmen zu ermöglichen wurde XMI (XML Metadata Interchange) ins Leben gerufen. XMI beschreibt, wie Instanzen der Elemente des MOF-Modells auf XML Definitionen abgebildet werden können. Somit ist ein Austausch von UML-Modellen möglich. Auch XMI ist ein Standard der OMG. Meta-Metamodell (M3 = MOF) Classifier «instanceof» Metamodell (M2 = UML) Attribut Classifier «instanceof» Modell (M1) «instanceof» «instanceof» Mensch + Alter : Integer «instanceof» Objekte (M0) Paul : Mensch Alter = 25 Abbildung 3: Four Layer Modeling Architecture von UML 13

18 2.2 UML Infrastructure und Superstructure Zwei der Vier Schichten der Four Layer Modeling Architecture bedürfen der Standardisierung und finden sich tatsächlich auch in zwei unterschiedlichen Dokumenten wieder. Die UML Infrastructure erklärt das Meta-Metamodell und die UML Superstructure das Metamodell. Die UML Infrastructure definiert Modellelementen und Unterpaketen: vier Pakete mit unterschiedlichen 1. PrimitiveTypes: vordefinierte Datentypen Integer, Boolean, String und UnlimitedNatural (natürliche Zahlen und der Asterisk ('*') für unendlich) 2. Basic: Klasse, Attribut, Operation, Paket 3. Abstractions: abstrakte Metaklassen, die zur weiteren Spezialisierung gedacht sind und voraussichtlich in vielen Metamodellen benutzt werden: Generalisierung, Instanz, Multiplizität, Sichtbarkeit, Einschränkungen (Constraints) u.a. 4. Constructs: Assoziation Diese vier Pakete werden zusammengefasst in einem Paket namens Core und bilden somit die Grundlage für die UML Infrastructure. Core PrimitiveTypes Abstractions Basic Constructs Abbildung 4: Core Pakete der UML Infrastructure 14

19 2.2 UML Die UML Superstructure beschreibt das Metamodell, also UML selbst. Dabei werden die Elemente aus der Infrastructure übernommen, d.h. alle Elemente der Superstructure sind Instanzen der Infrastructure. Weiterhin werden alle Elemente der Superstructure importiert. Sie stehen also auch im Metamodell zur Verfügung. Das zentrale Paket hier wird als Kernel bezeichnet Erweiterungsmöglichkeiten UML bietet mehrere Möglichkeiten zur Erweiterung und auch zur Einschränkung unterschiedlicher Elemente von UML. Dies sind Constraints (Einschränkungen oder Zusicherungen), Tagged Values (Eigenschaftswerte) und Stereotypen. Benutzt man eine oder mehrere dieser Erweiterungen, so erhält man ein sogenanntes Profile, das auch mittels XMI weitergegeben werden kann. Stereotypen sind Namen, die in Guillemets eingefasst sind ( «Stereotyp-Name» ) und können auf unterschiedliche Modellelemente angewendet werden. Viele vordefinierte Stereotypen sind bereits in UML enthalten, z.b. «class», das eine Klasse beschreibt. Zusätzlich kann ein Icon, also eine graphische Repräsentation angegeben werden. Es können Stereotyp oder Icon oder beides angezeigt werden. Ein Beispiel für vordefinierte Stereotypen und Icons sind Control, Boundary und Entity. Sie basieren auf dem Model-View-Controller Modell (MVC-Modell), Abbildung 5: Icons für die mit dem die in Anwendungen oft benutzte Trennung Stereotypen Control, Entity, Boundary in Eingabe, Verarbeitung und Ausgabe auf GUIbasierte Systeme übertragen wird. Die Eingabe entspricht dabei der MVCKomponente Controller und dem UML-Stereotyp «control». Die Verarbeitung wird von der MVC-Komponente Model und dem UML-Stereotyp «entity» übernommen, während für die Ausgabe die MVC-Komponente View und dem UML-Stereotyp «boundary» verantwortlich ist und üblicherweise durch Fenster, Dialoge oder Kommunikationsklassen wie TCP/IP realisiert werden. Tagged Values bestehen aus einem Namen und einem zugehörigen Wert. Dadurch können die unterschiedlichsten Informationen untergebracht werden, wie den Status der Entwicklung, Informationen über Autor und Zweck. Sie werden in geschweifte Klammern gefasst, beispielsweise {Autor = Paul } oder {Status = muss noch gemacht werden, Fertigstellung = 2004 }. Diese Informationen tauchen üblicherweise nicht im fertigen Produkt auf, sondern werden nur im Modell angezeigt. Ist der zugehörige Wert des Tagged values vom Typ Boolean und true, so muss der Wert nicht angezeigt werden (Beispiel: {abstract}). 15

20 2.2 UML Constraints sind Einschränkung der Benutzung oder Seniorengruppe Bedeutung von Elementen. Dies soll an einem Beispiel verdeutlicht werden: Seien zwei Klassen namens {Person.alter > 60} Person (mit Attribut Alter ) und Seniorengruppe Person gegeben sowie eine Beziehung zwischen diesen Klassen. Will man sicherstellen, dass nur Personen ab alter : Integer 60 Jahren einer Seniorengruppe zugewiesen werden Abbildung 6: Beispiel für können, dann kann das realisiert werden mit einem Constraints Constraint, das der Beziehung zugewiesen wird. Dieses hat die Form {person.alter > 60}. Üblicherweise werden Constraints in einer speziell für diesen Zweck ausgelegten Sprache der Object Constaint Language OCL verfasst. Aber auch andere Sprachen sind möglich Diagramme und Views UML 2.0 definiert mehrere Diagramme, die in die zwei Bereiche Struktur und Verhalten eingeteilt werden können: Strukturdiagramme (Structural Diagrams) Klassendiagramm (Class Diagram) Zeigt Klassen mit ihren Attributen und Operationen sowie die Beziehungen untereinander. Objektdiagramm (Object Diagram) oder Instanzdiagramm (Instance Diagram) Ähnlich dem Klassendiagramm werden hier Objekte mit spezifischen Werten dargestellt. Dies ist nur eine Momentaufnahme des Systems. Komponentendiagramm (Component Diagram) Mit dem Komponentendiagramm werden Komponenten und ihre Beziehungen untereinander angezeigt. Komponenten sind hierbei modulare und austauschbare Teile des Systems mit eindeutig definierter Schnittstelle. Verteilungsdiagramm (Deployment Diagram) Zeigt auf, wie das System auf unterschiedliche Computer verteilt ist und wie diese miteinander kommunizieren. Kompositionsstrukturdiagramm (Composite Structure Diagram) Beschreibt die interne Struktur einer Klasse oder Komponente. 16

21 2.2 UML Paketdiagramm (Package Diagram) In einem Paketdiagramm können verschiedene Modellelemente gruppiert werden. Dabei wird ein eindeutiger Namensraum festgelegt. Verhaltensdiagramme (Behavior Diagrams) Anwendungsfalldiagramm (Use Case Diagram) Das Systemverhalten wird aus der Sicht des Anwenders dargestellt. Es wird nicht gezeigt, wie, sondern was möglich ist. Aktivitätsdiagramm (Activity Diagram) Dient der Darstellung von Geschäftsprozessen wie sie Anwendungsfällen vorkommen, oder um komplexe Logik modellieren. in zu Zustandsdiagramm (State Machine Diagram) Das Zustandsdiagramm beschreibt Zustände und Zustandsübergänge eines Objekts ähnlich einem endlichen Automaten. Interaktionsdiagramme (Interaction Diagrams) Sequenzdiagramm (Sequence Diagram) Zeigen die sequentielle Logik, wobei in der Regel nur ein Weg durch einen Entscheidungsbaum angegeben wird. Es werden die Nachrichten zwischen verschiedenen Objekten in Abhängigkeit von der Zeit angegeben. Kommunikationsdiagramm (Communication Diagram) Dieses Diagramm beschreibt den Nachrichtenaustausch zwischen Objekten, wobei im Gegensatz zum Sequenzdiagramm die interne Struktur im Vordergrund steht. Interaktionsübersichtsdiagramm (Interaction Overview Diagram) Kombination aus Aktivitäts- und Interaktionsdiagrammen, wobei die einzelnen Aktivitäten Interaktionen sind. Zeitdiagramm (Timingdiagramm) Das aus der technischen Informatik bekannte Timingdiagramm beschreibt Zustandsänderungen in Abhängigkeit von der Zeit und als Reaktion auf externe Ereignisse. 17

22 2.2 UML Ein Diagramm besteht aus mehreren Modellelementen, cd Klassen die zur besseren Übersicht innerhalb eines Rechtecks (frame) dargestellt werden können. In diesem Frame Ein Kommentar kann in der linken oberen Ecke Art, Name und Parameter des Diagramms angezeigt werden. Die Art Abbildung 7: UML wird durch Ausschreiben des Diagrammtyps oder durch Diagramm mit Kommentar eine Abkürzung kenntlich gemacht (z.b. pkg für package, sm für state machine, sd für sequence diagramm). Viele Modellelemente können in mehreren Diagrammarten vorkommen, beispielsweise der Kommentar, der durch ein Rechteck mit umgeknickter rechter oberer Ecke dargestellt wird. Kommentare können in allen Diagrammarten vorkommen und können sowohl alleine stehen als auch über eine gestrichelte Linie mit einem anderen Modellelement verbunden werden. Große Softwaresysteme können aus mehreren hundert oder sogar tausend Klassen bestehen. Sie alle in einem einzigen Klassendiagramm darzustellen, wäre nicht sehr übersichtlich. Diese Vorgehensweise war aber auch nicht von den Entwicklern der UML beabsichtigt. Vielmehr sollten mehrere kleine Diagramme erzeugt werden, um einzelne Komponenten des Systems zu beschreiben. Dabei ist auch das Zusammenspiel unterschiedlicher Diagrammarten von großer Bedeutung. Um ein großes Softwaresystem aus unterschiedlichen Blickwinkeln zu betrachten, werden sogenannte Views (Sichten) benutzt. Dies sind Ansichten spezifischer Aspekte, die meist aus mehreren kleinen und unterschiedlichen Diagrammen bestehen. Oft benutzte Sichten sind: Anwendungsfallsicht (use case view): Zeigt die Funktionalität aus (Anwendungsfalldiagramm) der Sicht des Anwenders Entwurfssicht (design view oder logical view): Dient der Darstellung der statischen und dynamischen Struktur des zu entwickelnden Softwaresystems (Klassen-, Objekt-, Zustands-, Aktivitäts- und Kollaborationsdiagramm) Prozesssicht (process view): Benutzt die selben Diagramme wie die Entwurfssicht, jedoch stehen Aspekte wie Nebenläufigkeit, parallele Ausführung und die Synchronisation von Prozessen im Vordergrund. Diese Sicht wird manchmal auch concurrency view genannt. 18

23 2.2 UML Implementierungssicht (implementation view) Zeigt die Organisation des Quellcodes (Komponenten- und Model Management Diagramme) Verteilungssicht (deployment view): Beschreibt die Verteilung auf (Verteilungsdiagramm) unterschiedliche Computer Im Folgenden werden einige Modellelemente und Diagramme aufgezeigt, wobei der Schwerpunkt auf der Darstellung von Klassen und den Beziehungen zwischen Klassen liegt. Dabei ist zu beachten, dass in UML Farbe nicht semantisch benutzt wird; es werden lediglich Empfehlungen gegeben, um Unterschiede zwischen Elementen farblich hervorzuheben. Die Umsetzung bleibt aber dem Benutzer bzw. dem Hersteller von UML-konformer Software überlassen. Die UML-Spezifikation definiert im Wesentlichen einzelne Modellelemente. Diese können größtenteils in unterschiedlichen Diagrammen vorkommen Klassen- und Objektdiagramm Das Class Diagram oder Klassendiagramm beschreibt Klassen mit Attributen und Methoden sowie ihre Beziehungen untereinander. Eine Klasse wird dargestellt als Rechteck, das mittels horizontaler Linien in mehrere Bereiche unterteilt werden kann. Im ersten Bereich steht optional ein Klassen-Stereotyp, gefolgt vom Namen der Klasse (fett gedruckt) sowie optional Eigenschaften, die in geschweifte Klammern gefasst werden. Ist die Klasse abstrakt, so wird der Name in kursiver Schrift geschrieben und die Eigenschaft {abstract} hinzugefügt. Vor dem Klassennamen kann der Name eines Pakets gefolgt von zwei Doppelpunkten stehen. Der zweite Bereich listet die Attribute der Klasse auf, die in folgender Syntax verfasst sind: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }] Zu Beginn steht ein Symbol für die Sichtbarkeit: - für private, + für public, # für protected und ~ für package. Der Schrägstrich wird bei abgeleiteten 19

24 2.2 UML Attributen gesetzt, d.h. bei Attributen, die zur Laufzeit aus anderen Attributen ermittelt werden können. Der anschließende Name des Attributs wird gefolgt von Typ, Multiplizität sowie einem Initialwert. Zusätzliche Eigenschaften wie {readonly} oder auch die Angabe eines Wertebereichs werden in geschweiften Klammern festgehalten. Attribute, die als Typ eine Klasse haben, können auch durch Beziehungen visualisiert werden (siehe Aggregation). Im nächsten Bereich werden die Operationen bzw. Methoden dargestellt. Die Syntax ähnelt der der Attribute: [visibility] name ( [parameter-list] ) [: return-type] [{ property-string }] Ist die Methode abstrakt, so wird der Name entweder kursiv geschrieben oder unterstrichen. Zusätzlich kann die Eigenschaft {abstract} hinzugefügt werden. Die Parameterliste ist eine Komma separierte Liste von formalen Parametern und genügt folgender Syntax: [direction] name : type [multiplicity] [= default] [{ property-string }] direction gibt die Richtung des Parameters an. Fehlt diese Angabe, wird in als Standardwert angenommen. Zulässige Werte sind in, out und inout. Sowohl Attribute als auch Operationen können anhand der Sichtbarkeit gruppiert werden. Zusätzliche Bereiche mit benutzerdefinierten Bemerkungen oder Einschränkungen können folgen, jedoch sind alle Bereiche außer dem ersten optional. Objekte werden auf ähnliche Weise dargestellt. Im Namensbereich wird unterstrichen der Name des Objekts gefolgt von einem Doppelpunkt und dem Klassennamen angegeben. Anstelle der Attributsdefinitionen werden Attributnamen mit konkreten Werten verwendet. Beispiele für unterschiedliche Darstellungsformen von Klassen sind in Abbildung 8 gezeigt. (a) stellt eine Klasse mit Attributnamen und -Typen sowie einer Operation dar. In (b) werden zusätzlich Sichtbarkeit und Initialwerte angezeigt. (c) bietet eine Sortierung der Attribute nach Sichtbarkeit ähnlich der Syntax der Programmiersprache C++. Abbildung (d) und (e) sind Minimaldarstellungen, bei denen nur der Klassennamen angezeigt wird und (e) ist ein Objekt mit konkreten Werten. 20

25 2.2 UML (a) (b) (c) Window Window Window size: Area visibility: Boolean defaultsize: Area + size: Area = (100,100) # visibility: Boolean = true + defaultsize: Area draw() + draw() public size: Area = (100,100) defaultsize: Area protected visibility: Boolean = true + draw() (d) Window (e) Window (f) Ansicht1 : Window size = (100,100) visibility = true defaultsize = (50,50) Abbildung 8: UML Klassen und ein Objekt Bei den Beziehungen zwischen Klassen und Objekten werden vier Arten unterschieden: Assoziation, Generalisierung, Abhängigkeit und Realisation (Schnittstellen). Eine Assoziation stellt die allgemeinste Art einer Beziehung dar. Sie bedeutet lediglich, dass eine Klasse irgendwie Kenntnis von einer oder mehreren anderen Klassen haben muss. Die graphische Darstellung orientiert sich sehr an dem Entity-Relationship-Modell nach [Chen76], das u.a. bei der Modellierung von Datenbanken eingesetzt wird. Die nachfolgende Abbildung stellt einige Beispiele graphisch dar. Assoziationen werden durch eine durchgezogene Linie dargestellt. Soll die Beziehung nur in einer Richtung möglich sein, so wird die Linie an einem Ende mit einer Pfeilspitze abgeschlossen (a). Für jede der beiden Richtungen kann optional eine Bezeichnung angegeben werden. Die Richtung, für die diese Bezeichnung gilt, wird mit einem ausgefüllten Rechteck, das in die gewünschte Richtung zeigt, visualisiert (b). Diese Bezeichnung ist eine Beschreibung für die Assoziation selbst. Zusätzlich kann man angeben, welche Rolle eine Klasse bei einer Assoziation spielt (c). Weiterhin können Multiplizitäten angegeben werden (d). Diese geben an, wie viele Objekte der einen Sorte mit wie vielen Objekten der anderen Sorte in Verbindung stehen können. Formuliert wird dies als eine Zahl, eine Menge von Zahlen, Zahlenbereiche (z.b ) oder eine Kombination davon (Beispiele: 1 oder 3, 5, 7 oder 1..7, 11 ). Ist keine Multiplizität angegeben, so wird 1 als Default-Wert angenommen. Ist eine Klasse in Assoziation mit sich selbst, so nennt man dies Rekursive Assoziation (e). Sind 21

26 2.2 UML mehr als zwei Klassen in einer Assoziation involviert (n-äre Assoziation), so werden die Linien der Assoziation mit einer leeren Raute verbunden (f). In einer n-ären Assoziation sind weder Aggregation noch Qualifizierte Assoziation erlaubt. Eine Qualifizierte Assoziation wird bei one-to-many und many-to-many Beziehungen benutzt und stellt eine Art Schlüssel dar, mit dem eindeutig zwischen den verschiedenen Elementen an dem many-ende der Assoziation unterschieden werden kann. Der Schlüssel bzw. qualifier wird dabei in einem (b) benutzt 1..* 0..* Auto Kind Person wird benutzt von (c) 1 (a) hat Mutter (e) 1..* Zug Vorlesung fährt mit Auto {xor} Person (i) Firma (h) Fahrschein (f) Tag Raum (g) Uni Matrikelnr (d) * Student Abbildung 9: UML Assoziationen kleinen Rechteck dargestellt, das Klasse und Assoziation miteinander verbindet. Dieses Rechteck sollte immer kleiner sein, als die mit ihm verbundene Klasse, um Verwirrung zu vermeiden (Beispiel (g): Eine Universität hat für jeden Studenten eine eindeutige Matrikelnummer). Einer Assoziation kann eine Klasse zugeordnet werden, die dann Assoziationsklasse genannt wird. Sie ist mittels einer gestrichelten Linie mit der Assoziation verbunden und stellt zusätzliche Informationen für diese Beziehung zur Verfügung (h). Eine weitere Möglichkeit für die Modellierung mit Assoziationen stellt das Xor-Constraint zur Verfügung. An dem Namen erkennt man bereits, dass es sich dabei um eine Einschränkung (Constraint) handelt und das Xor weist darauf hin, dass von zwei Möglichkeiten nur genau eine verwendbar ist. Dazu ein Beispiel (i): Wir haben die drei Klassen Auto, Person und Firma. Ein Auto wird zugelassen auf den Namen einer Privatperson oder auf eine Firma, d.h. es gibt Assoziationen zwischen Auto und Person sowie zwischen Auto und Firma. Ein Auto kann aber nicht auf beide zugelassen werden. Die Lösung bietet das Xor-Constraint, das nur genau eine der beiden Assoziationen zulässt. Dargestellt wird es mit einer gestrichelten Linie zwischen den beiden Assoziationen und einer für Constraints in UML üblichen Schreibweise {xor}. 22

27 2.2 UML Eine Aggregation ist eine spezielle Form der Assoziation, deren beteiligte Klassen eine Ganzes-Teil-Struktur darstellen, d.h. eine Klasse ist Teil einer Klasse. Dabei kann das Teil auch ohne das Ganze existieren (Beispiel (a): Auto aggregiert Reifen). Eine weitere Spezialisierung dieses Konzepts ist die Komposition, bei der das Teil nicht ohne das Ganze existieren kann (Beispiel: Fenster aggregiert Icon und Button (b), Haus aggregiert Zimmer). Dargestellt werden diese beiden Assoziationen durch eine Raute, die im Fall der Aggregation leer (a) und im Fall der Komposition ausgefüllt (b) ist. Als besondere Form von Assoziation können Aggregation und Komposition die von Assoziationen bekannten Elemente Rolle, Multiplizität und qualifier haben. Ist die aggregierte Klasse Teil von mehreren aggregierenden Klassen, so nennt man die Aggregation shared (Beispiel (c): Ein Team besteht aus Personen, aber eine Person kann auch Mitglied in mehreren Teams sein). Visualisiert wird dies durch die Angabe einer Multiplizität ungleich eins, die auf der aggregierenden Seite steht also auf der Seite, an der die Raute dargestellt wird. Sind mehrere Klassen auf der Teil -Seite der Beziehung, dann können diese zusammengefasst und in einer Baumstruktur dargestellt werden (shared target style (d), im Gegensatz zu separate target style (b)). Soll auf die Visualisierung mit Hilfe von Assoziationen verzichtet werden, kann die Darstellung auch mit Attributen erfolgen ((e) mit Komposition, (f) mit Attribut). (a) hat Auto (c) * Team (b) (e) 4 Reifen Mitglied Window * Button Person (d) * Icon size Window 1 (f) Window * Button Area Window size: Area * Icon Abbildung 10: UML Aggregation und Komposition Die Generalisierung ist eine direkte Abbildung des Konzepts aus der objektorientierten Programmierung. Eine spezielle Klasse (Subklasse oder Unterklasse) erbt dabei alle Attribute, Operationen und Assoziationen von einer allgemeineren Klasse (Superklasse oder Oberklasse). Dieses Konzept kann nicht 23

28 2.2 UML Person (a) Beruf {incomplete, overlapping} (c) Geschlecht {complete, disjoint} (b) Mann Frau Mechaniker Lehrer Vehikel Landvehikel {incomplete, overlapping} Auto (e) (d) Wasservehikel {incomplete, overlapping} Segelboot Motorboot Amphibienfahrzeug Abbildung 11: UML Generalisierung auf Objekte übertragen werden und tritt deshalb im Objektdiagramm nicht auf. Generalisierung wird dargestellt durch eine durchgezogene Linie zwischen Superklasse und Subklasse mit einem leeren Dreieck auf der Seite der Superklasse (a). Wie bei Aggregation kann bei mehreren Subklassen die Darstellung in einer Baumstruktur erfolgen (b) oder sie kann durch eine gestrichelte Linie kenntlich gemacht werden (c). Auch eine Einteilung in mehrere logische Gruppen (Partitionen) ist möglich (Generalization Set, Beispiel (d): Landvehikel und Wasservehikel). Die Beschreibung der Gruppe wurde in früheren UML-Versionen Discriminator (Unterscheidungsmerkmal) genannt und wird an die zugehörige Generalisierung geschrieben. Es gibt vier Constraints, von denen je zwei gegensätzlich sind und nicht zusammen benutzt werden können: complete / incomplete und disjoint / overlapping. Complete (vollständig) bedeutet, dass keine weiteren Subklassen mehr hinzugefügt werden können (Beispiel (b): es gibt nur die Unterscheidung zwischen Mann und Frau, weitere Unterscheidungen wären nicht sinnvoll). Bei incomplete (unvollständig) können noch zusätzliche Subklassen modelliert werden. Die anderen beiden Constraints betreffen die Subklassen der Subklassen in der Vererbungshierarchie, wenn Mehrfachvererbung möglich ist. Eine Subklasse der Subklassen kann von allen Subklassen erben, die mit overlapping (überlappend) gekennzeichnet sind, während dies bei disjoint (trennen) nicht möglich ist. Dazu ein Beispiel: Sei Vehikel eine generalisierte Klasse der Klassen Auto und Motorboot, die mit dem Constraint overlapping 24

29 2.2 UML versehen wurden. Dann kann es eine Subklasse Amphibienfahrzeug (e) geben, die Auto und Motorboot als Superklasse hat. Da die Generalisierung zwischen einem allgemeinen und einem spezielleren Modellelement definiert ist, existiert auch eine Generalisierung von Assoziationen. Bei Abhängigkeiten (Dependencies) ist ein Modellelement abhängig von einem anderen. Wird ein Modellelement das als Supplier bezeichnet wird geändert, dann kann dies Auswirkungen auf das andere A (a) Element das Client genannt wird haben. ABCD Dargestellt wird dies mit einem Pfeil mit einer B gestrichelten Linie, die vom Client zum Supplier C zeigt. Optional kann der Pfeil mit einem Namen und DBCA einem Stereotyp versehen werden, von denen einige D vordefiniert sind. Es ist möglich, mehrere Clients und mehrere Supplier zu haben. In diesem Fall Sommerreifen zeigen die Pfeile aller Clients auf einen Punkt (der (b) auch als Punkt, also als kleiner ausgefüllter Kreis, «substitute» visualisiert werden kann), von dem aus Pfeile zu den Ganzjahresreifen Suppliern gehen (a). Es gibt mehrere verschiedene Arten von Abhängigkeiten, die durch Abbildung 12: UML Abhängigkeiten unterschiedliche Stereotypen gekennzeichnet werden. «abstraction» wird benutzt zwischen zwei Elementen, die dasselbe Konzept auf verschiedenen Abstraktionsstufen oder aus unterschiedlichen Blickwinkeln repräsentieren. Einige Spezialformen von «abstraction» sind vorgegeben (z.b. «derive», «refine», «trace»). So auch die Realisierung, bei der der Supplier eine Spezifikation und der Client dessen Implementierung repräsentiert. Die graphische Darstellung der Realisierung orientiert sich an Abhängigkeiten durch eine gestrichelte Linie und an Generalisierung durch ein leeres Dreieck auf der Seite des Suppliers (Spezifikation). Eine weitere Abhängigkeit ist mit «permit» gegeben, durch das der Client Zugriffsrechte auf alle Elemente des Supplieres erhält. Dies kann in C++ durch das Schlüsselwort friend erreicht werden. Durch «substitute» können Instanzen von Klassen während der Laufzeit ausgetauscht werden, ohne dass Generalisierung verwendet wird (b). Dies ist beispielsweise sinnvoll bei Zielplattformen, die Vererbung und Polymorphie nicht unterstützen. Bei der Verwendung von «use» benötigt ein Modellelement für seine Implementierung und Ausführung andere Modellelemente. 25

30 2.2 UML Eine Schnittstelle (Interface) ist eine Klasse, bei der alle Methoden abstrakt sind. Eine solche Klasse kann nicht instanziert werden, sondern definiert nur die Namen der Funktionalität. Eine andere Klasse (Anbieter) muss dann die Implementierung dieser Schnittstelle liefern, die dann von einer weiteren Klasse (Nutzer) benutzt wird. Für Schnittstellen gibt es drei mögliche Darstellungsformen. Bei der ersten Möglichkeit (a) wird die Schnittstelle wie eine Klasse als Rechteck mit dem Stereotyp «interface» dargestellt und ist mit dem Anbieter über eine Realisierung und mit dem Nutzer über eine Abhängigkeit verbunden. In der zweiten Möglichkeit (b) wird die Schnittstelle als Kreis (ball) visualisiert, die mit dem Anbieter über eine durchgezogene Linie verbunden ist. Der Kreis wird mit dem Namen der Schnittstelle versehen und ist mit dem Nutzer über eine Abhängigkeit (a) Anbieter «interface» Schnittstelle (b) Anbieter Nutzer Schnittstelle (c) Anbieter Nutzer (d) Protokollierung zur Abrechnung Nutzer Schnittstelle Pay-TV Decoder [1] Signal Abbildung 13: UML Schnittstellen und Ports («use») verbunden. In der dritten Möglichkeit (c) wird der Anbieter und die Schnittstelle wie zuvor dargestellt. Der Nutzer ist mit einer durchgezogenen Linie mit einem Halbkreis (socket) verbunden, der eine benötigte Schnittstelle repräsentiert. Diese Form nennt sich ball-and-socket Notation. Schnittstellen beschreiben die Verbindung zwischen verschiedenen Softwarekomponenten, aber sie sagen nichts über die Systemumgebung aus. Zu diesem Zweck benutzt man Ports, die durch ein kleines Rechteck am Rand der Klasse (oder auch anderer Modellelemente) dargestellt werden. Die benötigten und unterstützten Schnittstellen werden dann an den Port angebracht und Name sowie in eckigen Klammen Multiplizität daneben geschrieben. Im Beispiel (d) benötigt man zum Nutzen von Pay-TV einen Decoder. Dieser benötigt ein Fernsehsignal und bietet eine Schnittstelle an, mit der ein Unternehmen die Nutzung protokollieren und so exakte Rechnungen stellen kann. 26

31 2.2 UML Parametrisierte Klassen (Templates) sind Klassen, die noch nicht vollständig spezifiziert sind. Erst wenn Parameter an sie gebunden, können sie instanziert werden. Dieses Konzept wird in C++ mit Templates und in Java mit Generics realisiert. Graphisch dargestellt werden sie durch ein Rechteck auf der rechten oberen Ecke der Klasse (a), in dem die Parameter definiert werden. Die T, k : int Liste (a) eintrag : T [0..k] (b) (b) «bind» <T Gast, k 20> «bind» <T Adresse, k 50> Gaestebuch Telefonbuch Abbildung 14: UML Parametrisierte Klassen (Templates) Parameterdefinition ist eine durch Kommas separierte Liste von Parametern der Form name [: type] [= default], wobei der Typ Klasse nicht angezeigt wird ((a): T hat als Typ Klasse). Gebunden werden die Parameter mit dem Stereotyp «bind» dem eine in die Zeichen < > gefasste und durch Kommas separierte Liste mit Parametern der Form Parametername Wert folgt (b). Der Quellcode für dieses Beispiel in C++ ist: template <class T, int k> class Liste { T eintrag[k]; }; Liste<Adresse,100> Telefonbuch; Liste<Gast,20> Gaestebuch; und in Java: class Liste<T> { Vector<T> eintrag; public Liste(int k) { eintrag = new Vector<T>(k); } } Liste<Adresse> Telefonbuch=new Liste<Adresse>(100); Liste<Gast> Gästebuch =new Liste<Gast> (20); 27

32 2.2 UML Dabei sind Gast und Adresse noch zu definierende Klassen. Dieses Beispiel ist [Jeckle04] entnommen. Zusätzlich können Pakete im Klassendiagramm benutzt werden, die im Folgenden betrachtet werden Model Management Paketdiagramm UML definiert drei Möglichkeiten, um Modellelemente zu gruppieren. Dabei werden unterschiedliche Aspekte des Systems hervorgehoben. Pakete können verschiedene Modellelemente enthalten. Dabei wird ein eindeutiger Namensraum festgelegt, d.h. sie können beispielsweise in C++ durch namespace realisiert werden. Graphisch dargestellt werden sie durch ein großes Rechteck über dem ein kleines links ausgerichtetes Rechteck das tab genannt wird steht. Die Elemente der Gruppe können entweder in dem großen Rechteck untergebracht werden (a) oder außerhalb der Gruppe. In letzterem Fall werden sie mit durchgängigen Linien mit der Gruppe verbunden, wobei am Gruppenende der Linie ein Kreis mit einem Plus-Zeichen angebracht ist (b). Sind die Elemente in der Gruppe, dann wird der Gruppenname im tab angezeigt (a). Ansonsten kann der Name im großen Rechteck dargestellt werden (b). Jedes Element kann eine Sichtbarkeit haben, die entsprechend der Sichtbarkeit von Attributen und Operationen definiert ist und visualisiert wird ((c) und (d)). Grundsätzlich gibt es drei Beziehungen zwischen Paketen, die in Form einer Abhängigkeit mit unterschiedlichen Stereotypen dargestellt werden. Mit «access» erhält ein Paket P1 Zugriff auf ein anderes Paket P2, wobei alle Elemente aus P2 in P1 die Sichtbarkeit private haben. Durch «import» werden die Elemente aus einem Paket in ein anderes importiert und sind auch dort von außen sichtbar. Sie erhalten also per default die Sichtbarkeit public (Beispiel: in (c) importiert das Paket X das Paket Y. Dabei werden nur die öffentlichen Elemente d.h. die Elemente mit Sichtbarkeit '+' (public) importiert. Dies sind C und E. In (d) ist das Ergebnis des Imports zu sehen, wobei die importierten Elemente mit dem eindeutigen Namen des Pakets Y markiert sind, d.h. C wird zu Y::C ). In diesem Fall kann den importierten Elementen allerdings auch eine lokale Sichtbarkeit und ein lokaler Alias-Name zugewiesen werden (Beispiel: in (d) könnte Y::C auch -F genannt werden). Die dritte Abhängigkeit ist durch «merge» gegeben. Dadurch können Elemente mit gleichen Namen aus unterschiedlichen Paketen zu einem neuen Element verschmolzen werden (Beispiel: In (e) werden die Pakete P1 und P2 mit P3 verschmolzen. Das Ergebnis ist in (f) zu sehen. Dabei wurde das Element A, das in allen drei 28