Login | Register
My pages Projects Community openCollabNet

ArgoUML Anwenderhandbuch

Eine Lern- und Referenzbeschreibung

Alejandro Ramirez

Philippe Vanpeperstraete

Andreas Rueckert

Kunle Odutola

Jeremy Bennett

Linus Tolke

Michiel van der Wulp

??bersetzung: Harald Braun

Dieses Material darf nur nach den in der Open Publication Lizenz, Version 1.0 oder h??her beschriebenen Regeln und Bedingungen weitergegeben werden. Eine Kopie dieser Lizenz finden Sie im Abschnitt Open Publication License . Die letzte Version ist unter http://www.opencontent.org/openpub/ verf??gbar.

Zusammenfassung

Diese Version des Handbuches beschreibt die Version ${argo.core.version} von ArgoUML.


1. Vorwort
1. Einleitung
1.1. Die Anf??nge und der ??berblick ??ber ArgoUML
1.1.1. Objektorientierte Analyse und Design
1.1.2. Die Entwicklung von ArgoUML
1.1.3. Mehr ??ber das ArgoUML-Projekt
1.2. Der Anwendungsbereich dieses Anwenderhandbuches
1.2.1. Der Leserkreis
1.2.2. Anwendungsbereich
1.3. ??berblick ??ber das Anwenderhandbuch
1.3.1. Die Struktur des ??bungshandbuches
1.3.2. Die Struktur des Referenzhandbuches
1.3.3. Anwender-Feedback
1.4. Annahmen
1. ??bungshandbuch
2. Einleitung
3. UML basierte OOA&D
3.1. Hintergrundinformationen zu UML
3.2. UML basierter Prozess f??r OOA&D
3.2.1. Prozesstypen
3.2.2. Ein Entwicklungsprozess f??r dieses ??bungshandbuch
3.3. Warum ist ArgoUML anders
3.3.1. Kognitive Psychologie
3.3.2. Offene Standards
3.3.3. 100% reines Java
3.3.4. Open Source
3.4. ArgoUML Grundlagen
3.4.1. Gestartet bekommen
3.4.2. Die ArgoUML-Anwenderschnittstelle
3.4.3. Ausgabe
3.4.4. Mit Design-Kritiken arbeiten
3.5. Die Fallstudie (Noch zu schreiben)
4. Erfassen der Anforderungen
4.1. Einleitung
4.2. Der Anforderungs-Erfassungs-Prozess
4.2.1. Prozess-Schritte
4.3. Ergebnis des Anforderungs-Erfassungs-Prozesses
4.3.1. Visions-Dokument
4.3.2. Anwendungsfalldiagramm
4.3.3. Die Anwendungsfall-Spezifikation
4.3.4. Erg??nzende Anforderungsspezifikation
4.4. Anwendungsf??lle in ArgoUML verwenden
4.4.1. Akteure
4.4.2. Anwendungsf??lle
4.4.3. Assoziationen
4.4.4. Hierarchische Anwendungsf??lle
4.4.5. Stereotypen
4.4.6. Dokumentation
4.4.7. Systemgrenzen
4.5. Fallstudie
4.5.1. Visions-Dokument
4.5.2. Akteure und Anwendungsf??lle identifizieren
4.5.3. Assoziationen (Noch zu beschreiben)
4.5.4. Erweiterte Diagrammeigenschaften (Noch zu beschreiben)
4.5.5. Anwendungsfallspezifikationen (Noch zu beschreiben)
4.5.6. Erg??nzende Anforderungsspezifikation (Noch zu beschreiben)
5. Analyse
5.1. Der Analyseprozess
5.1.1. Klasse-, Verantwortlichkeits- und Zusammenarbeits-Karten (CRC)
5.1.2. Konzeptdiagramm (Noch zu beschreiben)
5.1.3. System-Sequenzdiagramm (Noch zu beschreiben)
5.1.4. System-Zustandsdiagramm (Noch zu beschreiben)
5.1.5. Anwendungsfalldiagramm realisieren (Noch zu beschreiben)
5.1.6. Dokumente (Noch zu beschreiben)
5.2. Klassendiagramme (Noch zu beschreiben)
5.2.1. Das Klassendiagramm (Noch zu beschreiben)
5.2.2. Erweiterte Klassendiagramme (Noch zu beschreiben)
5.3. Klassendiagramme in ArgoUML erzeugen
5.3.1. Klassen
5.3.2. Assoziationen (Noch zu beschreiben)
5.3.3. Klassenattribute und Operationen (Noch zu beschreiben)
5.3.4. Erweiterte Klasseneigenschaften (Noch zu beschreiben)
5.4. Sequenzdiagramme (Noch zu beschreiben)
5.4.1. Das Sequenzdiagramm (Noch zu beschreiben)
5.4.2. Aktionen identifizieren (Noch zu beschreiben)
5.4.3. Erweiterte Sequenzdiagramme (Noch zu beschreiben)
5.5. Sequenzdiagramme in ArgoUML erzeugen
5.5.1. Sequenzdiagramme
5.5.2. Aktionen (Noch zu beschreiben)
5.5.3. Erweiterte Sequenzdiagramme (Noch zu beschreiben)
5.6. Zustandsdiagramme (Noch zu beschreiben)
5.6.1. Das Zustandsdiagramm (Noch zu beschreiben)
5.6.2. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
5.7. Zustandsdiagramme in ArgoUML
5.7.1. Zustandsdiagramme (Noch zu beschreiben)
5.7.2. Zust??nde (Noch zu beschreiben)
5.7.3. Transitionen (Noch zu beschreiben)
5.7.4. Aktionen (Noch zu beschreiben)
5.7.5. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
5.8. Anwendungsf??lle realisieren (Noch zu beschreiben)
5.9. Realisierungs-Anwendungsf??lle in ArgoUML erstellen ( Noch zu beschreiben)
5.10. Fallstudie (Noch zu beschreiben)
5.10.1. CRC Karten
5.10.2. Klassendiagramme konzipieren (Noch zu beschreiben)
5.10.3. System-Sequenzdiagramme (Noch zu beschreiben)
5.10.4. System-Zustandsdiagramme (Noch zu beschreiben)
5.10.5. Realisierungs-Anwendungsf??lle (Noch zu beschreiben)
6. Design
6.1. Der Designprozess (Noch zu beschreiben)
6.1.1. Klasse, Verantwortlichkeiten und Zusammenh??nge (CRC) Karten
6.1.2. Paketdiagramm (Noch zu beschreiben)
6.1.3. Realisierungs-Klassendiagramme (Noch zu beschreiben)
6.1.4. Sequenz- und Kollaborationsdiagramme (Noch zu beschreiben)
6.1.5. Zustands- und Aktivit??tsdiagramme ( Noch zu beschreiben)
6.1.6. Verteilungsdiagramme (Noch zu beschreiben)
6.1.7. Dokumente (Noch zu beschreiben)
6.2. Paketdiagramme (Noch zu beschreiben)
6.2.1. Das Paketdiagramm (Noch zu beschreiben)
6.2.2. Erweiterte Paketdiagramme (Noch zu beschreiben)
6.3. Paketdiagramme in ArgoUML erstellen
6.3.1. Pakete
6.3.2. Beziehungen zwischen Paketen (Noch zu beschreiben)
6.3.3. Erweiterte Paketeigenschaften (Noch zu beschreiben)
6.4. Mehr ??ber Klassendiagramme (Noch zu beschreiben)
6.4.1. Das Klassendiagramm (Noch zu beschreiben)
6.4.2. Erweiterte Klassendiagramme (Noch zu beschreiben)
6.5. Mehr ??ber Klassendiagramme in ArgoUML (Noch zu beschreiben)
6.5.1. Klassen (Noch zu beschreiben)
6.5.2. Klassenattribute und -operationen (Noch zu beschreiben)
6.5.3. Erweiterte Klasseneigenschaften
6.6. Sequenz- und Kollaborationsdiagramme ( Noch zu beschreiben)
6.6.1. Mehr ??ber das Sequenzdiagramm (Noch zu beschreiben)
6.6.2. Das Kollaborationsdiagramm (Noch zu beschreiben)
6.6.3. Erweiterte Kollaborationsdiagramme (Noch zu beschreiben)
6.7. Kollaborationsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.7.1. Kollaborationsdiagramme (Noch zu beschreiben)
6.7.2. Nachrichten (Noch zu beschreiben)
6.7.3. Erweiterte Kollaborationsdiagramme (Noch zu beschreiben)
6.8. Zustandsdiagramme (Noch zu beschreiben)
6.8.1. Das Zustandsdiagramm (Noch zu beschreiben)
6.8.2. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
6.9. Zustandsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.9.1. Zustandsdiagramme (Noch zu beschreiben)
6.9.2. Zust??nde (Noch zu beschreiben)
6.9.3. Transitionen (Noch zu beschreiben)
6.9.4. Aktionen (Noch zu beschreiben)
6.9.5. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
6.10. Aktivit??tsdiagramme (Noch zu beschreiben)
6.10.1. Das Aktivit??tsdiagramm (Noch zu beschreiben)
6.11. Aktivit??tsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.11.1. Aktivit??tsdiagramme (Noch zu beschreiben)
6.11.2. Aktionszust??nde (Noch zu beschreiben)
6.12. Verteilungsdiagramme (Noch zu beschreiben)
6.12.1. Das Verteilungsdiagramm (Noch zu beschreiben)
6.13. Verteilungsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.13.1. Knoten (Noch zu beschreiben)
6.13.2. Komponenten (Noch zu beschreiben)
6.13.3. Beziehungen zwischen Knoten und Komponenten ( Noch zu beschreiben)
6.14. System-Architektur (Noch zu beschreiben)
6.15. Fallstudie (Noch zu beschreiben)
6.15.1. CRC-Karten (Noch zu beschreiben)
6.15.2. Pakete (Noch zu beschreiben)
6.15.3. Klassendiagramme (Noch zu beschreiben)
6.15.4. Sequenzdiagramme (Noch zu beschreiben)
6.15.5. Kollaborationsdiagramme (Noch zu beschreiben)
6.15.6. Zustandsdiagramme (Noch zu beschreiben)
6.15.7. Aktivit??tsdiagramme (Noch zu beschreiben)
6.15.8. Das Verteilungsdiagramm (Noch zu beschreiben)
6.15.9. Die System-Architektur (Noch zu beschreiben)
7. Codegenerierung, Reverse Engineering und Round Trip Engineering
7.1. Einleitung
7.2. Codegenerierung
7.2.1. Code aus der statischen Struktur generieren
7.2.2. Code aus Interaktionen und Zustandsautomaten generieren
7.3. Code in ArgoUML generieren
7.3.1. Statische Struktur
7.3.2. Interaktionen und Zustandsdiagramme
7.4. Reverse Engineering
7.5. Round-Trip Engineering
2. Referenz Anwenderschnittstelle
8. Einleitung
8.1. ??berblick ??ber das Fenster
8.2. Generelles Verhalten der Maus in ArgoUML
8.2.1. Maustasten-Terminologie
8.2.2. Taste 1 Klick
8.2.3. Taste 1-Doppelklick
8.2.4. Taste 1-Bewegung
8.2.5. Umschalt- und Strg- und die Taste 1
8.2.6. Alt Gr mit Taste 1: Verschieben
8.2.7. Strg mit Taste 1: Bedingtes ziehen
8.2.8. Taste 2-Aktionen
8.2.9. Taste 2-Doppelklick
8.2.10. Taste 2-Bewegung
8.3. Generelle Informationen ??ber Fenster
8.3.1. Fenstergr??sse ver??ndern
8.4. Die Statuszeile
9. Die Werkzeugzeile
9.1. Dateioperationen
9.2. Editieroperationen
9.3. Ansicht-Operationen
9.4. Neues Diagramm
10. Die Men??zeile
10.1. Einleitung
10.2. Das Mausverhalten in der Men??zeile
10.3. Das Men?? Datei
10.3.1. Neu
10.3.2. Projekt ??ffnen...
10.3.3. Projekt speichern
10.3.4. Projekt speichern unter...
10.3.5. Projekt speichern r??ckg??ngig machen
10.3.6. XMI importieren...
10.3.7. Exportiere als XMI...
10.3.8. Quellcode importieren...
10.3.9. Seite einrichten...
10.3.10. Drucken...
10.3.11. Grafik exportieren...
10.3.12. Alle Grafiken exportieren...
10.3.13. Notation
10.3.14. Projekteinstellungen
10.3.15. Am h??ufigsten verwendete Dateien
10.3.16. Beenden
10.4. Das Men?? Bearbeiten
10.4.1. Markieren
10.4.2. Aus Diagramm entfernen
10.4.3. Aus Modell entfernen
10.4.4. Perspektiven konfigurieren...
10.4.5. Einstellungen...
10.5. Das Men?? Ansicht
10.5.1. Gehezu Diagramm...
10.5.2. Suchen...
10.5.3. Zoom
10.5.4. Gitter einstellen
10.5.5. Einrasten einrichten
10.5.6. Seitenumbr??che
10.5.7. Symbolleisten
10.5.8. XML-Quelltext
10.6. Das Men?? "Neues Diagramm"
10.6.1. Neues Anwendungsfalldiagramm
10.6.2. Neues Klassendiagramm
10.6.3. Neues Sequenzdiagramm
10.6.4. Neues Kollaborationsdiagramm
10.6.5. Neues Zustands??bergangsdiagramm
10.6.6. Neues Aktivit??tsdiagramm
10.6.7. Neues Verteilungsdiagramm
10.7. Das Men?? Anordnen
10.7.1. Ausrichten
10.7.2. Anordnen
10.7.3. Reihenfolge
10.7.4. Gr??sse an Inhalt anpassen
10.7.5. Layout
10.8. Das Men?? Generieren
10.8.1. Markierte Klassen generieren ...
10.8.2. Alle Klassen generieren...
10.8.3. Gesamtes Projekt generieren... (Noch zu beschreiben)
10.8.4. Einstellungen zur Codegenerierung im Projekt... (Noch zu beschreiben)
10.9. Das Men?? Kritiken
10.9.1. Kritiken ein-/ausschalten
10.9.2. Design-Wichtungen...
10.9.3. Design Ziele...
10.9.4. Kritiken anzeigen...
10.10. Das Men??: Werkzeuge
10.11. Das Men??: Hilfe
10.11.1. Systeminformation
10.11.2. ??ber ArgoUML
11. Der Explorer
11.1. Einleitung
11.2. Das Verhalten der Maus im Explorer
11.2.1. Taste 1-Klick
11.2.2. Taste 1-Doppelklick
11.2.3. Taste 1-Bewegung
11.2.4. Taste 2-Aktionen
11.2.5. Taste 2-Doppelklick
11.3. Verhalten der Tastatur im Explorer
11.4. Auswahl der Perspektiven
11.5. Perspektiven konfigurieren
11.5.1. Der Dialog Perspektiven konfigurieren
11.6. Das kontextsensitive Men??
11.6.1. Erstelle neues
11.6.2. Kopiere das Diagramm als Bild in die Zwischenablage
11.6.3. Zum Diagramm hinzuf??gen
11.6.4. Aus Modell entfernen
11.6.5. Einstellen des Quellpfades... (Noch zu beschreiben)
11.6.6. Paket hinzuf??gen
11.6.7. Neuer Stereotyp
11.6.8. Alle Klassen im Namensraum hinzuf??gen
12. Das Editierfenster
12.1. Einleitung
12.2. Das Verhalten der Maus im Editierfenster
12.2.1. Taste 1-Klick
12.2.2. Taste 1-Doppelklick
12.2.3. Taste 1-Bewegung
12.2.4. Umschalt- und Strg-Taste und die Taste 1
12.2.5. Alt Gr mit Taste 1-Bewegung
12.2.6. Taste 2-Aktionen
12.2.7. Taste 2-Doppelklick
12.2.8. Taste 2-Bewegung
12.3. Das Verhalten der Tastatur im Editierfenster
12.3.1. Schrittweises bewegen eines Modellelementes
12.3.2. Durch die Modellelemente bewegen
12.4. Die Werkzeugleiste
12.4.1. Layout-Werkzeuges
12.4.2. Kommentierungs-Werkzeug
12.4.3. Zeichen-Werkzeuge
12.4.4. Anwendungsfalldiagrammspezifische Werkzeuge
12.4.5. Klassendiagrammspezifische Werkzeuge
12.4.6. Sequenzdiagrammspezifische Werkzeuge
12.4.7. Kollaborationsdiagrammspezifische Werkzeuge
12.4.8. Zustandsdiagrammspezifische Werkzeuge
12.4.9. Aktivit??tsdiagrammspezifische Werkzeuge
12.4.10. Verteilungsdiagrammspezifische Werkzeuge
12.5. Der Besen
12.6. Auswahl-Aktionsschaltfl??chen
12.7. Erl??uterungen (Clarifiers)
12.8. Das Zeichengitter
12.9. Der Reiter Diagramm
12.10. Pop-Up Men??'s
12.10.1. Kritiken
12.10.2. Reihenfolge
12.10.3. Hinzuf??gen
12.10.4. Darstellung
12.10.5. Modifikatoren
12.10.6. Kardinalit??t
12.10.7. Aggregation
12.10.8. Navigierbarkeit
12.11. Notation
12.11.1. Notation Sprachen
12.11.2. Editieren im Diagramm
12.11.3. Parsen
13. Der Bereich Details
13.1. Einleitung
13.2. Das Register "Zu Bearbeiten"
13.2.1. Assistenten
13.2.2. Die Schaltfl??che Hilfe
13.3. Das Register Eigenschaften
13.4. Das Register Dokumentation
13.5. Das Register Darstellung
13.6. Das Register Quellcode
13.7. Das Register Randbedingungen
13.7.1. Der Bedingungs-Editor
13.8. Das Register Stereotypen
13.9. Das Register Eigenschaftswerte
13.10. Das Register Checkliste
14. Der Bereich Zu-Bearbeiten
14.1. Einleitung
14.2. Das Verhalten der Maus im Bereich Zu-Bearbeiten
14.2.1. Taste 1-Klick
14.2.2. Taste 1-Doppelklick
14.2.3. Taste 2-Aktionen
14.2.4. Taste 2-Doppelklick
14.3. Auswahl der Darstellung
14.4. Element-Z??hler
15. Die Kritiken
15.1. Einleitung
15.1.1. Terminologie
15.1.2. Design-Mangel
15.2. Unkategorisiert
15.3. Klassenauswahl
15.3.1. Datentyp verbergen
15.3.2. Veringere die Anzahl der Klassen im Namensraum <Namensraum>
15.3.3. Diagramm aufr??umen
15.4. Benennung
15.4.1. L??se Assoziations-Namenskonflikt auf
15.4.2. ??berarbeite die Attributnamen, um einen Konflikt zu vermeiden
15.4.3. ??ndere Namen oder Signaturen in einem Modellelement
15.4.4. Doppelte End- (Rollen-) Namen in einer Assoziation
15.4.5. Rollenname steht im Konflikt mit einem Element
15.4.6. Einen Namen ausw??hlen (Klassen und Schnittstellen)
15.4.7. W??hlen Sie einen eindeutigen Namen f??r ein Modellelement aus (Klassen und Schnittstellen)
15.4.8. W??hlen Sie einen Namen aus (Attribute)
15.4.9. W??hlen Sie einen Namen aus (Operationen)
15.4.10. W??hlen Sie einen Namen aus (Zust??nde)
15.4.11. W??hlen Sie einen eindeutigen Namen f??r ein (zustandsbehaftetes) Modellelement aus.
15.4.12. ??ndern Sie den Namen, um eine Konfusion zu verhindern
15.4.13. W??hlen Sie einen legalen Namen aus
15.4.14. ??ndern Sie den Namen des Modellelementes in ein nicht-reserviertes Wort
15.4.15. W??hlen Sie einen besseren Namen f??r die Operation aus
15.4.16. W??hlen Sie einen besseren Attributnamen aus
15.4.17. Klassenname gro?? schreiben
15.4.18. Paketname ??berarbeiten
15.5. Speicher
15.5.1. ??berarbeiten Sie die Attributnamen, um einen Konflikt zu vermeiden
15.5.2. F??gen Sie Instanzvariablen zu einer Klasse hinzu
15.5.3. F??gen Sie der Klasse einen Konstruktor hinzu
15.5.4. Reduzieren Sie die Zahl der Attribute in der Klasse
15.6. Geplante Erweiterungen
15.6.1. Operationen in Schnittstellen m??ssen public sein
15.6.2. Schnittstellen d??rfen nur Operationen haben
15.6.3. Entferne die Referenz auf die spezifische Subklasse
15.7. Zustandsautomaten
15.7.1. Reduzieren Sie die Anzahl der Transitionen im <Zustand>
15.7.2. Reduzieren Sie die Anzahl der Zust??nde im Automaten <Automat>
15.7.3. F??gen Sie dem <Zustand> Transitionen hinzu
15.7.4. F??gen Sie ankommende Transitionen dem Modellelement <Modellelement> hinzu
15.7.5. F??gen Sie abgehende Transitionen dem Modellelement <Modellelement> hinzu
15.7.6. Entfernen Sie den zus??tzlichen Initialzustand
15.7.7. F??gen Sie einen initialen Zustand ein
15.7.8. Einer Transition ein Signal oder einen W??chter hinzuf??gen
15.7.9. ??ndere Vereinigungs-Transitionen
15.7.10. ??ndere Gabelungs-Transitionen
15.7.11. Entscheidungs-/Kreuzungstransitionen hinzuf??gen
15.7.12. Einer Transition W??chter hinzuf??gen
15.7.13. Das Diagramm aufr??umen
15.7.14. Eine Kante sichtbarer machen
15.7.15. Zusammengesetztes Assoziationsende mit der Kardinalit??t > 1
15.8. Designmuster
15.8.1. Die Nutzung des Singleton-Musters f??r eine <class> in Betracht ziehen.
15.8.2. Singleton Stereotyp-Verletzung in <Klasse>
15.8.3. Knoten haben normalerweise keine H??lle
15.8.4. Knoteninstanzen haben normalerweise keine H??lle
15.8.5. Komponenten befinden sich normalerweise innerhalb von Knoten
15.8.6. Komponenteninstanzen befinden sich normalerweise innerhalb von Knoten
15.8.7. Klassen befinden sich normalerweise innerhalb von Komponenten
15.8.8. Schnittstellen befinden sich normalerweise innerhalb von Komponenten
15.8.9. Objekte befinden sich normalerweise innerhalb von Komponenten
15.8.10. Verkn??pfungsenden haben nicht die gleiche Ebene
15.8.11. Klassifizierung einstellen (Verteilungsdiagramm)
15.8.12. Return-Aktionen werden vermisst
15.8.13. Vermisse Aufruf(Sende)-Aktion
15.8.14. Kein Ausl??seimpuls bei diesen Verkn??pfungen
15.8.15. Klassifizierung einstellen (Sequenzdiagramm)
15.8.16. Falsche Position dieses Ausl??seimpulses
15.9. Beziehungen
15.9.1. Zirkul??re Assoziation
15.9.2. <Assoziation> navigierbar machen
15.9.3. Entferne die Navigation von der Schnittstelle via <Assoziation>
15.9.4. Dem <Modellelement> eine Assoziation hinzuf??gen
15.9.5. Referenz auf ein spezifische Subklasse entfernen
15.9.6. Reduzieren Sie die Assoziationen des <Modellelementes>
15.9.7. Kanten sichtbarer machen
15.10. Instanzen bilden
15.11. Modularit??t
15.11.1. Der Klassifizierer befindet sich nicht im Namensraum seiner Assoziation.
15.11.2. F??gen Sie Elemente zum Paket <Paket> hinzu.
15.12. Erwartete Verwendung
15.12.1. Diagramm aufr??umen
15.13. Methoden
15.13.1. ??ndere Namen oder Signaturen im <Modellelement>
15.13.2. Die Klasse mu?? abstrakt sein
15.13.3. F??gen Sie der <Klasse> Operationen hinzu
15.13.4. Reduzieren Sie die Anzahl der Operationen im <Modellelement>
15.14. Code-Generierung
15.14.1. ??ndern Sie die Mehrfachvererbung in Schnittstellen
15.15. Stereotypen
15.16. Vererbung
15.16.1. ??berpr??fen Sie die Attributnamen, um einen Konflikt zu vermeiden.
15.16.2. Entfernen Sie die zirkul??re Vererbung der Klasse <Klasse>
15.16.3. Die Klasse mu?? abstrakt sein
15.16.4. Entfernen Sie das Schl??sselwort final oder entfernen Sie Subklassen
15.16.5. Illegale Generalisierung
15.16.6. Enferne unn??tige Realisierungen aus der Klasse <Klasse>
15.16.7. Definiere eine konkrete (Sub-)Klasse
15.16.8. Definieren Sie eine Klasse, um die Schnittstelle <Schnittstelle> zu implementieren
15.16.9. ??ndere Mehrfachvererbung in Schnittstellen
15.16.10. Machen Sie die Kanten sichtbarer
15.17. Containment
15.17.1. Entferne zirkul??re Komposition
15.17.2. Duplizieren Sie den Parameternamen
15.17.3. Zwei Aggregatenden (Rollen) in bin??rer Assoziation
15.17.4. Aggregatende (Rolle) in 3-Wege (oder mehr) Assoziation
15.17.5. Datentyp verbergen
3. Modellreferenz
16. Modellreferenz auf h??chster Ebene
16.1. Einleitung
16.2. Das Modell
16.2.1. Die Register Modelldetails
16.2.2. Symbolleiste Modelleigenschaften
16.2.3. Eigenschaftsfelder des Modelles
16.3. Datentyp
16.3.1. Register Datentyp-Details
16.3.2. Datatype Property Toolbar
16.3.3. Property Fields For Datatype
16.4. Enumeration
16.4.1. Enumeration Details Tabs
16.4.2. Enumeration Property Toolbar
16.4.3. Property Fields For Enumeration
16.5. Enumeration Literal
16.6. Stereotype
16.6.1. Stereotype Details Tabs
16.6.2. Stereotype Property Toolbar
16.6.3. Property Fields For Stereotype
16.7. Tag Definition
16.8. Diagram
16.8.1. Diagram Details Tabs
16.8.2. Diagram Property Toolbar
16.8.3. Property Fields For Diagram
17. Use Case Diagram Model Element Reference
17.1. Introduction
17.1.1. ArgoUML Limitations Concerning Use Case Diagrams
17.2. Actor
17.2.1. Actor Details Tabs
17.2.2. Actor Property Toolbar
17.2.3. Property Fields For Actor
17.3. Use Case
17.3.1. Use Case Details Tabs
17.3.2. Use Case Property Toolbar
17.3.3. Property Fields For Use Case
17.4. Extension Point
17.4.1. Extension Point Details Tabs
17.4.2. Extension Point Property Toolbar
17.4.3. Property Fields For Extension Point
17.5. Association
17.6. Association End
17.7. Dependency
17.8. Generalization
17.8.1. Generalization Details Tabs
17.8.2. Generalization Property Toolbar
17.8.3. Property Fields For Generalization
17.9. Extend
17.9.1. Extend Details Tabs
17.9.2. Extend Property Toolbar
17.9.3. Property Fields For Extend
17.10. Include
17.10.1. Include Details Tabs
17.10.2. Include Property Toolbar
17.10.3. Property Fields For Include
18. Class Diagram Model Element Reference
18.1. Introduction
18.1.1. Limitations Concerning Class Diagrams in ArgoUML
18.2. Package
18.2.1. Package Details Tabs
18.2.2. Package Property Toolbar
18.2.3. Property Fields For Package
18.3. Datatype
18.4. Enumeration
18.5. Stereotype
18.6. Class
18.6.1. Class Details Tabs
18.6.2. Class Property Toolbar
18.6.3. Property Fields For Class
18.7. Attribute
18.7.1. Attribute Details Tabs
18.7.2. Attribute Property Toolbar
18.7.3. Property Fields For Attribute
18.8. Operation
18.8.1. Operation Details Tabs
18.8.2. Operation Property Toolbar
18.8.3. Property Fields For Operation
18.9. Parameter
18.9.1. Parameter Details Tabs
18.9.2. Parameter Property Toolbar
18.9.3. Property Fields For Parameter
18.10. Signal
18.10.1. Signal Details Tabs
18.10.2. Signal Property Toolbar
18.10.3. Property Fields For Signal
18.11. Reception (to be written)
18.12. Association
18.12.1. Three-way and Greater Associations and Association Classes
18.12.2. Association Details Tabs
18.12.3. Association Property Toolbar
18.12.4. Property Fields For Association
18.13. Association End
18.13.1. Association End Details Tabs
18.13.2. Association End Property Toolbar
18.13.3. Property Fields For Association End
18.14. Dependency
18.14.1. Dependency Details Tabs
18.14.2. Dependency Property Toolbar
18.14.3. Property Fields For Dependency
18.15. Generalization
18.16. Interface
18.16.1. Interface Details Tabs
18.16.2. Interface Property Toolbar
18.16.3. Property Fields For Interface
18.17. Abstraction
18.17.1. Abstraction Details Tabs
18.17.2. Abstraction Property Toolbar
18.17.3. Property Fields For Abstraction
19. Sequence Diagram Model Element Reference
19.1. Introduction
19.1.1. Limitations Concerning Sequence Diagrams in ArgoUML
19.2. Object
19.2.1. Object Details Tabs
19.2.2. Object Property Toolbar
19.2.3. Property Fields For Object
19.3. Stimulus
19.3.1. Stimulus Details Tabs
19.3.2. Stimulus Property Toolbar
19.3.3. Property Fields For Stimulus
19.4. Stimulus Call
19.5. Stimulus Create
19.6. Stimulus Destroy
19.7. Stimulus Send
19.8. Stimulus Return
19.9. Link
19.9.1. Link Details Tabs
19.9.2. Link Property Toolbar
19.9.3. Property Fields For Link
20. Statechart Diagram Model Element Reference
20.1. Introduction
20.1.1. Limitations Concerning Statechart Diagrams in ArgoUML
20.2. State
20.2.1. State Details Tabs
20.2.2. State Property Toolbar
20.2.3. Property Fields For State
20.3. Action
20.3.1. Action Details Tabs
20.3.2. Action Property Toolbar
20.3.3. Property Fields For Action
20.4. Composite State
20.5. Concurrent Region
20.6. Submachine State
20.7. Stub State
20.8. Transition
20.8.1. Transition Details Tabs
20.8.2. Transition Property Toolbar
20.8.3. Property Fields For Transition
20.9. Event
20.9.1. Event Details Tabs
20.9.2. Event Property Toolbar
20.9.3. Property Fields For Event
20.10. Guard
20.10.1. Guard Details Tabs
20.10.2. Guard Property Toolbar
20.10.3. Property Fields For Guard
20.11. Pseudostate
20.11.1. Pseudostate Details Tabs
20.11.2. Pseudostate Property Toolbar
20.11.3. Property Fields For Pseudostate
20.12. Initial State
20.13. Final State
20.13.1. Final State Details Tabs
20.13.2. Final State Property Toolbar
20.13.3. Property Fields For Final State
20.14. Junction
20.15. Choice
20.16. Fork
20.17. Join
20.18. Shallow History
20.19. Deep History
20.20. Synch State
20.20.1. Synch State Details Tabs
20.20.2. Synch State Property Toolbar
20.20.3. Property Fields For Synch State
21. Collaboration Diagram Model Element Reference
21.1. Introduction
21.1.1. Limitations Concerning Collaboration Diagrams in ArgoUML
21.2. Classifier Role
21.2.1. Classifier Role Details Tabs
21.2.2. Classifier Role Property Toolbar
21.2.3. Property Fields For Classifier Role
21.3. Association Role
21.3.1. Association Role Details Tabs
21.3.2. Association Role Property Toolbar
21.3.3. Property Fields For Association Role
21.4. Association End Role
21.4.1. Association End Role Details Tabs
21.4.2. Association End Role Property Toolbar
21.4.3. Property Fields For Association End Role
21.5. Message
21.5.1. Message Details Tabs
21.5.2. Message Property Toolbar
21.5.3. Property Fields For Message
22. Activity Diagram Model Element Reference
22.1. Introduction
22.1.1. Limitations Concerning Activity Diagrams in ArgoUML
22.2. Action State
22.2.1. Action State Details Tabs
22.2.2. Action State Property ToolBar
22.2.3. Property fields for action state
22.3. Action
22.4. Transition
22.5. Guard
22.6. Initial State
22.7. Final State
22.8. Junction (Decision)
22.9. Fork
22.10. Join
22.11. ObjectFlowState
23. Deployment Diagram Model Element Reference
23.1. Introduction
23.1.1. Limitations Concerning Deployment Diagrams in ArgoUML
23.2. Node
23.2.1. Node Details Tabs
23.2.2. Node Property Toolbar
23.2.3. Property Fields For Node
23.3. Node Instance
23.3.1. Node Instance Details Tabs
23.3.2. Node Instance Property Toolbar
23.3.3. Property Fields For Node Instance
23.4. Component
23.4.1. Component Details Tabs
23.4.2. Component Property Toolbar
23.4.3. Property Fields For Component
23.5. Component Instance
23.5.1. Component Instance Details Tabs
23.5.2. Component Instance Property Toolbar
23.5.3. Property Fields For Component Instance
23.6. Dependency
23.7. Class
23.8. Interface
23.9. Association
23.10. Object
23.11. Link
24. Built In DataTypes, Classes, Interfaces and Stereotypes
24.1. Introduction
24.1.1. Package Structure
24.1.2. Exposure in the model
24.2. Built In Datatypes
24.3. Built In Classes
24.3.1. Built In Classes From java.lang
24.3.2. Built In Classes From java.math
24.3.3. Built In Classes From java.net
24.3.4. Built In Classes From java.util
24.4. Built In Interfaces
24.5. Built In Stereotypes
Glossary
A. Supplementary Material for the Case Study
A.1. Introduction
A.2. Requirements Documents (To be written)
A.2.1. Vision Document (To be written)
A.2.2. Use Case Specifications (To be written)
A.2.3. Supplementary Requirements Specification (To be written)
B. UML resources
B.1. The UML specs (To be written)
B.2. UML related papers (To be written)
B.2.1. UML action specifications (To be written)
B.3. UML related websites (To be written)
C. UML Conforming CASE Tools
C.1. Other Open Source Projects (To be written)
C.2. Commercial Tools (To be written)
D. The C++ Module
D.1. Modeling for C++
D.1.1. Class tagged values
D.1.2. Attribute tagged values
D.1.3. Parameters
D.1.4. Preserved sections
E. Limits and Shortcomings
E.1. Diagram Canvas Size
E.2. Missing functions
F. Open Publication License
F.1. Requirements On Both Unmodified And Modified Versions
F.2. Copyright
F.3. Scope Of License
F.4. Requirements On Modified Works
F.5. Good-Practice Recommendations
F.6. License Options
F.7. Open Publication Policy Appendix:
G. The CRC Card Methodology
G.1. The Card
G.2. The Group
G.3. The Session
G.4. The Process
Stichwortverzeichnis

Vorwort

Softwaredesign ist eine kognitiv herausfordernde T??tigkeit. Designer m??ssen die Entw??rfe manuell eingeben, aber die prim??re Schwierigkeit ist Entscheidungen zu treffen weniger Daten einzugeben. Wenn Designer ihre F??higkeiten Entscheidungen zu treffen verbesserten, w??rden bessere Entw??rfe dabei herauskommen.

Aktuelle CASE-Tools enthalten Automations- und grafische Anwender-Schnittstellen, welche die manuelle Arbeit der Designeingabe reduzieren und einen Entwurf in Programmcode transformieren. Sie unterst??tzen die Designer bei ihren Entscheidungen haupts??chlich durch die Visualisierung des Entwurfes und einfachen syntaktischen ??berpr??fungen. Dar??ber hinaus weisen viele CASE-Tools auch substantielle Vorteile im Bereich der Versionskontrolle und nebenl??ufiger Designmechanismen auf. Ein Bereich der Designunterst??tzung, der bisher noch nicht besonders gut unterst??tzt wurde, ist die Analyse von Designentscheidungen.

Aktuelle CASE-Tools haben eine Anwenderschnittstelle (GUI), die es den Designern erm??glicht, auf alle, durch das Tool angebotenen Funktionen zuzugreifen. Und sie unterst??tzen den Entwurfsprozess, indem sie es dem Designer erlauben, Diagramme im Stil popul??rer Design-Methoden einzugeben. ??blicherweise enthalten sie aber keine Prozessunterst??tzung, die den Designer durch die Designschritte f??hrt. Designer beginnen ??blicherweise mit einer leeren Seite und m??ssen jeden Aspekt des Entwurfes aus dem Kopf ableiten.

ArgoUML ist eine dom??nenorientierte Desginumgebung mit kognitiver Unterst??tzung des objektorientierten Entwurfes. ArgoUML enth??lt einige der gleichen Automatismen wie kommerzielle CASE-Tools. Sein Fokus liegt aber auf Funktionen, welche die kognitiven Bed??rfnisse von Designern befriedigen. Diese kognitiven Bed??rfnisse werden durch 3 kognitive Theorien beschrieben:

  1. Reflektion-w??hrend-Aktion;

  2. Opportunistisches Design; und

  3. Verst??ndnis und Probleml??sung.

ArgoUML basiert direkt auf der UML 1.4-Spezifikation. Das zentrale Modell-Repository ist eine Implementierung der Java Metadaten Schnittstelle (JMI=Java Metadata Interface), welche MOF direkt unterst??tzt und die maschinenlesbare Version der UML 1.4-Spezifikation der OMG verwendet.

Dar??ber hinaus ist es unser Ziel, eine verst??ndliche Unterst??tzung f??r OCL (die Object Constraint Language) und XMI (dem XML Model Interchange format) bereitzustellen.

ArgoUML wurde urspr??nglich durch eine kleine Gruppe als Forschungsprojekt entwickelt. ArgoUML hat viele Funktionen, die es sehr speziell machen. Aber es implementiert nicht all die Funktionen, die kommerzielle CASE-Tools enthalten.

Die aktuelle Version (${argo.core.version}) von ArgoUML implementiert alle Diagrammtypen des UML 1.4 Standard (ArgoUML-Versionen vor 0.20 implementierten den UML 1.3 Standard). Sie ist in Java geschrieben und l??uft auf jedem Rechner, der die Java 2-Plattform von Java 1.4 oder eine neuere Version aufweist. Es verwendet zum Speichern offene Dateiformate, wie XMI (XML Metadata Interchange Format) (f??r Modell- Informationen) und PGML (Precision Graphics Markup Language) (f??r grafische Informationen). Wenn ArgoUML UML 2.0 implementiert wird, wird PGML durch die UML Diagram Interchange Spezifikation ersetzt.

Dieses Handbuch ist die gesammelte Arbeit mehrerer Personen und entwickelte sich ??ber mehrere Jahre. Im Zusammenhang mit der ArgoUML-Release 0.10 schrieb Jeremy Bennett eine Menge neues Material, was dem in fr??heren Versionen von Alejandro Ramirez, Philippe Vanpeperstraete und Andreas Rueckert geschriebenen hinzugef??gt wurde. Er f??gte auch einige Dinge aus anderen Dokumenten ein, namentlich aus dem Entwickler-Cookbook von Markus Klink und Linus Tolke, der Kurzanleitung von Kunle Odutola sowie der FAQ von Denny Daniels. Im Zusammenhang mit der Version 0.14 wurden ??nderungen durch Linus Tolke und Michiel van der Wulp vorgenommen. Diese ??nderungen passten das Handbuch an die neuen Funktionen und das neue Erscheinungsbild von ArgoUML, Version 1.4 an und f??hrten einen Index ein. Es sind zu viele Anwender und Entwickler, die diese Arbeit durch Ihre Mitarbeit, wie Review-Kommentare oder Beobachtungen w??hrend des Lesens und der Anwendung des Handbuchs unterst??tzten, um sie alle namentlich benennen zu k??nnen.

ArgoUML ist frei verf??gbar und kann im kommerziellen Umfeld genutzt werden. Wenn Sie ArgoUML herunterladen, entnehmen Sie bitte die Nutzungsbedingungen den beigef??gten Lizenzbedingungen. Wir bieten Ihnen den Sourcecode von ArgoUML an, damit Sie sich diesen ansehen, an Ihre Bed??rfnisse anpassen und verbessern k??nnen. Wir hoffen, dass sich ArgoUML nach und nach zu einem leistungsf??higen und n??tzlichen Tool f??r jedermann entwickelt.

Dieses Anwenderhandbuch ist f??r den Designer gedacht, der seine Entw??rfe mit Hilfe von ArgoUML erstellen m??chte. Das Handbuch setzt voraus, dass Sie mit UML vertraut sind. Eventuell unterst??tzt es aber auch diejenigen, f??r die UML neu ist.

Das Handbuch ist in DocBook/XML geschrieben und sowohl als HTML als auch als PDF verf??gbar.

Das ArgoUML-Projekt heisst alle willkommen, die sich beteiligen wollen. Mehr finden Sie unter der Projekt-Webseite.

Teilen Sie uns bitte mit, was Sie ??ber das Anwenderhandbuch denken! Ihre Kommentare helfen uns, Dinge zu verbessern. Siehe Abschnitt 1.3.3, „Anwender-Feedback“ .

Kapitel 1. Einleitung

1.1. Die Anf??nge und der ??berblick ??ber ArgoUML

1.1.1. Objektorientierte Analyse und Design

Im letzten Jahrzehnt wurde die objektorientierte Analyse und Design (OOA&D) zu dem dominanten Softwareparadigma. Damit einhergehend fand ein Umdenken in allen, an dem Softwarelebenzyklus beteiligten Prozessen statt.

Die Unterst??tzung f??r Objekte begann mit der Programmiersprache Simula 67— aber es war das Erscheinen der Hybridsprachen wie C++, Ada und Objekt Pascal in den 1980'ern, die das durchstarten der OOA&D erm??glichten. Diese Sprachen enthielten eine Unterst??tzung f??r Beides, der OO- und der prozeduralen Programmierung. Die objektorientierte Programmierung wurde zur Hauptentwicklungsrichtung.

Ein OO-System wird als Simulation der realen Welt mit Hilfe von Softwarebausteinen entworfen und implementiert. Diese Pr??misse ist so leistungsf??hig wie einfach. Durch die Anwendung des OO-Design-Ansatzes kann ein System entworfen und getestet (oder korrekter: simuliert) werden, ohne dass es vorher gebaut werden muss.

Es ist die Entwicklung von Tools w??hrend der 1990'er, welche die objektorientierte Analyse und Design unterst??tzen, die diesen Ansatz vorantrieben. Gekoppelt mit der F??higkeit, Systeme auf einer sehr hohen Abstraktionsebene zu entwerfen, erm??glichte der toolbasierte OOA&D-Ansatz die Implementierung sehr viel komplexerer Systeme als sie fr??her m??glich gewesen w??ren.

Das letzte Element, das die OOA&D vorantrieb, war seine Eignung, grafische Anwenderschnittstellen zu modellieren. Die Popularit??t der objektbasierten und objektorientierten grafischen Sprachen, wie Visual Basic und Java reflektieren die Effizienz dieses Ansatzes.

1.1.2. Die Entwicklung von ArgoUML

W??hrend der 1980'er wurden eine Anzahl von OOA&D- Vorgehensmethoden und -Notationen durch unterschiedliche Forscherteams entwickelt. Es wurde klar, dass es viele gemeinsame Themenbereiche gibt und so wurde w??hrend der 1990'er ein vereinheitlichter Ansatz f??r die OOA&D-Notation unter der Schirmherrschaft der Object Management Group entwickelt. Dieser Standard wurde als Unified Modeling Language (UML) bekannt, und ist heute die Standardsprache f??r die Kommunikation von OO-Konzepten.

ArgoUML war als Tool und Umgebung f??r Analyse und Design objektorientierter Softwaresysteme gedacht. In diesem Sinne ist es vergleichbar mit vielen kommerziellen CASE-Tools, die als Tools f??r die Modellierung von Softwaresystemen verkauft werden. ArgoUML weist aber gegen??ber diesen Tools sehr viele wichtige Unterscheidungsmerkmale auf.

  1. Es ist frei.

  2. ArgoUML zeichnet sich durch die Erforschung kognitiver Psychologie aus, um ungew??hnliche Funktionen anbieten zu k??nnen. Diese erh??hen die Produktivit??t durch die Unterst??tzung kognitiver Bed??rfnisse von objektorientiert arbeitenden Softwaredesignern und -Architekten.

  3. ArgoUML nutzt sehr stark offene Standards - UML, XMI, SVG, OCL und andere.

  4. ArgoUML ist eine 100%ige Java-Anwendung. Dadurch kann ArgoUML auf allen Plattformen laufen, auf denen die Laufzeitumgebung der Java2-Plattform verf??gbar ist.

  5. ArgoUML ist ein Open-Source-Projekt. Die Verf??gbarkeit des Quellcodes stellt sicher, dass eine neue Generation von Softwaredesignern und -forschern jetzt ein bew??hrtes Framework haben, von dem aus, sie die Entwicklung und Evolution von CASE-Tooltechnologien vorantreiben k??nnen.

UML ist die am h??ufigsten bevorzugte OO-Modellierungssprache und Java eine der produktivsten OO-Entwicklungsplattformen. Jason Robbins und der Rest seines Forscherteams an der Universit??t Kalifornien vereinten diese Vorteile w??hrend der Entwicklung von ArgoUML. Das Ergebnis ist ein solides Entwicklungstool und eine Umgebung f??r das OO-Systemdesign. Dar??ber hinaus bildet es eine Testumgebung f??r die Evolution der objektorientierten CASE-Tool-Entwicklung und -Forschung.

Eine erste Release von ArgoUML war 1998 verf??gbar. Mehr als 100.000 Downloads bis Mitte 2001 zeigte, dass dieses Projektes in Bildungs- und kommerziellen Bereichen popul??r wurde.

1.1.3. Mehr ??ber das ArgoUML-Projekt

1.1.3.1. Wie wurde ArgoUML entwickelt

Jason Elliot Robbins gr??ndete das Argo-Projekt und erhielt fr??h die Projektleitung. Solange Jason im Projekt aktiv war, hatte er alle H??nde voll mit der Projektleitung zu tun.Das Projekt entwickelte sich kontinuierlich und sehr stark weiter. Es gab mehr als 300 Mitglieder in der Entwickler-Mailliste (siehe http://argouml.tigris.org/servlets/ProjectMailingListList). Mehrere Dutzend von Ihnen bildeten die Kern-Entwicklergruppe.

Die Entwickler-Mailliste ist der Ort, in dem alle Diskussionen ??ber die letzten Aktivit??ten stattfinden und Entwickler die Richtung diskutieren, die das Projektes nehmen sollte. Obwohl manchmal sehr kontrovers, blieben diese Diskussionen immer nett und freundlich (keine "flammenden Kriege" oder ??hnliches), so dass neue Entwickler nicht z??gern und einfach daran teilnehmen sollten. Sie werden immer willkommen sein.

Wenn Sie lernen wollen, wie das Projekt arbeitet und wie Sie sich einbringen k??nnen, rufen Sie die ArgoUML Web Seite "Developer Zone" auf und lesen sich die Dokumentation durch. Das Entwicklerkochbuch wurde speziell f??r diesem Zweck geschrieben.

1.1.3.2. Mehr ??ber die Infrastruktur

Neben der Entwickler-Mailliste gibt es auch eine Mailliste f??r Anwender (siehe The ArgoUML Mailing List List ), in der wir Probleme aus der Anwendersicht diskutieren k??nnen. Entwickler lesen diese Liste auch, so dass grunds??tzlich hoch qualifizierte Hilfe verf??gbar ist.

Bevor Sie eine Frage in eine dieser Listen einstellen, sollten Sie einen Blick auf die von Ewan R. Grantham verwaltete Anwender-FAQ werfen.

Weitere Informationen ??ber ArgoUML und andere UML-bezogene Themen sind unter der von Linus Tolke verwalteten ArgoUML Webseite verf??gbar.

1.2. Der Anwendungsbereich dieses Anwenderhandbuches

1.2.1. Der Leserkreis

Die aktuelle Fassung dieses Dokumentes ist f??r erfahrende Anwender der UML in OOA&D (vielleicht auch mit anderen Tools) gedacht, die zu ArgoUML wechseln m??chten.

K??nftige Fassungen werden Designer unterst??tzen, welche die OOA&D kennen und die UML-Notation in Ihren Entwicklungsprozess einbinden m??chten.

Ein langfristiges Ziel ist es, diejenigen zu unterst??tzen,

  1. die das Design erlernen und mit einem OOA&D-Prozess beginnen wollen, der die UML-Notation unterst??tzt und

  2. Personen, die an einem modularisiertem Design mit Hilfe einer GUI interessiert sind.

1.2.2. Anwendungsbereich

Die Absicht dieses Dokument ist es, eine verst??ndliche Einf??hrung zu geben, die Designer in Lage versetzt, ArgoUML vollst??ndig zu nutzen. Es ist in zwei Teile untergliedert.

  • Ein ??bungshandbuch, das zeigt, wie man mit ArgoUML arbeitet.

  • Ein vollst??ndiges Referenzhandbuch, das alles beschreibt, was Sie mit ArgoUML tun k??nnen.

Die Version 0.22 des Dokumentes bezieht sich auf den zweiten Teil.

In dieser Anleitung gibt es einige Dinge, die Sie nicht finden werden, weil sie an anderen Stellen beschrieben sind.

  • Beschreibungen, wie ArgoUML intern arbeitet.

  • Wie ArgoUML mit neuen Eigenschaften und Funktionen erweitert wird.

  • Eine Anleitung zur Fehlerbehebung.

  • Eine zusammenfassende Kurzanleitung f??r ArgoUML.

Diese Themen werden in Das Entwicklerkochbuch, Die FAQ, und Die Kurzanleitung beschrieben.

1.3. ??berblick ??ber das Anwenderhandbuch

1.3.1. Die Struktur des ??bungshandbuches

Das Kapitel 2, Einleitung enth??lt einen ??berblick ??ber UML-basierte OOA&D einschliesslich einer Anleitung, wie man ArgoUML installiert und startet.

Kapitel 4, Erfassen der Anforderungen bis Kapitel 7, Codegenerierung, Reverse Engineering und Round Trip Engineering geht dann durch alle Teile des Designprozesses. Von der ersten Anforderung bis zum abschliessenden Projekt-Build und der Verteilung.

F??r jedes auftretende UML-Konzept wird dessen Anwendung erl??utert. Anschliessend wird dessen Einsatz innerhalb von ArgoUML beschrieben. Zum Schluss wird eine Fallstudie benutzt, um Beispiele f??r diese Konzepte zu geben.

1.3.2. Die Struktur des Referenzhandbuches

Kapitel 8, Einleitung ist ein ??berblick ??ber die Anwenderschnittstelle und enth??lt eine Zusammenfassung der verschiedenen UML-Diagrammtypen von ArgoUML. Kapitel 10, Die Men??zeile und Kapitel 11, Der Explorer beschreiben die Men??zeile und jedes Fenster der Anwenderschnittstelle.

Kapitel 15, Die Kritiken beschreibt Details aller im System vorhandenen kognitiven Kritiken. Unter Umst??nden wird ArgoUML direkt auf dieses Handbuch verweisen, wenn es die Hilfestellung zu einer Kritik gibt.

Kapitel 16, Modellreferenz auf h??chster Ebene ist ein ??berblick ??ber die Modellelemente (z.B. die UML-Elemente, die in den Diagrammen verwendet werden k??nnen) von ArgoUML. Die folgenden Kapitel ( Kapitel 17, Use Case Diagram Model Element Reference bis Kapitel 24, Built In DataTypes, Classes, Interfaces and Stereotypes) beschreiben die Modellelemente, die in jedem ArgoUML-Diagramm erzeugt werden k??nnen, deren Eigenschaften, sowie einige Standard-Modellelemente die im System enthalten sind.

Es ist ein vollst??ndiges Glossary vorhanden. Anhang A, Supplementary Material for the Case Study enth??lt Material, um die im Dokument durchgehend benutzte Fallstudie zu unterst??tzen. Anhang B, UML resources und Anhang C, UML Conforming CASE Tools verweisen auf Hintergrundinformationen ??ber UML und UML-CASE-Tools. Anhang F, Open Publication License ist eine Kopie der "GNU Free Documentation License".

Eine der k??nftigen Ambitionen ist es, einen vollst??ndigen Index bereitzustellen.

1.3.3. Anwender-Feedback

Bitte teilen Sie uns mit, was Sie ??ber dieses Anwenderhandbuch denken. Ihre Kommentare helfen uns, Verbesserungen vorzunehmen. Mailen Sie Ihre Gedanken an die "ArgoUML Users Mailing List". Sollten Sie ein fehlendes Kapitel hinzuf??gen wollen, kontaktieren Sie bitte ArgoUML Developer Mailing List, damit Sie pr??fen k??nnen, ob bereits jemand anderes an diesem Teil arbeitet. Sie k??nnen sich zu jeder dieser Maillisten ??ber die ArgoUML Webseite anmelden.

1.4. Annahmen

Diese Version des Handbuches unterstellt, dass der Leser mit UML sehr vertraut ist. Dies zeigt sich durch die sparsame Beschreibung der UML-Konzepte in diesem ??bungshandbuch.

Die Fallstudie ist beschrieben, aber noch nicht vollst??ndig realisiert. Dies wird erst in zuk??nftigen Versionen dieses Handbuches der Fall sein.

Teil 1. ??bungshandbuch

Kapitel 2. Einleitung

Dieses ??bungshandbuch f??hrt Sie in Modellierung eines Systems mit Hilfe von ArgoUML ein.

Zuerst werden Sie mit dem Erscheinungsbild des Produktes vertraut gemacht und dann werden wir f??r einen Testfall durch den Analyse- und Entwicklungsprozess gehen. Es wird aber nicht jeder Winkel und jede Ritze des Produktes demonstriert. Dieser Detaillierungsgrad wird im Referenzmaterial bereitgehalten, das Sie in den nachfolgenden Teilen dieses Dokumentes finden.

Der Zustand des Modelles am Ende der Hauptabschnitte wird in .zargo-Dateien verf??gbar sein. Diese sind vorhanden, damit Sie verschiedene, nicht in diesem ??bungshandbuch speziell behandelte Aspekte durchspielen und dann zum richtigen Zustand des Modelles zur??ckkehren k??nnen. Diese .zargo-Dateien werden am Ende der Abschnitte, deren Arbeit sie repr??sentieren, ausgewiesen.

Ein ATM (automated teller machine) Geldautomaten-Projekt wurde als Fallstudie ausgew??hlt, um die verschiedenen Aspekte der von ArgoUML angebotenen Modellierungen zu demonstrieren. In den nachfolgenden Abschnitten werden wir einen „Geldautomaten“ vollst??ndig in UML beschreiben. Das ??bungshandbuch wird Sie allerdings nur durch bestimmte Teile davon f??hren.

An diesem Punkt sollten Sie ein Verzeichnis erzeugen, welches Ihr Projekt aufnimmt. Benennen Sie das Verzeichnis so, dass es zum Rest Ihres Dateisystems passt. Die Inhalte und die Unterverzeichnisse sollten Sie, wie nachfolgend beschrieben, bezeichnen.

Die Fallstudie ist ein Geldautomat. Ihre Firma hei??t „FlyByNight Industries“. Sie werden zwei Rollen spielen. Die des Projektmanagers und die des Analytikers.

Wir werden nat??rlich keinen physikalisch existierende Geldautomaten erstellen. Das Produkt, das wir als Fallstudie erzeugen werden ist ein Geldautomatensimulator, der zum Testen und Entwerfen eines physikalisch vorhandenen Geldautomaten verwendet wird.

Wie Ihre Firma die Arbeit in Projekten organisiert, ist gew??hnlich mehr durch politische als durch andere Einfl??sse bestimmt. Aus diesem Grund steht dies nicht im Mittelpunkt dieses Dokumentes. Wir werden zeigen, wie Sie Ihr Projekt nach dessen Definition selbst strukturieren k??nnen.

Kapitel 3. UML basierte OOA&D

In diesem Kapitel sehen Sie, wie UML als Notation innerhalb der OOA&D verwendet wird.

3.1. Hintergrundinformationen zu UML

Objektorientierung als Konzept kam in den 1960'ern auf und als Designkonzept ab 1972. Erst in den 1980'ern entwickelte sie sich im Bereich Analyse und Design als ernstzunehmende Alternative zum funktionalen Ansatz. Wir k??nnen eine Anzahl von Treibern identifizieren.

  1. Das Erscheinen der OO-Programmiersprachen wie SmallTalk und teilweise C++. C++ war eine pragmatische, von C abgeleitete OO-Sprache, die wegen ihrer Verkn??pfung mit UNIX sehr weit verbreitet war.

  2. Die Entwicklung leistungsf??higer Workstations und das Erscheinen von fensterbasierten Anwenderumgebungen. Grafische Anwenderschnittstellen (GUI) haben eine eingebaute Objektstruktur.

  3. Eine Vielzahl sehr bekannter Projektfehlschl??ge, die nahelegten, dass der aktuelle Ansatz nicht mehr tragf??hig war.

Mehrere Forscher schlugen OOA&D-Prozesse und Notationen vor. Denjenigen, denen tats??chlich etwas Erfolg beschieden war, waren Coad-Yourdon, Booch, Rumbaugh OMT, OOSE/Jacobson, Shlaer-Mellor, ROOM (f??r Echtzeit-Design) und die hybride "Strukturierte Programmierung" von Jackson.

W??hrend der fr??hen 1990'er wurde klar, dass diese Ans??tze viele gute, oft sehr einfache Ideen enthielten. Ein Haupt-Stolperstein waren jedoch die unterschiedlichen Notationen, was bedeutete, dass die Ingenieure mehr mit einer bestimmten OOA&D-Methode als mit dem generellen Ansatz vertraut waren.

UML wurde als gemeinsame Notation erdacht, welche die Interessen Aller ber??cksichtigen sollte. Der Originalstandard wurde durch Rational Rose vorangetrieben ( www.rational.com, in der drei der wichtigsten Forscher arbeiteten (Booch, Jacobson und Rumbaugh waren involviert)). Sie produzierten im Laufe des Jahres 1996 Dokumente, welche die UML, Version 0.9 und Version 0.91 beschrieben. Der Aufwand wurde industrieweit durch die Object Management Group (OMG) fortgesetzt, die bereits durch den CORBA-Standard sehr bekannt war. Ein erster Vorschlag, Version 1.0 wurde im Fr??hjahr 1997 ver??ffentlicht. Eine verbesserte Version 1.1 erschien im Herbst.

ArgoUML basiert auf UML, Version 1.4, die durch die OMG im M??rz 2000 herausgegeben wurde. Die aktuelle offizielle Version ist UML, Version 1.5 vom M??rz 2003, die in K??rze durch die Revision UML, Version 2.0 ersetzt werden wird. Diese befindet sich in den abschliessenden Standardisierungsschritten und wird wahrscheinlich in 2006 vollst??ndig sein.

3.2. UML basierter Prozess f??r OOA&D

Sie m??ssen verstehen, dass UML eine Notation f??r die OOA&D ist. Sie schreibt keinen bestimmten Prozess vor. Welcher Prozess auch immer angewendet wird, ein System wird in mehreren Phasen konstruiert.

  1. Erfassen der Anforderungen. In dieser Phase identifizieren wir die Anforderungen an das System. Dabei verwenden wir die Sprache des Problembereiches. Mit anderen Worten, wir beschreiben das Problem mit den Begrifflichkeiten des „Kunden“.

  2. Analyse. Wir nehmen die Anforderungen und beginnen diese in die Sprache der vermeintlichen L??sung umzuformen, in den L??sungsbereich. Zu diesem Zeitpunkt halten wir die Dinge auf einer hohen Abstraktionsebene, obwohl wir bereits in den Begrifflichkeiten der L??sung denken— entfernt von den konkreten Details einer spezifischen L??sung. Dieser Vorgang ist als Abstraktion bekannt.

  3. Design. Wir nehmen die Spezifikation aus der Analysephase und konstruieren die L??sung ganz detailliert. Wir bewegen uns von der Abstraktion des Problemes hin zu seiner Realisierung in konkreter Form.

  4. Build-Phase. Wir nehmen das aktuelle Design und setzen es in eine reale Programmiersprache um. Das schliesst nicht nur die Programmierung ein, sondern auch das Testen, ob das Programm den Anforderungen (Verifikation) entspricht, testen, ob das Programm das aktuelle Kundenproblem l??st ( Validierung) und das Schreiben der gesamten Anwenderdokumentation.

3.2.1. Prozesstypen

In diesem Abschnitt sehen wir uns die beiden Hauptprozesstypen an, die im Software-Engineering verwendet werden. Es gibt noch weitere, diese werden aber weniger h??ufig eingesetzt.

In den letzten Jahren gab es auch eine Bewegung, den f??r die Entwicklung von Software notwendigen Aufwand zu reduzieren. Dies f??hrte in der Entwicklung zu einer Anzahl von kleineren Prozessvarianten (oft als agile computing oder extreme programming bekannt), die auf sehr kleine Ingenieurteams zugeschnitten waren.

3.2.1.1. Der Wasserfall-Prozess

In diesem Prozess wird jeder Prozessschritt— Erfassen der Anforderungen, Analyse, Design und Build (Code und Test) abgeschlossen, bevor der n??chste beginnt. Dies ist in Abbildung 3.1, „Der Wasserfall-Prozess“ illustriert.

Abbildung 3.1. Der Wasserfall-Prozess

Der Wasserfall-Prozess


Dies ist ein sehr zufriedenstellender Prozess, in dem Anforderungen gut entworfen wurden und keine ??nderungen erwartet werden— zum Beispiel die Automatisierung eines bew??hrten, manuellen Systems.

Der Schwachpunkt dieses Ansatzes zeigt sich bei weniger gut definierten Problemen. Offene Punkte in den Anforderungen bleiben bis zur Phase Analyse und Design, oder auch bis zur Codephase ungekl??rt. Dies erfordert dann ein Zur??ckgehen, um diese Arbeit nachzuholen.

Der schlechteste Aspekt davon ist, dass ausf??hrbarer Code erst zum Ende des Projektes verf??gbar wird. Sehr h??ufig ist es so, dass erst zu diesem Zeitpunkt Probleme mit den Originalanforderungen (zum Beispiel mit der Anwenderschnittstelle) in Erscheinung treten.

Dies ist besonders schlimm, weil jeder folgende Schritt mehr Aufwand als der vorhergehende erfordert, so dass die Kosten sp??t entdeckter Probleme extrem teuer sind. Dies wird durch die Pyramide in Abbildung 3.2, „Zu erwartender Aufwand je Schritt des Wasserfallmodelles“ dargestellt.

Abbildung 3.2. Zu erwartender Aufwand je Schritt des Wasserfallmodelles

Zu erwartender Aufwand je Schritt des Wasserfallmodelles


Der Wasserfallprozess ist wahrscheinlich der dominante Designprozess. Durch seine Beschr??nkungen wird er jedoch mehr und mehr durch iterative Prozesse ersetzt. Insbesondere bei Projekten, bei denen die Anforderungen schlecht definiert sind.

3.2.1.2. Iterative Entwicklungsprozesse

In den letzten Jahren wurde ein neuer Ansatz verwendet, dessen Ziel es war, einen minimalen Teil Code fertigzustellen und schnellstm??glichst ausf??hren zu k??nnen, um Probleme im Entwicklungszyklus sehr schnell aufzudecken.

Diese Prozesse verwenden eine Reihe von „Mini-Wasserf??llen “, definieren einige Anforderungen (die wichtigsten zuerst, bringen diese durch den Analyse- und Design- sowie den Buildprozess, um eine fr??he Version des Produktes mit eingeschr??nkter Funktionalit??t zu erhalten. Die R??ckmeldungen k??nnen dann dazu verwendet werden, die Anforderungen zu ??berarbeiten, punktuelle Probleme zu identifizieren usw. bevor noch mehr Arbeit investiert wird.

Dieser Prozess wird dann f??r alle weiteren Anforderungen wiederholt, um ein Produkt mit wachsender Funktionalit??t zu konstruieren. Erneutes Feedback kann wieder in die Anforderungen einfliessen.

Dieser Prozess wird wiederholt, bis alle Anforderungen implementiert wurden und das Produkt fertig ist. Es ist diese Iteration, die diesem Prozess seinen Namen gab. Abbildung 3.3, „Zu erwartender Aufwand je Schritt des iterativen Prozesses“ zeigt, wie dieser Prozess mit der Pyramidenstruktur des Wasserfallprozesses verglichen werden kann.

Abbildung 3.3. Zu erwartender Aufwand je Schritt des iterativen Prozesses

Zu erwartender Aufwand je Schritt des iterativen Prozesses


Das Wachsen der Popularit??t iterativer Prozesse ist mit dem Wachsen der OOA&D eng verkn??pft. Es ist die saubere Kapselung von Objekten, die es erlaubt, einen Teil des Systems mit klar definierten Leerroutinen f??r den verbleibenden Code zu bauen.

3.2.1.2.1. Der Rational Unified Process

Der wahrscheinlich bekannteste iterative Prozess ist der Rational Unified Process (RUP) von Rational Software ( www.rational.com).

Dieser Prozess ber??cksichtigt, dass unsere Pyramidensicht der Wasserfallebenen nicht realistisch ist. In der Praxis neigen fr??he Iterationen dazu, zu gross zu werden (sie m??ssen zu Beginn eine betr??chtliche Menge definieren), w??hrend sp??tere Iterationen sehr viel Aufwand in der Design- und Buildphase ben??tigen.

RUP erkannte, dass Wiederholungen entsprechend Ihrer Lage im Gesamtprojekt in Phasen aufgeteilt werden k??nnen. Jede Phase kann eine oder mehrere Iterationen umfassen.

  • In der Anfangsphase neigen Iterationen dazu, mit Blick auf die Gesamtanforderung/ Analyse zu gross zu werden, w??hrend jede Build-Aktivit??t bez??glich der Emulation des Desgins durch das CASE-Tool eingeschr??nkt sein kann.

  • In der Ausarbeitungsphase werden die Iterationen dazu benutzt, die Spezifikation der Anforderungen zu vervollst??ndigen. Ihr Schwerpunkt liegt auf Analyse und Design und dem wahrscheinlich ersten real erzeugten Code.

  • In der Konstruktionsphase sind die Anforderungen und Analyse mehr oder weniger vollst??ndig, der Aufwand liegt h??ufig im Design und in der Buildphase.

  • In der abschliessenden Deploymentphase finden Iterationen weitestgehend in den Buildaktivit??ten und teilweise beim Test der Software statt.

[Anmerkung]Anmerkung

Es sollte klar sein, dass Testen ein integraler Bestandteil aller Phasen ist. Gerade in den fr??hen Phasen sollten die Anforderungen und das Design getestet werden. Und dies wird durch ein gutes CASE-Tool unterst??tzt.

Wir wollen in diesem Handbuch einen iterativen Prozess verwenden, der lose auf dem RUP basiert.

3.2.1.2.2. Iterationsgr????e

Eine gute Regel ist es, dass eine Iteration in typischen kommerziellen Projekten zwischen sechs und zehn Wochen umfassen sollte. Bei l??ngeren Zeitr??umen haben Sie sich wahrscheinlich mehr Anforderungen vorgenommen, als Sie in einem Schritt verarbeiten k??nnen. Sie verlieren auch den Fokus auf den n??chsten vollst??ndigen Iterationsschritt. Bei k??rzeren Zeiten haben Sie wahrscheinlich nicht gen??gend Anforderungen um einen sp??rbaren Vorschritt zu erzielen. In diesem Fall wird der mit einer Iteration verbundene zus??tzliche Overhead zum Problem.

Die Gesamtanzahl von Iterationen h??ngt von der Gr??sse des Projektes ab. Nehmen Sie die voraussichtliche Gesamtdauer (gesch??tzte Ausarbeitungzeit f??r das gesamte Subjekt) und unterteilen diese in 8 Wochen grosse Abschnitte. Die Erfahrung sagt, dass Iterationen im Verh??ltnis 1:2:3:3 bez??glich der RUP-Phasen „Anfangsphase“, „ Ausarbeitungsphase“, „Konstruktionsphase“ und „Deploymentphase“ aufgeteilt werden sollten. Ein Projekt, dass grosse Unsicherheiten in seiner Spezifikation aufweist (einige Forschungsprojekte zum Beispiel) wird viel gr??ssere fr??he Phasen aufweisen.

Wenn Sie ein Produkt per Vertrag f??r einen Kunden erstellen, ist der Endpunkt wohl definiert. Jedoch, wenn Sie ein neues Produkt f??r den Markt entwickeln, kann es eine Strategie sein, die Produktver??ffentlichung zu nehmen und den Zeitpunkt f??r das Ende des Engieering zu bestimmen (einige Zeit vorher). Dieser Zeitraum wird dann in Iterationen unterteilt. In dieser Zeit wird so viel von dem Produkt entwickelt wie m??glich. Der iterative Prozess ist sehr effektiv, wenn der Zeitpunkt der Markteinf??hrung wichtiger ist als die exakte Funktionalit??t.

3.2.1.3. Rekursive Entwicklungsprozesse

Sehr wenige Softwaresysteme sind als monolitische Werkzeuge geplant. Sie werden in Subsysteme, Module usw. unterteilt.

Die Softwareprozesse sind die gleichen. Mit fr??hen Abschnitten in denen der Prozess eine Top-Level-Struktur definiert und die wiederholte Anwendung des Prozesses auf Teile der Struktur, um jedes gr??ssere Detail zu definieren.

Zum Beispiel k??nnte das grundlegende Design eines Telefonsystemes Objekte identifizieren um

  1. Telefonleitungen zu belegen,

  2. Anrufe zu verarbeiten,

  3. Anrufe zu verarbeiten,

  4. den Kunden abzurechnen.

Der Softwareprozess kann dann auf jedes dieser vier Komponenten erneut angewendet werden, um deren Design zu identifizieren.

OOA&D mit seinen klaren Objektgrenzen unterst??tzt nat??rlich diesen Ansatz. Eine OOA&D in einer rekursiven Entwicklung wird manchmal als OOA&D/RD abgek??rzt.

Die rekursive Entwicklung kann parallel zu Wasserfall- oder iterativen Prozessen angewendet werden. Sie ist keine Alternative.

3.2.2. Ein Entwicklungsprozess f??r dieses ??bungshandbuch

In diesem ??bungshandbuch wollen wir einen reduzierten iterativen Prozess mit rekursiver Entwicklung, lose gekoppelt mit RUP verwenden. Die Fallstudie bringt uns durch die erste Iteration, obwohl wir am Ende des ??bungshandbuch-Abschnittes sehen werden, wie das Projekt vollst??ndig entwickelt wird.

Innerhalb der ersten Iteration werden wir jede Aktivit??t wie das Erfassen der Anforderungen, die Analyse, das Design und den Build angehen. Nicht alle Teile des Prozesses basieren auf UML oder ArgoUML. Wir werden sehen, welches andere Material hierf??r ben??tigt wird.

Innerhalb dieses Prozesses werden wir die M??glichkeit haben, die verschiedenen UML-Diagramme in ihre Anwendung zu sehen. Der vollst??ndige Umfang der UML-Diagramme und wie sie unterst??tzt werden ist im Referenzhandbuch beschrieben (siehe Abschnitt 16.8, „Diagram“).

3.2.2.1. Erfassen der Anforderungen

Unser "Erfassen der Anforderungen" wird das UML-Konzept von Anwendungsf??llen verwenden. Beginnend mit einem Visions-Dokument werden wir sehen, wie Anwendungsf??lle entwickelt werden k??nnen, um alle Aspekte des Systemverhaltens im Problembereich zu beschreiben.

3.2.2.2. Analyse

W??hrend der Analyse werden wir in das UML-Konzept der Klassen einf??hren. Dieses erlaubt es uns, eine Top-Level- Sicht von Objekten zu erzeugen, welche die L??sung darstellt— manchmal als Konzept-Diagramm bekannt.

Wir werden das UML Sequenzdiagramm und das Zustandsdiagramm einf??hren, um die Anforderungen f??r das Gesamtverhalten des Systems zu erfassen.

Abschliessend nehmen wir die Anwendungsf??lle aus dem Abschnitt „Erfassen der Anforderungen“ und wandeln diese in die Sprache des L??sungsbereiches um. Dies wird die UML-Ideen von Stereotypen und Realisierung illustrieren.

3.2.2.3. Design

Wir verwenden das UML Paketdiagramm, um die Komponenten des Projektes zu organisieren. Wir besuchen dann erneut das Klassendiagramm, das Sequenzdiagramm und das Zustandsdiagramm, um zu zeigen, wie diese rekursiv verwendet werden k??nnen, um die vollst??ndige L??sung zu designen.

W??hrend dieses Prozessteils m??ssen wir unsere Systemarchitektur entwickeln, um zu definieren, wie alle Komponenten zusammenpassen und miteinander zusammenarbeiten.

Obgleich es nicht zwingend Teil unseres Prozesses ist, werden wir uns ansehen, wie das UML Kollaborationsdiagramm als Alternative oder Erg??nzung zum Sequenzdiagramm verwendet werden kann. ??hnlich dem vorhergehenden, werden wir uns das UML Aktivit??tsdiagramm als Alternative oder Erg??nzung zum Zustandsdiagramm ansehen.

Abschliessend wollen wir das UML Deploymentdiagramm verwenden, um zu spezifizieren, wie das System aktuell realisiert werden soll.

3.2.2.4. Build

UML ist nicht wirklich mit dem Schreiben von Code verkn??pft. Jedoch wollen wir an dieser Stelle zeigen, wie ArgoUML f??r die Codegenerierung eingesetzt werden kann.

Wir wollen uns auch ansehen, wie das UML Anwendungsfalldiagramm und die Anwendungsfall-Spezifikation unsch??tzbare Werkzeuge f??r ein Testprogramm sind.

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, dieses 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 alternative Wege zu erreichen.

  2. Die Verwendung von im Designtool parallel ablaufenden Prozessen, die das aktuelle Design gegen Modelle wie „best practice “-Designs ??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, k??nftige Aktionsbereiche aufzuzeichnen.

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

3.3.2. Offene Standards

Die UML selbst ist 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 ??berzugehen, sofern dies notwendig ist.

3.3.2.1. XML Metadata Interchange (XMI)

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

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

Die Realit??t ist nicht sehr gut. 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 Einschr??nkungen auf. Diese Einschr??nkungen sind dazu gedacht, es der Software einfacher zu machen, eine EPS-Datei in ein anderes PostScript-Dokument einzubetten.

  • Das Graphics Interchange Format (GIF) ist ein patentiertes Format, obgleich die Patente im August 2006 ausliefen.

  • 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 bei seinem Einsatz keine Patentlizenz erforderlich 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 im elektronischen und Desktop-Publisching-Bereichen eingesetzt wird.

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

3.3.2.3. 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 Spezifikationssprachen- 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 Randbedingungen 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. Sie hat keinen 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. Dies ist so, 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 bei dichteren Code produzierenden interpretierenden Sprachen bedeuten, dass Sie nicht mehr viel langsamer sind.

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

3.3.4. 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. Mitzuarbeiten ist ein Weg „nebenbei“ mehr ??ber f??hrende Software zu lernen. Es ist ein Weg, eine Menge Sichtbarkeit (??ber 1.125.000 Personen haben ArgoUML Ende 2005 heruntergeladen) zu erhalten. Als Res??me 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 ein St??ck privaten Codes. 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.

3.4. ArgoUML Grundlagen

Das Ziel dieses Abschnittes ist es, Sie in die Lage zu versetzen mit ArgoUML zu starten. Er zeigt Ihnen, wie Sie den Code bekommen und starten k??nnen.

3.4.1. Gestartet bekommen

3.4.1.1. Systemanforderungen

Da ArgoUML in 100% reinem Java geschrieben ist, sollte es auf jeder Maschine mit installiertem Java laufen. Es wird Java, Version 1.4 oder h??her ben??tigt. Sie sollten es zu diesem Zeitpunkt bereits haben, aber falls nicht, k??nnen Sie es von www.java.com frei herunterladen. Beachten Sie, dass Sie nur die Java Runtime Umgebung (JRE) ben??tigen. Es gibt keine Notwendigkeit das gesamte Java Development Kit (JDK) herunterzuladen.

ArgoUML ben??tigt eine vern??nftige Rechenleistung. Einen PC mit einem 200 MHz-Prozessor, 64MB RAM und 10 MB verf??gbaren Speicherplatz auf der Festplatte sollten ausreichen. Laden Sie den Code im Abschnitt Download der Projekt-Webseite argouml.tigris.org herunter. Wie im n??chsten Abschnitt beschrieben, w??hlen Sie die Version aus, die Ihren Anspr??chen am Besten gen??gt.

3.4.1.2. Download-Optionen

Es gibt drei Optionen, wie Sie ArgoUML bekommen k??nnen.

  1. Sie starten ArgoUML direkt von der Web Seite mit Hilfe von Java Web Start. Dies ist die einfachste M??glichkeit.

  2. Sie laden den bin??ren, ausf??hrbaren Code herunter. Dies ist die richtige Option, wenn Sie beabsichtigen, ArgoUML regul??r zu benutzen.

  3. Sie laden sich den Quellcode mit Hilfe von CVS herunter und erzeugen sich Ihre eigene Version. W??hlen Sie diese Option, wenn Sie sich ansehen wollen wie ArgoUML intern arbeitet oder wenn Sie sich als Entwickler einbringen wollen. Diese Option erfordert das vollst??ndige JDK (siehe Abschnitt 3.4.1.1, „Systemanforderungen“).

Alle drei Optionen sind ??ber die Projekt-Webseite argouml.tigris.org frei verf??gbar.

3.4.1.3. ArgoUML mit Java Web Start aufrufen

Hierf??r sind zwei Schritte auszuf??hren.

  1. Sie installieren Java Web Start auf Ihrem Rechner. Java Web Start ist unter java.sun.com/products/javawebstart , oder ??ber den Java Web Start-Link auf der ArgoUML Home page verf??gbar.

  2. Sie klicken auf den Link Launch latest stable release auf der ArgoUML Home page.

Java Web Start wird ArgoUML herunterladen, zwischenspeichern und das erste Mal starten. Bei darauf folgenden Starts pr??ft es, ob ArgoUML aktualisiert wurde, l??dt nur die aktualisierten Teile herunter und startet es. Die ArgoUML Home page enth??lt weitere Details, wie man ArgoUML mit der Java Web Start-Konsole startet.

3.4.1.4. Die bin??re, ausf??hrbare Datei herunterladen

Wenn Sie das Herunterladen der bin??ren, ausf??hrbaren Datei ausw??hlen, k??nnen sie w??hlen, ob Sie die letzte stabile Version (die wahrscheinlich zuverl??ssiger ist, aber nicht alle Features aufweist) oder die aktuelle Version (die weniger zuverl??ssig ist, aber mehr Features aufweist) herunterladen wollen. W??hlen Sie dies entsprechend Ihrer Situation aus.

ArgoUML steht als .zip oder tar.gz Variante bereit. W??hlen Sie die erste Variante, wenn Sie Microsoft Windows Anwender sind und die letzte, wenn Sie mit einer UNIX-Variante arbeiten. Das Entpacken erfolgt wie nachfolgend beschrieben.

  • Bei Windows. Entpacken Sie die .zip-Datei mit WinZip oder einer sp??teren Version von Windows (ME, XP) in ein Verzeichnis Ihrer Wahl.

  • Bei Unix. Nutzen Sie GNU tar, um die Dateien in ein Verzeichnis Ihrer Wahl zu entpacken.

    tar zxvf <file>.tar.gz.

    Wenn Sie eine ??ltere Version von tar haben, ist die z-Option nicht verf??gbar. Benutzen Sie in diesem Fall

    gunzip < file.tar.gz | tar  xvf -.

Sie sollten jetzt in dem Verzeichnis eine Reihe von .jar -Dateien und die Datei README.txt vorfinden.

3.4.1.5. Probleme beim Herunterladen

Wenn das Herunterladen vollst??ndig abbricht und Sie keine lokale Unterst??tzung haben, versuchen Sie es auf der Webseite FAQ. Wenn das Problem mit Hilfe dieser Unterst??tzung nicht gel??st werden kann, versuchen Sie es ??ber die ArgoUML Mailingliste f??r Anwender.

Sie k??nnen sich in die Mailingliste auf der Projektseite argouml.tigris.org eintragen lassen, oder eine leere Nachricht an users@argouml.org mit dem Betreff subscribe senden.

Sie k??nnen dann Ihr Problem an users@argouml.org senden und darauf warten, dass Ihnen andere Anwender helfen.

Die Anwender-Mailingliste ist eine exzellente Einf??hrung f??r eigene Aktivit??ten im Projekt. Wenn Sie noch mehr eingebunden werden wollen, gibt es zus??tzliche Mailinglisten, welche die Entwicklung des Produktes sowie Erweiterungen in aktuellen und in k??nftigen Releases betreffen.

3.4.1.6. ArgoUML starten

Wie Sie ArgoUML starten, h??ngt davon ab, ob Sie Microsoft Windows oder eine Unix-Variante verwenden.

  • Bei Windows. Rufen Sie die MSDOS-Eingabeaufforderung auf, z.B. durch Start/Ausf??hren mit „command“. In dem Fenster wechseln Sie in das Verzeichnis, in dem sich die ArgoUML-Dateien befinden und geben Sie

    java -jar argouml

    ein. Diese Methode hat den Vorteil, dass die Fortschritts- und Debug-Informationen im DOS-Fenster angezeigt werden. Als Alternative erstellen Sie eine Batch- Datei (.bat), die das oben angef??hrte Kommando enth??lt und verlinken diese mit dem Desktop. Die Batchdatei sollte mit einer „pause“-Anweisung enden, f??r den Fall, dass Debug-Informationen w??hrend der Ausf??hrung erzeugt werden. Auf einigen Systemen funktioniert auch ein einfacher (Doppel)- Klick auf die argouml.jar-Datei. Auf anderen wird damit ein Zip-Tool aufgerufen. Sehen Sie in der Beschreibung zum Betriebssystem oder in der Hilfe nach, wie dies zu konfigurieren ist.

  • Bei Unix. ??ffnen Sie ein Shell-Fenster und geben Sie

    java -jar argouml

    ein.

3.4.1.7. Probleme beim Starten von ArgoUML

Wenn Sie ArgoUML erfolgreich heruntergeladen haben, ist es ungew??hnlich, wenn Probleme auftreten. Wenn Sie das Problem nicht l??sen k??nnen, versuchen Sie es ??ber die Anwender-Mailingliste (siehe Abschnitt 3.4.1.5, „Probleme beim Herunterladen“).

  • Falsche JRE. Ein h??ufiger Grund ist eine veraltete Java Runtime Umgebung (es muss die Version 1.4 oder h??her sein).

  • Falsche Sprache. Wenn das Produkt in einer Sprache startet, die sie nicht lesen k??nnen oder wollen, gehen Sie in das zweite Men?? von links. W??hlen Sie den untersten Men??eintrag aus. Abbildung 3.5, „Die Sprache im Erscheinungsbild-Fenster einstellen“ zeigt dies auf russisch. Dann klicken Sie auf den Reiter „Erscheinungsbild “. ??ffnen Sie die Drop-Down-Liste Abbildung 3.5, „Die Sprache im Erscheinungsbild-Fenster einstellen“ und w??hlen Sie eine Sprache aus. Beachten Sie, dass die Namen der Sprache in der jeweiligen Sprache angezeigt werden. Die dargestellte, ausgew??hlte Sprache ist Deutsch. Damit die ??nderungen wirksam werden, m??ssen Sie ArgoUML beenden und neu starten. Verwenden Sie die Taste X oben rechts.

Abbildung 3.4. Den Einstellungs-Assistenten finden

Den Einstellungs-Assistenten finden


Abbildung 3.5. Die Sprache im Erscheinungsbild-Fenster einstellen

Die Sprache im Erscheinungsbild-Fenster einstellen


3.4.2. Die ArgoUML-Anwenderschnittstelle

Bevor Sie mit der Fallstudie beginnen, m??ssen Sie sich noch mit der Anwenderschnittstelle vertraut machen. Lesen Sie hierf??r die Einleitung zur Anwenderschnittstellen- Referenz. Siehe Kapitel 8, Einleitung. Sie sollten auch Abschnitt 8.2, „Generelles Verhalten der Maus in ArgoUML“ lesen.

Wenn Sie dieses ??bungshandbuch durchgehen, wird Ihnen erl??utert, was Sie tun m??ssen. Wie Sie es tun m??ssen, steht oftmals in der Referenz zur Anwenderschnittstelle. Zu diesem Zeitpunkt ist es nicht notwendig, dass Sie die gesamte Referenz durchlesen. Aber Sie sollten tief genug eingestiegen sein, damit Sie Dinge in der Referenz finden k??nnen. An den entsprechenden Punkten im ??bungshandbuch wird der Versuch unternommen, Sie direkt zu den entsprechenden Teilen der Referenz zu f??hren.

Abbildung 3.6, „Erstmaliges ArgoUML-Fenster“, zeigt das ArgoUML-Fenster, wie es beim ersen Aufruf angezeigt wird.

Abbildung 3.6. Erstmaliges ArgoUML-Fenster

Erstmaliges ArgoUML-Fenster


Ziehen Sie die vertikalen Fensterteiler vorw??rts und r??ckw??rts. Ziehen Sie die horizontalen Fensterteiler hoch und runter. Spielen Sie etwas mit den kleinen Pfeilen links oder oben in den Fensterteilern. Siehe Abschnitt 8.3, „Generelle Informationen ??ber Fenster“.

3.4.2.1. Die Men??- und die Symbolleisten

Die Men??leiste und die Symbolleisten erm??glichen Ihnen den Zugriff auf alle Features von ArgoUML. Men??- und Werkzeugoptionen sind per Konvention abgeblendet, wenn sie nicht verf??gbar (ausgeschaltet) sind und Men??elemente, die eine Dialogbox aufrufen, weisen drei Punkte auf (...). Zum jetzigen Zeitpunkt sollten Sie Kapitel 9, Die Werkzeugzeile und Kapitel 10, Die Men??zeile lesen.

Men??: Datei. Die Elemente des Standard-Datei-Men??'s enthalten keine ??berraschungen. Wenn sie ben??tigt werden, werden wir sie einfach verwenden, ohne vorher zu zeigen wie sie arbeiten. Eine Vielzahl anderer, ArgoUML-spezifische Aktionen sind hier verf??gbar. Jetzt werden wir sie allerdings ??berspringen.

  1. Datei=>Projekt speichern r??ckg??ngig machen. Dies hat den gleichen Effekt wie Datei=>Projekt ??ffnen... und dann das aktuelle Projekt ausw??hlen.

  2. Export/Import. Markieren Sie die Projektzeile oben im Explorer. Wenn Sie diese nicht ge??ndert haben, sollte sie "unbenanntes Modell" lauten. F??hren Sie Datei=>Exportiere XMI aus und geben Sie als Dateiname "DeleteThis" im Dateiauswahl-Fenster ein. Markieren Sie den Reiter "Eigenschaften" im Detail-Fenster und ??ndern Sie den Namen des Modelles. F??hren Sie die Datei=>Import XMI- Aktion aus. Sie wird sie fragen, ob Sie Ihre vorher gemachten ??nderungen speichern m??chten. Klicken Sie auf "Nein" und markieren Sie dann die "DeleteThis.xmi"-Datei, die Sie gerade erzeugt haben. ??berpr??fen Sie den Namen des importierten Modelles mit dem von Ihnen gespeicherten.

  3. Datei=>Dateien importieren... . Wir werden dies sp??ter behandeln. Sie k??nnen dies jetzt nicht testen, es sei denn, Sie haben Java-Quellcode zur Hand.

  4. Datei=>(Alle) Grafik(en) exportieren... . Markieren Sie im Explorer-Fenster eines der Diagramme. Entweder das "Klassendiagramm 1" oder "Anwendungsfalldiagramm 1" (dabei wurde unterstellt, dass Sie diese nicht umbenannt oder gel??scht haben). F??hren Sie Datei=>Grafik exportieren... aus. Wenn sich die Dateiauswahl ??ffnet, steht der letzte gespeicherte Name im Feld Dateiname (auch von einen Projekt, das nicht mehr ge??ffnet ist). Die Dateiauswahl erm??glicht es Ihnen, eine Reihe von Formaten auszuw??hlen. ??ffnen Sie das Kombinationsfeld Dateityp und treffen Sie Ihre Wahl. Brechen Sie ab, wenn nichts sinnvolles zum Speichern vorhanden ist. F??hren Sie Datei=>Alle Grafiken exportieren... aus. Beachten Sie, dass Sie zum jetzigen Zeitpunkt keinen Dateinamen und kein Dateiformat ausw??hlen k??nnen. ArgoUML wird Ihnen nur die Eingabe eines Verzeichnisses erlauben. ArgoUML wird dann eine Datei f??r jedes Ihrer Diagramme erzeugen. Der Diagrammname wird der Dateiname und die Dateierweiterung wird durch das Standard-Grafik-Format bestimmt. Obwohl Sie keine Dateinamen im Browserfenster ausw??hlen k??nnen, k??nnen Sie einen Dateinamen in das Editierfeld eingeben. Aber wenn Sie das tun, wird nichts passieren. Sie werden mehr ??ber das Standard-Grafik-Format erfahren, wenn wir zum Bearbeiten-Men?? gehen.

  5. Datei=>Notation. Wir gehen jetzt ein St??ck weiter und erstellen ein kleines Klassendiagramm, so dass wir sehen k??nnen, was es mit der Notation auf sich hat. Im Explorer markieren oder erzeugen Sie ein Klassendiagramm. Siehe Abschnitt 10.6, „Das Men?? "Neues Diagramm"“ und Abschnitt 12.4.3, „Zeichen-Werkzeuge“. Erstellen Sie eine Klasse im Diagramm. Gehen Sie in das Detailfenster und erstellen Sie ein Attribut in der Klasse. Siehe Abschnitt 18.6.2, „Class Property Toolbar“. Im Register Eigenschaften des Detailfensters ??ndern Sie die Kardinalit??t auf "1..*". Jetzt gehen Sie in das Datei-Men?? und w??hlen Notation aus. Wechseln Sie zwischen UML und Java und beobachten Sie die ??nderungen im Editierfenster.

  6. Datei=>Projekt-Einstellungen. Im Dialog Projekt-Einstellungen ist es m??glich, die projektspezifischen Einstellungen zu konfigurieren. Er enth??lt Register f??r den Anwender, die Profile, die Notationen und die Darstellung der Diagramme. Um zum Beispiel die Sprach-Notation im Dialog Projekt-Einstellungen zu ??ndern klicken Sie auf Datei=>Projekt-Einstellungen... und w??hlen Sie den Register Notationen aus. Stellen Sie die Notation auf UML1.4 ein. Markieren Sie alle Optionen und klicken Sie auf ??bernehmen und beobachten Sie die ??nderungen im Diagramm. Stellen Sie die Standard-Schattenbreite auf 8 ein und klicken Sie auf ??bernehmen. Beachten Sie, es passiert nichts. Das ist so, weil Sie nicht die Schattenbreite ver??nderten, sondern den Standardwert. Wenn Sie beim n??chsten Mal eine Klasse in einem Diagramm erstellen, wird dieser neue Schatten erscheinen.

Men??: Bearbeiten. Das Men?? Bearbeiten sieht nicht so aus, wie Sie es von anderen Produkten gewohnt sind. Es gibt keine Aktionen "Ausschneiden", "Kopieren" oder "Einf??gen". Alle Aktionen sind ArgoUML-spezifisch, so dass wir Sie alle im Detail behandeln.

  1. Bearbeiten=>Markieren.

    • Markieren Sie ein Klassendiagramm im Explorer. Ist keines vorhanden, erstellen Sie eines mit Hilfe von Neues Diagramm=>Klassendiagramm. Erstellen Sie mit Hilfe des Klassenwerkzeuges drei Klassen, wie in der Referenz zur Anwenderschnittstelle unter klassendiagrammspezifische Werkzeuge beschrieben. F??hren Sie einen Doppelklick aus und klicken Sie dann im Editierfenster f??r Klassendiagramme auf die drei unterschiedlichen Klassen.

    • Durch klicken auf das "Markieren"-Werkzeug machen Sie den aktuellen Modus r??ckg??ngig. Siehe "Durch klicken auf das "Markieren"-Werkzeug den aktuellen Modus r??ckg??ngig machen". Abschnitt 12.4.1, „Layout-Werkzeuges“. Dies erlaubt es Ihnen auch andere Dinge, wie das Erstellen von Klassen im Editierfenster auszuf??hren.

    • Jede Klasse im Diagramm besteht aus drei vertikalen Abschnitten. F??hren Sie einen Doppelklick auf den obersten Abschnitt aus und geben Sie einen Namen f??r die Klasse ein. Anschliessend bet??tigen Sie die Enter-Taste. Benennen Sie die Klassen jetzt mit "A", "B" und "C". Markieren Sie die Klasse A, dann die Klasse B und dann die Klasse C, entweder im Editierfenster oder im Explorer.

    • F??hren Sie den Befehl Bearbeiten=>Markieren=>Zur??ck aus. Jetzt sollte die Klasse B markiert sein. F??hren Sie erneut Bearbeiten=>Markieren=>Zur??ck aus. Die Klasse A sollte jetzt markiert sein. Abschliessend f??hren Sie den Befehl Bearbeiten=>Markieren=>Vorw??rts aus. Die Klasse B sollte erneut markiert sein.

    • F??hren Sie jetzt den Befehl Bearbeiten=>Markieren=>Umkehren aus. Jetzt sollten die Klassen A und C markiert sein. F??hren Sie erneut den Befehl Bearbeiten=>Markieren=>Umkehren aus. Die Klasse B sollte wieder markiert sein.

    • F??hren Sie den Befehl Bearbeiten=>Markieren=>Aus Diagramm entfernen aus. Beachten Sie, dass die Klasse B aus dem Diagramm verschwunden ist, aber im Explorer immer noch existiert.

    • Markieren Sie die Klasse B im Explorer, klicken Sie mit der rechten Maustaste auf die Klasse und w??hlen Sie "Zum Diagramm hinzuf??gen" aus. Bewegen Sie den Cursor in das Editierfenster und klicken mit der linken Maustaste auf den Teil des Diagrammes, wo Sie glauben, dass die Klasse am Besten hinpasst. Sie sollten die Klasse an die Stelle zur??ckbringen, von der Sie sie vorher aus dem Diagramm entfernt haben. F??hren Sie den Befehl Bearbeiten=>Markieren=>Aus Modell entfernen aus. Jetzt sollte die Klasse B sowohl aus dem Diagramm als auch aus dem Explorer verschwinden.

  2. Bearbeiten=>Konfiguriere Perspektiven... . Lesen Sie Abschnitt 11.5, „Perspektiven konfigurieren“. Wir werden dies zum jetzigen Zeitpunkt nicht vertiefen, da es sehr viel gr??sserer darzustellender Projekte bedarf, als wir Sie jetzt zur Verf??gung haben.

  3. Bearbeiten=>Einstellungen...=>Voreinstellungen . Geben Sie Hilfe=>??ber ArgoUML ein. Sehen Sie sich das Bild im Register Logo an. Dies wird als Startfenster bezeichnet. Gehen Sie in Bearbeiten=>Einstellungen...=> Voreinstellungen. Schalten Sie die Optionsschaltfelder "Startfenster anzeigen" und "Gemeinsame Klassen im Voraus laden" aus. Beenden Sie ArgoUML und starten Sie es erneut. Beachten Sie, dass das Startfenster w??hrends des Hochfahrens nicht mehr erscheint.

  4. Bearbeiten=>Einstellungen...=>Umgebung . F??hren Sie den Befehl Datei=>Grafik exportieren... aus und beobachten Sie die Dateierweiterung im Dialogfeld "Dateityp" des Dateiauswahl-Dialoges. Gehen Sie in Bearbeiten=>Einstellungen...=> Umgebung und w??hlen einen anderen Wert f??r das Standard-Grafik-Format aus. Klicken Sie auf "??bernehmen" und dann auf "OK". Gehen Sie zur??ck in den Datei=>Grafik exportieren...- Dialog und beachten Sie, dass das neue Format jetzt der Standard ist.

  5. Bearbeiten=>Einstellungen...=>Benutzer . Geben Sie Ihren Namen und Ihre E-Mailadresse ein.

  6. Bearbeiten=>Einstellungen...=>Erscheinungsbild . ??ndern Sie "Aussehen" in "Metall". Beachten Sie, dass das Dialogfeld "Metall-Thema" aktiviert wird. ??ndern Sie das Thema in "Sehr grosse Schrift". Klicken Sie auf "??bernehmen" und dann auf "OK". Beachten Sie, dass nichts passiert ist. Beenden Sie ArgoUML und starten Sie es erneut. Die Darstellung sollte deutlich anders aussehen. Machen Sie Ihre ??nderungen r??ckg??ngig. Nehmen Sie Werte, die Sie bevorzugen.

  7. Bearbeiten=>Einstellungen...=>Notationen . Bei den Men??elementen Datei=>Notation und Datei=>Eigenschaften... spielten wir bereits damit herum. Starten Sie eine weitere Instanz von ArgoUML und stellen Sie die Gr??sse jeder Instanz so ein, dass Sie sie gleichzeitig ansehen k??nnen. In einer Instanz stellen Sie die Notation auf UML (die aktuelle Einstellung zeigt auch noch die Versionsnummer an), in der anderen stellen Sie die Notation auf Java ein.

    In beiden tun Sie bitte folgendes. Schalten Sie alle Optionsschaltfelder ein. F??hren Sie den Befehl Datei=>Neu aus und erstellen Sie eine Klasse in einem Klassendiagramm. Erstellen Sie ein Attribut mit Hilfe eines Doppelklicks auf den Abschnitt Attribute. Erstellen Sie eine Operation mit Hilfe eines Doppelklicks auf den Abschnitt Operationen. Beobachten Sie die Unterschiede in den Darstellungen.

  8. Bearbeiten=>Einstellungen...=>Module. Dies ist zuk??nftige Arbeit. Wir wollen dies nicht mit dieser Version des Tutorials vermischen.

Men??: Ansicht. Dieses Men?? erlaubt Ihnen zwischen Diagrammen hin- und herzuschalten, Modellelemente in einem Modell aufzufinden, in ein Diagramm hineinzuzoomen, das Gitter einzustellen, die Darstellung des Seitenumbruches zu ??ndern und die XML-Darstellung des Projektes anzuzeigen. Um zu einem definierten Punkt zur??ckzukehren, f??hren Sie Datei=>Neu... aus. Erstellen Sie je Diagramm ein Beispiel und f??hren Sie noch keine T??tigkeit im Explorer aus. Um die Baumknoten zu expandieren, klicken Sie auf die (+)-Zeichen im Explorer. Markieren Sie das entsprechende Klassendiagramm und vergeben Sie einen Namen.

  1. Ansicht=>Gehezu Diagramm... blendet ein Gehezu-Diagramm-Dialogfester auf. Markieren Sie den Eintrag Klassendiagramm und klicken Sie auf die Schaltfl??che "Gehe zur Auswahl". In der Spalte am rechten Rand sollten 0 Knoten und 0 Kanten angezeigt werden. Klicken Sie auf die Schaltfl??che "Schliessen". Im Fenster Details (Register Eigenschaften) geben Sie den Namen "Blort" ein. Erstellen Sie im Klassendiagramm zwei Klassen (Siehe ...) und gehen Sie wieder in Ansicht=>Gehezu Diagramm... . Sie sollten jetzt 2 Knoten und 0 Kanten angezeigt bekommen. Klicken Sie erneut auf die Schaltfl??che "Schliessen" und verbinden Sie die Klassen mit einem der "Linien"-Elemente wie Assoziation oder Vererbung. Gehen Sie erneut in Ansicht=>Gehezu Diagramm... und Sie sollten 2 Knoten und 1 Kante(n) sehen. Klicken Sie erneut auf die Schaltfl??che "Schliessen" und erstellen Sie eine dritte Klasse. Gehen Sie mit der Maus in die Werkzeugleiste zur Schaltfl??che "Neue Beziehungsklasse". Klicken Sie dieses Werkzeug an und verbinden Sie die neue Klasse mit einer der anderen. Nachdem Sie auf "Neue Beziehungsklasse" geklickt haben, bewegen Sie die Maus ??ber die neue Klasse. Halten Sie die Taste 1 gedr??ckt. Bewegen Sie die Maus zur anderen Klasse und lassen Sie die Taste 1 los. Gehen Sie erneut in Ansicht=>Gehezu Diagramm... und Sie sollten 3 Knoten und 2 Kante(n) sehen. Obwohl es eine Klasse ist und eine zweidimensionale Darstellung aufweist, z??hlt sie als Kante und nicht als Knoten. Markieren Sie andere Eintr??ge in diesem Fenster und klicken Sie auf die Schaltfl??che "Gehe zur Auswahl" im "Gehezu Diagramm"- Fenster. Beobachten Sie die ??nderungen im Explorer.

  2. Ansicht=>Suchen.... Zu diesem Zeitpunkt sollten sich drei normale Klassen und eine Beziehungsklasse im Explorer befinden. Benennen Sie diese "AA", "AB", "B" und "C". F??hren Sie eine Ansicht=>Suchen...- Operation aus. Klicken Sie auf die Schaltfl??che "Suchen". Beachten Sie, dass ein Register "* in *" erzeugt wurde. Dieses Register sollte sehr viele neue Dinge zeigen. ??ndern Sie im "Im Diagramm"-Editor "*" in "B*" und klicken Sie auf die Schaltfl??che "Suchen". Beobachten Sie den Inhalt des neuen Registers "* in B*". Sie sollten drei Klassen, die Verbindung (eine Assoziation) und die Assoziationsklasse sehen. Markieren Sie in der Kombinationsliste "Element-Typ" das Element "Schnittstelle" und klicken Sie auf die Schaltfl??che "Suchen". Im neuen Register "* in B* Inte..." sollten keine Eintr??ge vorhanden sein, da wir keine Schnittstellen definiert haben. Markieren Sie in der Kombinationsliste "Element-Typ" das Element "Klasse" und klicken Sie auf die Schaltfl??che "Suchen". Im neuen Register "* in B* Class" sollte ein Eintrag weniger vorhanden sein als im Register "* in B*". Wechseln Sie zwischen diesen beiden Registern hin und her und beobachten Sie die Unterschiede. Markieren Sie in einigen dieser Register ein Element und klicken Sie auf die Schaltfl??che "Gehe zur Auswahl". Beobachten Sie die ??nderungen im Diagramm und im Explorer.

  3. Ansicht=>Zoom. Als Ausnahme zur generellen Regel arbeitet das Symbolleisten- Equivalent von Ansicht=>Zoom nicht auf die gleiche Art und Weise wie das entsprechende Men??element. Durch das Hervorheben von Ansicht=>Zoom erscheint ein Untermen??, welches die Elemente "Vergr??ssern", "R??ckg??ngig" und "Verkleinern" enth??lt. Klicken Sie mehrmals auf diese Elemente und beobachten Sie die Effekte im Diagramm. Anschliessend klicken Sie auf die Zoom- Schaltfl??che in der Werkzeugleiste. Es erscheint ein Schieberegler, dessen Zeiger Sie bewegen k??nnen. Verschieben Sie den Zeiger und bewegen Sie ihn nach oben und nach unten und beobachten Sie dabei den Effekt auf das Diagramm.

  4. Ansicht=>Raster einstellen.

  5. Ansicht=>Einrasten einstellen.

  6. Ansicht=>Seitenumbr??che.

  7. Ansicht=>XML Dump.

Men??: Neues Diagramm. Das Men?? erlaubt es Ihnen, jedes der sieben von ArgoUML unterst??tzten UML-Diagrammtypen (Klasse, Anwendungsfall, Zustands-, Aktivit??ts-, Kollaborations-, Verteilungs- und Sequenzdiagramm) zu erstellen.

Zustands- und Aktivit??tsdiagramme k??nnen nur erstellt werden, wenn eine Klasse oder ein Akteur markiert ist und die relevanten Men??eintr??ge nicht deaktiviert sind (unter diesen Umst??nden passiert nichts).

Men??: Anordnen. Das Men?? Anordnen erlaubt es Ihnen, Modellelemente im Diagramm auszurichten, zu verteilen und neu anzuordnen und die Layout- Strategie f??r das Diagramm einzustellen.

Men??: Generieren. Das Men?? Generieren erlaubt es Ihnen, Java Code f??r die markierten oder alle Klassen zu generieren.

Men??: Kriterien. Das Men?? Kriterien erlaubt es Ihnen, die Pr??fkriterien ein- und auszuschalten, die Wichtung der Designvorgaben und Designzile festzulegen und die verf??gbaren Kriterien anzusehen.

Men??: Werkzeuge. Diese Men?? ist dauerhaft deaktiviert, es sei denn es sind Werkzeuge in Ihrer Version von ArgoUML verf??gbar.

Men??: Hilfe. Dieses Men?? gibt Zugriff auf die Details, wer das System erdachte und wo zus??tzliche Hilfe gefunden werden kann.

Werkzeugleiste: Datei. Diese Werkzeugleiste enth??lt einige Werkzeuge des Datei-Men??'s.

Werkzeugeleiste: Bearbeiten. Diese Werkzeugleiste enth??lt einige Werkzeuge des Bearbeiten- Men??'s.

Werkzeugleiste: Ansicht Diese Werkzeugleiste enth??lt einige Werkzeuge des Bearbeiten- Men??'s.

Werkzeugeleiste: Neues Diagramm. Diese Werkzeugleiste enth??lt einige Werkzeuge des Men??'s Neues Diagramm.

3.4.2.2. Der Explorer

Jetzt sollten Sie sich die Zeit nehmen Kapitel 11, Der Explorer zu lesen. Der Explorer ist fundamental f??r alles was Sie tun. Wir werden im Folgenden immer wieder auf ihn zur??ckkommen.

Im Explorer gibt es vor dem Paketsymbol „unbenanntes Modell “ ein Steuerelement zum Expandieren und Reduzieren und im "zu bearbeiten"-Fenster vor dem Paketsymbol „Mittel“. Klicken Sie auf diese Steuerelemente und beachten Sie, dass diese Fenster Baumstrukturen sind, die sich besser benehmen als Sie es erwarten w??rden. Das Steuerelement zum Expandieren oder Reduzieren ist entweder ein Plus-(+)/Minus-(-)Zeichen oder ein Knauf mit einem rechten oder nach unten gerichteten Zeiger, je nach dem, welches Aussehen (Look and Feel) von Ihnen eingestellt wurde.

Markieren Sie entweder das Klassendiagramm 1 oder das Anwendungsfalldiagramm 1 und beobachten Sie, wie sich der Inhalt des Detailfensters sich je nach markiertem Element im Explorer ??ndert. Das Detail-Fenster ist im Kapitel 12 beschrieben. Zum jetzigen Zeitpunkt ist es nicht erforderlich das Kapitel 12 zu lesen. Aber, es kann auch nichts schaden.

3.4.2.3. Das Editierfenster

Jetzt sollten Sie sich die Zeit nehmen, das Kapitel 12, Das Editierfenster zu lesen.

Wenn wir durch das Editierfenster gehen, werden manchmal ??nderungen im Detail- und im "zu bearbeiten"-Fenster auftreten. Beachten Sie diese im Moment nicht. Wir werden sie betrachten, wenn wir diese Fenster durchgehen.

Markieren Sie im Explorer das "Klassendiagramm 1". Der Name ist unwichtig. Wenn Sie ihn ge??ndert haben, markieren Sie nun den neuen Namen. Wenn Sie es gel??scht haben, f??hren Sie zuerst eine Neues Diagramm=>Klassendiagramm-Aktion durch. Klicken Sie auf die Schaltfl??che "Neues Paket" in der Werkzeugleiste des Editierfensters. Klicken Sie im Editierfenster irgendwohin. Beachten Sie, dass im Explorer ein Paket mit dem Namen (unbenannt Paket) erscheint.

F??hren Sie einen Doppelklick in der Werkzeugleiste des Editierfensters auf der Schaltfl??che "Neue Klasse" aus. Klicken Sie zuerst in das Paket und einmal ausserhalb des Paketes. Beachten Sie, dass im Explorer im Baum zwei Klassen beide mit dem Namen (unbenannt Klasse) erscheinen. Eine direkt mit dem Modellknoten und die andere mit dem Knoten (unbenannt Paket) verkn??pft.

Klicken Sie auf die Schaltfl??che Ausw??hlen in der Werkzeugleiste des Editierfensters und Sie k??nnen im Editierfenster arbeiten ohne neue Klassen hinzuzuf??gen. Markieren Sie im Explorer die Klasse, die nicht dem Paket zugeordnet ist. Dies markiert die entsprechende Klasse im Diagramm. Greifen Sie sich diese Klasse und verschieben Sie sie in das Paket. Beachten Sie, dass diese Klasse jetzt im Explorer ebenfalls dem Paketknoten untergeordnet wurde.

Markieren Sie im Diagramm die andere Klasse. Beachten Sie, dass sich im Explorer der markierte Knoten entsprechend ver??ndert. Greifen Sie diese Klasse und verschieben Sie sie aus dem Paket und beobachten Sie, was im Explorer passiert.

3.4.2.4. Das Detail-Fenster

Jetzt sollten Sie sich die Zeit nehmen Kapitel 13, Der Bereich Details zu lesen.

[Anmerkung]Anmerkung
  • Zu bearbeiten. Diskutiert die Unterschiede zu den anderen Registern je markiertem Element. Beinhaltet die Einzelheiten f??r die Diskussion im "Zu bearbeiten"-Fenster.

  • Eigenschaften,

  • Dokumentation,

  • Darstellung,

  • Quellcode,

  • Randbedingungen,

  • Stereotypen,

  • Eigenschaftswerte,

  • Checkliste.

  • Entfernen Sie "images/tutorial/detailsoverview.gif" aus dem Dateisystem.

3.4.2.5. Das "zu bearbeiten"-Fenster

Jetzt sollten Sie sich die Zeit nehmen Kapitel 14, Der Bereich Zu-Bearbeiten zu lesen.

[Anmerkung]Anmerkung
  • Beschreibt Priorit??ten.

  • L??st Elemente auf.

  • Beziehung zum "zu bearbeiten"-Register im Detail- Fenster.

  • Entfernen Sie "images/tutorial/todooverview.gif" aus dem Dateisystem.

3.4.2.6. Diagramme zeichnen

Grunds??tzlich werden Diagramme mit Hilfe der Werkzeugleiste des Editierfensters gezeichnet. Das gew??nschte Modellelement wird markiert und durch anklicken der gew??nschten Position im Diagramm positioniert.

Modellelemente, die sich bereits im Modell, aber nicht in einem Diagramm befinden, k??nnen dem Diagramm hinzugef??gt werden, indem man das Modellelement im Explorer markiert, aus dem Drop-Down-Men?? (Taste 2) Zum Diagramm hinzuf??gen ausw??hlt und dann mit der Taste 1 auf die gew??nschte Position im Diagramm klickt.

Genauso wie f??r UML-Modellelemente liefert die Werkzeugleiste des Editierfensters Zeichenobjekte (Rechtecke, Kreise, Linien, Polygone, Kurven, Text), um erg??nzende Informationen in Diagramme einbringen zu k??nnen.

3.4.2.6.1. Diagrammelemente bewegen

Es gibt verschieden Wege Diagrammelemente zu bewegen.

3.4.2.6.1.1. Mit Hilfe der Maustasten

Markieren Sie die Elemente, die Sie bewegen wollen. Durch dr??cken der Taste Strg k??nnen Sie mehrere Elemente markieren und und zeitgleich bewegen.

Nun bet??tigen Sie Ihre Pfeiltasten. Ihre Elemente bewegen sich bei jedem Tastendruck ein wenig.

Wenn Sie zus??tzlich die Umschalttaste bet??tigen, bewegen Sie sich ein wenig weiter.

3.4.2.6.1.2. Mit Hilfe der Werkzeugleiste des Editierfensters

Klicken Sie auf die Schaltfl??che "Besen" in der Werkzeugleiste. Bewegen Sie Ihre Maus in das Diagrammfenster, klicken rechts und halten sie gedr??ckt. Nun wird das Bewegen der Maus die Elemente ausrichten.

3.4.2.6.2. Elemente anordnen

Das Men?? Anordnen erlaubt es Ihnen, Elemente auszurichten oder zu gruppieren.

3.4.2.7. Mit Projekten arbeiten

3.4.2.7.1. ArgoUML nach dem erstmaligen Start

Abbildung 3.6, „Erstmaliges ArgoUML-Fenster“ zeigt, wie ArgoUML nach dem erstmaligen Start erscheint.

Das Hauptfenster ist in vier Fenster unterteilt. Dar??ber befinden sich das Men?? und die Werkzeugleiste. Wenn wir mit dem Fenster oben links beginnen und im Uhrzeigersinn weitergehen, k??nnen Sie den Explorer, der eine Baumansicht Ihres UML-Modelles anzeigt, das Editierfenster mit seiner Werkzeugleiste, zwei Scrollleisten und einer grauen Zeichenfl??che, das Detailfenster mit markiertem "zu bearbeiten"-Register und das "zu bearbeiten"-Fenster mit einer Baumansicht der zu bearbeitenden Elemente, auf verschiedene Art und Weise sortiert, je nach Auswahl in der Drop-Down-Liste im oberen Bereich des Fenster.

Jedesmal wenn ArgoUML ohne Projektdatei als Argument gestartet wird, wird ein neues leeres Projekt erzeugt. Dieses Projekt enth??lt ein Modell mit dem Namen unbenanntesModell. Diese Modell enth??lt ein leeres Klassendiagramm, Klassendiagramm 1 genannt und ein leeres Anwendungsfall- Diagramm, Anwendungsfalldiagramm 1 genannt.

Das Modell und die beiden leeren Diagramme k??nnen Sie im Explorer sehen, der f??r Sie das Hauptwerkzeug darstellt, um durch Ihr Modell zu navigieren.

Lassen Sie uns f??r einen Moment annehmen, dass dies jetzt der Zeitpunkt ist, wo Sie mit der Modellierung eines neuen Einkaufs- systems beginnen wollen. Sie wollen ihm den Namen einkaufsmodell geben und Sie wollen es in einer Datei mit dem Namen ErstesProjekt speichern.

3.4.2.7.2. Ein Projekt speichern - Das Men??: Datei

Im Moment speichert ArgoUML Diagramme in einem fr??h ver??ffentlichtem Standard, der Precision Graphics Markup Language (PGML). F??r diejenigen, die davon Gebrauch machen wollen, gibt es allerdings die Option, die grafischen Daten als SVG zu exportieren. Wenn ArgoUML UML 2.0 unterst??tzt, werden die Diagramme im UML 2.0 Diagramm Austausch Format gespeichert.

Zuerst lassen Sie uns das Modell in seinem aktuellen (leeren und unbenannten) Zustand speichern. Klicken Sie in der Men??zeile auf Datei, dann auf Projekt speichern unter.... Sie auch Abbildung 3.7, „ Projekt speichern unter... aufrufen “.

Abbildung 3.7. Projekt speichern unter... aufrufen

Projekt speichern unter... aufrufen


Bitte beachten Sie, dass das Men?? Datei die ??blichen Optionen f??r das Erzeugen eines neuen Projektes, f??r das ??ffnen eines existierenden Projektes, f??r das Speichern eines Projektes unter einem neuen Namen, f??r das Drucken des aktuell angezeigten Diagrammes, f??r das Speichern des aktuell angezeigten Diagrammes als Datei und f??r das Beenden des Programmes enth??lt.

Einige diese Men??-Kommandos k??nnen auch mit Hilfe einer Tastenkombination, wie im Drop-Down-Men?? dargestellt, ausgel??st werden. Das Festhalten der Taste „Strg“ und das Dr??cken der Taste „N“ wird zum Beispiel ein neues Projekt erzeugen.

In der aktuellen Version kann ArgoUML nur ein aktives Projekt gleichzeitig bearbeiten. Zus??tzlich kann ein Projekt nur ein UML- Modell enthalten. Da ein UML-Modell eine unbegrenzte Anzahl von Elementen und Diagrammen beinhalten kann, sollte es keine schwerwiegenden Begrenzugen aufweisen, gerade f??r die Modellierung sehr grosser und komplexer Systeme.

3.4.2.7.3. Der Dateiauswahl-Dialog

Aber lassen Sie uns zum Speichern unseres Projektes zur??ckgehen. Nachdem wir das Men??-Kommando Projekt speichern unter... angeklickt haben, ??ffnet sich der Dateiauswahl-Dialog, in dem wir den von uns gew??nschten Dateinamen eingeben k??nnen. Siehe auch Abbildung 3.8, „Der Dateiauswahl-Dialog“.

Abbildung 3.8. Der Dateiauswahl-Dialog

Der Dateiauswahl-Dialog


Dies ist eine Standard-Java-Dateiauswahl. Lassen Sie uns in einige Details einsteigen.

Die Hauptfunktion ist die scrollbare Verzeichnisliste in der Mitte des Dialoges. Mit Hilfe der Scrollleiste auf der rechten Seite k??nnen Sie sich in der Liste der im aktuell markierten Verzeichnis befindlichen Verzeichnisse nach oben und nach unten bewegen. Ob sie scrollbar oder nicht scrollbar ist, h??ngt von Menge der angezeigten Dateien und Verzeichnisse und deren Darstellung ab. Wenn alles in das Fenster passt, ist es nicht scrollbar, wie im Bild dargestellt.

Doppelklicken auf eine der angezeigten Verzeichnisse navigiert Sie in dieses Verzeichnis und erlaubt es Ihnen, schnell in der Verzeichnishierarchie Ihrer Festplatte hinunterzunavigieren.

Beachten Sie, dass nur Verzeichnisnamen und keine Dateinamen im Scrollbereich angezeigt werden. Tats??chlich ist der Dialog aktuell so eingestellt, dass er nur ArgoUML-Projektdateien mit der Erweiterung .zargo anzeigt. Dies k??nnen Sie im unteren Drop-Down-Steuerelement mit dem Namen Dateityp: sehen.

Beachten Sie auch, dass der aktuell markierte Verzeichnisname im oberen Drop-Down-Steuerlement mit der Bezeichnung Speichern in: angezeigt wird. Ein einziger Klick auf ein Verzeichnis innerhalb des Scrollbereiches markiert das Verzeichnis am Bildschirm, markiert das Verzeichnis allerdings nicht zum speichern.

Im oberen Bereich des Dialoges, ??ber dem scrollbaren Verzeichnis- Auswahlbereich, gibt es einige weitere Verzeichnis-Navigations- Werkzeuge.

  • Das Verzeichnis-Drop-Down-Steuerelement. Klicken auf den Pfeil zeigt eine Baumansicht der Verzeichnis- Hierarchie an, erlaubt es Ihnen schnell in der Hierarchie nach oben und unten zu navigieren und gleichzeitig schnell zu bestimmen, wo Sie sich aktuell in der Hierarchie befinden.

  • Das Symbol: Verzeichnis-nach-oben. Klicken auf dieses Symbol wird Sie in das ??bergeordnete Verzeichnis des aktuellen Verzeichnisses bringen.

  • Das Symbol: Home-Verzeichnis. Klicken auf dieses Symbol wird Sie in Ihr Home-Verzeichnis bringen.

  • Das Symbol: Neues Verzeichnis. Klicken auf dieses Symbol wird ein neues Verzeichnis, genannt „Neues Verzeichnis“ unter dem aktuellen Verzeichnis erzeugen. Nachdem das Verzeichnis erzeugt wurde, markieren Sie es und klicken Sie auf den Namen. Dies erlaubt es uns, den Namen unserer Wahl zu vergeben.

  • Das Symbol: Darstellung der Verzeichnisse.

OK, jetzt navigieren wir in das Verzeichnis, in das wir unsere ArgoUML-Projektdatei speichern wollen. F??llen Sie Dateiname: mit dem entsprechenden Namen aus, wie z.B. ErstesProjekt und klicken Sie auf die Schaltfl??che Speichern.

Sie haben nun ein aktives Projekt, ErstesProjekt genannt, das mit der Datei ErstesProjekt.zargo verbunden ist.

3.4.3. Ausgabe

3.4.3.1. Laden und Speichern

3.4.3.1.1. XMI-Dateien in ArgoUML speichern

ArgoUML speichert die Diagramminformationen in einer PGML-Datei (mit der Erweiterung .pgml, die Modellinformation in einer XMI-Datei (mit der Erweiterung .xmi und die Information ??ber das Projekt in einer Datei mit der Erweiterung .argo. Mehr ??ber PGML und XMI siehe unter Abschnitt 3.4.3.2.2, „Precision Graphics Markup Language (PGML)“ und Abschnitt 3.4.3.3, „XMI“.

All diese Dateien werden in eine Datei mit der Erweiterung .zargo gepackt. Sie k??nnen die .xmi -Datei aus der .zargo-Datei mit Hilfe einer generischen ZIP-Anwendung extrahieren. Versuchen Sie es und blicken Sie in den Zauber von Argo.

[Warnung]Warnung

Beachten Sie, sofern ein ZIP-Dienstprogramm installiert ist, dass ein Doppelklick das ZIP-Dienstprogramm starten wird und NICHT Argo.

3.4.3.2. Grafiken und Drucken

3.4.3.2.1. Das Graph Editing Framework (GEF)

GEF ist ein Softwarepaket, welches die Grundlage f??r die im Editierfenster erscheinenden Diagramme bildet. GEF war ein integraler Bestandteil von ArgoUML, der jetzt separiert wurde. Wie ArgoUML ist es ein Open-Source-Projekt und via Tigris verf??gbar.

3.4.3.2.2. Precision Graphics Markup Language (PGML)

PGML ist das aktuelle Speicherformat f??r in ArgoUML verwendete Diagramminformationen. In Zukunft wird PGML durch das UML 2.0 Diagramm-Austausch-Format ersetzt.

3.4.3.2.3. Anwendungen, die PGML ??ffnen

PGML ist ein Pr??prozessor von SVG (siehe Abschnitt 3.4.3.2.5, „Scalable Vector Graphics (SVG)“. Er wurde durch das W3C-Konsortium verworfen.

Aktuell kennen wir keine anderen Tools, die mit PGML arbeiten.

3.4.3.2.4. Diagramme drucken

Markieren Sie ein Diagramm und gehen Sie dann in Datei=>Grafik exportieren... . Sie k??nnen GIF-, PostScript-, Encapsulated PostScript- oder SVG-Format generieren.

3.4.3.2.5. Scalable Vector Graphics (SVG)

Ein weltweites Web-Konsortium (W3C) Standard-Vektor-Grafik- Format ( http://www.w3.org/TR/SVG/).

In modernen Browsern ist die Unterst??tzung des Formates eingebaut, f??r ??ltere Browser k??nnen Sie aber auch ein Plugin von adobe.com erhalten.

3.4.3.2.6. Diagramme als SVG speichern
  1. W??hlen Sie .svg als Dateityp aus.

  2. Geben Sie den gew??nschten Namen der Datei mit der .svg-Erweiterung am Ende ein. Beispiel: meinumldiagramm.svg

Et viola! SVG! Probieren Sie es aus und erforschen Sie es etwas... Sie sind nicht sch??n genug? Wenn Sie etwas ??ber das Rendern sch??ner SVG-Formate wissen, lassen Sie es uns wissen.

Die meisten modernen Browser unterst??tzen SVG. Wenn Ihrer das nicht tut, versuchen Sie es unter Firefox oder holen Sie sich ein Plugin f??r Ihren aktuellen Browser von adobe.com

[Anmerkung]Anmerkung

Sie wollen keine Scrollleisten f??r Ihre SVG haben, es sei denn Sie sind in HTML eingebettet. Viel Gl??ck und lassen Sie es uns wissen, was Sie finden!

3.4.3.3. XMI

ArgoUML unterst??tzt XMI 1.0, 1.1 und 1.2 Dateien, die UML 1.3 und UML 1.4-Modelle enthalten. Um die beste Kompatibilit??t zu erhalten, exportieren Sie Ihre Modelle in UML 1.4 und XMI 1.1 oder 1.2. Stellen Sie sicher, dass all propriet??ren Erweiterungen abgeschaltet sind (wie z.B. Poseidon's Diagrammdaten).

Mit UML-Versionen vor UML 2.0 ist es nicht m??glich Diagramm- Informationen zu speichern, sodass keine Diagramme transferriert werden.

Es gibt auch ein Werkzeug, das XMI nach HTML konvertiert. F??r mehr Informationen , siehe http://www.objectsbydesign.com/projects/xmi_to_html_2.html.

3.4.3.3.1. XMI von Rational Rose benutzen

...

3.4.3.3.2. Von Poseidon erzeugte Modelle benutzen

Im Exportiere als XMI..., aber stellen Sie sicher, das Speichere mit Diagrammdaten nicht markiert ist.

3.4.3.3.3. Von MagicDraw erzeugte Modelle benutzen

...

3.4.3.3.4. XMI Kompatibilit??t mit anderen ArgoUML-Versionen

ArgoUML-Versionen vor 0.19.7 unterst??tzen UML 1.3/XMI 1.0. Danach ist das Speicherformat UML 1.4/XMI 1.2, das nicht r??ckw??rtskompatibel ist. Neuere Versionen von ArgoUML werden Projekte ??lterer Versionen lesen, aber nicht umgekehrt. Wenn Sie glauben, zu einer ??lteren Version von ArgoUML zur??ckkehren zu m??ssen, sollten Sie vorsichtig sein und ein Backup Ihres alten Projektes abspeichern.

Wenn Sie zus??tzlich XMI-Dateien speichern, die durch andere Werkzeuge gelesen werden sollen, sollten Sie die unterschiedlichen Versionen unterscheiden. Die meisten modernen UML-Modellierungs-Werkzeuge sollten UML 1.4 lesen, aber Sie haben vielleicht In-Haus-Codegeneratoren oder andere Werkzeuge, die UML 1.3 ben??tigen.

3.4.3.3.5. Andere XMI-Formate in ArgoUML importieren

Die XMI-Kompatibilit??t zwischen den UML-Modellierungs-Werkzeugen wurde ??ber die Jahre verbessert, aber Sie werden wahrscheinlich Probleme bekommen.

ArgoUML wird keine XMI-Dateien lesen, die UML 1.5 oder UML 2.0- Modelle enthalten, aber es sollte m??glich sein, die meisten UML 1.4 und UML 1.3-Modelle zu ??ffnen. Wenn Sie eines finden, dass Sie nicht ??ffnen k??nnen, erstellen Sie bitte einen Bug- Bericht, so dass ein Entwickler dies erforschen kann.

3.4.3.3.6. XMI Format generieren

W??hlen Sie das Kommando Datei=> Exportiere als XMI... und w??hlen Sie einen Dateinamen.

3.4.3.4. Code-Generierung

3.4.3.4.1. Durch ArgoUML generierter Code

Es ist m??glich Ihren generierten Code mit ArgoUML zu ??bersetzen, Sie m??ssen lediglich die Methodenr??mpfe implementieren, um verwendbare Ergebnisse zu erzielen.

3.4.3.4.2. Code f??r Methoden generieren

Im Moment k??nnen Sie keinen Code f??r Methoden (Operationen) in ArgoUML schreiben. Das Quellcode-Fenster ist editierbar, aber die ??nderungen werden ignoriert. ArgoUML ist aktuell ein reines Design-Werkzeug, es ist keine IDE-Funktionalit??t vorhanden, aber der Wunsch ist da. Sie k??nnen Forte und ArgoUML zusammenarbeiten lassen; dies ist ein guter Workaround.

Sie k??nnen uns hier heraushelfen, wenn Sie wollen!

3.4.4. Mit Design-Kritiken arbeiten

Designkritiken sind Teil der praktischen Anwendung der Theorie der Kognitiven Psychologie, die in ArgoUML implementiert ist. Siehe Abschnitt 3.3.1, „Kognitive Psychologie“

3.4.4.1. Nachrichten von den Designkritiken

Wo stehen wir aktuell? Ein neues Projekt wurde erstellt und wurde in der Datei ErstesProjekt.zargo gespeichert. Abbildung 3.9, „ ArgoUML-Fenster mit gespeichertem Projekt ErstesProjekt.zargo zeigt, wie Ihr ArgoUML-Fenster zu diesem Zeitpunkt aussehen sollte.

Abbildung 3.9. ArgoUML-Fenster mit gespeichertem Projekt ErstesProjekt.zargo

ArgoUML-Fenster mit gespeichertem Projekt ErstesProjekt.zargo


Das Projekt enth??lt ein Paket auf oberster Ebene, genannt unbenanntesModell, welches ein Klassendiagramm und ein Anwendungsfalldiagramm enth??lt.

Wenn wir auf den Bildschirm blicken, sehen wir, dass das Verzeichnis „Mittel“ im "zu bearbeiten"-Fenster (das linke untere Fenster) einige Elemente enthalten muss, da sein Aktivierungs-Symbol angezeigt wird.

Klicken auf dieses Symbol ??ffnet das Verzeichnis „Mittel “. Ein ge??ffnetes Verzeichnis wird durch das Symbol dargestellt.

Aber, was ist dieses „zu bearbeiten“-Fenster ??berhaupt? Sie haben bis jetzt noch nichts aufgezeichnet, was zu tun w??re. Wo kommen diese "zu bearbeiten"-Elemente jetzt her?

Die Antwort ist simpel und ist gleichzeitig eines der wichtigsten Punkte von ArgoUML. W??hrend Sie mit Ihrem UML-Modell arbeiten, wird Ihre Arbeit kontinuierlich durch ein St??ck Code, Design-Kritik genannt, gemonitort. Das ist ??hnlich einem pers??nlichen Mentor, der Ihnen ??ber die Schulter sieht und Sie jedesmal darauf hinweist, wenn er irgendetwas fragw??rdiges in Ihrem Design sieht.

Kritiken sind etwas v??llig unaufdringliches. Sie geben Ihnen eine freundliche Warnung, aber Sie zwingen Sie nicht in Design- Prinzipien, denen Sie nicht folgen wollen. Lassen Sie uns einen Blick darauf werfen, was die Kritiken uns mitteilen. Klicken Sie auf das Symbol in der N??he des Verzeichnisses Mittel und klicken Sie auf das Element ??berpr??fen Sie den Paketnamen unbenanntesModell.

Abbildung 3.10, „ ArgoUML-Fenster zeigt das Kritik-Element ??berpr??fen Sie den Paketnamen unbenanntesModell zeigt, wie Ihr Bildschirm nun aussieht.

Abbildung 3.10. ArgoUML-Fenster zeigt das Kritik-Element ??berpr??fen Sie den Paketnamen unbenanntesModell

ArgoUML-Fenster zeigt das Kritik-Element ??berpr??fen Sie den Paketnamen unbenanntesModell


Beachten Sie, dass Ihre Markierung im "zu bearbeiten"-Fenster in rot markiert ist und dass jetzt eine vollst??ndige Erl??uterung im Detail-Fenster (das untere rechte Fenster) erscheint. Sie m??ssen vielleicht Ihr Detail-Fenster in der Gr??sse anpassen oder herunterscrollen, um die angezeigten Nachricht in Ihrem Beispiel vollst??ndig sehen zu k??nnen.

Was Ihnen ArgoUML wahrscheinlich mitteilen will, Paketnamen werden in Kleinbuchstaben geschrieben. Das oberste, von ArgoUML erzeugte Standard-Paket wird unbenanntesModell genannt und verletzt daher ein Designprinzip. (Aktuell kann dies als Bug von ArgoUML betrachtet werden, aber es kommt gerade gelegen, um die arbeitsweise von Kritiken zu demonstrieren).

An diesem Punkt k??nnen Sie w??hlen, ob Sie den Paketnamen manuell ??ndern oder durch die Design-Kritik stillschweigend dieses eine Mal oder immer ??ndern wollen.

Wir werden nichts davon tun (wir kommen darauf zur??ck, wenn wir ??ber die Design-Kritiken detaillierter sprechen), aber wir werden eine andere einfache Funktion von ArgoUML nutzen— die Autokorrektur-Funktion.

Um dies zu tun, klicken Sie auf die Schaltfl??che Weiter im Detailfenster. Dadurch wird ein Umbenennungs- Assistent innerhalb des Eigenschaftsfensters angezeigt, der vorschl??gt, den Namen unbenanntesmodell (alles in Kleinbuchstaben) zu verwenden.

3.4.4.2. Design-Kritiken bei der Arbeit: Der Paket-Umbenennungs- Assistent

Ersetzen Sie den Namen unbenanntesmodell durch einkaufsmodell und klicken Sie auf die Schaltfl??che Fertig stellen. Abbildung 3.11, „ Das ArgoUML-Fenster zeigt den Kritik-Assistenten, zur Umbenennung des Paketes “ zeigt, wie das ArgoUML- Fenster nun aussehen sollte.

Abbildung 3.11. Das ArgoUML-Fenster zeigt den Kritik-Assistenten, zur Umbenennung des Paketes

Das ArgoUML-Fenster zeigt den Kritik-Assistenten, zur Umbenennung des Paketes


Beobachten Sie nun, wie die Design-Kritik im "zu bearbeiten"- Fenster verschwindet und es verbleibt nur der Hinweis F??gen Sie dem Paket einkaufsmodell Elemente hinzu in der "zu bearbeiten"-Liste.

Wenn dies nicht sofort passiert, warten Sie einige Sekunden. ArgoUML macht ausgiebigen Gebrauch von mehreren, parallel ausgef??hrten Ausf??hrungsthreads. Dies kann einige Sekunden Verz??gerung verursachen bevor die Information auf dem Bildschirm auf den neusten Stand gebracht wird.

Die ??nderung des Paketnamens sollte sich auch im Explorer, in der linken oberen Ecke Ihres ArgoUML-Fensters, wiederspiegeln.

Wir sind jetzt so weit, unser erstes UML-Diagramm, ein Anwendungsfalldiagramm, zu erstellen. Aber lassen Sie uns zuerst speichern, was wir bis jetzt getan haben.

Klicken Sie auf das Men??element Datei und w??hlen Sie Projekt speichern... aus. Sie k??nnen jetzt ArgoUML sicher beenden, ohne Ihre bisherige Arbeit zu verlieren, oder mit dem Erstellen Ihres ersten Diagrammes fortfahren.

3.5. Die Fallstudie (Noch zu schreiben)

Hier wollen wir mit der Fallstudie beginnen. Es ist der Zeitpunkt, wo Sie Ihr Projekt definieren; nicht Ihr Produkt, aber Ihr Projekt. Es kann argumentiert werden, dass die Modellierungskonzepte hier auch erscheinen sollten, aber das wurde so nicht aufgebaut. Wenn Sie sich die Zeit nehmen, sich das ArgoUML-Projekt anzusehen, werden Sie eine grosse Anzahl von "Code-" und Dokumentationszeilen, die Teil des Projektes sind, finden. Sie sind aber nicht Teil des Produktes. Beispiel: Dieses Dokument ist Teil des Produktes w??hrend das Kochbuch und die build.xml-Dateien nur Teil des Projektes sind. Mindestens die Dateistruktur des Projektes k??nnte in einem Paketdiagramm dargestellt werden.

...

Kapitel 4. Erfassen der Anforderungen

4.1. Einleitung

Das Erfassen der Anforderungen ist der Identifizierungsprozess, was der „Kunde“ von dem vorgeschlagenen System will.

Der Schl??ssel zu diesem Zeitpunkt ist, dass wir uns im Problembereich befinden. Zu diesem Zeitpunkt m??ssen wir alles aus der Perspektive des „Kunden“ und in der Sprache des „Kunden“ beschreiben.

Das gr??sste Risiko, dass wir beim Erfassen der Anforderungen haben ist, dass wir in Begriffen der m??glichen L??sung anfangen zu denken. Dies muss bis zur Analyse-Phase warten (siehe Kapitel 5, Analyse). Einer der Schritte der Analyse- Phase nimmt das Ergebnis der Anforderungsphase und ??bersetzt es in die Sprache einer gedachten L??sung.

Erinnern Sie sich, dass wir beides einsetzen, einen inkrementalen und einen iterativen Prozess.

Wir kommen im Anforderungsprozess darauf zur??ck, wenn wir das Problem in kleinere Teile unterteilen. F??r jedes davon m??ssen seine Anforderungen erfasst sein.

Wir werden wahrscheinlich w??hrend der Anforderungsphase bei jeder Iteration darauf zur??ckkommen, wenn wir versuchen, die Anforderungen des Systems immer weiter zu definieren.

[Anmerkung]Anmerkung

Der einzige Teil der vom UML-Standard spezifizierten Anforderungsnotation ist das Anwendungsfalldiagramm. Der Rest ist prozessspezifisch. Der in diesem Kapitel beschriebene Prozess ist sehr stark an den Rational Unified Prozess angelehnt.

4.2. Der Anforderungs-Erfassungs-Prozess

Wir beginnen mit einer Top-Level-Sicht auf das von uns zu l??sende Problem und die Schl??sselbereiche der Funktionalit??t, die wir f??r die L??sung adressieren m??ssen. Dies ist unser Visions- Dokument und es sollte nur einige Seiten lang sein.

Die Top-Level-Sicht eines Geldautomaten (automated teller machine (ATM)) zum Beispiel, sollte folgendes unterst??tzen.

  1. Bargeld lagern, Bargeld abheben und Kontoabfragen durch Kunden.

  2. Warten des Equipments durch Bank-Ingenieure und leeren der Kassen und Bargeld nachf??llen durch die lokale Bankfiliale.

  3. Nachvollziehbarkeit aller an den zentralen Bankcomputer gesendeten Aktivit??ten.

Aus dieser Top-Level-Sicht k??nnen wir die prinzipiellen Aktivit??ten des Systems und die extern Handelnden (Menschen, Equipment) die in diese Aktivit??ten eingebunden sind extrahieren. Diese Aktivit??ten sind als Anwendungsf??lle und die extern Handelnden als Akteure bekannt.

Akteure k??nnen Menschen oder Maschinen sein. Vom praktischen Standpunkt aus gesehen besteht deren Wert darin, die Nutzer hinter einer Maschine zu kennen, da nur diese in der Lage sind, sich mit dem Anforderungs-Erfassungs-Prozess zu besch??ftigen.

Anwendungsf??lle sollte signifikante Aktivit??ten f??r das System sein. Der Nutzung des Geldautomaten durch den Kunden ist zum Beispiel ein Anwendungsfall. Die Eingabe einer PIN-Nummer ist es nicht.

Es gibt eine Grauzone zwischen diesen beiden Extremen. Wie wir sehen werden, ist es oft n??tzlich, sehr grosse Anwendungsf??lle in kleinere Sub-Anwendungsf??lle zu unterteilen. Wir k??nnen zum Beispiel Bargeld lagern, Bargeld auszahlen und Kontoabfragen als Sub- Anwendungsf??lle definieren.

Es gibt keine harte und schnelle Regel. Einige Architekten pr??ferieren wenige relativ grosse Anwendungsf??lle, andere pr??ferieren eine gr??ssere Anzahl kleinerer Anwendungsf??lle. Eine n??tzliche Faustregel ist, dass jedes praktikable Projekt nicht mehr als 30 Anwendungsf??lle erfordern sollte (wenn es mehr ben??tigt, sollte es in separate Projekte aufgeteilt werden).

Wir stellen dann die Beziehungen zwischen den Anwendungsf??llen und Akteuren in einem oder mehreren Anwendungsfalldiagrammen dar. In gr??sseren Projekten wird mehr als ein Diagramm ben??tigt. Normalerweise werden Gruppen zusammengeh??riger Anwendungsf??lle in einem Diagramm dargestellt.

Wir m??ssen dann eine detailliertere Spezifikation f??r jeden Anwendungsfall erstellen. Dies beinhaltet sein normales Verhalten, alternatives Verhalten und alle Vor- und Nachbedingungen. Dies erfolgt in einem Dokument, dass h??ufig als Anwendungsfalldokumentation oder Anwendungsfallszenario bekannt ist.

Da Anwendungsf??lle nat??rlicherweise funktional sind, ben??tigen wir ein Dokument, um die nicht-funktionalen Anforderungen (Kapazit??ts-, Leistungs-, Umgebungsanforderungen usw.) aufzunehmen. Diese Anforderungen werden in einem Dokument Erg??nzende Anforderungsspezifikation festgehalten.

4.2.1. Prozess-Schritte

Die Schritte im Anforderungs-Erfassungs-Prozess k??nnen wie folgt zusammengefasst werden.

  1. Das Visions-Dokument beinhaltet eine Gesamtsicht auf das Problem und die gew??nschten Charakteristika seiner L??sung.

  2. Identifizieren Sie die Anwendungsf??lle und Akteure aus dem Visions-Dokument und stellen deren Beziehungen zueinander in einem oder mehreren Anwendungsfalldiagrammen dar.

  3. Erstellen Sie f??r jeden Anwendungsfall eine detaillierte Anwendungsfall-Spezifikation, die das normale und alternative Verhalten, die Vor- und Nachbedingungen beinhaltet.

  4. Fassen Sie alle nicht-funktionalen Anforderungen in einer Erg??nzenden Anforderungs-Spezifikation zusammen.

In jedem iterativen Entwicklungsprozess werden wir priorisieren und fr??he Iterationen werden sich darauf fokussieren, das haupts??chliche Verhalten der wichtigsten Anwendungsf??lle aufzunehmen.

Die meisten modernen Anforderungs-Erfassungs-Prozesse unterstellen, dass es wichtig ist, dass der ma??gebliche Repr??sentant des Kunden w??hrend dieses Prozesses vollst??ndig involviert ist.

4.3. Ergebnis des Anforderungs-Erfassungs-Prozesses

Fast alle Ergebnisse des Anforderungs-Erfassungs-Prozesses sind dokumentarisch. Das einzige Diagramm ist das Anwendungsfalldiagramm, das die Beziehungen zwischen den Anwendungsf??llen und den Akteuren darstellt.

4.3.1. Visions-Dokument

Typische Kapitel dieses Dokumentes k??nnten die folgenden sein.

  • Zusammenfassung. Eine Aussage zum Umfeld, zum Problem und zu den Zielen der L??sung.

  • Ziele. Was wir erreichen wollen (und wie wir es erreichen wollen).

  • Marktumfeld oder vertragliche Vereinbarungen. Bei einer Entwicklung zur Marktf??hrerschaft, sollte es die Zielm??rkte, die Alleinstellungsmerkmale, die zwingenden Ereignisse und so weiter aufzeigen. Bei einer vertraglich vereinbarten Entwicklung sollte es die Hauptelemente der vertraglichen Vereinbarung erl??utern.

  • Nutzer. Die Nutzer (im weitesten Sinne) des Systems. Viele davon werden als Akteure, oder Steuer-Equipment das in Akteure umgewandelt wird, abgebildet.

  • Haupteigenschaften. Auf einer sehr hohen Abstraktionsebene: Was sind die haupts??chlichen Aspekte des Problems/der gew??nschten L??sung. Es ist hilfreich, hier bereits zu priorisieren.

  • Randbedingungen. Eine Sicht auf die nicht-funktionalen Parameter des Systems auf einer sehr hohen Abstraktionsebene. Diese werden in der erg??nzenden Anforderungsspezifikation detailliert ausgearbeitet.

  • Anhang. Eine Liste der Akteure und Anwendungsf??lle die zur Erf??llung der Vision notwendig sind. Es ist hilfreich, diese mit den vorher beschriebenen Abschnitten zu verlinken um eine in sich geschlossene Darstellung sicherzustellen.

4.3.2. Anwendungsfalldiagramm

Das Visions-Dokument identifizierte die Anwendungsf??lle und Akteure. Das Anwendungsfalldiagramm stellt dar, wie sie interagieren. In unserem ATM (Geldautomat) Beispiel haben wir „Kunde nutzt den Automaten“, „Wartung des Automaten“ und „Revision“ als die drei Hauptanwendungsf??lle identifiziert. Als Akteure haben wir „Kunde“, „Wartungsingenieur“, „lokaler Zweigstellenbeamter “ und „Zentralcomputer“ identifiziert.

Abbildung 4.1, „ Grundlegendes Anwendungsfalldiagramm f??r einen Geldautomaten “ zeigt, wie das in einem Anwendungsfalldiagramm dargestellt werden kann. Die Anwendungsf??lle werden als Ovale dargestellt, die Akteure als Strichm??nnchen (auch wenn es Maschinen sind), mit Linien (als Assoziationen bekannt), die die Anwendungsf??lle mit den damit involvierten Akteuren verbinden. Ein Rahmen um die Anwendungsf??lle stellt die Abgrenzung zwischen dem System (durch die Anwendungsf??lle definiert) und den Akteuren dar, die extern sind.

[Anmerkung]Anmerkung

Nicht alle Analytiker m??chten einen Rahmen um die Anwendungsf??lle verwenden. Dies ist ein Fall pers??nlicher Vorlieben.

Abbildung 4.1. Grundlegendes Anwendungsfalldiagramm f??r einen Geldautomaten

Grundlegendes Anwendungsfalldiagramm f??r einen Geldautomaten


Die folgenden Abschnitte zeigen, wie das grundlegene Anwendungsfalldiagramm erweitert werden kann, um zus??tzliche Informationen ??ber das zu designende System darzustellen.

4.3.2.1. Aktive und passive Akteure

Aktive Akteure initiieren eine Interaktion mit dem System. Dies kann durch einen Pfeil in der Assoziation vom Akteur zum Anwendungsfall dargestellt werden. Im Geldautomaten-Beispiel ist der Kunde ein aktiver Akteur.

Die Interaktion mit passiven Akteuren wird durch das System initiiert. Dies kann durch einen Pfeil in der Assoziation vom Anwendungsfall zum Akteur dargestellt werden. Im Geldautomaten-Beispiel ist der Zentralcomputer ein passiver Akteur.

Dies ist ein gutes Beispiel, wo die Pfeile helfen, da es uns erlaubt, ein ereignisgetriebenes System (der Geldautomat initiiert die Interaktion mit dem Zentralcomputer) von einem zyklisch abfragenden System (der Zentralcomputer fragt den Geldautomaten von Zeit zu Zeit ab) zu unterscheiden.

Dort wo ein Akteur entweder aktiv oder passiv sein kann, je nach den Umst??nden, kann der Pfeil weggelassen werden. Im Geldautomaten-Beispiel f??llt der Bankingenieur in diese Kategorie. Normalerweise ist er aktiv, indem er regelm??ssig auftaucht um die Maschine zu warten. Wenn jedoch der Geldautomat einen Fehler entdeckt, kann er den Ingenieur auffordern diesen zu beheben.

Die Verwendung von Pfeilen bei Assoziationen wird als Navigation der Assoziation bezeichnet. Wir sollten dies sp??ter in der UML im Einsatz sehen. Die Wahl der OMG eine bidirektionale Assoziation durch keine anstelle von zwei Pfeilspitzen darzustellen ist unvorteilhaft. Mit dieser Konvention k??nnen Sie nicht zwischen einer Assoziation unterscheiden, deren Navigation noch zu bestimmen ist und einer die bidirektional ist.

Abbildung 4.2, „ Anwendungsfalldiagramm f??r einen Geldautomaten mit Navigation. “ zeigt das Geldautomaten-Anwendungsfalldiagramm mit dargestellter Navigation.

Abbildung 4.2. Anwendungsfalldiagramm f??r einen Geldautomaten mit Navigation.

Anwendungsfalldiagramm f??r einen Geldautomaten mit Navigation.


4.3.2.2. Multiplizit??t

Es kann sehr n??tzlich sein, die Multiplizit??t von Assoziationen zwischen Akteuren und Anwendungsf??llen darzustellen. Damit meinen wir, wie viele Auspr??gungen eines Akteurs mit wie vielen Auspr??gungen eines Anwendungsfalles interagieren.

Standardm????ig nehmen wir an, dass eine Auspr??gung eines Akteurs mit einer Auspr??gung eines Anwendungsfalles interagiert. In den anderen F??llen k??nnen wird die Multiplizit??t an einem Ende der Assoziation kennzeichnen. Entweder mit einer Nummer, um darzustellen, wie viele Auspr??gungen involviert sind, oder mit einem durch zwei Punkten separierten Bereich (.. ). Ein Stern (*) wird verwendet, um eine beliebige Zahl darzustellen.

Im Geldautomaten-Beispiel gibt es nur einen Zentralcomputer, aber es k??nnen beliebig viele Nutzungen des Geldautomaten aufgezeichnet werden. Daher plazieren wir das Kennzeichen 0..* am Ende des Anwendungsfalles. Es gibt keine Notwendigkeit f??r eine Kennzeichnung am anderen Ende, da der Standard 1 ist.

Eine lokale Bank kann bis zu drei Beamte haben, die autorisiert sind, die Geldautomaten zu leeren und zu bef??llen. Daher plazieren wir bei der Beziehung zwischen dem Akteur und dem Anwendungsfall Wartung Geldautomat am Ende zum Akteur die Kennzeichnung 1..3. Sie k??nnen sich mit beliebig vielen Geldautomaten befassen, so dass wir auf dem anderen Ende das Kennzeichen 0..* plazieren.

Es gibt beliebig viele Kunden und beliebig viele Geldautomaten die diese nutzen d??rfen. Daher plazieren wir an jedem Ende der Assoziation das Kennzeichen 0..*.

Abbildung 4.3, „ Anwendungsfalldiagramm f??r einen Geldautomaten und dargestellter Multiplizit??t. “ zeigt das Geldautomaten-Anwendungsfalldiagramm mit dargestellter Multiplizit??t.

Abbildung 4.3. Anwendungsfalldiagramm f??r einen Geldautomaten und dargestellter Multiplizit??t.

Anwendungsfalldiagramm f??r einen Geldautomaten und dargestellter Multiplizit??t.


Die Multiplizit??t kann ein Diagramm ??berladen und wird oft nicht angezeigt, ausser wo es f??r das Verst??ndnis kritisch ist. Im Beispiel Geldautomat w??rde wir nur 1..3 zum lokalen Bankbeamten darstellen, da alle anderen aus dem Kontext heraus offensichtlich sind.

4.3.2.3. Hierarchien von Anwendungsf??llen

In unserem Geldautomatenbeispiel haben wir jetzt drei Anwendungsf??lle, um das Verhalten des Systems zu beschreiben. Auch wenn Anwendungsf??lle immer einen signifikanten Teil des Systemverhaltens beschreiben sollten, wenn diese zu generell sind, k??nnen sie schwer zu beschreiben sein.

Wir k??nnten zum Beispiel das Verhalten des Anwendungsfalles „Geldautomat nutzen“ durch das Verhalten von drei einfacheren Anwendungsf??llen, wie „Bargeld lagern“, „Bargeld ausgeben“ und „Konto abfragen“ ausdr??cken. Der Hauptanwendungsfall k??nnte durch einbinden (include) des Verhaltens der ben??tigten Unteranwendungsf??lle spezifiziert werden.

Der Anwendungsfall „Geldautomat warten“ k??nnte ebenfalls durch zwei Anwendungsf??lle „Equipment warten “ und „Geldautomat neu starten“ definiert werden. In diesem Fall sind die zwei im Hauptanwendungsfall involvierten Akteure nat??rlich nur in einem oder dem anderen der beiden Unteranwendungsf??lle involviert. Dies wird im nachfolgenden Diagramm dargestellt.

Die Aufteilung eines Anwendungsfalles in einfacherere Unteranwendungsf??lle wird in UML durch eine include Beziehung, einem gestrichelten Pfeil vom Hauptanwendungsfall zum Unteranwendungsfall mit der Kennzeichnung «include» bezeichnet.

Abbildung 4.4. Anwendungsfalldiagramm f??r einen Geldautomaten mit include-Beziehungen.

Anwendungsfalldiagramm f??r einen Geldautomaten mit include-Beziehungen.


Include-Beziehungen sind ideal f??r das Herunterbrechen des Anwendungsfallverhaltens in Hierarchien. Wir wollen jedoch auch einen Anwendungsfall, der eine Erweiterung (extension) eines existierenden Anwendungsfalles darstellt, in bestimmten Umst??nden darstellen.

Im Geldautomatenbeispiel haben wir einen Anwendungsfall „ Equipment warten“, der die Routinewartung des Geldautomaten beinhaltet. Wir wollen aber auch den Spezialfall einer ungeplanten Reparatur abdecken, die durch den vom Geldautomaten erkannten internen Fehlers ausgel??st wurde.

Dies wird in UML durch die extend-Beziehung dargestellt. Im Hauptanwendungsfall spezifizieren wir einen Namen f??r einen Ort in der Beschreibung, an den die Erweiterung des Verhaltens hinzugef??gt werden kann. Der Name und der Ort werden in einem separaten Abschnitt innerhalb des Anwendungsfall- Ovales dargestellt. Die Darstellung der extend-Beziehung entspricht der include-Beziehung, aber mit dem Kennzeichen «extend». An der extend- Beziehung spezifizieren wird die Bedingung, unter der das Verhalten hinzugef??gt wird.

Abbildung 4.5, „ Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung. “ zeigt das Geldautomaten-Anwendungsfalldiagramm mit einer extend- Beziehung auf einen Anwendungsfall f??r ungeplante Reparaturen. Das Diagramm ist jetzt sehr komplex so dass wir es in zwei aufteilen sollten. Eines f??r die haupts??chlichen Dinge, das andere f??r den Kundennutzen und Revision.

Der Anwendungsfall „Equipment warten“ definiert den Namen „Unshed“ am Anfang seiner Beschreibung. Der erweiterte Anwendungsfall „ungeplante Reparatur“ wird herangezogen, wenn der Geldautomat einen internen Fehler entdeckt.

Abbildung 4.5. Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung.

Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung.


Anwendungsf??lle k??nnen auch auf andere Art und Weise miteinander verkn??pft sein. Ein Anwendungsfall kann eine Generalisierung eines Sub-Anwendungsfalles (oder alternativ: Der Sub-Anwendungsfall ist eine Spezialisierung des Hauptanwendungsfalles). Das ist der extend-Beziehung sehr ??hnlich, aber ohne die Bedingung des spezifischen Erweiterungspunktes, unter welcher der Haupt-Anwendungsfall erweitert wird und ohne Bedingung unter welcher der Sub-Anwendungsfall verwendet wird.

Der Generalisierung wird in einem Anwendungsfalldiagramm durch einen Pfeil mit durchgehender Linie und einer weissen Pfeilspitze vom Sub-Anwendungsfall zum Hauptanwendungsfall dargestellt. Das kann hilfreich sein, wenn ein Sub-Anwendungsfall das Verhalten des Hauptanwendungsfalles in einer Vielzahl von Positionen und in einem weiten Bereich von Sachverhalten spezialisiert. Das Fehlen jeglicher Einschr??nkungen macht es sehr schwierig, die Generalisierung genau zu beschreiben. Im Normalfall verwenden Sie besser eine extend-Beziehung.

4.3.3. Die Anwendungsfall-Spezifikation

Jeder Anwendungsfall muss dokumentiert sein, um das das spezifizierte Verhalten im Detail zu erl??utern. ArgoUML unterst??tzt Sie in diesem Bereich durch das Generieren graphischer Dateien, die in diese Dokumentation eingebunden werden kann. Dieses Dokument ist unter verschieden Namen in verschiedenen Prozessen bekannt: Anwendungsfall-Spezifikation, Anwendungsfall-Szenario oder auch (verwirrend) nur Anwendungsfall.

Eine typische Anwendungsfall-Spezifikation wird folgende Kapitel enthalten.

  • Name. Der Name des Anwendungsfalles.

  • Ziel. Eine ein oder zweizeilige Zusammenfassung dar??ber, was dieser Anwendungsfall f??r seine Akteure ausf??hrt.

  • Akteure. Die in diesen Anwendungsfall involvierten Akteure und jeden Umstand bez??glich Ihrer Einbindung.

    [Anmerkung]Anmerkung

    Dies sollte keine Beschreibung des Akteurs sein. Die sollte mit dem Akteur im Anwendungsfalldiagramm verkn??pft sein.

  • Vorbedingung. Diese w??rden besser als „Voraussetzungen“ bezeichnet, aber der ??berall verwendete Begriff ist Vorbedingungen. Dies ist eine Beschreibung jeder vereinfachenden Voraussetzung, die wir zum Start des Anwendungsfalles machen k??nnen.

    Im Geldautomatenbeispiel k??nnten wir beim Anwendungsfall „Equipment warten“ die Voraussetzung haben, das immer ein Ingenieur verf??gbar ist und wir uns nicht vor dem Fall f??rchten m??ssen, in dem ein Routinewartungs-Besuch ausgelassen wurde.

    [Achtung]Achtung

    Vermeiden Sie Vorbedingungen wo immer das m??glich ist. Sie m??ssen sich absolut sicher sein, dass die Vorbedingung unter allen m??glichen Umst??nden eingehalten wird. Wenn nicht, ist ihr System zu wenig spezifiziert und wird daher fehlschlagen, wenn die Vorbedingung nicht wahr ist. Wenn Sie nicht sicher sein k??nnen, dass die Vorbedingung immer wahr ist, m??ssen Sie einen zweiten Anwendungsfall spezifizieren, der den Fall handhabt, wenn die Vorbedingung falsch ist. Im ersten Fall sind die Vorbedingungen die Ursache der Probleme, im zweiten Fall die Ursache f??r mehr Arbeit.

  • Standardablauf. Die aufeinander folgenden Schritte, die das Verhalten des Anwendungsfalles im „Normalfall“ beschreiben. Wo ein Anwendungsfall mehrere normale Szenarien aufweist, wird einer davon willk??rlich ausgew??hlt. Die Spezifizierung des Standardablaufes wird nachfolgend detaillierter beschrieben Abschnitt 4.3.3.1, „Den Standardablauf spezifizieren“.

  • Alternative Abl??ufe. Eine Reihe von linearen Sequenzen beschreiben jede der alternativen, gegen??ber dem Standardablauf abweichenden Verhaltensweisen. Die Spezifizierung alternativer Abl??ufe ist detaillierter in Abschnitt 4.3.3.2, „Alternative Abl??ufe spezifizieren“ beschrieben.

  • Nachbedingungen. Dies ist der Zustand jeder Nachbedingung, den wir am Ende des Anwendungsfalles feststellen k??nnen. Sehr hilfreich, wo der Anwendungsfall einer von einer Serie von in den Hauptanwendungsfall eingebundenen Unteranwendungsf??llen ist, wo sie die Vorbedingung f??r den n??chsten einzubindenden Anwendungsfall bilden.

    [Achtung]Achtung

    Nachbedingungen sind wie Vorbedingungen am Besten zu vermeiden. Sie bilden eine Belastung f??r die Spezifikation des Anwendungsfallablaufes, das sichergestellt sein muss, dass die Nachbedingung immer eingehalten wird. Daher sind sie auch eine Ursache von Problemen und zus??tzlicher Arbeit.

  • Anforderungen. In einer idealen Welt w??rden das Visionsdokument, die Anwendungsfalldiagramme, die Anwendungsfallbeschreibungen und die Spezifikation der zus??tzlichen Anforderungen die Anforderungen f??r ein Projekt bilden.

    Bei den meisten Marktf??hrer-Entwicklungen, ist es gew??hnlich der Fall, dass sich die Eigentumsrechte der Anforderungen im gleichen Business befinden, wie das Team, das die Entwicklung durchf??hren wird. Die Marketingabteilung kann das Erfassen und die Analyse der Anwendungsfallanforderungen erlernen, um ihre kundenspezifischen Aktivit??ten damit zu verbinden.

    Bei externen Vertragsentwicklungen jedoch, kann der Kunde auf einer traditionellen „Liste von Features“ als Basis des Vertrages bestehen. Wo dies der Fall ist, sollte dieser Abschnitt der Anwendungsfallspezifikation mit den vertraglich festgelegten Features ??bereinstimmen, die durch den Anwendungsfall abgedeckt werden.

    Das wird oft mit Hilfe eines Third-Party-Werkzeuges ausgef??hrt, das Dokumente verkn??pfen kann und eine automatische Pr??fung des Geltungsbereiches enth??lt. In diesem Fall wird dieser Abschnitt nicht ben??tigt oder kann automatisch generiert werden.

Die abschliessende Gr??sse der Anwendungsfallspezifikation h??ngt von der Komplexit??t der Anwendungsf??lle ab. Als Faustregel gilt, dass die meisten Anwendungsf??lle ca. 10-15 Seiten f??r die Spezifikation ben??tigen, das meiste davon f??r die alternativen Abl??ufe. Wenn sie sehr viel gr??sser sind, sollten Sie die Anwendungsf??lle aufteilen. Wenn sie sehr viel kleiner sind, betrachten Sie, ob der Anwendungsfall einen zu kleinen Bereich des Verhaltens beschreibt.

4.3.3.1. Den Standardablauf spezifizieren

Alle Abl??ufe in einer Anwendungsfallspezifikation sind linear — d.h. es gibt keine bedingte Verzweigung. Jede Auswahl im Ablauf wird durch einen anderen, nach dem Auswahlpunkt kommenden alternativen Ablauf behandelt. Es ist wichtig, sich daran zu erinnern, dass wir hier das Verhalten und nicht die Programmierung spezifizieren.

Ein Ablauf wird durch eine Reihe von numerierten Schritten spezifiziert. Jeder Schritt muss einige Interaktionen mit einem Akteur oder mindestens eine ??nderung generieren, die durch einen Akteur extern ??berwacht wird. Das Anforderungen erfassen sollte nicht das versteckte interne Verhalten eines Systems spezifizieren.

In unserem Geldautomatenbeispiel k??nnten wir im Anwendungsfall „Bargeld ausgeben“ die folgende Sequenz von Schritten im Standardablauf haben:

  1. Der Kunde gibt an, dass eine Quittung erforderlich ist.

  2. Der Kunde gibt die gew??nschte Bargeldmenge ein.

  3. Der Geldautomat ??berpr??ft mit dem Zentralcomputer, dass der Kunde diese Auszahlung durchf??hren kann.

  4. Der Geldautomat gibt das Bargeld an den Kunden.

  5. Der Geldautomat gibt die Quittung an den Kunden aus.

Zur Erinnerung: Dies ist ein Sub-Anwendungsfall der im Haupt- Anwendungsfall „Geldautomat benutzen“ enthalten ist, der voraussichtlich das Pr??fen von Karten und PINs handhaben wird, bevor dieser eingebundene Anwendungsfall aufgerufen wird.

[Anmerkung]Anmerkung

Der erste Schritt ist keine Bedingung. Wir nehmen als unseren Standardablauf den Fall, wo der Kunden eine Quittung haben m??chte. Der Fall, wo der Kunde keine Quittung haben will, wird ein alternativer Ablauf sein.

4.3.3.2. Alternative Abl??ufe spezifizieren

Dies erfasst die alternativen Szenarien, wie lineare Abl??ufe, die durch den Standardablauf referenziert werden. Zu Beginn erzeugen wir eine Liste der alternativen Abl??ufe.

    1. Der Kunde ben??tigt keine Quittung.

    2. Das Kundenkonto unterst??tzt keine Auszahlung.

    3. Die Kommunikation mit dem Zentralcomputer ist unterbrochen.

    4. Der Kunde unterbricht die Transaktion.

    5. Der Kunde macht beim Annehmen des Bargeldes Fehler.

Nachfolgend arbeiten wir jeden alternativen Ablauf als Referenz zum Standardablauf aus. Der erste alternative Ablauf k??nnte zum Beispiel wie folgt aussehen:

    1. Der Kunde ben??tigt keine Quittung.

      1. In Schritt 1 des Standardablaufes sagen die Kunden, dass Sie keine Quittung ben??tigen.

      2. Der Standardablauf geht von Schritt 2 in Schritt 4, Schritt 5 wird nicht ben??tigt.

Die Konvention ist, dass die verschiedenen alternativen Abl??ufe numeriert werden, wie A.1, A.2, A.3, usw. Die Schritte innerhalb eines alternativen Ablaufes werden darauf aufbauend numeriert. So dass die Schritte der ersten Alternative wie folgt lauten w??rden: A.1.1, A.1.2, A.1.3, usw.

4.3.3.3. Iterative Entwicklung der Anwendungsfallspezifikationen

Die Iterative Entwicklung wird die die Anwendungsf??lle priorisieren und die erste Iteration wird die wichtigsten adressieren.

Fr??he Iterationen werden den Standardablauf der wichtigsten Anwendungsf??lle nur mit den grundlegenden Details erfassen und die ??berschriften der haupts??chlichen alternativen Abl??ufe auflisten.

Sp??tere Iterationen werden die verbleibenden Anwendungsf??lle adressieren, die Schritte der individuellen alternativen Abl??ufe ausformulieren und wahrscheinlich mehr Details ??ber die individuellen Schritte enthalten.

4.3.4. Erg??nzende Anforderungsspezifikation

Dies erfasst die nicht-funktionalen Anforderungen oder Randbedingungen, die f??r das System gelten. Da Anwendungsf??lle von Natur aus inh??rent funktional sind, k??nnen sie diese Art von Information nicht aufnehmen.

[Anmerkung]Anmerkung

Einige Analytiker plazieren nicht-funktionale Anforderungen in einem Abschnitt am Ende einer jeden Anwendungsfallspezifikation, der die nicht-funktionalen, anwendungsfallbezogenen Anforderungen enth??lt.

Dies kann einige Probleme verursachen. Der erste Punkt ist, dass nicht-funktionale Anforderungen (zum Beispiel ??ber die Performance) in vielen Anwendungsf??llen erscheinen mu?? und es ist eine schlechte Praxis, Informationen zu replizieren. Zweitens gibt es einige invariable systemweite nicht-funktionale Anforderungen, die ein systemweites Dokument erfordern. Daher meine Pr??ferenz f??r eine einzige erg??nzende Anforderungsdokumentation.

Es sollte ein Abschnitt f??r jeden Hauptbereich der nicht-funktionalen Anforderungen geben. Die Checkliste von Ian Sommerville in seinem Buch Software Engineering (Third Edition, Addison-Wesley, 1989) ist eine hilfreiche Anleitung.

  • Geschwindigkeit. Prozessorleistung, Anwender-/Ereignis-Antwortzeiten, Bildauffrischungszeiten.

  • Gr??sse. Hauptspeicher (und m??gliche Zwischenspeicher), Plattenkapazit??t.

  • Leichte Anwendbarkeit. Ausbildungszeit, Stil und Details des Hilfesystems.

  • Zuverl??ssigkeit. Durchschnittliche Fehlerauftrittszeit, die Nichtverf??gbarkeitswahrscheinlichkeit, die Fehlerrate, die Verf??gbarkeit.

  • Widerstandsf??higkeit. Wiederanlaufzeit nach einem Fehler, Prozentsatz der Ereignisse, die Fehler verursachen, die Wahrscheinlichkeit von Datenverlust bei einem Fehler.

  • Portabilit??t. Prozentsatz von zielabh??ngigem Code/Klassen, Anzahl der Zielsysteme.

Dazu sollten wir Abschnitte ??ber die Umgebung (Temperatur, Feuchtigkeit, Blitzschutz) und ??bereinstimmung mit Standards hinzuf??gen.

4.4. Anwendungsf??lle in ArgoUML verwenden

ArgoUML erlaubt es Ihnen Anwendungsfalldiagramme zu zeichnen. Wenn Sie ein neues Projekt erstellen, ist ein Anwendungsfalldiagramm standardm????ig mit dem Namen Anwendungsfalldiagramm 1 angelegt. W??hlen Sie diesen Diagrammnamen im Explorer durch einen Klick mit der Taste 1 aus (der obere linke Quadrant des ArgoUML-Fensters).

Neue Anwendungsfalldiagramme k??nnen, wenn ben??tigt, ??ber Erzeuge Diagramm in der Men??zeile oder ??ber die Werkzeugleiste erstellt werden. Sie werden im Bearbeitungsfenster (der obere rechte Quadrant des ArgoUML-Fensters) bearbeitet.

4.4.1. Akteure

Um einen Akteur dem Diagramm hinzuzuf??gen, klicken Sie mit der Taste 1 auf das Akteur-Symbol in der Werkzeugleiste des Bearbeitenfensters ( ) und dann klicken Sie mit der Taste 1 an die Stelle, wo Sie ihn plazieren wollen. Der Akteur kann nachtr??glich durch eine Taste 1- Bewegung bewegt werden (z.B. ??ber dem Akteur die Taste 1 herunterdr??cken, um diesen zu markieren, ihn an die neue Position bewegen und die Taste 1 loslassen, um den Akteur an diese Stelle zu bringen).

Mehrere Akteure k??nnen in einem Schritt durch einen Doppelklick mit der Taste 1 auf das Akteursymbol hinzugef??gt werden. Jeder nachtr??gliche Taste 1-Klick wird einen Akteur in das Diagramm bringen. Ein Klick mit der Taste 1 auf das Auswahlsymbol ( ) wird das Hinzuf??gen der Akteure stoppen.

Der Name des Akteurs wird in seinem Eigenschaftsfenster vergeben. Zuerst markieren Sie den Akteur (wenn nicht bereits markiert) im Bearbeitungsfenster mit Hilfe des Taste 1-Klick. Dann klicken Sie auf das Eigenschaften-Register im Detailfenster. Der Name wird im Feld Name eingegeben und wird am Bildschirm erscheinen.

Als eine Abk??rzung, die Ihnen erlaubt, den Namen direkt einzugeben, f??hren Sie mit der Taste 1 einen Doppelklick auf den Namen des Akteurs im Bearbeitenfenster aus (oder geben Sie ihn einfach ??ber die Tastatur ein, wenn der Akteur markiert ist). Dies ist ein komfortabler Weg, einen Namen f??r einen neuen Akteur einzugeben.

Wenn sie einen Akteur erstellt haben, werden Sie sehen, dass er im Exlorer (der obere linke Quadrant des ArgoUML-Fensters) erscheint. Dieser zeigt alle im UML-Design erstellten Modellelemente. Eine Kombinationsfeldliste am oberen Ende des Explorers beeinflusst die Reihenfolge der Modellelemente im Explorer. Die n??tzlichsten sind Nach Paketen (Standard) und Nach Diagrammen. Das letztere gruppiert die Modellelemente nach Diagrammen.

4.4.2. Anwendungsf??lle

Das Vorgehen, um Anwendungsf??lle hinzuzuf??gen, ist das gleiche wie f??r das Hinzuf??gen von Akteuren, allerdings indem das Anwendungsfall- Symbol im Bearbeitenfenster verwendet wird ( ).

Standardm????ig zeigen Anwendungsf??lle in ArgoUML nicht ihre Erweiterungspunkte an (wird verwendet, um Beziehungen anzulegen). Sie k??nnen die Erweiterungspunkte auf einen von zwei Wegen anzeigen.

  1. Markieren Sie den Anwendungsfall im Bearbeitenfenster mit einem klick der Taste 1 aus, dann markieren Sie das Register Darstellung und klicken auf die Checkbox Erweiterungspunkte.

  2. Durch klicken mit der Taste 2 auf dem Anwendungsfall im Bearbeitenfenster erscheint ein kontext-sensitives Popup-Men?? und aus diesem w??hlen Sie Darstellung/ Erweiterungspunkte anzeigen aus.

Der gleiche Ansatz kann f??r das verstecken des Erweiterungspunktbereiches verwendet werden.

4.4.2.1. Einem Anwendungsfall einen Erweiterungspunkt hinzuf??gen

Es gibt zwei Wege, einem Anwendungsfall einen Erweiterungspunkt hinzuzuf??gen.

  1. Markieren Sie mit der Taste 1 den Anwendungsfall im Bearbeitenfenster. Dann klicken Sie in der Werkzeugleiste auf das Symbol Neue Erweiterung ( und ein neuer Erweiterungspunkt mit Standardnamen und -ort wird im Anschluss an die exisiterenden Erweiterungspunkte hinzugef??gt.

    [Anmerkung]Anmerkung

    Das Symbol Erweiterungspunkt hinzuf??gen ist inaktiv, bis ein Anwendungsfall markiert ist.

  2. Markieren Sie den Anwendungsfall im Bearbeitenfenster mit dem Taste 1-Klick und dann w??hlen Sie das Register Eigenschaften im Detailfenster aus. Ein Taste 2-Klick ??ber dem Feld Erweiterungspunkt: wird ein kontext-sensitives Popup-Men?? ??ffnen. Markieren Sie Hinzuf??gen aus, um einen neuen Erweiterungspunkt hinzuzuf??gen.

    Wenn bereits ein Erweiterungspunkt existiert, werden Sie in diesem Feld im Register Eigenschaften angezeigt. Der neue Erweiterungspunkt wird unmittelbar vor dem Eintrag ??ber dem das Popup-Men?? aufgerufen wurde eingef??gt. Diese Reihenfolge kann sp??ter durch die Nach oben und Nach unten-Eintr??ge im Popup-Men?? ver??ndert werden.

Welche Methode auch immer verwendet wird, der neue Erweiterungspunkt wird markiert und sein Register Eigenschaften kann im Detailfenster angezeigt werden. Der Name und der Ort des Erweiterungspunktes sind Freitext, der die entsprechenden Felder des Registers Eigenschaften setzt.

Ein exisiterender Erweiterungspunkt kann in seinem Register Eigenschaften bearbeitet werden. Das Register Eigenschaften kann auf zwei Wegen erreicht werden.

  1. Wenn f??r den Anwendungsfall der Erweiterungspunkt-Bereich im Diagramm angezeigt wird, markieren Sie den Anwendungsfall mit dem Taste 1-Klick und dann markieren Sie den Erweiterungspunkt mit einem weiteren Taste 1-Klick. Das Register Eigenschaften kann dann im Detailfenster ausgew??hlt werden.

  2. Im anderen Fall markieren Sie den Anwendungsfall und sein Register Eigenschaften im Detailfenster. Ein Taste 1- Klick auf den gew??nschten Eintrag im Feld Erweiterungspunkte wird das Register Eigenschaften f??r den Erweiterungspunkt im Detailfenster zur Anzeige bringen.

Die Felder Name und Ort des Erweiterungspunktes k??nnen bearbeitet werden.

Wenn der Erweiterungspunktbereich angezeigt wird, ist der Doppelklick auf den Erweiterungspunkt eine Abk??rzung und erlaubt es Ihnen den Text direkt einzugeben. Dies wird analysiert, um den Namen und den Ort f??r den Erweiterungspunkt zu setzen.

Erweiterungspunkte d??rfen gel??scht oder deren Reihenfolge mit Hilfe des Taste 2-Popup-Men??s ??ber dem Feld Erweiterungspunkte im Register Eigenschaften des Anwendungsfalles ge??ndert werden.

Nachdem Sie einen Erweiterungspunkt erstellt haben, wird er im Explorer (oberer linker Quadrant des ArgoUML-Fensters) erscheinen. Erweiterungspunkte werden immer als Sub-Baum ihres eigenen Anwendungsfalles dargestellt.

4.4.3. Assoziationen

Um im Diagramm einen Anwendungsfall mit einem Akteur zu verbinden, klicken Sie der Taste 1 auf das Assoziationssymbol in der Editierwerkzeugleiste ( ). Auf dem Anwendungsfall halten Sie die Taste 1 gedr??ckt, gehen zum Akteur und lassen die Taste 1 los (oder beginnen Sie beim Akteur und enden am Anwendungsfall).

Dadurch wird eine gerade Linie zwischen dem Akteur und dem Anwendungsfall erzeugt. Sie k??nnen die Linie segmentieren, indem Sie die Taste 1 auf der Linie gedr??ckt halten und vor dem loslassen bewegen. Der Linie wird ein Schnittpunkt hinzugef??gt, den Sie mit der Taste 1 bewegen k??nnen. Durch Aufnehmen und durch verschieben zu einem Ende der Linie kann der Schnittpunkt entfernt werden.

Es k??nnen mehrere Assoziationen gleichzeitig hinzugef??gt werden, indem Sie auf das Assoziationssymbol einen Taste 1-Doppelklick ausf??hren. Jede darauf folgende Taste 1-dr??cken/bewegen/loslassen- Sequenz wird einen Akteur mit einem Anwendungsfall verbinden. Das Anklicken des Auswahlsymbols ( ) mit der Taste 1 stoppt das Hinzuf??gen von Assoziationen.

Es ist auch m??glich, Assoziationen mit Hilfe der kleinen „Griffe “ hinzuzuf??gen, die links und rechts eines Anwendungsfalles oder eines Akteurs erscheinen, wenn dieser markiert ist und sich die Maus dar??ber befindet. Das Ziehen des Griffes von einem Anwendungsfall zu einem Akteur wird eine Assoziation zu diesem Akteur erzeugen (und umgekehrt beim Ziehen eines Griffes von einem Akteur zu einem Anwendungsfall).

Das Ziehen eines Griffes von einem Anwendungsfall in den leeren Raum wird einen neuen Akteur am anderen Ende erzeugen. Umgekehrt wird das Ziehen eines Griffes von einem Akteur in den leeren Raum einen neuen Anwendungsfall erzeugen.

Es ist m??glich, der Assoziation einen Namen zu geben, der die Beziehung des Akteurs zum Anwendungsfall beschreibt. Obgleich das gew??hnlich nicht notwendig ist. Dies wird ??ber das Eigenschaftsregister der Assoziation getan. Solch ein Name erscheint entlang der Assoziation in der N??he der Mitte.

4.4.3.1. Navigation einstellen

Es gibt zwei Wege, die Navigation einer Assoziation einzustellen.

  1. Das Anklicken der Assoziation mit der Taste 2 bringt ein kontextsensitives Popup-Men?? nach oben. Das Untermen?? Navigierbarkeit enth??lt Optionen f??r die bidirektionale Navigation (der Standard, ohne Pfeile) und f??r die Navigierbarkeit Akteur->Anwendungsfall und Anwendungsfall->Akteur.

  2. Verwenden Sie die Taste 1, um die Assoziation zu markieren und markieren Sie sein Eigenschaftsregister im Detailfenster. Dieses enth??lt ein Feld mit der Bezeichnung Verbindungen: mit Eintr??gen f??r jedes mit einem Akteur oder Anwendungsfall verbundenen Ende und seiner Kardinalit??t. Markieren Sie das Ende welches das Ende des Pfeiles darstellt mit einem Taste 1- Doppelklick. Dies bringt das Eigenschaftsregister f??r das Assoziationsende nach oben. Verwenden Sie den Taste 1- Klick, um die Markierung des K??stchens navigierbar zu entfernen.

    [Anmerkung]Anmerkung

    Dies erscheint anti-intuitiv, aber tats??chlich sind Assoziationen standardm????ig in beide Richtungen navigierbar (wenn keine Pfeile angezeigt werden). Dieser Prozess ist eher das Ausschalten der Navigation an einem Ende, als das Einschalten am anderen Ende.

Sie werden sehen, dass es m??glich ist, einem Assoziationsende im Eigenschaftsregister einen Namen zu geben. Dieser Name wird an dem Ende der Assoziation erscheinen und kann dazu verwendet werden die Rolle zu beschreiben, die ein Akteur oder ein Anwendungsfall in dieser Assoziation spielt.

Ein Zeitmanagmentsystem f??r ein Gesch??ft kann zum Beispiel Anwendungsf??lle f??r die Vervollst??ndigung der Zeittabellen und f??r das Abzeichnen der Zeittabellen aufweisen. Ein Akteur Mitarbeiter kann in beides involviert sein. Einmal als Mitarbeiter und zum anderen in der Rolle als Manager.

4.4.3.2. Die Kardinalit??t einstellen

Es gibt zwei Wege, die Kardinalit??t am Ende einer Assoziation einzustellen.

  1. Der Taste 2-Klick ??ber dem Ende einer Assoziation verursacht das Erscheinen eines kontextsensitiven Popup- Men??s mit einem Untermen?? Kardinalit??t. Dieses erlaubt es Ihnen, auszuw??hlen aus 1 (dem Standard), 0..1, 0..* und 1..*.

  2. Bringen Sie das Eigenschaftsregister f??r das Assoziationsende wie in "Navigation einstellen" nach oben (siehe zweite Option in Abschnitt 4.4.3.1, „Navigation einstellen“). Ein Dropdown-Men?? gibt Ihnen die Kardinaltit??tsoptionen aus, die ausgew??hlt werden k??nnen.

Der zweite dieser beiden Ans??tze hat mehr Optionen, obgleich ArgoUML es dem Anwender aktuell nicht erlaubt eine beliebige Kardinaltit??t einzustellen.

4.4.4. Hierarchische Anwendungsf??lle

Der Originalentwurf der UML erlaubt es, dass Anwendungsf??lle in Paketen gruppiert, sowie Beziehungen zwischen ihnen spezifiziert werden k??nnen. In ArgoUML werden nur die Beziehungsmechanismen unterst??tzt. Alle drei Beziehungen, die auf Anwendungsf??lle angewendet werden k??nnen werden unterst??tzt. Dieses sind include, extend und generalization.

4.4.4.1. Include

Die Prozedur zum Hinzuf??gen einer Include-Beziehung ist die gleiche, wie f??r das Hinzuf??gen einer Assoziation. Allerdings verwenden Sie das Include-Symbol aus der Editier-Werkzeugleiste ( ) um die beiden Anwendungsf??lle zu verbinden.

Seit Include-Beziehungen richtungsgebunden sind, ist die Reihenfolge mit der die beiden Enden markiert werden wichtig. Der einbindende (Haupt) Anwendungsfall sollte zuerst (Taste 1 dr??cken) und der eingebundene (sekund??re) Anwendungsfall als zweiter (Taste 1 loslassen) markiert werden.

Es ist m??glich die Include-Beziehungen mit Hilfe des Eigenschaftsregisters zu benennen. Dies wird aber selten getan und wird im Anwendungsfalldiagramm nicht dargestellt.

4.4.4.2. Extend

Die Prozedur zum Hinzuf??gen einer Extend-Beziehung ist die gleiche, wie f??r das Hinzuf??gen einer Include-Beziehung. Allerdings verwenden Sie das Extend-Symbol aus der Editier- Werkzeugleiste ( ) um die beiden Anwendungsf??lle zu verbinden.

Wie bei den Include-Beziehungen ist die Reihenfolge des Markierens wichtig. In diesem Fall sollte der erweiternde (sekund??re) Anwendungsfall zuerst (Taste 1 dr??cken) und dann der erweiterte (Haupt-) zweite Anwendungsfall markiert werden (Taste 1 loslassen).

[Anmerkung]Anmerkung

Dies ist gegen??ber der Include-Beziehung genau umgekehrt, reflektiert aber die Art und Weise, wie Designer denken. Die Tatsache, dass der Pfeil des Extend-Symboles nach oben zeigt ( im Gegensatz zum Include-Symbol) sollte Ihnen helfen, sich daran zu erinnern.

Um eine Bedingung f??r die Extend-Beziehung einzugeben, markieren Sie die Extend-Beziehung im Editierfenster (Taste 1-Klick) und ??ffenen Sie das Eigenschaftsregister im Detailfenster ( Taste 1-Klick auf das Register). Der Text der Bedingung kann in das Bedingungs-Feld eingegeben werden. Lange Bedingungen sollten - sofern gew??nscht - ??ber mehrere Zeilen aufgeteilt werden. Die Bedingung wird unterhalb der «extend»-Kennzeichnung im Diagramm dargestellt.

Es ist m??glich die Extend-Beziehungen mit Hilfe des Eigenschaftsregisters zu benennen. Dies wird aber selten getan und wird im Anwendungsfalldiagramm nicht dargestellt.

4.4.4.3. Generalisierung

Die Prozedur zum Hinzuf??gen einer Generalisierung ist die gleiche, wie f??r das Hinzuf??gen einer Extend-Beziehung. Allerdings verwenden Sie das Generalisierungs-Symbol aus der Editier-Werkzeugleiste ( ).

Seit die Generalisierung eine gerichtete Beziehung ist, ist die Reihenfolge des Markierens wichtig. Der spezialisierte Anwendungsfall sollte zuerst (Taste 1 dr??cken) und der generalisierte als zweites markiert werden (Taste 1 loslassen).

Es ist auch m??glich, die Generalisierung mit Hilfe der kleinen Griffe, die oben und unten am Anwendungsfall erscheinen, wenn er markiert ist, hinzuzuf??gen. Das Ziehen des oberen Griffes auf einen anderen Anwendungsfall erzeugt eine Generalisierung. Der Original-Anwendungsfall ist das spezialisierte Ende und der Anwendungsfall auf den der Griff gezogen wurde wird das generalisierte Ende. Das ziehen in den leeren Raum wird einen neuen Anwendungsfall mit einem generalisierten Ende erzeugen.

??hnlich ist es beim Ziehen des unteren Griffes. Dies erzeugt eine Generalisierung bei der der Original-Anwendungsfall das generalisierteEnde darstellt.

Die Generalisierung ist auch zwischen Akteuren erlaubt, obwohl dieser Gebrauch ausserhalb des Bezugsbereiches dieses Tutorials liegt. Im Gegensatz zu den Anwendungsf??llen gibt es keine Generalisierungs-Griffe bei Akteuren, so dass Generalisierungen mit Hilfe der Symbole in der Werkzeugleiste erzeugt werden m??ssen.

Es ist m??glich die Generalisierungs-Beziehungen mit Hilfe des Eigenschaftsregisters zu benennen. Wird ein Name eingegeben, wird dieser im Anwendungsfalldiagramm dargestellt.

4.4.5. Stereotypen

Die UML enth??lt das Konzept der Schablonen, um die Basisnotation zu erweitern. Es mag zum Beispiel n??tzlich erscheinen, ein Problem sowohl auf Gesch??ftsebene als auch auf der Ingenieur-Ebene zu modellieren. In diesem Fall unterscheidet die OMG zwischen einem PIM und einem PSM. F??r beide werden wir Anwendungsf??lle ben??tigen, aber die Anwendungsf??lle auf der Gesch??ftsebene enthalten eine andere Art von Informationen als die auf der Ingenieurs-Ebene. Sie nutzen sehr wahrscheinlich eine andere Sprache und Notation in ihren darunter liegenden Anwendungsfallspezifikationen.

Stereotypen werden zur Kennzeichnung von UML-Modellelementen wie Anwendungsf??lle benutzt, um darzustellen, dass diese zu einer bestimmten Kategorie geh??ren. Diese Kennzeichen werden in guillemots ( « ») ??ber dem Namen des Modellelementes im Diagramm dargestellt. Der UML-Standard definiert eine Anzahl von Standard-Stereotypen und der Anwender darf weitere Stereotypen selbst definieren.

Sie werden sehen, dass ArgoUML in jedem Eigenschaftsregister eine Drop-Down-Auswahl Stereotypen aufweist. Dieses ist mit den Standard-Stereotypen gef??llt, zu denen Sie Ihre eigenen hinzuf??gen k??nnen.

Die Details der Schablonen liegt ausserhalb des Bezugsbereiches dieses Tutorials. Das Referenzhandbuch (siehe Abschnitt 16.6, „Stereotype“) dokumentiert die von ArgoUML bereitgestellte Unterst??tzung.

[Warnung]Warnung

In ArgoUML fehlen einige der Standard-UML-Stereotypen. Zus??tzlich stellen nicht alle Modellelemente die Stereotypen im Diagramm dar. Aktuell sind sie in Anwendungsf??llen und Akteuren enthalten.

4.4.6. Dokumentation

ArgoUML enth??lt einige einfache Dokumentationsm??glichkeiten, die mit den Modellelementen im Diagramm verkn??pft sind. Haupts??chlich sollten diese nur zum Aufzeichnen der Ablageorte der Dokumente verwendet werden, nicht f??r die aktuelle Dokumentation selbst.

Die Dokumentation f??r ein bestimmtes Modellelement wird im Dokumentationsregister im Detailfenster aufgezeichnet (der unten rechts befindliche Quadrant des Bildschirms).

Zus??tzlich k??nnen in den Diagrammen Kommentare mit Hilfe des Text- Symboles der Editier-Werkzeugleiste hinzugef??gt werden ( ).

Es wird empfohlen, dass ein Anwendungsfalldiagramm das Dokumentationsregister des Akteurs nutzen sollte, um die Informationen ??ber den Akteur aufzuzeichnen. Oder, sollte der Akteur sehr komplex sein, sich auf ein separates Dokument beziehen, welches die Information ??ber den Akteur beinhaltet.

Das Dokumentationsregister des Anwendungsfalles sollte den Ablageort der Anwendungsfalldokumentation aufzeichnen. Die Information in der Anwendungsfallspezifikation (f??r alle, auch den einfachsten Anwendungsf??llen) ist zu komplex, als dass sie direkt in das Register eingegeben werden k??nnte.

Das Projekt sollte auch ein separates Visionsdokument haben und eine erg??nzende Anforderungsspezifikation. Ein Kommentar in Diagrammen kann dazu verwendet werden, sich auf diese zu beziehen, wenn der Anwender dies n??tzlich findet.

[Warnung]Warnung

Das Dokumentationsregister enth??lt ein K??stchen Veraltet. Der Status dieses Kennzeichens bleibt in der aktuellen Release von ArgoUML beim Speichern und Laden nicht erhalten.

4.4.7. Systemgrenzen

ArgoUML enth??lt eine Reihe von Werkzeugen, um beliebige grafische Kommentare in Diagramme einzuf??gen (wir lernten das Text-Tool bereits kennen). Diese finden Sie auf der rechten Seite der Editier- Werkzeugleiste und sind im Referenzhandbuch vollst??ndig dokumentiert (siehe Kapitel 12, Das Editierfenster).

Das Rechteck kann verwendet werden, um die Grenzen des Systems darzustellen. Nutzen Sie das Taste 2-kontextsensitive Popup- Men?? Reihenfolge, um diese hinter alle anderen Elemente zu plazieren. Es gibt jedoch keinen Weg, die F??llfarbe zu ??ndern. Sie werden es daher vorziehen, die Systemgrenzen aus vier einzelnen Linien zu zeichnen. Dies ist die Methode, die f??r die Diagramme in diesem Kapitel verwendet wurde.

[Anmerkung]Anmerkung

Das Editierfenster in ArgoUML hat ein Gitter, in das Objekte beim zeichnen einrasten. Die Gr????e dieses Gitters und seine Auswirkungen k??nnen durch das Ansicht-Men?? (verwenden Sie Raster einstellen und Einrasten einstellen) ver??ndert werden. Dies ist im Referenzhandbuch vollst??ndig beschrieben (siehe Kapitel 10, Die Men??zeile).

4.5. Fallstudie

4.5.1. Visions-Dokument

Ein Visionsdokument enth??lt mehr als nur die Dinge, die f??r die Modellierung erforderlich sind. Es enth??lt auch finanzielle und verwaltungsrelevante Informationen. Die folgenden Abschnitte sind solche Teile eines Visionsdokumentes Abschnitt 4.3.1, „Visions-Dokument“. In der Praxis muss dieses Format nicht sklavisch eingehalten werden, aber es ist hier f??r die Konsistenz erforderlich.

4.5.1.1. Zusammenfassung

Die Firma m??chte eine Serie von Geldautomaten produzieren und vermarkten. Der Zweck dieses Projektes ist es, die Hardware und die Software zu produzieren die beides ist: Wartbar und Robust.

4.5.1.2. Ziele

Bessere entworfene Produkte auf Basis neuer Technologien produzieren. Wir folgen der MDA-Philosophie der OMG indem wir zuerst ein plattformunabh??ngiges Modell (Platform Independent Model (PIM)) erzeugen. Da die aktuelle Modellierungstechnologie die Verwaltung der Integrit??t der Verbindung zwischen der PIM und den plattformspezifischen Modellen (Platform Specific Model (PSM)) nicht zulassen, wird die PIM vergleichsweise stabil werden bevor die erste Iteration der PSM produziert wird. Die Softwareplattform wird die Java-Technologie sein. Das System wird einen einfachen Userid (von der Geldautomatenkarte) und Kennwort (oder PIN)-Mechanismus verwenden.

4.5.1.3. Der Markt

Das aktuell auf dem Markt vorhandene Equipement basiert auf ??lterer Technologie bei der Hard- und Software. Diese Technologie hat noch nicht das Ende seiner Lebensdauer erreicht, was es unwahrscheinlich macht, das die Hersteller dieser Produkte diese in der nahen Zukunft austauschen werden. Auf der anderen Seite ist neuere Technologie verf??gbar, die uns einen nennenswerten Vorteil verschafft, wenn wir sie jetzt implementieren.

4.5.1.4. Projektbeteiligte

Zwischen den Projektbeteiligten dieses Systemes befinden sich die Entwicklungsabteilung, die Wartung und der zentrale Computer- Betrieb. Die vollst??ndige Liste der Projektbeteiligten und die spezifischen Personen, die diese repr??sentieren sind:

  • Entwicklung. Bunny, Bugs

  • Wartung. Hardy, Oliver

  • Computerbetrieb. Laurel, Stanley

  • Gesch??ftsf??hrer. Hun, Atilla von

  • Marketing. Harry, Oil Can

4.5.1.5. Haupteigenschaften

Geld aufbewahren, Geld abheben und Kontostandsabfragen der Kunden. Kunden sind Personen, die Konten bei ihrer Bank haben aber auch Personen, die Abhebungen von Konten anderer Banken oder von Kreditkarten vornehmen wollen.

Wartung des Equipements durch die Bankingenieure. Diese Aktion kann durch den Ingenieur initiiert auf Basis eines Wartungsplanes werden. Sie kann aber auch durch das Equipement initiiert werden, die den Ingenieur ruft, wenn es einen internen Fehler entdeckt.

Das Herausnehmen der Einlagen und das Aufladen von Geld erfolgt durch Beamte der lokalen Bankfiliale. Diese Aktionen werden entweder auf Basis eines Planes ausgef??hrt, oder wenn der Zentralcomputer feststellt, dass der Geldvorrat zu gering oder die Einlagenkassette fast voll ist.

Es wird ein Nachweis von allen Aktivit??ten erzeugt und periodisch an den Zentralcomputer der Banken gesandt. Es soll dem Wartungsingenieur m??glich sein, eine Kopie des Nachweislog auf einer Diskette f??r den Transport zum Zentralcomputer zu speichern.

Es wird W??hl- und Standleitungssupport ben??tigt. Der Geldautomat soll auch weiterarbeiten k??nnen, wenn die Kommunikation mit dem Zentralcomputer nicht verf??gbar ist.

4.5.1.6. Randbedingungen

Das Projekt muss innerhalb von 9 Monaten abgeschlossen sein. Es darf nicht mehr als 1.750.000 USD ausschliesslich der Produktionskosten kosten. Komponenten k??nnen ausserhalb produziert werden aber die Basisarchitektur als auch die Infrastruktur wird im Haus entworfen. Eine enge Zusammenarbeit muss zwischen der Softwareentwicklung und dem Design, der Entwicklung und der Produktion der Hardware sichergestellt werden. Weder die Hardware noch die Software darf als unabh??nige Variable betrachtet werden. Sie m??ssen immer gleichzeitig betrachtet werden.

4.5.1.7. Anhang

Im Folgenden finden Sie Akteure, die diese Vision direkt unterst??tzen. Zus??tzliche Akteure k??nnen sp??ter identifiziert werden, sofern Sie zur Unterst??tzung dieser Vision oder der Technologie erforderlich sind. Sie sollten nicht zu dieser Liste hinzugef??gt werden, es sei denn, sie sind zur direkten Unterst??tzung dieser Vision, wie in diesem Dokument beschrieben, erforderlich.

  • Zentralcomputer

  • Kunde

  • Lokaler Bankbeamter

  • Wartungsingenieur

Im Folgenden finden Sie Anwendungsf??lle, die diese Vision direkt unterst??tzen. Zus??tzliche Anwendungsf??lle k??nnen sp??ter identifiziert werden, wenn Sie zur Unterst??tzung dieser Vision oder der Technologie erforderlich sind oder die hier aufgelisteten Anwendungsf??lle unterst??tzen. Sie sollten dieser Liste nicht hinzugef??gt werden, es sei denn, sie sind f??r die direkte Unterst??tzung der Vision, wie in diesem Dokument beschrieben, erforderlich.

  • Pr??fen

  • Kunden nutzt den Automaten

  • Wartung

4.5.2. Akteure und Anwendungsf??lle identifizieren

F??r die Geldautomaten-Fallstudie werden wir die Beispiele in Abschnitt 4.3, „Ergebnis des Anforderungs-Erfassungs-Prozesses“, Abbildung 4.4, „ Anwendungsfalldiagramm f??r einen Geldautomaten mit include-Beziehungen. “ und Abbildung 4.5, „ Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung. “, und fortschreiben, um zus??tzliche Akteure und Anwendungsf??lle zu identifizieren, die unser Geldautomatenmodell enth??lt. Abbildung 4.4, „ Anwendungsfalldiagramm f??r einen Geldautomaten mit include-Beziehungen. “ und Abbildung 4.5, „ Anwendungsfalldiagramm f??r einen Geldautomaten. Zeigt eine extend-Beziehung. “ erl??utert die grunds??tzlichen Konzepte und Komponenten des Anwendungsfalldiagrammes wie Anwendungsf??lle, Akteure, Kardinalit??t und Include-/Extend-Beziehungen. Sie zeigen die Beziehungen zwischen den Akteuren und den Anwendungsf??llen und demonstieren wie diese Akteure und Anwendungsf??lle miteinander interagieren.

In Abbildung 4.4, „ Anwendungsfalldiagramm f??r einen Geldautomaten mit include-Beziehungen. “ sehen wir ein Anwendungsfalldiagramm f??r einen Geldautomaten, bestehend aus «include»-Beziehungen f??r die Anwendungsf??lle Geldautomat warten und Geldautomat nutzen. Geldautomat warten wird dar??ber hinaus durch zwei Anwendungsf??lle definiert: "Equipement warten" und "Geldautomat neu starten". Geldautomat nutzen wurde dar??ber hinaus durch drei einfachere Anwendungsf??lle definiert: "Geld einnehmen", "Geld abheben" und "Kontostand abfragen".

Noch zu beschreiben...

4.5.3. Assoziationen (Noch zu beschreiben)

Noch zu beschreiben...

4.5.4. Erweiterte Diagrammeigenschaften (Noch zu beschreiben)

Noch zu beschreiben...

4.5.5. Anwendungsfallspezifikationen (Noch zu beschreiben)

Noch zu beschreiben...

4.5.6. Erg??nzende Anforderungsspezifikation (Noch zu beschreiben)

Noch zu beschreiben...

Kapitel 5. Analyse

Die Analyse ist der Prozess, die „Kunden“-Anforderungen zu nehmen und in die Sprache und Perspektive der k??nftigen L??sung umzuwandeln.

Wir sollten zu diesem Zeitpunkt nicht versuchen die detaillierte L??sung auszuarbeiten. Dies passiert in der Design -Phase (siehe Kapitel 6, Design).

Wie die Grenze zwischen den Anforderungs- und der Analyse-Phase ist die Grenze zwischen Analyse und Design inh??rent unscharf. Der Schl??ssel dazu ist, dass die Analyse die L??sung nicht weiter als notwendig definieren sollte, um die Anforderungen in der Sprache der L??sung zu spezifizieren. Die Modellelemente in der Analyse repr??sentieren generell eine h??here Abstraktionsebene.

Noch einmal, die rekursive, und iterative Natur unserer Prozesse bedeutet, dass wir in der Zukunft noch h??ufig auf die Analysephase zur??ckkommen werden.

5.1. Der Analyseprozess

Es gibt drei gedankliche Ausrichtungen dar??ber, wie man sich der Analyse ann??hern sollte. Die Ontologen definieren die Daten (aktuell die Metadaten) zuerst und plagen sich sp??ter mit den Prozessen. Der wahre Ontologe w??rde es vorziehen, ??berhaupt nicht an Prozesse denken zu m??ssen. Der Ph??nomenalist kehrt dies um und stellt die Prozesse ??ber die Daten. Der Paradigmatiker betrachtet die Prozesse und Daten gleichwertig wichtig und adressiert beide von Beginn an.

Wenn es dazu kommt, Purist zu sein, dann hat der Ontologe die Oberhand. Es ist m??glich, eine Datenbank zu definieren und zu erzeugen, in die Daten eingegeben und geholt werden kann, ohne R??cksicht darauf, was mit ihnen getan wird oder nicht. Auf der anderen Seite ist es nicht besonders n??tzlich einen Prozess zu implementieren ohne irgendwelche Datenstrukturen zu haben auf denen der Prozess arbeitet.

5.1.1. Klasse-, Verantwortlichkeits- und Zusammenarbeits-Karten (CRC)

Die CRC-Methode (CRC = Class, Responsibility, Collaborators) favorisiert die Vorliebe der Ph??nomenologen f??r die Analyse. Es ist ??quivalent mit den Anwendungsf??llen zu beginnen, die Aspekte der Prozesse (Operationen) in Klassendiagrammen und Szenarien darzustellen aus denen Sequenzdiagramme initiiert werden k??nnen.

CRC-Karten und die entsprechende Methode sind detailliert in Anhang G, The CRC Card Methodology beschrieben. Sie werden in der Designphase erneut verwendet und weiter diskutiert in Kapitel 6, Design.

Die St??rke der CRC-Karten w??hrend der Analyse.

  • Gemeinsames Projektvokabular -

  • Breites Bereichswissen -

  • F??hrt Paradigmenwechsel durch -

  • Live-Prototyping -

  • Indentifiziert L??cken in den Anforderungen -

In dieser Phase sollte die Gruppe aus zwei oder drei Fachexperten bestehen. Einer als Vermittler der objektorientierten Technologie und der Rest der Gruppe sollte aus Personen bestehen, die f??r das das Ausrollen des Systems verantwortlich sind.

Wenn man das erste Mal in die Analysephase eintritt, tritt ein spezieller Fall der CRC-Sitzung auf, weil es keine Klassen oder Szenarien gibt, die man in der CRC-Sitzung f??r die Definition ausw??hlen k??nnte. Zu diesem Zeitpunkt tritt ein spezieller Sitzungstyp, Brainstorming genannt, auf. W??hrend dieser Phase identifizieren Sie den grundlegenden Satz von Klassen des Problembereiches, indem Sie die Problembeschreibung oder das Anforderungsdokument oder was immer Sie auch ??ber das gew??nschte Ergebnis wissen als Startpunkt verwenden. Die Hauptw??rter, die Sie finden, sind gute Ans??tze f??r einen ersten Satz von Klassen in dem System. W??hrend der Brainstorming-Sitzung sollten die Ideen wenig bis gar nicht diskutiert werden. Schreiben Sie diese auf und filtern Sie die Ergebnisse nach dem Brainstorming. Zu diesem Zeitpunkt ist die Unterscheidung zwischen Klasse und Objekt unscharf.

Nachdem ein vern??nftiger Satz von Klassen durch die Gruppe definiert wurde, k??nnen die Verantwortlichkeiten hinzugef??gt werden. F??gen Sie Verantwortlichkeiten hinzu, die aus den Anforderungen oder den Namen der Klassen deutlich hervorgehen. Sie m??ssen nicht alle finden m??ssen (oder in jedem Fall alle). Die Szenarien werden dies deutlicher machen. Der Vorteil, einige bereits am Anfang zu finden ist, dass es hilft, einen Anfangspunkt zu finden.

W??hlen Sie die ersten Szenarios aus dem Anforderungsdokument aus, indem Sie dessen Verben auf die gleiche Weise pr??fen, wie wir vorher die Hauptw??rter durchgingen. Dann f??hren Sie diesen Prozess so oft als notwendig durch, um die begonnene Analysephase zu vervollst??ndigen.

Wann ist genug Analyse durchgef??hrt worden und wann kann das Design beginnen? Wenn alle unterschiedlichen Verantwortlichkeiten zugeordnet wurden und das System stabil geworden ist. Nachdem das gesamte normale Verhalten abgedeckt wurde, ist es notwendig aussergew??hnliches Verhalten zu simulieren. Wenn Sie feststellen, dass die Verantwortlichkeiten alle an der richtigen Stelle sind, um die neuen Szenarien zu unterst??tzen und nur noch wenige ??nderungen an den Karten vorzunehmen sind, dann ist das ein Anzeichen daf??r, dass Sie mit dem Design beginnen k??nnen.

5.1.2. Konzeptdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.1.3. System-Sequenzdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.1.4. System-Zustandsdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.1.5. Anwendungsfalldiagramm realisieren (Noch zu beschreiben)

Noch zu beschreiben...

5.1.6. Dokumente (Noch zu beschreiben)

Anwendungsfall- und Erg??nzende Anforderungs-Spezifikationen sind in die Sprache der L??sung umzuwandeln. Noch zu beschreiben...

5.2. Klassendiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.2.1. Das Klassendiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.2.2. Erweiterte Klassendiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.2.2.1. Assoziationsklassen (Noch zu beschreiben)

Noch zu beschreiben...

5.3. Klassendiagramme in ArgoUML erzeugen

5.3.1. Klassen

Klassendiagramme aus existierendem Material (Vision, Anwendungsf??lle, usw.) identifizieren. Noch zu beschreiben...

5.3.1.1. Das Kommentarsymbol in der Werkzeugleiste verwenden

Klicken Sie auf Ihre Zielklasse. Dann klicken Sie auf das Kommentarsymbol. ArgoUML wird die Verkn??pfung automatisch generieren.

Sie k??nnen auch einen Rechtsklick ausf??hren, um einen Kommentar hinzuzuf??gen! Beachten Sie, dass Sie eine unbegrenzte Anzahl von Kommentaren zu jeder Klasse hinzuf??gen k??nnen!

[Warnung]Warnung

Beachten Sie, dass Ihr Kommentar nicht im Sourcecoderegister erscheint.

5.3.2. Assoziationen (Noch zu beschreiben)

Noch zu beschreiben...

5.3.2.1. Aggregation (Noch zu beschreiben)

Noch zu beschreiben...

5.3.3. Klassenattribute und Operationen (Noch zu beschreiben)

Noch zu beschreiben...

5.3.3.1. Daten in Attribut- und Methodenfenster eingeben

Klicken Sie direkt in das Klassenelement und beginnen Sie mit der Eingabe. Verwenden Sie nicht die Dialogfenster des Eigenschaftsregisters; sie sind noch nicht vollst??ndig implementiert und f??hren nur zu ein bischen Frustration.

Nat??rlich w??re es von Interessse, wenn Sie Stereotypen rechts in den Bereich f??r Klassenattribute schreiben k??nnten, um XML-Diagramme zu generieren.

5.3.3.2. Klassenattribute (Noch zu beschreiben)

Noch zu beschreiben...

5.3.3.3. Klassenoperationen (Noch zu beschreiben)

Noch zu beschreiben...

5.3.4. Erweiterte Klasseneigenschaften (Noch zu beschreiben)

5.3.4.1. Assoziationsklassen (Noch zu beschreiben)

Noch zu beschreiben...

5.3.4.2. Stereotypen (Noch zu beschreiben)

Noch zu beschreiben...

5.4. Sequenzdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.4.1. Das Sequenzdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.4.2. Aktionen identifizieren (Noch zu beschreiben)

Noch zu beschreiben...

5.4.3. Erweiterte Sequenzdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.5. Sequenzdiagramme in ArgoUML erzeugen

5.5.1. Sequenzdiagramme

5.5.1.1. Ein Sequenzdiagramm erzeugen

Normalerweise k??nnen Sie mit einem Sequenzdiagramm sofort beginnen. Im Men?? Neues Diagramm w??hlen Sie aus Sequenzdiagramm.

5.5.2. Aktionen (Noch zu beschreiben)

Noch zu beschreiben...

5.5.3. Erweiterte Sequenzdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.6. Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.6.1. Das Zustandsdiagramm (Noch zu beschreiben)

Die Zustandsdiagrammarten (Moore, Mealy); Hierarchische Diagramme. Noch zu beschreiben...

5.6.2. Erweiterte Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.6.2.1. Hierarchische Zustandsdiagramme (Noch zu beschreiben )

Noch zu beschreiben...

5.7. Zustandsdiagramme in ArgoUML

5.7.1. Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.7.1.1. Ein Zustandsdiagramm erzeugen

Markieren Sie eine Klasse, dann k??nnen Sie ein Zustandsdiagramm erstellen.

5.7.2. Zust??nde (Noch zu beschreiben)

Noch zu beschreiben...

5.7.2.1. Einen zusammengesetzten Zustands editieren

Wenn Sie einen zusammengesetzten Zustands editieren, wie erhalten Sie Zugriff auf den zusammengesetzten Zustands?

Die Antwort ist, die Klasse markieren und dann das Zustandsdiagramm erstellen.

5.7.3. Transitionen (Noch zu beschreiben)

Noch zu beschreiben...

5.7.4. Aktionen (Noch zu beschreiben)

Noch zu beschreiben...

5.7.5. Erweiterte Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.7.5.1. Hierarchische Zustandsdiagramme ( Noch zu beschreiben)

Noch zu beschreiben...

5.8. Anwendungsf??lle realisieren (Noch zu beschreiben)

Noch zu beschreiben...

5.9. Realisierungs-Anwendungsf??lle in ArgoUML erstellen ( Noch zu beschreiben)

Noch zu beschreiben...

5.10. Fallstudie (Noch zu beschreiben)

Abh??ngig davon, welche Methode Sie verwenden, ist es an der Zeit, dass Sie ohne jeden Zweifel die Problembeschreibung aus Abschnitt 4.5, „Fallstudie“ nehmen und die Hauptw??rter extrahieren. Diese Liste sollte verdichtet werden, so dass nur noch die Hauptw??rter enthalten sind, die als Klasse erwartet werden. Dieser Ansatz hat folgendes Ergebnis:

  • Konto

  • Nachweislog

  • Bank

  • Geld

  • Kunde

5.10.1. CRC Karten

Der Projektmanager beruft eine CRC-Sitzung ein, in der die ersten Klassen definiert werden. Der Multiplikator erinnert die Teilnehmer daran, dass wir uns in der Analysephase befinden und nur an den Dingen interessiert sind, welche Bed??rfnisse erf??llt werden m??ssen (auf Gesch??ftsebene) und alles weglassen m??ssen, was nach "wie m??ssen wir es tun" aussieht. Als generelle Regel diese Ansatzes bedeutet das, eine Teilmenge der Hauptw??rter aus dem Problembereich (siehe oben). Die Gruppe beginnt mit einer vollst??ndigen Liste aller Hauptw??rter der Beschreibung, pr??ft jedes und entscheidet, welche unpassend sind und aus der Liste gestrichen werden. Jede Klasse wird dann einem der Teilnehmer zugewiesen.

ist fortzusetzen......

5.10.2. Klassendiagramme konzipieren (Noch zu beschreiben)

Noch zu beschreiben...

5.10.2.1. Klassen identifizieren (Noch zu beschreiben)

Noch zu beschreiben...

5.10.2.2. Assoziationen identifizieren (Noch zu beschreiben)

Noch zu beschreiben...

5.10.3. System-Sequenzdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.10.3.1. Aktionen identifizieren (Noch zu beschreiben)

Noch zu beschreiben...

5.10.4. System-Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

5.10.5. Realisierungs-Anwendungsf??lle (Noch zu beschreiben)

Noch zu beschreiben...

Kapitel 6. Design

Wir haben jetzt das Problem, das wir in der Sprache der vermeintlichen L??sung zu l??sen versuchen. In der Designphase konstruieren wir alle Details dieser L??sung.

Die verwischten Grenzen zwischen der Analyse und dem Design zeigt sich hier auch durch die gemeinsame Verwendung derselben UML-Werkzeuge. In diesem Kapitel werden wir sehr h??ufig die UML-Technologie verwenden, die wir bereits kennengelernt haben. Der grosse Schritt ist das Umwandeln in konkrete Ausdr??cke. Wir bewegen uns von den abstrakten Konzepten der Analyse hin zu deren konkreten Realisierung.

Erneut bedeutet die rekursive und iterative Natur unseres Prozesses, dass wir in Zukunft viele Male zur??ck in die Designphase kommen.

6.1. Der Designprozess (Noch zu beschreiben)

Der Designprozess erweitert den Modellierungsaufwand jenseits der Gesch??ftsanforderungen in Richtung des L??sungsraumes. W??hrend dieser Arbeit entscheiden Sie, ob Sie Java, C++, J3EE, CORBA, SOAP, W??hlleitungen, Internetverbindungen, Standleitungen, XML, usw. verwenden werden. Viele dieser Entscheidungen werden das PSM-Modell direkt beeinflussen, andere widerum werden sich nur in den erzeugten Dokumenten wiederspiegeln.

...

6.1.1. Klasse, Verantwortlichkeiten und Zusammenh??nge (CRC) Karten

Die St??rken der CRC-Karten w??hrend des Design

  • Verbreitern der objektorientierten Design-Expertise

  • Design Reviews

  • Framework die Implementierung

  • Informelle Notation

  • Auswahl der unterst??tzenden Softwarekomponenten

  • Performance-Anforderungens

In dieser Phase ersetzen die Entwickler einige der fachlichen Experten in der Gruppe. Es sollte aber immer mindestens ein fachlicher Experte in der Gruppe verbleiben.

Der Fokus der Gruppe bewegt sich von der Frage was zu tun ist hin zu der Frage wie es zu tun ist. Der Klassen aus dem L??sungsbereich werden denen der Analysephase hinzugef??gt. Es wird dar??ber nachgedacht, welche Klassen werden ben??tigt, damit das System arbeitet. Ben??tigen Sie eine Listenklasse, die Objekte beinhaltet? Ben??tigen Sie Klassen, die Ausnahmen behandeln? Ben??tigen Sie Wrapperklassen f??r andere Subsysteme? In diesem Abschnitt wird nach neuen Klassen gesucht, nach Klassen, die die Implementierung des Systems unterst??tzen.

W??hrend der Designphase wird der Unterschied zwischen Klasse und Objekt wichtig. Denken Sie ??ber die Objekte in Ihren Szenarien nach. Wer erzeugt die Objekte? Was passiert, wenn sie erzeugt und gel??scht werden? Wie ist die Lebensdauer des Objektes im Gegensatz zur Lebensdauer der Information, die durch das Objekt gehalten wird.

Jetzt ist es an der Zeit sich anzusehen, welche Informationen die Objekte halten, verglichen mit den von anderen Klassen angeforderten oder berechneten Informationen. Benutzen Sie die R??ckseite der Karte, um die gefundenen Attribute f??r diese Klassen aufzuschreiben. Teilen Sie die Verantwortlichkeiten in Sub-Verantwortlichkeiten auf und listen Sie die Sub-Verantwortlichkeiten unter der Hauptverantwortlichkeit einger??ckt auf. Verschieben Sie die daf??r notwendigen Klassen zu den Verantwortlichkeiten die sie nutzen. ^

Hinter der Kollaboratorklasse listen Sie auf Ihrer Karte die Verantwortlichkeit der in dieser Zusammenarbeit verwendeten Klasse auf. Hinter den kollaborierenden Verantwortlichkeiten Ihrer Karte listen Sie die durch die kollaborierenden Objekte zur??ckgelieferten Daten in Klammern auf.

Spielen Sie die Szenarien der Analysephase erneut durch, beachten Sie dabei aber alle Erw??gungen der diskutierten Design-Heuristiken. Nehmen Sie Ihre eigenen Szenarien und versuchen Sie es.

6.1.2. Paketdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.1.3. Realisierungs-Klassendiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.1.4. Sequenz- und Kollaborationsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.1.5. Zustands- und Aktivit??tsdiagramme ( Noch zu beschreiben)

Noch zu beschreiben...

6.1.6. Verteilungsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.1.7. Dokumente (Noch zu beschreiben)

System Architektur. Noch zu beschreiben...

6.2. Paketdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.2.1. Das Paketdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.2.2. Erweiterte Paketdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.2.2.1. Subpakete (Noch zu beschreiben)

Noch zu beschreiben...

6.2.2.2. Datentypen hinzuf??gen (Noch zu beschreiben)

Noch zu beschreiben...

6.2.2.3. Stereotypen hinzuf??gen (Noch zu beschreiben)

Noch zu beschreiben...

6.3. Paketdiagramme in ArgoUML erstellen

6.3.1. Pakete

Ausarbeiten, was in Pakete kommt. Noch zu beschreiben...

6.3.1.1. Subpakete (Noch zu beschreiben)

Noch zu beschreiben...

6.3.2. Beziehungen zwischen Paketen (Noch zu beschreiben)

Noch zu beschreiben...

6.3.2.1. Abh??ngigkeit (Noch zu beschreiben)

Noch zu beschreiben...

6.3.2.2. Generalisierung (Noch zu beschreiben)

Noch zu beschreiben...

6.3.2.3. Realisierung und Abstraktion (Noch zu beschreiben)

Noch zu beschreiben...

6.3.3. Erweiterte Paketeigenschaften (Noch zu beschreiben)

Noch zu beschreiben...

6.3.3.1. Neue Datentypen erstellen (Noch zu beschreiben)

Noch zu beschreiben...

6.3.3.2. Neue Stereotypen erstellen (Noch zu beschreiben)

Noch zu beschreiben...

6.4. Mehr ??ber Klassendiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.4.1. Das Klassendiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.4.1.1. Klassenattribute (Noch zu beschreiben)

Noch zu beschreiben...

6.4.1.2. Klassenoperationen (Noch zu beschreiben)

Noch zu beschreiben...

6.4.2. Erweiterte Klassendiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.4.2.1. Realisierung und Abstraktion (Noch zu beschreiben)

Noch zu beschreiben...

6.5. Mehr ??ber Klassendiagramme in ArgoUML (Noch zu beschreiben)

6.5.1. Klassen (Noch zu beschreiben)

Mehr ??ber das Identifizieren von Klassen aus existierendem Material und der Gebrauch von Stereotypen. Noch zu beschreiben...

6.5.2. Klassenattribute und -operationen (Noch zu beschreiben)

Noch zu beschreiben...

6.5.2.1. Klassenattribute (Noch zu beschreiben)

Noch zu beschreiben...

6.5.2.2. Klassenoperationen (Noch zu beschreiben)

Noch zu beschreiben...

6.5.3. Erweiterte Klasseneigenschaften

6.5.3.1. Operationen bei Schnittstellen

6.5.3.1.1. Schnittstellen, die Schnittstellen erweitern

Durch einfaches Klicken auf das Schnittstellensymbol in der Werkzeugleiste und anschliessendem klicken in das Diagrammfenster f??gen Sie dem aktuellen Klassendiagramm eine unbenannte Schnittstelle hinzu (siehe Abbildung 6.1, „Markieren des Schnittstellenwerkzeuges“).

Abbildung 6.1. Markieren des Schnittstellenwerkzeuges

Markieren des Schnittstellenwerkzeuges


Dann f??hren Sie einen Doppelklick auf das Namensfeld der Schnittstelle aus, um dessen Namen wie im Bild Abbildung 6.2, „Schnittstelle im Klassendiagramm“ gezeigt zu ??ndern.

Abbildung 6.2. Schnittstelle im Klassendiagramm

Schnittstelle im Klassendiagramm


Geben Sie den Namen ein (z.B. TestSchnittstelle in diesem Fall). Dr??cken Sie „Enter“, wenn der Name vollst??ndig ist. (Sie k??nnen den Namen auch ??ndern, indem Sie in das Eigenschaftsregister im Detailfenster nach dem Hinzuf??gen der Schnittstelle gehen.)

F??gen Sie eine weitere Schnittstelle hinzu, indem Sie die letzten beiden Schritte wiederholen. Dann klicken Sie auf das Generalisierungssymbol in der Werkzeugleiste wie in Bild Abbildung 6.3, „Generalisierung in der Werkzeugleiste des Klassendiagrammes“ dargestellt.

Abbildung 6.3. Generalisierung in der Werkzeugleiste des Klassendiagrammes

Generalisierung in der Werkzeugleiste des Klassendiagrammes


Bewegen Sie den Mauszeiger auf die Subschnittstelle, dr??cken Sie die linke Maustaste und ziehen Sie die Generalisierung auf die Superschnittstelle, indem Sie die Maustaste loslassen. Bild Abbildung 6.4, „Generalisierung zwischen zwei Schnittstellen.“ zeigt, wie Ihr Diagramm jetzt aussehen sollte.

Abbildung 6.4. Generalisierung zwischen zwei Schnittstellen.

Generalisierung zwischen zwei Schnittstellen.


Durch klicken auf die Subschnittstellen und das Sourceregister und anschliessende Auswahl der Javanotation f??r das Sourceregister k??nnen Sie sehen, dass die Schnittstelle nun seine Superschnittstelle erweitert.

6.5.3.2. Stereotypen (Noch zu beschreiben)

Noch zu beschreiben...

6.6. Sequenz- und Kollaborationsdiagramme ( Noch zu beschreiben)

[Anmerkung]Anmerkung

Sequenzdiagramme funktionieren in der ArgoUML-Version 0.14 nicht.

Noch zu beschreiben...

6.6.1. Mehr ??ber das Sequenzdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.6.2. Das Kollaborationsdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.6.2.1. Nachrichten (Noch zu beschreiben)

Noch zu beschreiben...

6.6.2.2. Aktionen (Noch zu beschreiben)

Noch zu beschreiben...

6.6.3. Erweiterte Kollaborationsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.7. Kollaborationsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)

6.7.1. Kollaborationsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.7.2. Nachrichten (Noch zu beschreiben)

Noch zu beschreiben...

6.7.2.1. Aktionen (Noch zu beschreiben)

Noch zu beschreiben...

6.7.3. Erweiterte Kollaborationsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.8. Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.8.1. Das Zustandsdiagramm (Noch zu beschreiben)

Mehr dar??ber.Noch zu beschreiben...

6.8.2. Erweiterte Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.1. Aktionen (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.2. Transitionen (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.2.1. Trigger (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.2.2. W??chter (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.2.3. Effekte (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.3. Pseudo-Zust??nde (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.3.1. Junction and Choice (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.3.2. Verzweigen und Verkn??pfen (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.4. Hierarchische Zustandsautomaten (Noch zu beschreiben)

Noch zu beschreiben...

6.8.2.5. Modelle f??r die Zustandshistorie (Noch zu beschreiben)

Breite versus Tiefe. Noch zu beschreiben...

6.9. Zustandsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)

6.9.1. Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.9.2. Zust??nde (Noch zu beschreiben)

Noch zu beschreiben...

6.9.3. Transitionen (Noch zu beschreiben)

Noch zu beschreiben...

6.9.4. Aktionen (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5. Erweiterte Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.1. Transitionen (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.1.1. Trigger (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.1.2. W??chter (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.1.3. Effekte (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.2. Pseudozust??nde (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.2.1. Junction and Choice (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.2.2. Verzweigen und Verkn??pfen (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.3. Hierarchische Zustandsautomaten (Noch zu beschreiben)

Noch zu beschreiben...

6.9.5.4. Historie (Noch zu beschreiben)

Breite versus Tiefe. Noch zu beschreiben...

6.10. Aktivit??tsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.10.1. Das Aktivit??tsdiagramm (Noch zu beschreiben)

Mehr dar??ber. Noch zu beschreiben...

6.10.1.1. Aktionszust??nde (Noch zu beschreiben)

Noch zu beschreiben...

6.11. Aktivit??tsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)

6.11.1. Aktivit??tsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.11.1.1. Ein Aktivit??tsdiagramm erstellen

Markieren Sie einen Anwendungsfall oder eine Klasse, dann k??nnen Sie ein Aktivit??tsdiagramm erstellen.

6.11.2. Aktionszust??nde (Noch zu beschreiben)

Noch zu beschreiben...

6.12. Verteilungsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.12.1. Das Verteilungsdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.13. Verteilungsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)

6.13.1. Knoten (Noch zu beschreiben)

Noch zu beschreiben...

6.13.1.1. Knoten-Instanzen (Noch zu beschreiben)

Noch zu beschreiben...

6.13.2. Komponenten (Noch zu beschreiben)

Noch zu beschreiben...

6.13.2.1. Komponenten-Instanzen (Noch zu beschreiben)

Noch zu beschreiben...

6.13.3. Beziehungen zwischen Knoten und Komponenten ( Noch zu beschreiben)

Noch zu beschreiben...

6.13.3.1. Abh??ngigkeit (Noch zu beschreiben)

Noch zu beschreiben...

6.13.3.2. Assoziationen (Noch zu beschreiben)

Noch zu beschreiben...

6.13.3.3. Verkn??pfungen (Noch zu beschreiben)

Noch zu beschreiben...

6.14. System-Architektur (Noch zu beschreiben)

Noch zu beschreiben...

6.15. Fallstudie (Noch zu beschreiben)

6.15.1. CRC-Karten (Noch zu beschreiben)

Noch zu beschreiben...

6.15.2. Pakete (Noch zu beschreiben)

Noch zu beschreiben...

6.15.2.1. Pakete identifzieren (Noch zu beschreiben)

Noch zu beschreiben...

6.15.2.2. Datentypen und Stereotypen (Noch zu beschreiben)

Noch zu beschreiben...

6.15.3. Klassendiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.15.3.1. Klassen identifizieren (Noch zu beschreiben)

Noch zu beschreiben...

6.15.3.2. Assoziationen identifizieren (Noch zu beschreiben)

Noch zu beschreiben...

6.15.3.3. Attribute und Operationen spezifizieren ( Noch zu beschreiben)

Noch zu beschreiben...

6.15.4. Sequenzdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.15.4.1. Aktionen identifzieren (Noch zu beschreiben)

Noch zu beschreiben...

6.15.5. Kollaborationsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.15.5.1. Nachrichten identifizieren (Noch zu beschreiben)

Noch zu beschreiben...

6.15.6. Zustandsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.15.7. Aktivit??tsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.15.8. Das Verteilungsdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.15.9. Die System-Architektur (Noch zu beschreiben)

Noch zu beschreiben...

Kapitel 7. Codegenerierung, Reverse Engineering und Round Trip Engineering

7.1. Einleitung

Wir haben jetzt unser Design vollst??ndig spezifiziert. Mit dem richtigen Simulator k??nnen wir das Design aktuell ausf??hren und sehen, wie es arbeitet. (ArgoUML enth??lt keine solche Funktionalit??t, aber diese Funktionalit??t wird in anderen Tools angeboten).

ArgoUML erlaubt es Ihnen, Code aus dem Design in vielen verschiedenen Programmiersprachen auszuf??hren. Wir haben bereits sehr wahrscheinlich im Design eine Programmiersprache ausgew??hlt, weil einige der Designanforderungen fordern, eine spezielle Sprache auszuw??hlen.

Das Ergebnis dieses Prozesses ist ein Satz von Dateien, der das Programm bildet, welches das Problem l??st.

Nochmals, die rekursive und iterative Natur unseres Prozesses bedeutet, dass wir in der Zukunft noch viele Male in die Buildphase zur??ckkehren werden.

Es gibt dazu auch noch eine andere Seite und das ist die Reverse Engineering-Seite. Wenn wir ein altes Programm haben, dass wir vielleicht ??berpr??fen wollen, dann k??nnen wir die Dateien nehmen und daraus mit Hilfe des Reverse Engineering ein Design erstellen. Das kann eingesetzt werden, wenn wir versuchen wollen, ein nicht so gut dokumentiertes Programm verstehen zu wollen oder als Schnelleinstieg in die Designarbeit.

Der Prozess des vor- und zur??ckgehens zwischen den ??nderungen im Design gefolgt von einer Codegenerierung und anschliessender ??nderungen im Code gefolgt von einem Reverse Engineering bei jeder ??nderung, die bestm??gliche Perspektive, wird Round-trip Engineering genannt.

7.2. Codegenerierung

Das Ergebnis der Codegenerierung ist das vollst??ndige Programm. Je nach Inhalt des Designs, k??nnen wir auch Unit-Testf??lle generieren.

Um dies tun zu k??nnen, ben??tigen wir das Designmodell, welches die statischen und dynamischen Aspekte des Programmes beinhaltet.

7.2.1. Code aus der statischen Struktur generieren

Es ist ziemlich unkompliziert, diese Generierung durchzuf??hren. Zumindestens so lange wir es f??r eine objektorientierte Sprache tun. Dies sind einige der grundlegenden Regeln:

  • Eine Klasse wird eine Klasse.

    In einigen Zielsprachen (wie Java, C++) werden sie auch Dateien und ??bersetzungseinheiten.

  • Eine Generalisierung wird zu einer Vererbung.

    Wenn die Zielsprache keine Vererbung unterst??tzt und wir dies w??hrend des Design's nicht adressieren, sind einige spezielle Konvertierungen erforderlich, um dieses Problem zu l??sen.

  • Ein Attribut wird zu einer Membervariablen.

  • Eine navigierbare Assoziation wird eine Membervariable.

    Abh??ngig von der Zielsprache, der Zielplattform und der Kardinalit??ten der Assoziation wird dies ein Zeiger, eine Referenz, eine Collection-Klasse, ein Eintrag in einigen Tabellen oder Bitabbildungen (map) sein.

  • Eine nicht abstrakte Operation in einer Klasse wird zu einer Methode.

  • Eine abstrakte Operation in einer Klasse wird zu einer abstrakten Methode.

  • Ein Parameter in einer Operation wird zu einem Parameter in der Methode.

    Bei einfachen Typen (int, boolean) ist dies der Normalfall. In C++ werden diese wahrscheinlich Const-Klassen. In Java kann dies f??r Klassen nicht eingefordert werden.

  • Ein out- oder in/out-Parameter in einer Operation wird zu einem referenzierenden Parameter in der Methode.

    In C++ werden dies referenzierende nicht-konstante Parameter. Bei Javaklassen ist dies der Standard. Einfache Typen (int, boolean) m??ssen in Java in ein Objekt einer korrespondierenden Klasse (Integer, Boolean) konvertiert werden.

  • Die Sichtbarkeit von Attributen, Assoziationen und Operationen werden zu Sichtbarkeit von Membervariablen oder Methoden.

  • Pakete werden Verzeichnisse, Namensr??ume oder beides.

7.2.2. Code aus Interaktionen und Zustandsautomaten generieren

Diese Konvertierung ist nicht so unkompliziert, wie die Konvertierung der statischen Struktur. Sie h??ngt sehr viel mehr von der Zielsprache und der Zielplattform ab.

Generell ist es nur m??glich, das Folgende zu Interaktionen zu sagen:

  • Eine Nachricht wird in einen Funktionsaufruf konvertiert.

    Die Empf??ngerklasse wird eine Funktion mit dem richtigen Namen und der richtigen Signatur haben.

    Die sendende Funktion in der Klasse eines Senders wird einen Funktionsaufruf auf eine Funktion des Empf??ngers aufweisen.

  • Eine asynchrone Nachricht wird entweder eine Nachricht senden, die durch einige andere Thread- oder Funktionsaufrufe verarbeitet werden, die einen neuen Thread starten.

Das Folgende beschreibt einen m??glichen Weg, Zustandsautomaten zu generieren:

  • Ein Zustandsautomat wird in einen Satz von Membervariablen generiert, bei dem sich jede Methode in dieser Klasse auf das entscheidende Verhalten bezieht.

  • Ein Zustand wird zu einem zusammengeh??renden Satz von Werten dieser Membervariablen generiert.

  • Ein Ereignis wird zu einem Aufruf auf eine Membermethode generiert, der den Zustand ??ndern kann.

    Diese Methoden w??rden dann typischerweise eine grosse switch-Anweisung haben, aufgesplittet je nach aktuellem Zustand.

  • Ein W??chter wird, in dem Zweig des richtigen Zustandes, zu einer if-Anweisung in der Ereignis- Membermethode generiert.

  • Eine Transition wird als Zuordnung auf einige Zustandsvariablen generiert.

  • Eine Aktion wird als Funktionsaufruf generiert.

7.3. Code in ArgoUML generieren

7.3.1. Statische Struktur

Der gr??sste Teil der Generierung wird automatisch durch die ausgew??hlten Sprachmodule erledigt. Dateien, die ben??tigt werden, um den aktuellen Code aufzunehmen, werden in Verzeichnis- hierarchien generiert.

7.3.2. Interaktionen und Zustandsdiagramme

Es gibt aktuell keine Unterst??tzung daf??r in ArgoUML, f??r keine Sprache.

7.4. Reverse Engineering

Reverse Engineering wird in zwei F??llen verwendet:

  1. Um die vorher entwickelte Klasse in das aufzubauende Modell zu bekommen.

  2. Um eine UML-Darstellung der vorher entwickelten Klassen zu erhalten, damit man verstehen kann, wie diese arbeiten.

Grunds??tzlich f??hrt dies eine umgekehrte Codegenerierung aus.

7.5. Round-Trip Engineering

Round-Trip Engineering macht es m??glich, die Perspektive w??hrend des Entwurfes zu wechseln. Erstellen Sie einige Klassen in einem Klassendiagramm. Schreiben Sie mit Hilfe Ihres favorisierten Editors etwas Code f??r einige Operationen oder Funktionen. Verschieben Sie die Operationen im Klassendiagramm von einer Klasse in eine andere...

Aktuell wird dies durch ArgoUML f??r keine Sprache unterst??tzt.

Teil 2. Referenz Anwenderschnittstelle

Kapitel 8. Einleitung

Dieses Kapitel beschreibt das gesamte Verhalten der Anwenderschnittstelle. Die Beschreibung der verschiedenen Teile der Komponenten, die Men??zeile, Fenster und verschiedene Diagramme befinden sich in separaten Kapiteln.

8.1. ??berblick ??ber das Fenster

Abbildung 8.1, „??berblick ??ber die ArgoUML-Fenster“ zeigt das Hauptfenster von ArgoUML.

Die Titelzeile des Fensters zeigt die folgenden 4 Informationen, jeweils getrennt voneinander duch einen Bindestrich.

  • Den aktuellen Dateinamen. Ist noch kein Dateiname f??r das Projekt vergeben, dann wird in der Titelzeile „Unbenannt“ angezeigt.

  • Der Name des aktuell aktiven Diagrammes.

  • Der Name „ArgoUML“.

  • Ein Stern (*). Dieses Symbol ist nur vorhanden, wenn die aktuelle Projektdatei „ungesichert“ ist. Z.B. sie wurde ver??ndert, aber noch nicht gespeichert. Mit anderen Worten, fehlt der Stern, dann wurde die aktuelle Datei nicht ver??ndert.

Abbildung 8.1. ??berblick ??ber die ArgoUML-Fenster

??berblick ??ber die ArgoUML-Fenster


Oben am Bildschirm befindet sich eine Men??zeile, die in Kapitel 9, Die Werkzeugzeile beschrieben wird.

Der Fensterrumpf teilt sich in vier Subfenster oder Felder auf. Von oben links im Uhrzeigersinn sind dies der Explorer (siehe Kapitel 11, Der Explorer), das Editierfenster (siehe Kapitel 12, Das Editierfenster), das Detailfenster (siehe Kapitel 13, Der Bereich Details) und das „Zu bearbeiten“-Fenster (siehe Kapitel 14, Der Bereich Zu-Bearbeiten). Alle 4 Fenster haben oben eine Werkzeugleiste (im Detailfenster befindet sie sich unter dem Eigenschafts-Register. Einen ??berblick ??ber die Fenster finden Sie in Abschnitt 8.3, „Generelle Informationen ??ber Fenster“. Im unteren Bereich des Fensters befindet sich eine Statuszeile, die in Abschnitt 8.4, „Die Statuszeile“ beschrieben ist.

8.2. Generelles Verhalten der Maus in ArgoUML

Das in verschiedenen Fenstern von ArgoUML (siehe Abschnitt 8.3, „Generelle Informationen ??ber Fenster“) oder der Men??zeile vorhandene, spezifische Verhalten der Maus wird in den Kapiteln diskutiert, die diese Fenster und die Men??zeile beschreiben. In diesem Abschnitt behandeln wir das Verhalten, das in ArgoUML generell anzutreffen ist.

An verschiedenen Stellen in ArgoUML muss Text direkt editiert werden (zum Beispiel im Randbedingungs-Editor; siehe Abschnitt 13.7.1, „Der Bedingungs-Editor“). Das Verhalten der Maus beim Bearbeiten von Text wird in den nachfolgenden Abschnitten diskutiert.

8.2.1. Maustasten-Terminologie

ArgoUML unterstellt eine Maus mit zwei Tasten. Wir beziehen uns auf die Tasten mit den Bezeichnungen „Taste 1“ und „Taste 2“. Taste 1 ist die linke Taste auf einer Rechtsh??nder-Maus und wird manchmal als Auswahl-Taste bezeichnet. Taste 2 ist die rechte Taste auf einer Rechtsh??nder-Maus und wird manchmal als Einstell--Taste bezeichnet.

Ein einfaches dr??cken und loslassen der Maustaste wird als Klick bezeichnet. Zwei Klicks in schneller Abfolge wird als Doppelklick bezeichnet. Das Bewegen der Maus w??hrend eine Taste gedr??ckt ist, wird als Tastenbewegung bezeichnet, mit einem Startpunkt bei Taste gedr??ckt und einem Endpunkt bei Taste losgelassen.

8.2.2. Taste 1 Klick

Das Klicken auf ein Objekt der Anwenderschnittstelle oder auf ein Modellelement eines Diagrammes kann unterschiedliche Dinge ausl??sen. Der gr????te Teil des Verhaltens ist f??r den Anwender erfahrungsgem???? vollst??ndig intuitiv. Haupts??chlich wegen des hohen Grades an Standardisierung, auch plattform??bergreifend (Macintosh, PC, UNIX,...). ArgoUML befolgt die Java Look and Feel Design- Richtlinien von Sun. Siehe http://java.sun.com/products/jlf/. Daraus folgt, dass das Verhalten von allgemeinen Komponenten der Anwenderschnittstelle in diesem Dokument generell nicht diskutiert wird.

Auf der anderen Seite k??nnen Mausaktionen in einem Diagramm f??r den Anwender nicht so intuitiv erscheinen, da sie spezifisch f??r ArgoUML sind. Deshalb werden sie hier erl??utert. In K??rze: klicken markiert oder aktiviert das Objekt nahe des Mauszeigers und verschiebt den Fokus (z.B. Navigation).

Noch detaillierter: der Taste 1-Klick kann die folgenden Ergebnisse verursachen:

8.2.2.1. Auswahl

Hier wird die Taste 1 dazu verwendet, ein Modellelement (aus einer Liste oder einer Baumstruktur oder aus einem Diagramm) auszuw??hlen (zu markieren), auf das die darauf folgenden Operationen angewendet werden sollen. Mehrere Modellelemente k??nnen durch eine Umschalt- und/oder Strg- Kombination mit der Taste 1 ausgew??hlt werden, siehe Abschnitt 8.2.5, „Umschalt- und Strg- und die Taste 1“. Die Markierung wird immer durch einen eingef??rbten Hintergrund klar angezeigt.

In einem Diagramm werden die markierten Modellelemente durch farbige „Vierecke“ an den Ecken/Enden des Objektes dargestellt. Modellelemente k??nnen auf unterschiedlichen Wegen markiert oder dessen Markierung aufgehoben werden:

  • Taste 1-Klick. Entfernt die Markierung aller Modellelemente und markiert das angeklickte Element.

  • Taste 1-Bewegung. Das Bewegen der Maus mit gedr??ckter Taste erlaubt in einem Diagramm, nicht mit einem Modellelement, das Zeichnen eines Rechteckes um die Modellelemente, die markiert werden, wenn die Taste 1 losgelassen wird.

  • Men??funktionen und Tastenk??rzel. Viele Men??operationen ver??ndern die Markierung als Seiteneffekt. Zum Beispiel beim erstellen eines neuen Diagrammes. Viele Tastenk??rzel f??r Men??operationen ??ndern die Markierung, z. B. Strg-A, die f??r die Funktion Markiere alles steht.

8.2.2.2. Aktivierung

Hier wird die Taste 1 dazu verwendet, die Komponente der Anwenderschnittstelle zu aktivieren. Z.B. eine Schaltfl??che. Das Objekt wird gew??hnlich hervorgehoben, wenn die Maustaste gedr??ckt und dann aktiviert, wenn die Maustaste losgelassen wird. Ein Objekt der Anwenderschnittstelle aktivieren bedeutet, dass dessen Funktion ausgef??hrt wird.

8.2.2.3. Navigation

Hier wird die Taste 1 dazu verwendet, den Fokus von einer Komponente der Anwenderschnittstelle oder eines Modellelementes eines Diagrammes auf ein anderes zu ver??ndern. Dies ist unter dem Begriff Tastaturfokus besser bekannt, weil Tastaturkommandos gew??hnlich auf Modellelemente wirken, die den Fokus haben. Der Fokus wird durch einen (hart sichtbaren) Rahmen um das Modellelement, oder bei einem Texteingabefeld durch einen blinkenden Cursor dargestellt.

8.2.2.4. Generelles Verhalten beim Editieren von Text

Hier wird Taste 1 dazu verwendet, die Stelle innerhalb des Textes zu markieren, an dem die Operation (Text hinzuf??gen und l??schen) ausgef??hrt werden soll.

8.2.3. Taste 1-Doppelklick

Das Verhalten des Taste 1-Doppelklicks variiert in den einzelnen Fenstern und wird in den zugeh??rigen Kapiteln behandelt.

8.2.3.1. Generelles Verhalten beim Editieren von Text

Hier wird der Taste 1-Doppelklick dazu verwendet, ein vollst??ndiges Wort oder eine andere syntaktische Einheit innerhalb des Textes zu markieren. Nachfolgende Operationen (Text einf??gen und l??schen) werden den markierten Text ersetzen.

8.2.4. Taste 1-Bewegung

8.2.4.1. Generelles Verhalten beim Editieren von Text

Hier wird die Taste 1-Bewegung verwendet, um einen Textbereich zu markieren. Nachfolgende Operationen (Text einf??gen und l??schen) werden den markierten Text ersetzen.

8.2.5. Umschalt- und Strg- und die Taste 1

8.2.5.1. Innerhalb von Listen

Dieses Verhalten tritt auf, wo es Listen mit Dingen gibt, die markiert werden d??rfen. Dies schliesst verschiedene Dialogfenster und das „Zu bearbeiten“-Fenster ein, wo es eine Liste von „zu bearbeitenden“ Elementen gibt, die zu markieren sind.

Dort, wo markiert werden muss wird die Umschalttaste mit der Taste 1 verwendet, um die Markierung von der urspr??nglichen Taste 1-Markierung zur aktuellen Position zu erweitern.

Die Strg-Taste und die Taste 1 wird ??hnlich verwendet, um individuelle Elemente der aktuellen Markierung hinzuzuf??gen. Wird Strg-Taste 1 auf einem bereits markierten Element verwendet, wird das Element aus der Markierung entfernt.

[Achtung]Achtung

Anwender von Microsoft Windows k??nnten mit dem Gebrauch des Umschalt-Strg-Klick vertraut sein (z.B. Umschalt- und Strg-Taste w??hrend des klickens gedr??ckt halten), um der existierenden Markierung Sublisten hinzuzuf??gen. ArgoUML unterst??tzt dies nicht. Umschalt-Strg-Klicks wirken wie Strg-Klicks.

8.2.5.2. Generelles Verhalten beim Editieren von Text

In verschiedenen F??llen kann Text in ArgoUML direkt editiert werden (zum Beispiel beim Benennen eines Modellelementes im Eigenschaftsregister oder bei der Eingabe eines UML-Hinweises/ -Kommentares. Hier wird Umschalt-Taste 1 verwendet, um ausgehend von einem vorher markierten Punkt einen Textbereich zu markieren. Nachfolgende Operationen (Text einf??gen und l??schen) werden den markierten Text ersetzen.

8.2.6. Alt Gr mit Taste 1: Verschieben

Wenn Sie die Alt Gr-Taste gedr??ckt halten, w??hrend Sie die Taste 1 in einem Diagramm dr??cken, wird die Bewegung der Maus den Zeichenbereich verschieben. Diese Funktion wird durch den Mauszeiger angezeigt, der zu einer Kreuz mit Pfeilen-Darstellung wechselt.

8.2.7. Strg mit Taste 1: Bedingtes ziehen

Wenn Sie die Strg-Taste herunterdr??cken, w??hrend Sie mit der gedr??ckten Maustaste 1 auf ein Diagramm ziehen, wird die Bewegung des gezogenen Elementes bedingt in eine der acht grunds??tzlichen Richtungen erfolgen: Norden, S??den, Osten, Westen, Nordosten, S??dosten, S??dwesten, Nordwesten.

8.2.8. Taste 2-Aktionen

Taste 2-Aktionen sind alle vom Fenster oder der Men??zeile abh??ngig und werden in den jeweiligen Kapiteln behandelt.

8.2.9. Taste 2-Doppelklick

Taste 2-Aktionen sind alle vom Fenster oder der Men??zeile abh??ngig und werden in den jeweiligen Kapiteln behandelt.

8.2.10. Taste 2-Bewegung

Taste 2-Aktionen sind alle vom Fenster oder der Men??zeile abh??ngig und werden in den jeweiligen Kapiteln behandelt.

8.3. Generelle Informationen ??ber Fenster

Die vier Sub-Fenster des ArgoUML-Hauptfensters werden Fenster genannt. Von oben links im Uhrzeigersinn sind dies der Explorer (siehe Kapitel 11, Der Explorer), das Editierfenster (siehe Kapitel 12, Das Editierfenster), das Detailfenster (siehe Kapitel 13, Der Bereich Details) und das „Zu bearbeiten“-Fenster (siehe Kapitel 14, Der Bereich Zu-Bearbeiten). Oben im Editierfenster gibt es eine Werkzeugleiste.

8.3.1. Fenstergr??sse ver??ndern

Sie k??nnen die Fenstergr??sse ver??ndern, indem Sie die Trennbalken zwischen den Fenstern verschieben. Um diese M??glichkeit anzuzeigen, wechselt die Mausdarstellung, wenn sie sich ??ber den Trennbalken befindet.

Dar??ber hinaus gibt es zwei kleine nach links zeigende Pfeile in den vertikalen Trennbalken, einer im oberen Bereich des Trennbalkens, zwischen dem Explorer und dem Editierfenster und einen im oberen Bereich des vertikalen Trennbalkens zwischen dem „Zu bearbeiten“- und dem Detailfenster. Ein Taste 1-Klick auf den ersten von ihnen erweitert das Editierfenster bis zur vollen Breite des Fensters, der Taste 1-Klick auf den zweiten erweitert das Detailfenster auf die volle Breite des Fensters.

Es gibt ebenso kleine nach unten gerichtete Pfeile in den horizontalen Trennbalken, jeweils am linken Ende. Klicken auf diese Pfeile wird den Explorer und das Editierfenster auf die volle H??he des Fensters erweitern.

Durch die Verwendung des oberen Pfeile der vertikalen Trennbalken und des Pfeiles des horizontalen Trennbalkens ist es m??glich, das Editierfenster auf das gesamte Fenster zu erweitern.

Die urspr??ngliche Konfiguration kann durch erneutes Klicken auf diese Pfeile wiederhergestellt werden, die sich jetzt am Rand des Fensters befinden.

8.4. Die Statuszeile

Die Statuszeile befindet sich am unteren Rand des ArgoUML-Fensters und wird dazu verwendet, kurzes Hinweisnachrichten anzuzeigen. Normalerweise sind diese Nachrichten selbsterkl??rend. Sie wird z. B. f??r die Anzeige von Parsing-Fehlermeldungen verwendet, wenn ein in ein Diagramm eingegebener Text nicht interpretiert werden kann.

Kapitel 9. Die Werkzeugzeile

9.1. Dateioperationen

Diese Schaltfl??chen haben wie ihre Gegenst??cke im Men?? Datei identische Funktionen.

9.2. Editieroperationen

Diese Schaltfl??chen haben mit Ihren Gegenst??cken im Men?? Bearbeiten identische Funktionen.

9.3. Ansicht-Operationen

Die Schaltfl??che Suche... hat das identische Verhalten wie das Gegenst??ck im Men?? Ansicht. Die Schaltfl??che Zoom ist die luxeri??ser als die Version im Men?? Ansicht.

  • Suche... Siehe vollst??ndige Beschreibung unter Abschnitt 10.5.2, „ Suchen... “.

  • Zoom Dies ist eine andere Version als die im Men?? Ansicht in Abschnitt 10.5.3, „Zoom“ beschriebene Fassung. Das Klicken mit der Taste 1 auf das Zoom-Symbol ??ffnet ein Fenster wie im Bild unten dargestellt.

    Abbildung 9.1. Der Zoom-Schieberegler in der Werkzeugleiste

    Der Zoom-Schieberegler in der Werkzeugleiste


    Wenn das Fenster ge??ffnet ist, sind folgende Aktionen m??glich:

    • Das Klicken mit der Taste 1 auf den „Schieberegler“ gefolgt von der Bewegung der Taste 1 wird den Zoomfaktor einstellen.

    • Das Klicken mit der Taste 1 auf die angezeigte Prozentzahl erlaubt das direkte Editieren des vorgegebenen Zoomfaktors (in Prozent) mit der Tastatur. Ein Doppelklick auf den angezeigten Wert markiert den vollst??ndigen Eintrag f??r ein leichtes ??berschreiben.

    • Das Klicken mit der Taste 1 ober- oder unterhalb des Schiebereglers erh??ht oder verringert den Zoomfaktor um 1%. Verwenden Sie diese Funktion, um die Feinjustierung des Prozentsatzes vorzunehmen.

    • Das Klicken mit der Taste 1 oder mit der Taste 2 auf das Zoom-Werkzeug oder ausserhalb des Schiebereglerfensters schliesst das Fenster.

    • Mit Hilfe der Tastatur kann der Zoom-Schieberegler wie folgt bedient werden: Wenn das Zoom- Symbol in der Werkzeugleiste den Fokus hat (wird durch einen d??nnen blauen Rahmen dargestellt) und dr??cken der Leertaste ??ffnet sich das Zoom- Schiebereglerfenster. Verwenden Sie die Pfeil-Tasten, um den Prozentsatz 1 durch 1 zu erh??hen bzw. zu verringern. Verwenden Sie Umschalt-Tab, um den Fokus auf das Eingabefeld Prozentsatz zu bringen, in dem sie den vorgegebenen Wert direkt editieren k??nnen. Dr??cken der Taste Return aktiviert den ge??nderten Wert. Wenn der „Schieberegler“ den Fokus hat, dr??cken der Taste Bild nach oben/ Bild nach unten erh??ht/verringert den Prozentsatz um 50. Dr??cken der Taste Pos 1 setzt den Prozentsatz auf 500% und Ende auf 0%.

9.4. Neues Diagramm

Diese Schaltfl??chen haben wie Ihre Gegenst??cke im Men?? Neues Diagramm identische Funktionen.

Kapitel 10. Die Men??zeile

10.1. Einleitung

Ein wichtiges Prinzip hinter ArgoUML ist es, dass Aktionen auf jedem Weg, den der Anwender f??r g??nstig h??lt, aufgerufen werden k??nnen. Im Ergebnis k??nnen viele (aber nicht alle) Aktionen ??ber das Men?? aber auch ??ber andere Wege in ArgoUML ausgef??hrt werden.

Eine Anzahl gemeinsamer Men??eintr??ge ist auch ??ber Tastaturk??rzel verf??gbar.

Es ist auch m??glich, das Men?? von der Tastatur aus zu bedienen. Jede Ebene eines Men??s wird durch einen Buchstaben (im Men?? unterstrichen dargestellt oder durch Eingabe des Namens im Moment des dr??ckens der ALT-Taste) identifiziert. Diese Buchstabensequenz, w??hrend die ALT-Taste gedr??ckt wird, w??hlt den Eintrag aus.

Das Folgende ist eine Erl??uterung, wie die Men??elemente angeordnet sind.

  • Das Men?? Datei enth??lt Operationen, die auf das ganze Projekt/Datei wirken. Alle Elemente in diesem Men?? k??nnen so begr??ndet werden.

  • Das Men?? Bearbeiten ist haupts??chlich daf??r gedacht, das Modell zu editieren oder den Inhalt eines Diagrammes zu ver??ndern. Es enth??lt auch Funktionen, die das Editieren erst erm??glichen, wie z.B. das Markieren. Dieses Men?? ist nicht f??r Diagramm-Layout-Funktionen gedacht. Die meisten Funktionen hier, tun irgendetwas mit dem markierten Modellelement und Diagramm. Die Elemente „Konfiguriere Perspektiven...“ und „Einstellungen...“ sind ein bi??chen unterschiedlich, da sie einstellen, wie ArgoUML arbeitet - aber sie geh??ren nicht in das Dateimen??, da ihre Einstellungen nicht im Projekt gespeichert werden.

  • Das Men?? Ansicht ist f??r Funktionen, die weder das Modell noch das Diagrammlayout ver??ndern, sondern nur die Art und Weise wie das Diagramm angezeigt wird. Ein gutes Beispiel ist „Zoom“. Auch navigierende Funktionen befinden sich hier, z.B. „Suchen“ und „Gehezu Diagramm...“. Alle ??nderungen der Einstellungen dieses Men??s wirken sich auf alle Diagramme aus (z.B. Zoom).

  • Das Men?? Neues Diagramm enth??lt alle m??glichen Diagramme, die erstellt werden k??nnen. Dies Funktionen sind kontextabh??nig, da mit dem markierten Modellelement arbeiten.

  • Das Men?? Anordnen erlaubt Layout??nderungen im aktuellen Diagramm, was nicht das selbe ist wie die Elemente im Men?? Ansicht. Die Funktionen k??nnen nicht das UML-Modell ??ndern.

  • Das Men?? Generieren ist f??r die Codegenerierung. Die Funktionen hier wirken entweder auf das markierte Modellelement oder auf das ganze Projekt.

  • Das Men?? Kritiken ist speziell f??r die Einstellungen der Kritiken, die f??r alle Projekte gelten.

  • Das Men?? Werkzeuge ist aktuell leer. Wurden Plugins installiert, erscheinen deren Funktionen an dieser Stelle.

  • Das Men?? Hilfe enth??lt die ??blichen „Systeminformationen“ und „??ber ArgoUML“.

10.2. Das Mausverhalten in der Men??zeile

Das generelle Verhalten der Maus und die Bezeichnung der Tasten ist umfassend im Kapitel Anwenderschnittstelle ausgef??hrt (siehe Abschnitt 8.2, „Generelles Verhalten der Maus in ArgoUML“). Es gibt kein ArgoUML-spezifisches Verhalten f??r Men??s.

10.3. Das Men?? Datei

Dieses sind Aktionen, welche die Ein- und Ausgabe betreffen und das umfassende Management von Projekten sowie das ArgoUML-System.

10.3.1. Neu

Tastenk??rzel Strg-N.

Dies initialisiert ein neues Projekt in ArgoUML. Das Projekt wird ohne Name erstellt. Es enth??lt ein (oberste Ebene) unbenanntesModell bezeichnetes Modell und zwei leere Diagramme: Ein Klassendiagramm und ein Anwendungsfalldiagramm.

[Achtung]Achtung

unbenanntesModell ist kein Modellname, der der Konvention entspricht (die meisten Prozesse erwarten, dass Modelle aus Kleinbuchstaben gebildet werden sollten). ArgoUML erlaubt es Ihnen Gro??- und Kleinbuchstaben zu verwenden, aber eine Kritik wird Sie warnen, dass dies nicht der Konvention entspricht. Siehe Abschnitt 16.2, „Das Modell“.

Wurde das Modell ge??ndert (was durch den „*“ in der Titelzeile des ArgoUML-Fensters angezeigt wird), ist die Aktivierung der Funktion „Neu“ potentiell nicht die Absicht des Anwenders, da sie die ??nderungen l??schen w??rde. Aus diesem Grund erscheint ein Best??tigungsdialog, der es dem Anwender erlaubt, zuerst seine Arbeit zu speichern oder die Operation vollst??ndig r??ckg??ngig zu machen.

Abbildung 10.1. Der Best??tigungsdialog f??r Neu.

Der Best??tigungsdialog f??r Neu.


10.3.2. Projekt ??ffnen...

Tastenk??rzel Strg-O.

Diese Funktion ??ffnet ein existierendes Projekt aus einer Datei. Die Auswahl dieser Men??option wird einen Dateiauswahldialog ??ffnen (siehe Abbildung 10.2, „ Der Dateiauswahldialog f??r Projekt ??ffnen.... “).

Abbildung 10.2. Der Dateiauswahldialog f??r Projekt ??ffnen....

Der Dateiauswahldialog f??r Projekt ??ffnen....


Der Hauptbereich des Dialoges ist ein Textbereich mit einer Liste aller Verzeichnisse und Dateien im aktuell ausgew??hlten Verzeichnis, welches mit dem aktuellen Filter ??bereinstimmt (siehe nachfolgend).

Das Navigieren im Verzeichnisbaum ist durch das Markieren eines Verzeichnisses in der DropDown-Auswahl oben im Dialog m??glich. Im Baum tiefer navigieren kann durch Doppelklicken auf das im Hauptbereich angezeigte Verzeichnis mit der Taste 1 bewirkt werden.

Im unteren Teil des Dialoges befindet sich ein Textfeld mit der Bezeichnung Dateiname: f??r den Namen der Datei, die ge??ffnet werden soll. Der Dateiname kann hier direkt eingegeben oder aus der obigen Verzeichnisliste mit Hilfe des Taste 1-Klick ausgew??hlt werden.

Darunter befindet sich eine mit Dateityp: bezeichnete DropDown-Auswahl, um einen Filter f??r die Dateien auszuw??hlen, die in der Verzeichnisliste angezeigt werden sollen. Nur die Dateien werden angezeigt, die mit diesem Filter ??bereinstimmen. Die verf??gbaren Filter sind nachstehend aufgef??hrt. Der Standardfilter ist der erste, der alle verf??gbaren Formate kombiniert.

  • ArgoUML-Datei (*.zargo, *.uml, *.xmi, *.xml, *.zip)

  • ArgoUML-komprimierte Projektdatei (*.zargo)

  • ArgoUML-Projektdatei (*.uml)

  • XML Metadata Interchange (*.xmi)

  • XML Metadata Interchange (*.xml)

  • XMI komprimierte Projektdatei (*.zip)

10.3.3. Projekt speichern

Tastenk??rzel Strg-S.

Speichert das Projekt unter seinem aktuellen Dateinamen. Benutzen Sie Projekt speichern unter..., um das Projekt in einer anderen Datei zu speichern. Wurde kein Dateiname vergeben ( z.B. nach Neu), dann arbeitet diese Funktion genau wie Projekt speichern unter....

[Anmerkung]Anmerkung

Unter bestimmten Umst??nden gibt es nichts zu speichern. Dann ist diese Men??option deaktiviert. Z.B. wenn der Anwender das geladene Projekt nicht ver??ndert hat. Die Pr??senz eines „*“ in der Titelzeile von ArgoUML zeigt an, dass das aktuelle Projekt „ungesichert“ ist (ge??ndert wurde) und gespeichert werden kann.

10.3.4. Projekt speichern unter...

??ffnet einen Dialog, der es Ihnen erlaubt, das Projekt unter einem anderen Dateinamen zu speichern (oder das erste Mal einen Dateinamen zu spezifizieren, wenn das Projekt ein neues Projekt ist).

Der Dialog ist weitgehend identisch mit dem f??r Projekt ??ffnen (siehe Abbildung 10.2, „ Der Dateiauswahldialog f??r Projekt ??ffnen.... “). Die Dateinamenerweiterung wird automatisch gesetzt.

10.3.5. Projekt speichern r??ckg??ngig machen

Diese Men??option erlaubt es Ihnen, alle vorher vorgenommen ??nderungen r??ckg??ngig zu machen und die zuletzt gespeicherte Version des aktuellen Projektes zur??ckzuladen. Sie arbeitet ein bisschen wie die R??ckg??ngig-Funktion, speichert aber nur die ??nderungen zur??ck, die seit dem letzten Speichern der Datei vorgenommen wurden.

Diese Men??option ist deaktiviert, bis das aktuelle Projekt gespeichert oder vorher geladen und ge??ndert wurde.

Wenn diese Men??option aktiviert ist, ??ffnet sich ein kleiner Best??tigungsdialog, wie im nachfolgenden Bild gezeigt. Diese Warnung, dass alle vorher vorgenommenen ??nderungen r??ckg??ngig gemacht werden ist notwendig, da diese Aktion nicht mehr r??ckg??ngig gemacht werden kann. Die Auswahl Nein bricht die ganze Aktion ab. Das ist dann so, als h??tten Sie die Men??option niemals ausgew??hlt. Die Auswahl Ja l??dt die zuletzt gespeicherte Datei zur??ck.

Abbildung 10.3. Der Warndialog f??r Projekt speichern r??ckg??ngig machen.

Der Warndialog f??r Projekt speichern r??ckg??ngig machen.


10.3.6. XMI importieren...

Diese Men??option erlaubt es Ihnen, ein UML 1.3 oder 1.4-Modell zu laden, welches durch ein anderes Tool als XMI-Datei, entsprechend dem XMI-V1.0-, V1.1- oder V1.2-Standard exportiert wurde. Die Erweiterung einer solchen Datei sollte .xmi lauten.

Wenn das Modell ge??ndert wurde (angezeigt durch einen „* “ in der Titelzeile von ArgoUML), dann ist die Aktivierung der „XMI importieren...“-Funktion wahrscheinlich nicht die Absicht des Anwenders, da dies die ??nderungen l??scht. Aus diesem Grund erscheint die Dialog, der es dem Anwender erlaubt, zuerst seine Arbeit zu speichern oder die Operation vollst??ndig abzubrechen.

Abbildung 10.4. Der Best??tigungsdialog f??r XMI importieren....

Der Best??tigungsdialog f??r XMI importieren....


Ist dieses Men?? aktiviert erscheint die Standarddateiauswahl, siehe Abbildung 10.5, „Der Dialog f??r XMI importieren....“. Beachten Sie die Tatsache, dass diese Datei nur das Modell beinhaltet, nicht irgendein Diagrammlayout. Aus diesem Grund wird das neue Projekt keinerlei Diagramme enthalten.

Abbildung 10.5. Der Dialog f??r XMI importieren....

Der Dialog f??r XMI importieren....


10.3.7. Exportiere als XMI...

Dieses Men?? erlaubt es Ihnen, die vollst??ndige Struktur eines UML 1.4-Modelles als XMI-Datei entsprechend dem XMI V2.1-Standard zu speichern. Beachten Sie die Tatsache, dass diese Datei nur das Modell enthalten wird, nicht irgendein Diagrammlayout. Aus diesem Grund gehen die Diagramme verloren, wenn die XMI-Datei ??ber das Men?? Datei - Projekt ??ffnen... erneut geladen wird.

Ist das Men?? aktiviert, erscheint die Standarddateiauswahl, siehe Abbildung 10.6, „Der Dialog f??r Exportiere als XMI....“.

Abbildung 10.6. Der Dialog f??r Exportiere als XMI....

Der Dialog f??r Exportiere als XMI....


10.3.8. Quellcode importieren...

Eine sehr leistungsf??hige Eigenschaft von ArgoUML ist es, das es Java-Code „reengineeren“ kann, um ein Klassendiagramm zu erhalten. Dieser Untermen??eintrag spezifiert den Java-Code, der zum reengineeren importiert werden soll.

Der Dialog ist ??hnlich dem f??r Projekt ??ffnen... (siehe Abbildung 10.2, „ Der Dateiauswahldialog f??r Projekt ??ffnen.... “), allerdings mit zwei zus??tzlichen Registern neben der Verzeichnisliste, wie in Abbildung 10.7, „Der Dateiauswahldialog f??r Quellcode importieren....“ gezeigt).

Abbildung 10.7. Der Dateiauswahldialog f??r Quellcode importieren....

Der Dateiauswahldialog f??r Quellcode importieren....


Diese Felder sind im Verhalten die gleichen wie in Projekt ??ffnen... (siehe Abschnitt 10.3.2, „ Projekt ??ffnen... “).

In der N??he des Dateifilters „Alle Dateien“ gibt es den Standardfilter „Java-Quelldatei (*.java).

Das erste der beiden Register ist mit Allgemeines bezeichnet und durch einen Taste 1-Klick auf das Register ausgew??hlt. Es enth??lt eine Auswahlbox f??r die Auswahl der Sprache ( in V0.18 von ArgoUML kann nur Java ausgew??hlt werden) und der folgenden Wahlm??glichkeiten:

  • Verzeichnisse rekursiv absteigend . Wenn markiert (Standard), dann wird das Reengineering auch die Unterverzeichnisse nach Javadateien durchsuchen. Wenn nicht, wird die Suche auf das aktuelle Verzeichnis eingeschr??nkt.

  • Nur ge??nderte/neue Dateien . Wenn markiert (Standard), dann werden nur ge??nderte oder neue Dateien importiert. Wenn nicht, werden alle Klassen ersetzt.

  • Erzeuge Diagramme aus dem importierten Code . Wenn Sie dies deaktivieren, werden keine Diagramme erzeugt. Z.B., alle Daten werden nur im Explorer sichtbar sein.

  • Minimiere Klassensymbole in den Diagrammen . Wenn aktiviert, dann werden die Attribut- und Operations- Trenner in den Klassen des generierten Klassendiagrammes nicht angezeigt. Achtung: Dieses Element ist standardm????ig markiert und wird durch viele Anwender ??bersehen, die dann von dem Ergebnis ??berrascht sind.

  • Automatisches Diagramm-Layout ausf??hren. Wenn markiert, dann wird ArgoUML sein Bestes tun, um die generierten Diagramme automatisch zu formatieren. Wenn nicht, dann werden alle Elemente in die linke obere Ecke des Diagrammes plaziert.

  • Importdetails: Nur Klassifizierungen / Klassifizierungen und Eigenschaften / Vollst??ndiger Import . Das letztere ist der Standard.

  • Codierung der Eingabedatei:. Der Wert Cp1252 ist sehr oft der Standard. Diese Zeichenkette repr??sentiert den codierten Zeichensatz- Bezeichnung (CCSID).

Der zweiter der beiden Register ist mit Java bezeichnet und wird durch einen Taste 1-Klick auf das Register ausgew??hlt. Es enth??lt zwei Paar Optionsauswahlfelder.

  • Die erste Optionsauswahl erlaubt die Auswahl zwischen der Modellierung der Attribute von Javaklassen als UML-Attribute ( der Standard) oder als UML-Assoziationen auf die Klasse.

  • Die zweite Optionsauswahl erlaubt die Auswahl zwischen der Modellierung von arrays als eigenst??ndige neue Datentypen (der Standard) oder als Basisdatentyp mit Kardinalit??t.

10.3.9. Seite einrichten...

Diese Option ??ffnet den Standarddialog des Betriebssystems, um die Drucker-Papiergr??sse, die Ausrichtung und andere Optionen einzustellen.

10.3.10. Drucken...

Tastenk??rzel Strg-P.

Diese Option ??ffent den Standarddialog des Betriebssystems, der es Ihnen erlaubt, das aktuelle Diagramm auszudrucken.

In einigen F??llen erscheint der Dialog Abbildung 10.8, „Der Dialog: Das Diagramm ??berschreiten die Seitengr??sse.“, wenn der Druckvorgang gestartet wurde. Die Auswahl der Schaltfl??che „An Seite anpassen“ druckt das gesamte Diagramm auf eine Seite, indem es das Diagramm herunterskaliert. Dies kann dazu f??hren, dass der gesamte Text bei grossen Diagrammen zu klein zum lesen wird. Aber es ist ein schneller und einfacher Weg einen verwendbaren Ausdruck zu bekommen. Die Auswahl der Option „Mehrere Seiten“ druckt unskaliert, indem es das Diagramm in so viele Einzelteile aufteilt, wie n??tig. Dr??cken der Schliessen-Schaltfl??che f??hrt zum Schliessen des Dialoges.

Abbildung 10.8. Der Dialog: Das Diagramm ??berschreiten die Seitengr??sse.

Der Dialog: Das Diagramm ??berschreiten die Seitengr??sse.


[Warnung]Warnung

Wenn das aktuelle Diagramm keine markierten Modellelemente enth??lt, dann wird das gesamte Diagramm gedruckt. Jedoch, wenn ein oder mehrere Modellelemente markiert sind, wird nur der Bereich ausgedruckt den diese umfassen! Wenn die Skalierung ausgew??hlt ist (durch die Wahl der Option „An Seite anpassen“ im oben beschriebenen Dialog), dann wird die Skalierung nur auf Basis der markierten Modellelemente ausgef??hrt. Ist keine Skalierung ausgew??hlt (oder nicht notwendig), dann werden alle Seiten ausgedruckt, die ein markiertes Modellelement beinhalten.

10.3.11. Grafik exportieren...

Diese Men??option ??ffnet einen Dialog, der es erlaubt, das aktuell markierte Diagramm (im Editierfenster) in einem von einer Vielzahl von Grafikformaten zu speichern.

Der Dialog ist mit dem in Projekt ??ffnen verwendeten identisch (siehe Abbildung 10.2, „ Der Dateiauswahldialog f??r Projekt ??ffnen.... “), mit Ausnahme des Feldes Dateityp:. Der ausgew??hlte Dateityp bestimmt das beim Speichern verwendete Grafikformat. Der Dateiname wird automatisch mit der entsprechenden Dateierweiterung erweitert ( wenn er nicht bereits eingegeben wurde). Auf Basis des Diagrammnamens wird ein Standarddateiname generiert.

Die verf??gbaren Grafiktypen sind:

  • GIF-Bild (*.gif)

  • Encapsulated Postscript-Datei (*.eps)

  • PNG-Bild (*.png)

  • Postscript-Datei (*.ps)

  • Scalable Vector Graphics-Datei (*.svg)

Das standardm????ig ausgew??hlte Grafikformat wird im Dialog unter der Men??option Bearbeiten - Einstellungen... eingestellt.

10.3.12. Alle Grafiken exportieren...

Diese Men??option ??ffnet einen Dialog, um ein Verzeichnis auszuw??hlen. In dieses Verzeichnis wird f??r alle Diagramme des aktuellen Projektes je eine Grafikdatei generiert.

Die Namen der Dateien werden aus den Diagrammnamen gebildet. Das verwendete Grafikformat wurde im Bearbeiten-Men?? (siehe Abschnitt 10.4.5, „ Einstellungen... “) eingestellt.

10.3.13. Notation

Dieses Untermen?? pr??sentiert eine Auswahl von Optionsschaltfl??chen f??r die Notation, z.B. die Sprache, in der alle textuellen Erl??uterungen in den Diagrammen dargestellt werden.

Diese Eigenschaft definiert die Notation des Projektes.

Es gibt 2 Wege, die Notation einzustellen:

  • Im Bearbeiten-Men??, siehe Abschnitt 10.4.5.7, „Register Notation“ im Notationsregister des Dialoges Einstellungen, der die Standard- Notation f??r neue Projekte definiert. Diese Einstellung wird in der Datei argouml.user.properties im Verzeichnis .argouml des User-Home- Verzeichnisses gespeichert.

  • Im Datei-Men??, Men??element Notation. Dieses bestimmt, wie alle textuellen Erl??uterungen in den Diagrammen des aktuellen Projektes dargestellt werden. Diese Einstellung wird in der Projektdatei gespeichert.

Die folgenden 2 Notationen werden in ArgoUML erzeugt:

  • UML 1.4. Verwendet die UML-Notation als Standardnotation f??r jedes Modellelement in jedem Diagramm.

  • Java. Verwendet die Java-Notation als Standardnotation f??r jedes Modellelement in jedem Diagramm.

Die folgenden Optionen sind nur verf??gbar, wenn das entsprechende Plugin installiert wurde.

  • Cpp.

  • CSharp.

  • PHP.

Neben UML ist in V0.22 von ArgoUML nur Java teilweise implementiert.

10.3.14. Projekteinstellungen

In dieser Men??option erscheint ein Dialog, der es dem Anwender erlaubt, verschiedene Optionen des aktuell geladenen Projektes einzustellen.

Alle Einstellungen in diesem Dialog werden in der Projektdatei, zusammen mit dem Modell, gespeichert.

Abbildung 10.9. Der Dialog Projekteinstellungen: Das Register Benutzer.

Der Dialog Projekteinstellungen: Das Register Benutzer.


Im Register Benutzer k??nnen Sie folgende Felder einstellen:

  • Das erste Feld enth??lt den Namen des Autors oder den Verantwortlichen f??r das aktuelle Projekt. Standardm????ig wird der Name und die E-Mailadresse des Erstellers eingef??gt, so dass Sie dies wahrscheinlich niemals bearbeiten m??ssen. Aber, es ist m??glich.

  • Das Feld Projektbeschreibung kann einen beliebigen Text enthalten, den Sie zur Beschreibung des Projektes ben??tigen. Standardm????ig ist dieses Feld leer.

  • Das Feld "Gespeichert mit ArgUML" gibt die Version von ArgoUML an, mit der dieses Projekt gespeichert wurde (zum letzten Mal gespeichert wurde). Dies kann hilfreich sein, wenn mehrere Designer mit unterschiedlichen Versionen von ArgoUML arbeiten, die nicht immer r??ckw??rtskompatibel sind.

Abbildung 10.10. Der Dialog Projekteinstellungen – Das Register Profile.

Der Dialog Projekteinstellungen – Das Register Profile.


Im Register Profile k??nnen Sie die folgenden Einstellungen ??ndern:

  • Den Typ der “Stereotype Darstellung” f??r das Projekt; diese kann als Text, mit kleinen oder gro??en Symbolen erscheinen.

  • Die im Projekt konfigurierten UML-Profile – die Modellelemente dieser UML-Profile k??nnen im Projekt referenziert werden.

Abbildung 10.11. Der Dialog Projekteinstellungen: – Das Register Notationen.

Der Dialog Projekteinstellungen: – Das Register Notationen.


Im Register Notationen k??nnen Sie die folgenden Felder einstellen:

  • Das erste Feld ist ein Dialogfeld, das die Auswahl der im Projekt verwendeten Notation erlaubt. Standardm????ig werden UML und Java aufgelistet. Es k??nnen aber auch andere Sprachen per Plugins hinzugef??gt werden. Weitere Erl??uterungen entnehmen Sie dem Kapitel ??ber die Notation: Abschnitt 12.11, „Notation“.

  • Franz??sische Anf??hrungszeichen (« ») f??r Stereotypen (standarm????ig leer). Standardm????ig verwendet ArgoUML Paare von kleiner als und gr????er als (<< >>) Zeichen f??r Stereotypen. Wird dieses K??stchen markiert, werden die Stereotypen in den Diagrammen in richtigen franz??sische Anf??hrungszeichen gestellt (« »).

    Diese Eigenschaft wurde ArgoUML vermutlich hinzugef??gt, weil franz??sische Anf??hrungszeichen durch die verschiedensten Schriften nur sehr schlecht unterst??tzt werden und wenn Sie vorhanden sind, dann sind sie sehr klein und schlecht sichtbar.

  • Sichtbarkeit anzeigen (standardm????ig leer). Ist dies markiert, dann wird ArgoUML die Sichtbarkeitssymbole vor jedem z.B. Attribut im Diagramm anzeigen. In der UML-Notation ist dies das "+" f??r public, "-" f??r private, "#" f??r protected und "~" f??r Paket. F??r ein Attribut k??nnte es z.B. anzeigen: +neuesAttr : int .

  • Kardinalit??t anzeigen (standardm????ig leer). Ist dies markiert, wird ArgoUML die Kardinalit??t von z.B. Attributen im Diagramm anzeigen. In der UML-Notation wird die Kardinalit??t zwischen [] angezeigt. Wie z.B.: +neuesAttr [0..*] : int. Diese Einstellung hat keinen Einfluss auf die Anzeige der Kardinalit??t an Assoziationsenden.

  • Anfangswerte anzeigen (standardm????ig leer). Ist dies markiert, wird ArgoUML den Anfangswert eines z.B. Attributes im Diagramm anzeigen. In der UML-Notation wird der Anfangswert wie folgt dargestellt: +neuesAttr : int = 1.

  • Eigenschaften anzeigen (standardm????ig leer). Ist dies markiert, wird ArgoUML die Eigenschaften zwischen geschweiften Klammern {} anzeigen. F??r ein Attribut k??nnte die Anzeige wie folgt aussehen: +neuesAttr : int { eingefroren }.

  • Typen und Parameter anzeigen (standardm????ig markiert). Wenn dieses Markierfeld nicht markiert ist, werden die Attribute in Klassen ohne Typ dargestellt und Operationen ohne Parameter angezeigt. Diese Eigenschaft kann w??hrend der Analysephase Ihres Projektes n??tzlich sein. Sind alle Markierfelder im Register Notation nicht markiert, dann zeigt ArgoUML z.B. f??r ein Attribut folgendes an: neueOperation().

  • Stereotypen im Explorer anzeigen (standardm????ig leer). Ist dies markiert, dann wird ArgoUML die Stereotypen in der N??he des Modellelementsymboles im Explorer anzeigen. Z.B. in der Baumstruktur auf der linken Seite.

  • Standard-Schattenbreite (standardm????ig auf 1 eingestellt). ArgoUML ist in der Lage, aus ??sthetischen Gr??nden alle Elemente in einem Diagramm mit einem Schatten zu zeichnen. Verwenden Sie diese Einstellung, um die Gr????e des Schattens einzustellen. Diese Einstellung wird beim Erstellen des Modellelementes verwendet. Das Register "Darstellung" im Detailfenster erlaubt es Ihnen, den Schatten nach dem Erstellen je Modellelement einzustellen. ArgoUML V0.22 beh??lt diese ??nderungen allerdings nach dem Speichern und Laden nicht.

Abbildung 10.12. Der Dialog Projekteinstellungen – Das Register Diagramm-Darstellung.

Der Dialog Projekteinstellungen – Das Register Diagramm-Darstellung.


Im Register Diagramm-Darstellung k??nnen Sie die im Diagramm verwendete Schriftart ??ndern.

10.3.15. Am h??ufigsten verwendete Dateien

ArgoUML erinnert sich an die am h??ufigsten gespeicherten Dateien und listet sie an dieser Stelle auf, um Sie in die Lage zu versetzen, diese auf einfache Weise zu laden.

Die maximale Anzahl von Dateien, die hier gelistet werden k??nnen, kann im Men?? Bearbeiten -> Einstellungen... eingestellt werden. Die Liste der Dateien wird in der Datei argo.user.properties im Homeverzeichnis des Benutzers gespeichert.

10.3.16. Beenden

Tastenk??rzel Alt-F4.

Diese Men??option schliesst ArgoUML. Wenn Sie ein Projekt mit ungesicherten ??nderungen haben, erscheint eine Warnmeldung, die Sie fragt, ob Sie diese speichern wollen. Siehe Abbildung 10.13, „Der Dialog ??nderungen speichern.“. Die Optionen sind:

  • Ja (das Projekt speichern und ArgoUML beenden);

  • Nein (das Projekt nicht speichern, aber ArgoUML beenden); und

  • Abbrechen (das Projekt nicht speichern und ArgoUML nicht beenden).

  • Der Dialog kann auch durch Klicken auf die Schliessen-Schaltfl??che im Fensterrand geschlossen werden. Dies hat den gleichen Effekt wie die Auswahl "Abbrechen".

Abbildung 10.13. Der Dialog ??nderungen speichern.

Der Dialog ??nderungen speichern.


10.4. Das Men?? Bearbeiten

Dieses Men?? enth??lt die Unterst??tzung f??r das Markieren von Modellelemente im Editierfenster; das Entfernen von Modellelementen aus Diagrammen und dem Modell und die Steuerung der Benutzereinstellungen.

10.4.1. Markieren

Dieses Untermen?? unterst??tzt das Markieren von Elementen im Men?? Bearbeiten. Es hat folgende Eintr??ge:

  • Alle Elemente (Tastenk??rzel Strg-A). Markiert alle Modellelemente im aktuellen Fenster oder im aktuellen Feld. Das genaue Verhalten h??ngt vom aktuellen Fenster ab (z.B. das Letzte, in das Sie hineingeklickt haben); Explorerfenster, Editierfenster, "Zu Bearbeiten"-Fenster, Detailfenster. Eine Regel ist auf alle F??lle anwendbar: die Markierung im Diagramm (Editierfenster) und im Explorer sind immer synchronisiert.

    Wenn das Editierfenster das aktuelle Fenster ist: Zuerst werden die Markierungen im Explorer und im aktuellen Diagramm entfernt und dann wird alles im Diagramm befindliche markiert (und wenn die gleichen Elemente im Explorer erscheinen, werden diese ebenfalls markiert, weil dies immer synchronisiert ist).

    Wenn der Explorer das aktuelle Fenster ist: Alle sichtbaren Elemente im Explorer sind markiert und unsichtbare Elemente sind nicht markiert.

    Wenn das "Zu Bearbeiten"-Fenster das aktuelle Fenster ist: Alle sichtbaren Elemente im "Zu Bearbeiten"-Fenster sind markiert, alle unsichtbaren Elemente sind nicht markiert. Tats??chlich funktioniert dies genauso wie im Explorerfenster, weil beides Baumstrukturen sind.

    Wenn das Detailfenster das aktuelle Fenster ist: Die Funktion arbeitet nur, wenn sich der Cursor in einem bestimmten Feld befindet, in dem das Markieren m??glich ist. Z.B. in einem Namensfeld. In so einem Fall erweitert die Funktion Alle Elemente markieren die aktuelle Markierung auf den gesamten Feldinhalt.

  • Vorheriges Element. ArgoUML merkt sich einen Satz von Modellelementen, den Sie w??hrend der Navigation durch das Modell markiert haben. Diese Men??option bringt Sie zu dem zuvor markierten Modellelement. Gibt es keine zuvor markierten Modellelemente, dann ist diese Men??option deaktiviert.

  • N??chstes Element. ArgoUML merkt sich einen Satz von Modellelementen, den Sie w??hrend der Navigation durch das Modell markiert haben. Diese Men??option bringt Sie zum n??chsten markierten Modellelement (nachdem Sie die Men??option Zur??ck verwendet haben). Gibt es keine n??chsten Modellelemente, dann ist diese Men??option deaktiviert.

  • Umkehren. Diese Men??option kehrt die aktuelle Markierung im aktuellen Fenster um. Genauer: Alles, was markiert ist wird demarkiert und alles was innerhalb des aktuellen Fensters nicht markiert ist wird markiert.

10.4.2. Aus Diagramm entfernen

Tastenk??rzel Entf.

Dies entfernt die aktuell markierten Elemente aus dem Diagramm, aber nicht aus dem Modell.

Das Modellelement kann durch einen Taste 2-Klick auf das Modellelement im Explorer, oder durch ziehen des markierten Elementes in das Diagramm wieder in das Diagramm eingef??gt werden.

10.4.3. Aus Modell entfernen

Tastenk??rzel Strg-Entf.

Diese Funktion l??scht die markierten Elemente vollst??ndig aus dem Modell.

Wenn das zu l??schende Element nicht nur im aktuellen Diagramm sondern auch in einem anderen Diagramm vorhanden ist, erscheint der Dialog x.

Abbildung 10.14. Der Best??tigungsdialog zu Aus Modell entfernen.

Der Best??tigungsdialog zu Aus Modell entfernen.


10.4.4. Perspektiven konfigurieren...

Diese Men??option ruft den gleichen Dialog auf, wie die Schaltfl??che oben im Explorer. Die vollst??ndige Beschreibung entnehmen Sie bitte Abschnitt 11.5, „Perspektiven konfigurieren“.

10.4.5. Einstellungen...

Diese Men??option ??ffnet einen Dialog, der es dem Benutzer erlaubt, verschiedene Optionen, die das Verhalten von ArgoUML bestimmen einzustellen (siehe Abbildung 10.15, „Der Dialog Einstellungen - Voreinstellungen.“).

Diese Einstellungen werden persistent f??r die Nutzung durch nachfolgende ArgoUML-Sitzungen gespeichert.

ArgoUML hat verschiedene benutzerspezifische Konfigurationen, die in diesem Dialog oder direkt in den verschiedenen Fenstern eingestellt werden k??nnen. Auch die Lage und Gr????e des Hauptfensters ist eine solche Einstellung. Die Aktivierung dieser Men??option veranlasst, dass die Informationen in der Datei argo.user.properties gespeichert werden. Der Speicherort dieser Datei ist das "Benutzer-Homeverzeichnis ", welches als ${user.home} definiert ist und wie in Abschnitt 10.4.5.2, „Register Umgebung“ beschrieben, bestimmt werden kann.

[Tipp]Tipp

Dies ist eine Textdatei, die Sie zum Konfigurieren von ArgoUML bearbeiten k??nnen.

Abbildung 10.15. Der Dialog Einstellungen - Voreinstellungen.

Der Dialog Einstellungen - Voreinstellungen.


Die Optionen k??nnen in verschiedenen Registern eingestellt werden, die in den folgenden Abschnitten beschrieben werden. F??r jedes Register gibt es drei Schaltfl??chen im unteren Bereich des Dialoges.

  • OK. Die Aktivierung dieser Schaltfl??che (Taste 1-Klick) ??bernimmt die gew??hlten Einstellungen und beendet den Dialog.

  • Abbrechen. Die Auswahl dieser Schaltfl??che (Taste 1-Klick) beendet den Dialog ohne irgendeine, seit dem letzten ??bernehmen ge??nderte Einstellung anzuwenden (oder seit dem der Dialog gestartet wurde, wenn ??bernehmen noch nicht verwendet wurde).

  • ??bernehmen. Die Auswahl dieser Schaltfl??che (Taste 1-Klick) ??bernimmt die gew??hlten Einstellungen und verbleibt im Dialog.

Das Schliessen des Dialoges (mit der Schliessen-Schaltfl??che in der oberen Ecke des Fensterrandes) hat den gleichen Effekt, wie Abbrechen.

10.4.5.1. Register Voreinstellungen

Die Auswahl des Registers Voreinstellungen (Taste 1-Klick auf das Register) enth??lt die folgenden Optionen als Markierfelder.

  • Start-Fenster anzeigen (standardm????ig markiert). Wenn markiert, wird ArgoUML ein kleines Fenster mit einem Bild w??hrend des Startvorganges anzeigen.

    [Tipp]Tipp

    Das Start-Fenster kann auch im Hilfe-Men?? angesehen werden (siehe Abschnitt 10.11.2, „??ber ArgoUML“).

  • Gemeinsame Klassen im Voraus laden (standardm????ig markiert). Wenn markiert, erstellt ArgoUML von einer Anzahl von Klassen w??hrend des Startens Klassenobjekte, so dass deren Instanziierung schneller verl??uft, wenn sie ben??tigt werden.

  • Beim Starten: Letztes Projekt laden (standardm????ig leer). Pr??fen Sie diesen Eintrag, wenn Sie immer im gleichen Projekt arbeiten und wollen, dass dieses automatisch geladen wird, wenn Sie ArgoUML starten.

  • Entferne (Nicht-Standard)-Diagramme w??hrend des Importes (standardm????ig leer). Das Markieren dieses Elementes weist ArgoUML an, die "Diagrammelemente" w??hrend des importieren der XMI-Dateien zu ignorieren.

    Sie m??ssen diese Einstellung nur verwenden, wenn ArgoUML einen Fehler w??hrend des importierens Ihrer XMI-Datei ausgibt, die besagt, das unbekannte Elemente mit der Bezeichnung "Diagramm" aufgetreten sind. Einige Versioen von Poseidon sind bekannt daf??r, dass sie diesen Dateityp standardm????ig erstellen, obwohl es gew??hnlich eine Exportoption gibt, die Erstellung von Standard-XMI-Dateien zu erzwingen.

  • UML-Profildatei ( /org/argouml/model/mdr/mof/default-uml14.xmi per Standard).

    Dies ist ein Read-Only-Feld, welches das aktuell von ArgoUML verwendete Profil anzeigt. Wenn Sie zum Start ein anderes Profil spezifizieren oder ein Plugin mit einem anderen Profil installieren, dann wird es hier angezeigt.

    In der Zukunft wird dies ein beschreibbares Feld, dass es Ihnen erlaubt, unterschiedliche Profile auszuw??hlen, die mit der jeweiligen Modellierungsumgebung (Java, C++, AndroMDA, usw.) ??bereinstimmen.

10.4.5.2. Register Umgebung

Das Ausw??hlen des Registers Umgebung (Taste 1-Klick auf das Register) listet verschiedene Umgebungselemente auf. Beachten Sie, dass keiner der Pfade ge??ndert werden kann — diese sind nur Gegenstand einer Aufzeichnung.

Abbildung 10.16. Der Dialog Einstellungen - Umgebung.

Der Dialog Einstellungen - Umgebung.


  • Standard-Grafikformat. Hier k??nnen Sie das gleiche Grafikformat ausw??hlen, wie im Men?? Abschnitt 10.3.11, „Grafik exportieren...“. Das ausgew??hlte Format wird standardm????ig in den Men??optionen "Grafik exportieren..." und "Alle Grafiken exportieren..." verwendet.

  • Aufl??sung Grafikexport. Dies erlaubt es Ihnen, die Aufl??sung der erzeugten Grafiken k??nstlich zu erh??hen. Die vorgegebene Einstellung ist "Standard". Um in der Lage zu sein "Hoch" oder "Extra hoch" einzustellen, m??ssen Sie gew??hnlich die virtuelle Maschine von Java mit zus??tzlich reserviertem Speicher starten.

  • ${argo.ext.dir}. Das Verzeichnis, welches die ArgoUML-Erweiterungen beinhaltet; standardm????ig ist dies das Unterverzeichnis ext im Build-Verzeichnis von ArgoUML.

  • ${java.home}. Das Home-Verzeichnis der Java Laufzeitumgebung (Java Runtime Environment = JRE).

  • ${user.home}. Das Homeverzeichnis des Benutzers. Wird zum Speichern der Datei argo.user.properties verwendet.

  • ${user.dir}. Das Verzeichnis, von dem aus ArgoUML gestartet wurde.

  • Startverzeichnis. Das Verzeichnis, in dem ArgoUML seine Dateisuche startet usw.

10.4.5.3. Register Benutzer

Dieses Register erlaubt es dem Benutzer zus??tzliche Informationen zu erfassen, die im System genutzt werden. Es werden zwei Textfelder angeboten.

Abbildung 10.17. Der Dialog f??r Einstellungen - Benutzer.

Der Dialog f??r Einstellungen - Benutzer.


  • Vollst??ndiger Name. Erlaubt es dem Benutzer seinen vollst??ndigen Namen einzugeben.

  • Email-Adresse. Erlaubt es dem Benutzer, seine EMail-Adresse einzugeben.

Diese Informationen werden ben??tigt, wenn Sie Hilfe per EMail anfordern.

10.4.5.4. Register Erscheinungsbild

Dieses Register erlaubt es dem Benutzer, das Aussehen (Look and Feel) und das Thema einzustellen. Z.B. wie die gesamte Anwenderschnittstelle von ArgoUML aussehen soll. Es bietet die folgenden Einstellungen an.

Abbildung 10.18. Der Dialog f??rEinstellungen - Erscheinungsbild.

Der Dialog f??rEinstellungen - Erscheinungsbild.


  • Aussehen. Die hier gemachte Auswahl beeinflusst die gesamte Anwenderschnittstelle. Die ??nderung wird nur wirksam, wenn ArgoUML beendet und neu gestartet wird.

  • Metall-Thema. Dieses Element ist deaktivert, wenn das Aussehen Metall nicht ausgw??hlt wurde. Die Auswahl hier beeinflusst die gesamte Anwenderschnittstelle. Die ??nderung wird nur wirksam, wenn ArgoUML beendet und neu gestartet wird.

  • R??nder von Diagrammlinien und Text gl??tten. Diese Funktion ist in bestimmten Plattformen als „Anti-aliasing“ bekannt. Sie bewirkt, dass diagonale Linien durch die Nutzung von verschiedenen Grauschattierungen nicht so stark gezackt aussehen. Diese Funktion arbeitet nur, wenn es das Betriebssystem unterst??tzt.

10.4.5.5. Das Register Profile

In diesen Register kann der Anwender die Einstellungen der ArgoUML-Anwendung bez??glich der Profile ??ndern.

Abbildung 10.19. Der Dialog Einstellungen - Profile.

Der Dialog Einstellungen - Profile.


  • Stereotyp-Darstellung – Auswahl, um Stereotypen als Text, kleine oder gro??e Symbole darzustellen.

  • Standard-XMI-Verzeichnisse – erlaubt dem Anwender, die Verzeichnisse zu konfigurieren, in denen ArgoUML die benutzerdefinierten Profile finden kann.

  • Standard-Profiles – Auswahl, welches Profil von den verf??gbaren Profilen als Standard f??r neue Projekte festgelegt wurde.

10.4.5.6. Das Register Tastenkombinationen konfigurieren

(Noch zu beschreiben)

Abbildung 10.20. Der Dialog f??r Einstellungen - Tastenkombinationen konfigurieren.

Der Dialog f??r Einstellungen - Tastenkombinationen konfigurieren.


10.4.5.7. Register Notation

Dieses Register erlaubt es dem Nutzer, bestimmte Notationseinstellungen zu spezifizieren. Z. B. wie Dinge in Diagrammen dargestellt werden. Es bietet folgende Markierfelder an.

Alle Einstellungen definieren nur die Standards, die in neuen Projekten verwendet werden. Wenn Sie die Art und Weise wie Diagramme in Ihrem aktuellen Projekt aussehen sollen ??ndern wollen, dann siehe Men?? Datei - Eigenschaften.

Abbildung 10.21. Der Dialog f??r Einstellungen - Notationen.

Der Dialog f??r Einstellungen - Notationen.


  • Notationssprache (standardm????ig UML 1.4). Diese Funktion erlaubt die ??nderung der Standardnotation (z.B. Sprache: UML, Java, ...), die in Diagrammen neuer Projekte verwendet wird. Nehmen Sie an, dass ein Designer fordert, dass die Standardnotation des Projektes Java sein soll. Wenn er das Projekt speichert, wird die Auswahl Java innerhalb der Projektdatei gespeichert. Wenn irgendjemand anderes das Diagramm anzeigt, wird es die Java-Notation ebenfalls vorfinden. Diese Person kann die UML-Notation im Men?? Datei - Notation ausw??hlen und wird alle Diagramme in UML sehen. Siehe Abschnitt 10.3.13, „Notation“.

  • Die Namen der Knoten fettgedruckt darstellen.

    Diese Eigenschaft veranlasst, dass die Namen jedes Knotens (z.B. etwas mit einem geschlossenen Polygon gezeichnet) fettgedruckt dargestellt werden.

    Es gibt keine Semantik, fettgedruckte Namen darzustellen, aber ihr Diagramm wird sch??ner aussehen.

  • Franz??sische Anf??hrungszeichen (« ») f??r Stereotypen (standardm????ig leer). Standardm????ig verwendet ArgoUML die Zeichenpaare kleiner als und gr????er als (<< >>) f??r Stereotypen. Ist dieses Feld markiert, werden die Stereotypen in Diagrammen zwischen franz??sische Anf??hrungszeichen gestellt (« »).

    Diese Funktion wird in ArgoUML selten genutzt, da franz??sische Anf??hrungszeichen in diversen Schriften schlecht unterst??tzt werden und wenn sie vorhanden sind, sind sie sehr klein und schlecht sichtbar.

    Unabhh??ngig von der Art und Weise in der sie dargestellt werden, k??nnen Sie immer reale franz??sische Anf??hrungszeichen (wenn Ihre Tastatur dies unterst??tzt) oder deren << >>-??quivalente eingeben.

  • Zeige Assoziationsnamen.

    Diese Eigenschaft veranlasst, dass die Namen jeder Assoziation versteckt werden, sofern sie nicht markiert wurden.

  • Sichtbarkeit anzeigen (standardm????ig leer). Ist dies markiert, dann wird ArgoUML die Sichtbarkeitsmarkierungen vor z.B. jedem Attribut in den Diagrammen anzeigen. In UML steht die Notation "+" f??r public, "-" f??r private, "#" f??r protected und "~" f??r Paket. Es k??nnte f??r ein Attribut z.B. wie folgt aussehen: +neuesAttr : int.

  • Kardinalit??ten anzeigen (standardm????ig leer). Wenn dies markiert ist, dann wird ArgoUML die Kardinalit??t z.B. jeden Attributes im Diagramm darstellen. In der UML-Notation wird die Kardinalit??t zwischen [] gestellt: +neuesAttr [0..*] : int. Diese Einstellung hat keine Auswirkung auf die Darstellung der Kardinalit??t von Assoziationsenden.

  • Anfangswerte anzeigen (standardm????ig leer). Wenn dies markiert ist, dann wird ArgoUML den Anfangswert z.B. eines Attributes im Diagramm darstellen. In der UML-Notation wird der Anfangswert wie folgt dargestellt: +neuesAttr : int = 1.

  • Eigenschaften anzeigen (standardm????ig leer). Wenn dies markiert ist, dann wird ArgoUML die verschiedenen Eigenschaften zwischen geschweifte Klammern {} darstellen. F??r ein Attribut z.B. k??nnte dies wie folgt aussehen: +neuesAttr : int { eingefroren }.

  • Typen und Parameter anzeigen (standardm????ig markiert). Wenn das Feld nicht markiert ist, werden die Attribute in Klassen ohne Typ und Operationen ohne Parameter dargestellt. Diese Funktion kann w??hrend der Analysephase Ihres Projektes n??tzlich sein. Sind alle Felder im Register Notation nicht markiert, dann k??nnte ArgoUML ein Attribut wie folgt anzeigen: neuesAttr. Und f??r eine Operation: neueOperation().

  • Stereotypen im Explorer anzeigen (standardm????ig leer). Wenn dies markiert ist, dann wird ArgoUML die Stereotypen in der N??he der Symbole der Modellelemente im Explorer anzeigen. Z.B. in der Baumstruktur auf der linken Seite.

  • Zeige "1"-Kardinalit??ten.

    Diese Eigenschaft erlaubt es dem Anwender auszuw??hlen, ob er alle Kardinalit??ten, die "1" sind darstellen will oder nicht...

    Manche Menschen betrachten eine nicht dargestellte Kardinalit??t als "undefiniert", so dass es der einzige Weg ist, zwischen einer Kardinalit??t von 1 und einer undefinierten Kardinalit??t zu unterscheiden, indem man dieses Markierfeld markiert.

  • Verstecke Pfeilspitzen bei bi-direktionalen Assoziationen..

    Der UML-Standard definiert unterschiedliche Arten, die Navigierbarkeit von Assoziationen in Diagrammen darzustellen. Darstellungsoption 1 ist es, alle Pfeile anzuzeigen (z.B. sie k??nnen nur in eine bestimmte Richtung navigieren, wenn ein Pfeil dargestellt wird). Darstellungsoption 2 ist, keine Pfeile anzuzeigen und Darstellungsoption 3 ist, nur dann einen Pfeil anzuzeigen, wenn die Assoziation gerichtet ( unidirektional) ist.

    Vor der Version 0.26, konnte ArgoUML nur die Darstellungsoption 3 verwenden. Aktuell kann der Anwender zwischen der Option 1 und 3 ausw??hlen. Die Option 2 wird nicht unterst??tzt.

    In der Vergangenheit wurde die Option 3 sehr h??ufig in anderen UML-Werkzeugen verwendet, aber neuerdings wird die Option 1 h??ufiger eingesetzt.

  • Standard-Schattenbreite (standardm????ig auf 1 eingestellt). ArgoUML ist in der Lage, alle Elemente in einem Diagramm mit einem Schatten zu versehen. Verwenden Sie diese Einstellung, um die Gr????e des Schattens einzustellen, der beim Erzeugen des Modellelementes verwendet wird. Das Register "Darstellung" im Detailfenster erlaubt das Einstellen des Schattens je Modellelement, nachdem diese erzeugt wurden.

10.4.5.8. Das Register Diagramm-Darstellung

(Noch zu beschreiben)

Abbildung 10.22. Der Dialog f??r Einstellungen - Diagramm-Darstellung.

Der Dialog f??r Einstellungen - Diagramm-Darstellung.


10.4.5.9. Das Register Module

Dieses Register zeigt eine Liste der installierten Module an, die aktiviert oder deaktiviert werden k??nnen. Seitdem dies ein neues Konzept in ArgoUML ist, enth??lt es derzeit eine Liste von Modulen, die nicht entfernt werden k??nnen und eine Schaltfl??che, um das Konzept zu testen. Das Dr??cken dieser Schaltfl??che f??gt dem Men?? Werkzeuge eine nutzlose Men??option hinzu.

Beachten Sie auch, dass es sich um ein Konzept f??r "neue " Module handelt, so dass alte einbindbare Module nicht auf diese Weise arbeiten und daher nicht aufgelistet sind.

10.4.5.10. Durch Plugins zus??tzlich hinzugef??gte Register

Ein Plugin-Modul hat die M??glichkeit zus??tzliche Register hinzuf??gen zu k??nnen. Ein Beispiel ist C++, welches folgendes Register hinzuf??gt.

Abbildung 10.23. Der Dialog f??r Einstellungen - C++.

Der Dialog f??r Einstellungen - C++.


10.5. Das Men?? Ansicht

Dieses Men?? wird f??r Aktionen verwendet, die Auswirkungen darauf haben, wie die verschiedenen Fenster dargestellt werden.

10.5.1. Gehezu Diagramm...

Dieses Men?? ??ffnet einen Dialog, der alle im aktuellen Projekt befindlichen Diagramme auff??hrt.

Abbildung 10.24. Der Dialog f??r Gehe zu Diagramm....

Der Dialog f??r Gehe zu Diagramm....


Der Dialog enth??lt eine Tabelle aus drei Spalten und einer Zeile f??r jedes Diagramm im aktuellen Projekt. Ein Schieberegler erlaubt den Zugriff auf die gesamte Tabelle, wenn diese f??r das Fenster zu gross ist. Ein Doppelklick mit der Taste 1 auf eine beliebige Zeile wird das Diagramm im Editierfenster markieren. Die drei Spalten sehen wie nachfolgend beschrieben aus:

  • Typ. Auflistung des Diagrammtyps.

  • Name. Auflistung der f??r die Diagramme vergebenen Namen.

  • Beschreibung. Stellt dar, wieviele Knoten und Kanten sich im Diagramm befinden. Ein Knoten ist ein „2-D “-Modellelement und eine Kante ist eine Verk??pfung zu einem Modellelement.

Wenn der Dialog nicht modal ist, kann der Dialog w??hrend des Editierens des Modelles zur leichteren Navigation ge??ffnet bleiben.

[Warnung]Warnung

Die Version 0.26 von ArgoUML aktualisiert den Dialog nicht sofort, wenn ??nderungen in den Diagrammen vorgenommen werden: ??nderung des Namens, hinzuf??gen von Diagrammen, l??schen von Diagrammen.

10.5.2. Suchen...

Diese Men?? ??ffnet einen nicht-modalen Dialog mit der ArgoUML- Suchmaschine.

Abbildung 10.25. Der Dialog f??r Suchen....

Der Dialog f??r Suchen....


Das Register Name und Ort definiert die durchzuf??hrende Suche. Es enth??lt folgendes:

  • Ein Textfeld mit der Bezeichnung Elementname:, in dem der Name des zu suchenden Modellelementes spezifiziert wird. Die Ersetzungszeichen (* und ? k??nnen hier verwendet werden. Ein Pull-down-Men?? gew??hrt den Zugriff auf vorher verwendete Ausdr??cke.

  • Ein Textfeld mit der Bezeichnung Im Diagramm: spezifiziert, welche Diagramme durchsucht werden sollen. Erneut k??nnen Ersetzungszeichen verwendet werden. Beide Textfelder haben den Standardeintrag *. Z.B. Alles suchen.

  • Rechts von den beiden Textfeldern erlaubt ein Auswahlelement mit der Bezeichnung Elementtyp: die Spezifikation der zu suchenden UML-Metaklasse.

  • Die Auswahl Suche in: erlaubt die Suche ??ber das gesamte Projekt (Standard) oder eine Teilsuche ??ber die Ergebnisse der vorhergehenden Suche. Wenn sie ge??ffnet ist, erscheint eine Liste mit Registern, welche die Suchergebnisse enthalten.

  • Unterhalb dieser Felder befindet sich die Schaltfl??che L??sche Register. Diese l??scht die Darstellung der Register aus den vorangegangenen Suchl??ufen (siehe unten). Diese Schaltfl??che ist deaktiviert, wenn keine Register, ausser dem Register Hilfe, vorhanden sind.

  • Und abschliessend gibt es die Schaltfl??che Suchen . Diese l??st die Suche anhand der in den Text- und Auswahlfeldern spezifizierten Suchkriterien aus. Die Ergebnisse werden in einem Register angezeigt, welche die unteren beiden Drittel der Seite einnehmen.

Die beiden unteren Drittel des Dialoges beinhalten ein grundlegendes Register (mit Hilfe bezeichnet), das eine zusammenfassende Hilfestellung bereitstellt und weitere Register, welche die Ergebnisse der Suchl??ufe anzeigen. Diese Bezeichnungen der Suchregister werden aus dem gesuchten Element imDiagramm zusammengesetzt und sind horizontal in zwei H??lften unterteilt.

Der Taste 1-Doppelklick auf dieses Register entfernt dieses und ??ffnet ein neues Fenster, welches den Registerinhalt enth??lt. Z. B. die Suchergebnisse. Diese Fenster kann beliebig verschoben und in seiner Gr????e ver??ndert werden. Beim Register Hilfe funktioniert dies nicht.

Die obere H??lfte ist mit Ergebnis: und der Anzahl der gefundenen Elemente bezeichnet. Es zeigt eine Tabelle mit einer Zeile mit vier Spalten f??r jedes Modellelement. Die Breite der Spalten kann eingestellt werden.

  • Typ. Enth??lt den Typ des Modellelementes.

  • Name. Enth??lt den Namen des Modellelementes.

  • Im Diagramm. Wo Modellelemente in einem Diagramm sichtbar sind, werden hier die Namen der Diagramme aufgelistet. Im anderen Fall wird N/A angezeigt.

  • Beschreibung. Enth??lt die Beschreibung des Modellelementes.

Der Taste 1-Klick auf eine Zeile wird mehr Informationen ??ber das Modellelement preisgeben, indem es die zugeh??rigen Modellelemente in der unteren H??lfte (siehe unten) darstellt. Der Doppelklick auf eine Zeile beschreibt ein Modellelement im Diagramm und das Element und das Diagramm werden markiert.

Die untere H??lfte des Registers ist eine Tabelle mit der Bezeichnung Zugeh??rige Elemente: mit den gleichen Spalten wie in der oberen H??lfte. Wenn ein Modellelement in der oberen H??lfte markiert wurde, zeigt diese Tabelle die Details eines jeden zugeh??rigen Elementes.

[Tipp]Tipp

Wenn Sie den Dialog vertikal vergr??ssern, zeigt es sich, dass der Teil "Zugeh??rige Elemente" ebenfalls seine Gr????e ??ndert, aber nicht der Teil mit den Suchergebnissen. Zwischen diesen Teilen befindet sich jedoch eine Trennlinie. Wenn Sie die Maus dar??ber bewegen, verwandelt sich der Mauszeiger in das Gr??ssenver??nderungs-Symbol und die Begrenzung zwischen diesen beiden Bereichen kann nach oben oder nach unten bewegt werden, um den Platz im Fenster aufzuteilen.

[Warnung]Warnung

Dieser Dialog ist nicht modal, was es erlaubt, dass er w??hrend des editierens des Modelles ge??ffnet bleiben kann. Aber die Implementierung der Version 0.26 von ArgoUML aktualisiert diesen Dialog nicht sofort, wenn ??nderungen an den gefundenen Modellelementen vorgenommen werden: ??nderungen des Namens des Modellelementes, ??nderung des Diagrammnamens. Das L??schen eines Diagrammes stoppt nicht die M??glichkeit danach zu suchen.

10.5.3. Zoom

Diese Men??option ??ffnet ein Untermen??, welches das Skalieren aller Diagramme um einen Faktor erlaubt. Diese Einstellung wird nicht persistent gespeichert.

Im Untermen?? kann folgendes ausgew??hlt werden:

  • Verkleinern. Tastenk??rzel (Strg-Minus). Verbessert den ??berblick ??ber die Zeichnung.

  • R??ckg??ngig. Kehrt zur Standard-Zoomrate zur??ck (z.B. 100%).

  • Vergr??ssern. Tastenk??rzel (Strg-Plus). Vergr??ssert die Elemente in den Zeichnungen.

10.5.4. Gitter einstellen

Dieses Men?? erlaubt folgende Auswahl der Bildschirm-Gitterdarstellung:

  • Zeilen 16: vollst??ndiges Gitter, mit einem Zwischenraum von 16 Pixeln.

  • Zeilen 8: vollst??ndiges Gitter, mit einem Zwischenraum von 8 Pixeln.

  • Punkte 16: Punkte, mit einem Zwischenraum von 16 Pixeln (der Standard).

  • Punkte 32: Punkte, mit einem Zwischenraum von 32 Pixeln.

  • Kein Gitter: Kein irgendwie geartetes Gitter.

10.5.5. Einrasten einrichten

Dieses Men?? erlaubt die Auswahl zwischen folgenden Gitter-Einrast-Schwellwerten:

  • Einrasten 4: Rastet innerhalb eines Bereiches von 4 Pixeln ein.

  • Einrasten 8: Rastet innerhalb eines Bereiches von 8 Pixeln ein.

  • Einrasten 16: Rastet innerhalb eines Bereiches von 16 Pixeln ein.

  • Einrasten 32: Rastet innerhalb eines Bereiches von 32 Pixeln ein.

[Anmerkung]Anmerkung

Es gibt keine Option das Einrasten auf das Gitter abzustellen.

[Anmerkung]Anmerkung

Wenn Sie existierende Elemente auf ge??nderte Einrastbereiche ausrichten wollen, k??nnen Sie das Men?? Anordnen > Am Gitter ausrichten verwenden (siehe Abschnitt 10.7.1, „Ausrichten“).

10.5.6. Seitenumbr??che

Mit dieser Men??option werden die Seitenumbr??che im Diagramm dargestellt oder nicht (durch weiss gepunktete Linien).

[Warnung]Warnung

Diese Men??option funktioniert in ArgoUML V0.24 nicht.

10.5.7. Symbolleisten

Dieses Men?? erlaubt es dem Anwender beliebige Symbolleisten zu verbergen oder anzuzeigen. Standardm????ig werden alle angezeigt.

10.5.8. XML-Quelltext

Aktiviert ein Fenster, das den gesamten Inhalt des aktuellen Projektes im XML-Format darstellt.

Obwohl sehr n??tzlich zum Debuggen von ArgoUML, ist diese Men??option f??r den normalen Benutzer wenig interessant.

10.6. Das Men?? "Neues Diagramm"

Dieses Men?? ist daf??r gedacht, die verschiedenen, von ArgoUML unterst??tzten Typen von UML-Diagrammen zu erzeugen.

10.6.1. Neues Anwendungsfalldiagramm

Dieser Men??eintrag erstellt ein leeres Anwendungsfalldiagramm und markiert das Diagramm im Editierfenster. Ist ein Paket aktuell markiert, dann wird das Anwendungsfalldiagramm innerhalb dieses Paketes erstellt. Das bedeutet, dass es in der Explorerhierarchie (Ansicht: Nach Paketen) als Teil des Paketes dargestellt wird. Im Diagramm erstellte Modellelemente werden im Namensraum des Paketes erzeugt. Dies wirkt sich nicht nur auf das Paket aus, sondern auch auf eine Klasse, Schnittstelle, Anwendungsfall, usw..

[Tipp]Tipp

Das verhindert nicht, dass Modellelemente aus anderen Namensr??umen/Paketen im Diagramm erscheinen. Sie k??nnen im Explorer mit Hilfe des Popup-Men??s Zum Diagramm hinzuf??gen hinzugef??gt werden.

10.6.2. Neues Klassendiagramm

Dieser Men??eintrag erstellt ein leeres Klassendiagramm und markiert das Diagramm im Editierfenster. Ist ein Paket aktuell markiert, dann wird das Klassendiagramm innerhalb dieses Paketes erstellt. Das bedeutet, dass es in der Explorerhierarchie (Ansicht: Nach Paketen) als Teil des Paketes dargestellt wird. Im Diagramm erstellte Modellelemente werden innerhalb des Namensraumes des Paketes erstellt. Dies wirkt sich nicht nur auf das Paket aus, sondern auch auf eine Klasse, Schnittstelle, Anwendungsfall, usw..

[Tipp]Tipp

Das verhindert nicht, dass Modellelemente aus anderen Namensr??umen/Paketen im Diagramm erscheinen. Sie k??nnen im Explorer mit Hilfe des Popup-Men??s Zum Diagramm hinzuf??gen hinzugef??gt werden.

10.6.3. Neues Sequenzdiagramm

Dieser Men??eintrag erstellt ein leeres Sequenzdiagramm und markiert das Diagramm im Editierfenster. Er erzeugt auch ein UML-Element Kollaboration, das ein Container f??r die im neuen Diagramm dargestellten Elemente ist. Wenn eine Klasse aktuell markiert ist, wird ein Sequenzdiagramm und eine Kollaboration erstellt, die das Verhalten dieser Klasse repr??sentieren. Das bedeutet, dass die erstellten Elemente in der Explorerhierarchie (Ansicht: Nach Paketen) als Teil der Klasse dargestellt werden. Im Diagramm erstellte Modellelemente werden innerhalb des Namensraumes der Kollaboration erzeugt. Ein Sequenzdiagramm muss nicht nur das Verhalten einer Klasse repr??sentieren, sondern auch jeden anderen Klassifizierer, wie zum Beispiel eine Schnittstelle, einen Anwendungsfall, usw.. Es ist auch m??glich, Sequenzdiagramme f??r eine Operation zu erstellen.

10.6.4. Neues Kollaborationsdiagramm

Dieser Men??eintrag erstellt ein leeres Kollaborationsdiagramm und markiert das Diagramm. Es erstellt auch ein UML-Element Kollaboration, das ein Container f??r die im neuen Diagramm dargestellten Elemente ist. Wenn ein Paket markiert ist, wenn dieser Men??eintrag aktiviert wird, wird das Kollaborationsdiagramm unterhalb einer Kollaboration innerhalb dieses Paketes erstellt. Das bedeutet, dass es in der Explorerhierarchie (Ansicht: Nach Paketen) als Teil der Kollaboration innerhalb des Paketes dargestellt wird. Im Diagramm erstellte Modellelemente werden im Namensraum der Kollaboration des Paketes erstellt.

[Tipp]Tipp

Das verhindert nicht, dass Modellelemente aus anderen Namensr??umen/Paketen im Diagramm erscheinen. Sie k??nnen im Explorer mit Hilfe des Popup-Men??s Zum Diagramm hinzuf??gen hinzugef??gt werden.

10.6.5. Neues Zustands??bergangsdiagramm

Dieser Men??eintrag erstellt ein, mit der aktuellen Klasse verkn??pftes, leeres Zustands??bergangsdiagramm und markiert das Diagramm im Editierfenster. Er erstellt auch ein UML-Element Zustandsautomat, der ein Container f??r die im neuen Diagramm dargestellten Elemente ist.

Zustands??bergangsdiagramme sind mit einem Modellelement mit dynamischem Verhalten verkn??pft, wie z.B. einem Klassifizierer oder einer Verhaltenseigenschaft, welche den Kontext f??r den zu repr??sentierenden Zustandsautomaten enth??lt. Passende Modellelemente sind zum Beispiel eine Klasse, eine Operation und ein Anwendungsfall. Wenn kein solches Elemente zum Zeitpunkt des aktivierens des Men??s Neues Zustands??bergangsdiagramm markiert ist, dann wird eine ungebundener Zustandsautomat erstellt. Um ein korrektes UML-Modell zu erhalten, m??ssen Sie den Kontext des Zustandsautomaten im Detailfenster einstellen.

10.6.6. Neues Aktivit??tsdiagramm

Dieser Men??eintrag erstellt ein, mit der aktuell markierten Klasse verkn??pftes, leeres Aktivit??tsdiagramm und markiert das Diagramm im Editierfenster. Er erzeugt auch ein UML-Element Aktivit??tsgraph, der einen Container f??r die im neuen Diagramm dargestellten Elemente ist.

Aktivit??tsdiagramm sind mit einem Modellelement mit dynamischem Verhalten verkn??pft, wie z.B. Pakete, Klassifizierer ( einschliesslich Anwendungsf??llen) und Verhaltenseigenschaften. Passende Modellelemente sind z.B. eine Klasse, ein Anwendungsfall, eine Operation und ein Paket. Wenn ein solches Element zum Zeitpunkt des aktivierens des Men??s Neues Aktivit??tsdiagramm nicht markiert ist, wird ein ungebundener Aktivit??tsgraph erstellt. Um ein korrektes UML-Modell zu erhalten, m??ssen Sie den Kontext des Aktivit??tsgraphen im Detailfenster angeben.

10.6.7. Neues Verteilungsdiagramm

Dieser Men??eintrag erstellt ein leeres Verteilungsdiagramm und markiert das Diagramm im Editierfenster.

[Tipp]Tipp

Modellelemente aus anderen Namensr??umen/Paketen k??nnen vom Explorer aus durch ziehen oder durch das Popup-Men?? Zum Diagramm hinzuf??gen hinzugef??gt werden.

10.7. Das Men?? Anordnen

Dieses Men?? enth??lt Funktionen, die dabei helfen, die Modellelemente in den Diagrammen des Editierfensters auszurichten. Die aufgerufenen Men??funktionen werden haupts??chlich auf jedes Modellelement oder auf die aktuell im Editierfenster markierten Modellelemente angewendet.

10.7.1. Ausrichten

Dieses Untermen?? richtet die markierten Elemente aus. Es enth??lt sieben Ausrichtungsoptionen.

  • Oben b??ndig. Richtet die markierten Modellelemente entlang ihren oberen Kanten aus.

  • Unten b??ndig. Richtet die markierten Modellelemente entlang ihrer unteren Kanten aus.

  • Rechtsb??ndig (Tastenk??rzel Strg-R). Richtet die markierten Modellelemente entlang ihrer rechten Kanten aus.

  • Linksb??ndig (Tastenk??rzel Strg-L). Richtet die markierten Modellelemente entlang ihrer linken Kanten aus.

  • Horizontal mittig. Richtet die markierten Modellelemente entlang der horizontalen Mitten in einer vertikalen Linie aus.

  • Vertikal mittig. Richtet die markierten Modellelemente entlang ihrer vertikalen Mitten in einer horizontalen Linie aus.

  • Am Gitter ausrichten. Richtet die markierten Modellelemente entlang ihrer oberen und rechten Kanten auf die Gittereinrastgrenzen aus ( siehe Abschnitt 10.5.5, „Einrasten einrichten“ ).

    [Tipp]Tipp

    Die Ausrichtung erfolgt bezogen auf die aktuelle Gittereinrast-Einstellung. Diese kann kleiner, gr????er oder identisch mit dem dargestellten Gitter sein. Seitdem die elemente an den Gittereinrastgrenzen ausgerichtet werden hat dieser Men??eintrag solange keine Auswirkungen bis Sie entweder die Gittereinrasteinstellungen auf einen gr????eren Wert eingestellt haben oder einen der anderen Anordnen-Men??eintr??ge verwendet haben, um die Elemente aus ihren urspr??nglichen Positionen zu bewegen.

10.7.2. Anordnen

Dieses Untermen?? ordnet die markierten Elemente an. Es enth??lt vier Optionen zum Anordnen.

  • Horizontal gleiche Zwischenr??ume. Die am weitesten rechts und links befindlichen Modellelemente werden nicht bewegt. Die anderen werden horizontal justiert, bis der horizontale Zwischenraum (z.B. von der rechten Kante des linken Modellelementes zur linken Kante des rechten Modellelementes ) zwischen allen markierten Elementen gleich ist.

  • Horizontal gleiche Abst??nde. Die am weitesten rechts und links befindlichen Modellelemente werden nicht bewegt. Die anderen werden horizontal justiert, bis der Abstand zwischen den horizontalen Mitten aller markierten Elemente gleich ist.

  • Vertikal gleiche Zwischenr??ume. Die oberen und die unteren Modellelemente werden nicht bewegt. Die anderen werden vertikal justiert, bis der vertikale Zwischenraum (z.B. von der unteren Kante des oberen Modellelementes zur oberen Kante des unteren Modellelementes) f??r alle markierten Elemente gleich ist.

  • Vertikal gleiche Abst??nde. Die oberen und die unteren Modellelemente werden nicht bewegt. Die anderen werden vertikal justiert, bis der Abstand zwischen den vertikalen Mitten aller markierten Elemente gleich ist.

10.7.3. Reihenfolge

Dieses Untermen?? bestimmt die Reihenfolge ??berlappender Elemente. Es enth??lt vier Optionen.

  • Nach vorne. Die markierten Modellelemente werden in der Reihenfolge einen Schritt nach vorne geholt.

  • Nach hinten. Die markierten Modellelemente werden in der Reihenfolge einen Schritt nach hinten gesetzt.

  • In den Vordergrund. Die markierten Modellelemente werden in der Reihenfolge vor alle anderen Modellelemente gebracht.

  • In den Hintergrund. Die markierten Modellelemente werden in der Reihenfolge hinter alle anderen Modellelemente gebracht.

10.7.4. Gr??sse an Inhalt anpassen

Dieses Men??element wirkt auf alle markierten Elemente im aktuellen Diagramm. Es setzt die Gr??sse aller Modellelemente auf die minimale Gr??sse, in welcher der gesamte Text gerade noch in das Element passt.

10.7.5. Layout

Dieses Men??element enth??lt eine automatische Diagramm-Layoutfunktion. Wenn Sie z.B. dieses Men??element aktivieren, werden alle Elemente des aktuellen Klassendiagrammes entsprechend bestimmter Layoutalgorithmen neu angeordnet.

Diese Funktion arbeitet aktuell nur bei Klassendiagrammen. Bei allen anderen Diagrammtypen f??hrt dieses Men??element nichts aus. .

10.8. Das Men?? Generieren

Dieses Men?? enth??lt die Funktionen f??r die Codegenerierung aus UML-Diagrammen. Diese Funktionalit??t baut auf den strukturellen Informationen der Klassendiagramme auf.

[Anmerkung]Anmerkung

Ohne installierte Plugin-Module unterst??tzt ArgoUML nur die Codegenerierung mit Java. ArgoUML V0.20 unterst??tzt die folgenden Sprachen per Plugin: C#, C++, php4, php5.

[Warnung]Warnung

Codegenerierung ist nat??rlich eine sehr fortschrittsbezogene Arbeit. Die aktuelle Version von ArgoUML wird ein strukturelles Template f??r Ihren Code generieren, aber es ist nicht in der Lage mit der Verhaltens-Spezifikationen umzugehen, um Code f??r das dynamische Verhalten des Modelles zu generieren.

10.8.1. Markierte Klassen generieren ...

Dieser Men??eintrag ??ffnet den Dialog f??r den ArgoUML-Codegenerator (siehe Abbildung 10.26, „ Der Dialog f??r Markierte Klassen generieren .... “ ).

Abbildung 10.26. Der Dialog f??r Markierte Klassen generieren ....

Der Dialog f??r Markierte Klassen generieren ....


Neben der Beschriftung Verf??gbare Klassen listet der Dialog f??r jede installierte Sprache alle markierten Klassen namentlich auf, mit einem Markierfeld auf der linken Seite. Alle Markierfelder sind beim ersten Mal nicht markiert. Das Markieren eines Markierfeldes veranlasst die Codegenerierung f??r diese Klasse. Das Markieren mehrerer Sprachen f??r eine Klasse veranlasst, dass die Klasse in all diesen Sprachen generiert wird.

Die Schaltfl??chen Alles markieren und Nichts markieren kann helfen, wenn sehr viele Elemente markiert oder deren Markierung entfernt werden sollen.

Der untere Teil des Dialoges ist ein editierbares Kombinationsfeld mit der Beschriftung Ausgabeverzeichnis, um das Verzeichnis festzulegen, in das der Code generiert wird. Innerhalb dieses Verzeichnisses wird ein Oberverzeichnis mit dem Namen des Modelles erstellt. Weitere Unterverzeichnisse werden erzeugt, welche die Hierarchie der Pakete/Namensr??ume des Modelles reflektieren. Ein Pull-down-Men?? erlaubt den Zugriff auf vorher verwendete Ausgabeverzeichnisse.

Am Ende des Dialoges befinden sich zwei Schaltfl??chen, die mit Generieren und Abbrechen beschriftet sind. Ein Taste 1-Klick auf die erstgenannte wird die Codegenerierung ausl??sen, ein Taste 1-Klick auf die zuletzt genannte wird die Codegenerierung abbrechen.

10.8.2. Alle Klassen generieren...

Tastenk??rzel F7.

Diese Funktion verh??lt sich wie Markierte Klassen generieren... (siehe Abschnitt 10.8.1, „Markierte Klassen generieren ...“) als w??ren alle Klassen im aktuellen Diagramm markiert.

10.8.3. Gesamtes Projekt generieren... (Noch zu beschreiben)

10.8.4. Einstellungen zur Codegenerierung im Projekt... (Noch zu beschreiben)

10.9. Das Men?? Kritiken

Dieses Men?? steuert eines von ArgoUML's Alleinstellungsmerkmalen; die Verwendung von Kritiken, um den Designer anzuleiten. Die dahinterstehende Theorie ist ausf??hrlich in Jason Robbins' PhD-Dissertation beschrieben http://argouml.tigris.org/docs/robbins_dissertation/.

[Anmerkung]Anmerkung

Ein Wort zur Terminilogie: Die Kritiken sind Hintergrundprozesse, die das aktuelle Modell anhand verschiedener „guter“ Designkriterien ??berpr??fen. Es gibt jeweils eine Kritik f??r jedes Designkriterium.

Die Ausgabe einer Kritik ist eine kritische Beschreibung — eine Ausf??hrung zu einigen Aspekten des Modelles, die nicht der guten Designpraxis zu folgen scheinen.

Zum Schluss wird die kritische Beschreibung generell durch ein hochgestelltes "zu bearbeiten"-Element empfehlen, wie der identifizierte, schlechte Designansatz berichtigt werden kann.

[Anmerkung]Anmerkung

Die Kritiken sind asynchrone Prozesse die parallel zum Hauptprozess von ArgoUML ablaufen. ??nderungen ben??tigen ??blicherweise eine oder zwei Sekunden bis die Kritiken verf??gbar sind.

10.9.1. Kritiken ein-/ausschalten

Dies ist ein Markierfeld, welches steuert, ob die Kritiken eingeschaltet sind. Standardm????ig ist das Feld markiert. Ist es nicht markiert, sind alle Kritiken ausgeschaltet und jedes, durch die Kritiken generierte "zu bearbeiten"-Element (alle, au??er den vom Designer von Hand erstellten) wird im "Zu bearbeiten"-Fenster versteckt.

10.9.2. Design-Wichtungen...

Dieser Men??eintrag ??ffnet einen Dialog, der steuert, wie die mit einem bestimmten Designbereich verkn??pften Kritiken angewendet werden (siehe Abbildung 10.27, „ Der Dialog f??r Design-Wichtungen.... “).

Abbildung 10.27. Der Dialog f??r Design-Wichtungen....

Der Dialog f??r Design-Wichtungen....


ArgoUML kategorisiert Kritiken je nachdem wie die Designwichtungen diese adressieren. Es gibt 16 solcher Kategorien. Die Kritiken in jeder Kategorie werden detailliert im Kapitel ??ber Kritiken ( Kapitel 15, Die Kritiken) diskutiert.

Die Schieberegler k??nnen f??r jede Kategorie eingestellt werden, um die Kritiken zu steuern, die in dieser Kategorie ausgel??st werden. Das verschieben eines Reglers auf Aus schaltet alle Kritiken dieser Kategorie ab und entfernt alle damit verbundenen "zu bearbeiten"-Elemente aus dem "Zu bearbeiten"-Fenster.

Das Einstellen des Reglers auf einen h??her priorisierten Wert, wird alle auf oder ??ber dieser Priorit??t befindlichen Kritiken innerhalb der Design...kategorie freischalten (Aus ist die niedrigste Priorit??t)

[Anmerkung]Anmerkung

Die Regler sind f??r alle Designkategorien standardm????ig auf Hoch eingestellt.

10.9.3. Design Ziele...

Dieser Men??eintrag ??ffnet einen Dialog, der steuert, wie Designziele behandelt werden (siehe Abbildung 10.28, „ Der Dialog f??r Design Ziele.... “).

Abbildung 10.28. Der Dialog f??r Design Ziele....

Der Dialog f??r Design Ziele....


ArgoUML verfolgt das Konzept, dass Designer eine Anzahl von Designzielen haben, die sie erreichen wollen (zum Beispiel eine gute strukturelle Darstellung, eine detaillierte Verhaltensdarstellung usw.). Kritiken sind mit einem oder mehreren Zielen verkn??pft.

Dieser Dialog erlaubt es dem Benutzer, die Priorit??t eines jeden Designzieles zu spezifizieren.

Um die Kritiken, die das jeweilige Ziel beeinflussen zu steuern, k??nnen die Schieberegler f??r jedes Designziel eingestellt werden. Das Einstellen des Reglers auf Null, wird alle Kritiken dieses Zieles ausschalten und alle damit verkn??pften "Zu bearbeiten"- Elemente aus dem "Zu bearbeiten"-Fenster entfernen.

Die Einstellung eines Reglers auf einen h??heren Wert wird alle Kritiken auf oder ??ber der Priorit??t innerhalb der Designwichtungskategorie freigeben (1 ist die h??chste und 5 die niedrigste Priorit??t).

[Tipp]Tipp

Es kann n??tzlich sein, ??ber diese Funktion ??hnlich zu denken wie bei Design-Wichtungen (siehe Abschnitt 10.9.2, „Design-Wichtungen...“), aber mit der Gruppierung der Kritiken gem???? dem Ergebnis der OOA&D und nicht mit der Gruppierung gem???? der Struktur der UML.

[Warnung]Warnung

Die Version 0.20 von ArgoUML enth??lt ein einziges Designziel mit der Bezeichnung Nicht spezifiziert. Der Regler ist standardm????ig auf die Priorit??t 1 eingestellt. Jedoch enth??lt es keine Kritiken und hat somit keine Auswirkungen.

10.9.4. Kritiken anzeigen...

Dieser Men??eintrag ??ffnet einen Dialog, der die individuellen Kritiken steuert (siehe Abbildung 10.29, „ Der Dialog f??r Kritiken anzeigen.... “).

Abbildung 10.29. Der Dialog f??r Kritiken anzeigen....

Der Dialog f??r Kritiken anzeigen....


Dieser Dialog steuert das Verhalten der einzelnen Kritiken. Links befindet sich eine Liste aller Kritiken, um diese individuell ein- oder ausschalten zu k??nnen. F??r jede Kritik gibt es drei Spalten, beschriftet mit Aktiv, Titel und deaktiviert. Die erste davon ist ein Markierfeld, das mit Taste 1-Klicks ver??ndert werden kann. Die zweite ist der Titel der Kritik und die dritte zeigt an, wenn die Kritik im "Zu bearbeiten"-Fenster deaktiviert wurde (siehe Kapitel 14, Der Bereich Zu-Bearbeiten. Eine Kritik ist nur dann wirklich aktiv, wenn das Markierfeld in der ersten Spalte markiert ist und die Kritik nicht deaktiviert wurde.

Jede Kritik, bei der das Markierfeld in der ersten Spalte nicht markiert ist, ist inaktiv und wird nicht ausgel??st. Zus??tzlich wird jedes, mit dieser Kritik verkn??pfte "Zu bearbeiten"-Element aus dem "Zu bearbeiten"-Fenster entfernt.

Die Version 0.26 von ArgoUML umfasst 90 Kritiken, einige davon sind unvollst??ndig implementiert. Sie sind je Designwichtungskategorie im Kapitel Kritiken detailliert beschrieben (siehe Kapitel 15, Die Kritiken).

Rechts von der Liste gibt es eine Reihe von Feldern, mit Details Kritik bezeichnet, die eine detaillierte Kontrolle ??ber die einzelnen Kritiken gibt. Das Markieren einer Kritik in der linken Liste wird die Felder f??r diese Kritik bef??llen.

Das erste Feld rechts ist mit Klasse: bezeichnet. Darauf folgt der vollst??ndige Name der Klasse in ArgoUML, welche die Kritik implementiert. Dieser Name kann aus eindeutiger Bezeichner f??r diese Kritik verwendet werden, z.B. bei der Kommunikation ??ber diese Kritik.

Das erste Feld danach ist ein Textfeld mit der Beschriftung Titel:. Dieses Textfeld beinhaltet den vollst??ndigen Titel der Kritik (der in der linken Liste abgeschnitten sein kann).

[Anmerkung]Anmerkung

Im Titel k??nnen Sie den Text <ocl>self</ocl> sehen, der durch den Namen des in Frage kommenden Modellelementes ersetzt wird, wenn die Kritik ausgel??st wird.

Das n??chste Feld ist ein mit Priorit??t beschriftetes Pull-down-Men??. Die drei verf??gbaren Optionen sind Hoch, Mittel und Niedrig und spezifizieren die Priorit??tskategorie eines jeden "Zu bearbeiten"-Elementes dieser Kritik. Dies ??ndert nich die Priorit??t bereits existierender "Zu bearbeiten"-Elemente. Nur die neu generierten. Die ??nderung der Priorit??t einer Kritik wird nicht dauerhaft gespeichert.

Das n??chste Feld ist mit Mehr Informationen: beschriftet und enth??lt eine URL, die auf weitergehende Informationen zeigt. Mit der rechts befindlichen Schaltfl??che Gehe zu k??nnen Sie zu dieser URL springen.

[Warnung]Warnung

In der Version 0.26 von ArgoUML sind keine weitergehende Informationen verf??gbar und die Schaltfl??che Gehe zu ist deaktiviert.

Das n??chste Textfeld ist mit Beschreibung: bezeichnet und ist ein Textbereich mit einer detaillierten Beschreibung dessen, was die Kritik bedeutet. Ist der Text zu gross f??r den Bereich, erscheint auf der rechten Seite ein Schieberegler.

[Anmerkung]Anmerkung

In diesem Textbereich k??nnen Sie den Text <ocl>self</ocl> vorfinden, der durch den Namen des in Frage kommenden Modellelementes ersetzt wird, wenn die Kritik ausgel??st wird.

Das letzte Feld ist ein mit Verwende Kennzeichen: beschriftetes Pull-down-Men??, mit drei Optionen: Immer , Wenn, nur eines und Nie .

Kennzeichen sind Symbole und rote Wellenlinien in aktuellen Diagrammen, um den Artefakt zu kennzeichnen, auf den sich die Kritik bezieht. Die urspr??ngliche Absicht war es, die Verbindung zwischen den Kritiken und den Kennzeichen etwas flexibler zu machen.

Ein Benutzer m??chte z.B. die Kritik Fehlender Name mit einem roten Unterstrich angezeigt bekommen, ein anderer Benutzer m??chte die Kennzeichen ausschalten oder mit einer gr??nen Wellenlinie oder einem blauen Fragezeichen bezeichnet haben. Kritiken, bei denen die Kennzeichen ausgeschaltet sind, w??rden immer noch im "Zu bearbeiten"-Fenster aufgelistetes Feedback erzeugen.

[Achtung]Achtung

In der Release V0.26 von ArgoUML hat diese Auswahl keine Funktion. Sie ist f??r die k??nftige Entwicklung.

Unterhalb der Felder befinden sich zwei Schaltfl??chen in einer horizontalen Reihe.

  • Aktivieren. Es ist m??glich, eine Kritik im "Zu bearbeiten"-Fenster zu deaktivieren ( siehe Kapitel 14, Der Bereich Zu-Bearbeiten), was die Kritik f??r eine bestimmte Zeit ausschaltet. Wenn die Kritik deaktiviert wurde, wird diese Schaltfl??che aktiviert und wird die Kritik wieder aktivieren. Ansonsten ist sie deaktiviert.

    [Tipp]Tipp

    Sie k??nnen eine deaktivierte Kritik erkennen, da dies in der linken Liste in der dritten Spalte angezeigt wird.

  • Erweitert. Diese Schaltfl??che veranlasst ArgoUML einige zus??tzliche Spalten in der Tabelle der Kritiken anzuzeigen. Sie erlauben eine detailliertere Untersuchung der Eigenschaften einer Kritik.

Die untere rechte Schaltfl??che des Dialoges ist mit Schliessen beschriftet. Ein Taste 1-Klick schliesst den Dialog.

10.10. Das Men??: Werkzeuge

Dieses Men?? enth??lt einen generieschen Men??erweiterungspunkt f??r die in ArgoUML enthaltenen Plugins. Das Standardsystem hat kein Plugin und dieser Men??eintrag ist standardm????ig leer.

10.11. Das Men??: Hilfe

Diese Men?? enth??lt Hilfen f??r den Gebrauch von ArgoUML. Es hat zwei Eintr??ge.

10.11.1. Systeminformation

Dieses Men?? ??ffnet den Dialog Systeminformation, siehe Abbildung 10.30, „Der Dialog f??r Systeminformation.“

Abbildung 10.30. Der Dialog f??r Systeminformation.

Der Dialog f??r Systeminformation.


Verwenden Sie dieses Men??, um das System f??r den Systemmanager oder Entwickler zu beschreiben auf dem ArgoUML l??uft. Das Dr??cken der Schaltfl??che Starte Speicherbereinigung (GC) startet nicht nur den Java Garbage Collector sondern aktualisiert auch die dargestellten Informationen. Um das Kopieren und Einf??gen in (z.B.) eine E-Mail zu unterst??tzen, daf??r ist die Schaltfl??che In Zwischenablage kopieren vorgesehen. Die Schaltfl??che Schliessen schlie??t den Dialog.

10.11.2. ??ber ArgoUML

Dieser Men??eintrag ??ffnet das Hilfefenster von ArgoUML (siehe Abbildung 10.31, „Das Hilfefenster von ArgoUML“).

Abbildung 10.31. Das Hilfefenster von ArgoUML

Das Hilfefenster von ArgoUML


Das Fenster weist sechs Register auf, die durch einen Taste 1- Klick ausgew??hlt werden k??nnen. Standardm????ig wird das erste Register (Startfenster) angezeigt.

  • Startfenster. Dies zeigt das Bild und die aktuelle Versionsnummer, welche angezeigt werden, wenn ArgoUML hochf??hrt.

  • Version. Dieses Register enth??lt die Versionsinformationen von den verschiedenen Paketen aus denen ArgoUML besteht, sowie einigen Betriebssystem- und Umgebungsinformationen.

  • Anerkennung. Dieses Register f??hrt alle auf, die ArgoUML erstellt haben, einschliesslich der Kontaktdaten f??r die verschiedenen Modul-Eigent??mer.

  • Kontakt. Dieses Register enth??lt die Haupt-Kontaktdaten f??r ArgoUML- Projekt-Webseite und der Entwickler-Mail-Listen.

  • Fehler mitteilen. Dieses Register gibt Ihnen Informationen, wie Sie mit Fehlern in ArgoUML umgehen sollen. Es ist wichtig, dass alle Fehler erfasst und jede Kooperation gew??rdigt wird.

  • Recht. Ein Auszug der FreeBSD-Lizenz, der die gesamte ArgoUML-Software unterliegt.

    [Achtung]Achtung

    Die verschiedenen Projektdokumentationen unterliegen nicht alle der FreeBSD-Lizenz (wie es f??r die Software der Fall ist). Im speziellen unterliegt dieses Handbuch der OpenPub-Lizenz (siehe Anhang F, Open Publication License).

Kapitel 11. Der Explorer

Der Explorer wurde vorher Navigationsfenster/-baum genannt oder machmal Navigatorfester/-baum.

11.1. Einleitung

Abbildung 11.1, „??berblick ??ber den Explorer“ zeigt das ArgoUML-Fenster mit dem hervorgehobenen Explorer.

Abbildung 11.1. ??berblick ??ber den Explorer

??berblick ??ber den Explorer


Der Explorer erlaubt es dem Anwender, die Struktur des Modelles in einer Anzahl von vordefinierten Perspektiven zu betrachten. Er erlaubt es den Anwendern auch, ihre eigenen Perspektiven f??r das benutzerspezifische Erkunden des Modelles zu definieren.

Eine wichtige Eigenschaft, bezogen auf die Idee der kognitive Psychologie in ArgoUML ist, dass nicht alle Modellelemente notwendigerweise in allen Perspektiven dargestellt werden. Im Gegenteil, die Perspektiven werden dazu verwendet, uninteressante Teile des Modelles zu verstecken.

11.2. Das Verhalten der Maus im Explorer

Das generelle Verhalten der Maus und die Benennung der Schaltfl??chen ist im Kapitel mit dem ??berblick ??ber die Anwenderschnittstelle ausgef??hrt (siehe Kapitel 8, Einleitung).

11.2.1. Taste 1-Klick

Elemente, die Subhierarchien haben, werden innerhalb der hierarchischen Darstellung durch angezeigt, wenn die Hierarchie verborgen ist und wenn die Hierarchie ge??ffnet ist.

Ein Taste 1-Klick ??ber dem Namen eines Diagramm-Modellelementes veranlasst, dass das Diagramm markiert und im Editierfenster angezeigt wird. Zus??tzlich werden seine Details im Detailfenster dargestellt.

Ein Taste 1-Klick im Hauptbereich des Explorers ??ber dem Namen eines Modellelementes, welches kein Diagramm ist, wird markiert und seine Details im Detailfenster angezeigt. Ist das Modellelement Teil eines aktuell im Editierfenster dargestellten Diagrammes, wird das Modellelement dort hervorgehoben.

[Anmerkung]Anmerkung

Wenn das Modellelement Teil eines, vom aktuell im Editierfenster angezeigten, abweichenden Diagrammes ist, gibt es keine ??nderung des Diagrammes im Editierfenster.

Wo der Taste 2-Klick verwendet wurde, um ein kontextsensitives Popup-Men?? zu ??ffnen (siehe nachfolgend), wird der Taste 1- Klick dazu verwendet, den gew??nschten Men??eintrag auszuw??hlen. Ein Taste 1-Klick ausserhalb des Men??bereiches wird diesen entfernen.

11.2.2. Taste 1-Doppelklick

Dies hat den gleichen Effekt wie ein einziger Taste 1-Klick. Wenn das Baumelement kein Blatt ist, wird es zwischen dem ??ffnen und Schliessen der Hierarchie hin- und herwechseln.

11.2.3. Taste 1-Bewegung

Die Taste 1-Bewegung bedeutet, dass Sie ein oder mehrere Modellelemente nehmen und an eine neue Stelle ziehen. Das Loslassen des Modellelementes bewirkt in ArgoUML die Ausf??hrung einiger Funktionen. Je nachdem, wo Sie das Modellelement loslassen.

11.2.3.1. Vom Explorer zum Explorer

Das Loslassen der Maustaste ??ber einem Namensraum bewirkt, dass das Modellelement Teil dieses Namensraumes wird. In der paketorientierten Explorerperspektive bedeutet dies eine einfach ziehen-und-loslassen-Funktion.

Verwenden Sie diese ziehen-und-loslassen-Eigenschaft, um z.B. Klassen leicht von einem Paket zu einem anderen zu bewegen.

11.2.3.2. Vom Explorer zum Diagramm

Das Loslassen eines Modellelementes in einem Diagramm enspricht der Funktion "Zum Diagramm hinzuf??gen". Aus diesem Grund wird es, wenn das Diagramm dieses Modellelement noch nicht darstellt, hinzugef??gt.

Verwenden Sie diese ziehen-und-loslassen-Eigenschaft, um z.B. ein Diagramm aus importierten XMI-Dateien zu erstellen. Dieses tun Sie, weil XMI-Dateien zwar alle Modellelemente, aber keine Diagramminformation enthalten.

11.2.4. Taste 2-Aktionen

Wenn sie im Explorer verwendet werden, werden sie ein auswahlabh??ngiges Popup-Men?? anzeigen. Die Men??eintr??ge sind hervorgehoben (aber nicht markiert) und Untermen??s werden durch nachfolgende Mausbewegungen ge??ffnet (ohne irgendwelche Tasten). Die Auswahl der Men??eintr??ge erfolgt mit der Taste 1 oder der Taste 2.

11.2.5. Taste 2-Doppelklick

Dies hat keinen anderen Effekt als ein einfacher Taste 2-Klick.

11.3. Verhalten der Tastatur im Explorer

Alle in einer Baumverzweigung aktiven Tasten weisen ihr normales Verhalten auf.

Wenn ein Diagramm ausgew??hlt ist, wird das Dr??cken von Strg-C das Diagramm im GIF-Format in die Zwischenablage kopieren.

11.4. Auswahl der Perspektiven

Die Modellelemente im ArgoUML-Modell k??nnen f??r die Darstellung in der Baumansicht f??r eine Anzahl von Perspektiven konfiguriert werden. Zu diesem Zweck erlaubt ein Pull-down-Men?? im oberen Bereich, die Auswahl der Explorerperspektive.

Nachfolgend gibt es ein Pull-down-Men??, um die Reihenfolge der Elemente innerhalb der Hierarchie auszuw??hlen. Die zwei M??glichkeiten sind: "Nach Typ und Name" und "Nach Name". Der vorherige gruppiert alle Elemente nach ihrem Typ und sortiert diese alfabetisch nach ihrem Namen. Der letztere sortiert einfach nur nach dem Namen.

Die folgenden Explorerperspektiven k??nnen in dem obigen Pull-down- Men?? ausgew??hlt werden:

  • Paketorientiert (der Standard). Die Hierarchie ist anhand der Pakethierarchie organisiert. Die oberste Ebene zeigt das Modell. Darunter befinden sich alle auf oberster Ebene befindlichen Pakete des Modelles und alle Modellelemente, die sich direkt im Namensraum des Modelles befinden.

    Unterhalb eines jeden Paketes befinden sich alle Modellelemente, die sich innerhalb des Namensraumes dieses Paketes befinden, einschliesslich aller weiteren Sub-Pakete (die widerum ihre eigenen Subhierarchien haben k??nnen).

  • Klassenorientiert. Zeigt Klassen in deren Pakethierarchie, genauso wie Datentypen und Elemente von Anwendungsfalldiagrammen. Sie ist der paketorientierten Sicht sehr ??hnlich, aber sie zeigt keine verbundenen oder verkn??pften Elemente.

  • Diagrammorientiert. In dieser Sicht umfasst die oberste Ebene alle Diagramme des Modelles. Unterhalb eines jeden Diagrammes befindet sich eine flache Liste aller Modellelemente des Diagrammes. Modellelemente, die Sub-Modellelemente haben, die nicht im Diagramm erscheinen, haben ihre eigene Hierarchie (zum Beispiel Attribute und Operationen von Klassen).

  • Vererbungsorientiert. In dieser Sicht zeigt die oberste Ebene das Modell. Unterhalb dieser Ebene befinden sich alle Modellelemente, die im Modell keine Generalisierung aufweisen. Modellelemente, die eine Spezialisierung aufweisen haben eine Sub-Hierarchie, welche die Spezialisierungen anzeigt.

  • Klassenassoziationsorientiert. In dieser Sicht zeigt die oberste Ebene das Modell. Darunter befinden sich alle Diagramme und alle Klassen. Alle Klassen mit Assoziationen zeigen die Hierarchie zu den assoziierten Klassen.

  • Hierarchieorientiert. In dieser Sicht wird das Modell auf der obersten Ebene dargestellt, darunter nur Knoten und unter diesen nur Komponenten, die auf den Knoten basieren. Und unter diesen Komponenten alle Elemente die auf den Komponenten basieren.

  • Zustandsorientiert. In dieser Sicht zeigt die oberste Ebene alle Zustandsautomaten und alle, mit Klassen verkn??pften Aktivit??tsgrafiken.

    Unterhalb jedes Zustandsautomaten befindet sich eine Hierarchie, die alle Zustands??bergangsdiagramme und all deren Zust??nde anzeigt.

    Unterhalb jeder Aktivit??tsgrafik befindet sich eine Hierarchie, die das Aktivit??tsdiagramm und alle seine Aktionszust??nde anzeigt. Unterhalb jedes Aktionszustandes befindet sich eine Liste von in den Aktionszustand ein- und ausgehenden ??berg??ngen.

  • ??bergangsorientiert. Dies ist sehr ??hnlich der Zustandsorientierten Sicht, aber unter jedem Zustandsautomaten sind die Diagramme und alle im Diagramm befindlichen ??bergange aufgelistet, wobei die Zust??nde als Subhierarchien unter ihren verkn??pften ??berg??ngen dargestellt werden.

    Unter jedem Aktivit??tsgrafen sind die Diagramme und alle ??berg??nge in den Diagrammen aufgelistet, wobei die Aktionszust??nde als Subhierarchien unter ihren verkn??pften ??berg??ngen dargestellt werden.

  • Anordnungsorientiert. In dieser Sicht werden alle Modellelemente entsprechend ihrer Anordnung im UML-Metamodell dargestellt.

    Diese Perspektive zeigt weit mehr Modellelemente als alle anderen - sie versteckt nichts. Aus diesem Grund ist diese Sicht nicht so anwenderfreundlich, aber sehr n??tzlich f??r den UML-Spezialisten.

11.5. Perspektiven konfigurieren

Der Explorer ist anwenderkonfigurierbar entworfen worden, um es dem Designer zu erlauben, alles auf seine oder ihre pr??ferierte Art und Weise anzeigen zu k??nnen.

11.5.1. Der Dialog Perspektiven konfigurieren

Ein Taste 1-Klick oben links im Explorer auf das Symbol "Perspektiven konfigurieren" ( ) ??ffnet den Dialog Explorer Perspektiven (siehe Abbildung 11.2, „Der Dialog Perspektiven konfigurieren“).

Abbildung 11.2. Der Dialog Perspektiven konfigurieren

Der Dialog Perspektiven konfigurieren


Die obere H??lfte des Dialoges enth??lt eine Liste aller aktuell definierten Perspektiven und rechts davon eine Reihe von untereinander angeordneten Schaltfl??chen. Der Taste 1-Klick kann zum Ausw??hlen einer Perspektive verwendet werden. Sie k??nnen gleichzeitig nur jeweils eine Perspektive ausw??hlen.

Das Markieren einer Perspektive f??llt ein Textfeld oberhalb der Liste, in dem der Name der Perspektive editiert werden kann.

Die untere H??lfte des Dialoges enth??lt zwei Listen. Die eine links, mit Regelbibliothek beschriftet, enth??lt eine Liste der verf??gbaren Regeln, die f??r das Erstellen einer Perspektive verwendet werden k??nnen. Die eine rechts, mit Ausgew??hlte Regeln beschriftet, enth??lt die, f??r die in der obigen Liste der Perspektiven markierte Perspektive aktuell ausgew??hlten Regeln. In beiden Listen k??nnen Sie nur eine Regel gleichzeitig ausw??hlen.

Als Trennung der beiden Bereiche in der unteren H??lfte des Dialoges befinden sich Schaltfl??chen, die mit >> und << beschriftet sind. Die erste davon ??bertr??gt die in der Biblothek markierte Regel von der linken Liste in die rechte— z.B. sie f??gt der Perspektive eine Regel hinzu. Die zweite ??bertr??gt die rechts markierte Regel in die Bibliotheksliste auf der Linken— z.B. sie entfernt aus der Perspektive eine Regel.

Wenn Sie die Maus ??ber die horizontale Line bewegen, die die zwei H??lften des Dialoges voneinander trennen, dann sehen Sie den ??nderungscursor, der Ihnen anzeigt, dass Sie diese Linie nehmen und nach oben oder unten ziehen k??nnen.

Alle drei Titel der Listen zeigen die Anzahl der in der Liste befindlichen Elemente an. ArgoUML Version 0.24 hat 9 Standardperspektiven und 72 Regeln in der Bibliothek, aus den Perspektiven gebildet werden k??nnen.

Die Schaltfl??chen oben rechts sind nachfolgend erkl??rt:

  • Neu. Sie erstellt eine grundlegend neue Perspektive ohne Regeln und einem automatisch generierten Namen.

  • Entfernen. Sie entfernt die markierte Perspektive.

  • Duplizieren. Sie erstellt eine Kopie der markierten Perspektive, so dass diese als Basis f??r eine neue Perspektive genutzt werden kann. Die neue wird mit "Kopie von" gefolgt vom Originalnamen bezeichnet.

  • Nach oben. Sie bewegt die markierte Perspektive um einen Platz in der Liste nach oben. Bei der obersten Perspektive ist diese Schaltfl??che deaktiviert.

  • Nach unten. Sie bewegt die markierte Perspektive um einen Platz in der Liste nach unten. Bei der letzten Perspektive ist diese Schaltfl??che deaktiviert.

  • Standards wiederherstellen. Sie stellt alle Perspektiven und deren Regeln auf die eingebauten Standards von ArgoUML ein.

Ganz unten rechts befindet sich eine Schaltfl??che mit der Beschriftung OK, die verwendet wird, wenn alle ??nderungen vervollst??ndigt sind. Ein Taste 1-Klick auf diese Schaltfl??che wird den Dialog schliessen. Die ??nderungen werden in der Datei argo.user.properties gespeichert, wenn Sie ArgoUML beenden.

Dann gibt es noch die Schaltfl??che Abbrechen, die alle im Dialog durchgef??hrten ??nderungen aufhebt. Das Bet??tigen des Dialog-Schliessen-Symboles (normalerweise in der oberen rechten Ecke) hat den gleichen Effekt, wie das Bet??tigen der Schaltfl??che Abbrechen.

11.6. Das kontextsensitive Men??

Ein Taste 2-Klick ??ber irgendeinem markierten Modellelement im Hauptbereich des Explorers veranlasst, dass ein Popup-Men?? erscheint.

11.6.1. Erstelle neues

Dieser Eintrag im Popup-Men?? ??ffnet ein Untermen?? mit Eintr??gen f??r jeden Diagrammtyp.

Der Namensraum des neuen Diagrammes, wird auf dem markierten Modellelement basieren.

11.6.2. Kopiere das Diagramm als Bild in die Zwischenablage

Dieser Eintrag im Popup-Men?? erstellt eine grafische Datei im Standard-Grafikformat und bringt es in die Zwischenablage Ihres PC. Die Grafik kann unmittelbar darauf in z.B. ein Anforderungsdokument in OpenOffice.Org kopiert werden.

Das Grafikformat und seine Aufl??sung werden durch die Standardeinstellungen von ArgoUML bestimmt: W??hlen Sie das Men?? Bearbeiten, dann Einstellungen... und dann das Register Umgebung aus. Die PNG und GIF-Formate und die Aufl??sung Standard werden empfohlen.

[Tipp]Tipp

Einige Anwendungen (wie z.B. Doors von Telelogic) erfordern es, dass die Hintergrundfarbe der generierten Grafik angepasst wird (es sei denn, das Bild ist leer). Dies kann mit einem Tool wie IrfanView durchgef??hrt werden; es ist genauso leicht wie das Klicken dessen Schaltfl??che Einf??gen und dann dessen Schaltfl??che Kopieren.

11.6.3. Zum Diagramm hinzuf??gen

Dieser Eintrag im Popup-Men?? erscheint bei jedem Modellelement, welches dem Diagramm im Editierfenster hinzugef??gt werden kann.

Das Element kann in ein Diagramm durch Bewegen des Cursors in das Editierfenster oder ein gedoppeltes Editierfenster (wobei es als Kreuz erscheint) und klicken mit der Taste 1 plaziert werden.

[Achtung]Achtung

Dieser Men??eintrag erscheint nur dann als nicht deaktiviert, wenn es das Diagramm im Editierfenster erlaubt, das dieses Modellelement enthalten sein darf und das Modellelement sich nicht bereits in dem Diagramm befindet. ArgoUML l????t es nicht zu, dass Sie mehr als eine Kopie eines bestimmten Modellelementes in ein Diagramm plazieren.

11.6.4. Aus Modell entfernen

Dieser Eintrag im Popup-Men?? erscheint bei jedem Modellelement, welches aus dem Modell gel??scht werden kann.

[Warnung]Warnung

Dies l??scht das Modellelement vollst??ndig aus dem Modell, nicht nur aus dem Diagramm. Um das Modellelement nur aus dem Diagramm zu entfernen, benutzen Sie das Bearbeiten-Men?? (siehe Abschnitt 10.4.2, „ Aus Diagramm entfernen “).

[Achtung]Achtung

Sie k??nnen ein Diagramm aus dem Modell entfernen. Je nach Typ des Diagrammes, kann das alle Modellelemente l??schen, die in dem Diagramm angezeigt werden. Um die Unterschiede zu illustrieren, betrachten Sie die folgenden Beispiele:

  • Das L??schen eines Klassendiagrammes l??scht nicht jedes Modellelement, das darin angezeigt wird. Alle Modellelemente die im Diagramm angezeigt werden, bleiben im Modell erhalten. Dies ist so, weil ein Klassendiagramm nicht auf jedes Modellelement entsprechend dem UML-Standard V1.4 " abgebildet" wird.

  • Das L??schen eines Zustandsdiagrammes l??scht auch den Zustandsautomaten, den es repr??sentiert und behandelt auch alle Modellelemente des Zustandsautomaten auf die gleiche Weise. Dies ist so, weil ein Zustandsdiagramm entsprechend dem UML-Standard V1.4 nicht auf einen Zustandsautomaten "abgebildet" wird.

11.6.5. Einstellen des Quellpfades... (Noch zu beschreiben)

Dieser Eintrag im Popup-Men?? ...

11.6.6. Paket hinzuf??gen

Dieser Eintrag im Popup-Men?? ist verf??gbar, wannimmer ein Modellelement markiert ist, das ein Paket enthalten darf, z.B. ein Paket. Nach dem Aktivieren dieses Men??s wird das Modellelement ein neues Paket enthalten.

11.6.7. Neuer Stereotyp

Dieser Eintrag im Popup-Men?? ist verf??gbar ... (Noch zu beschreiben)

11.6.8. Alle Klassen im Namensraum hinzuf??gen

Dieser Eintrag im Popup-Men?? ist nur bei Klassendiagrammen verf??gbar. Das Aktivieren dieses Men??eintrages wird alle Klassen des aktuellen Namensraumes zum Diagramm hinzuf??gen. Sie werden in der oberen linken Ecke angeordnet; offensichtlich eine g??nstige Gelegenheit, die im Men?? befindliche „Anordnen->Layout“-Funktion zu verwenden.

Kapitel 12. Das Editierfenster

12.1. Einleitung

Abbildung 12.1, „??berblick ??ber das Editierfenster“ zeigt das ArgoUML-Fenster mit dem hervorgehobenen Editierfenster.

Abbildung 12.1. ??berblick ??ber das Editierfenster

??berblick ??ber das Editierfenster


Darin werden alle Diagramme gezeichnet. In fr??heren Versionen von ArgoUML firmierte dieses Fenster unter verschiedenen Namen. Sie werden die Begriffe „Zeichenfenster“, „ Diagrammfenster“ oder „Multi-Editorfenster“ in anderen, noch nicht aktualisierten Dokumentationen vorfinden.

Das Fenster hat oben eine Werkzeugleiste und unten ein einziges mit Als Diagramm beschriftetes Register, das in Version 0.20 von ArgoUML keine Funktion hat. Der Hauptbereich zeigt das aktuell ausgew??hlte Diagramm, dessen Name in der Titelzeile des Fensters angezeigt wird.

12.2. Das Verhalten der Maus im Editierfenster

Das generelle Verhalten der Maus und die Benennung der Tasten ist im Kapitel ??berblick ??ber die Anwenderschnittstelle ausgef??hrt ( siehe Kapitel 8, Einleitung).

12.2.1. Taste 1-Klick

In der Werkzeugleiste des Editierfensters wird der Taste 1-Klick dazu verwendet, ein Werkzeug f??r das Erstellen eines neuen Modellelementes auszuw??hlen und dieses dem Diagramm hinzuzuf??gen ( siehe Doppelklicken zum Erstellen mehrerer Modellelemente). Das Hinzuf??gen eines neuen Modellelementes zum Diagramm wird bei den meisten Werkzeugen durch bewegen der Maus in den Editierbereich und erneutes klicken bewerkstelligt.

Im Haupteditierbereich wird der Taste 1-Klick dazu verwendet, ein individuelles Modellelement zu markieren.

Viele Modellelemente (z.B. Akteur, Klasse) zeigen spezielle Verhaltensweisen, wenn sie markiert sind und die Maus dar??ber f??hrt. Diese werden „Auswahl-Aktionsschaltfl??chen“ genannt, siehe Abschnitt 12.6, „Auswahl-Aktionsschaltfl??chen“. Sie erscheinen an den Seiten, oben und unten und geben einen Beziehungstyp an. Klicken auf eine Auswahl-Aktionsschaltfl??che erstellt eine neues Modellelement mit einer Beziehung des angezeigten Typs. Wenn die Umschalttaste gedr??ckt ist, wenn die Maus ??ber ein markiertes Modellelement f??hrt, werden manchmal unterschiedliche Griffe angezeigt. Sie stehen f??r unterschiedliche Beziehungstypen.

Wo der Taste 2-Klick verwendet wurde, um ein kontextsensitives Popup-Men?? zu ??ffnen (siehe unten), wird der Taste 1-Klick dazu verwendet, den gew??nschten Men??eintrag auszuw??hlen. Das Popup-Men?? wird durch einen beliebigen Taste 1-Klick ausserhalb des Men??bereiches entfernt.

Es gibt verschiedene noch detailliertere Effekte, die in den Beschreibungen der verschiedenen Werkzeuge diskutiert werden (siehe Abschnitt 12.4, „Die Werkzeugleiste“).

12.2.2. Taste 1-Doppelklick

Wenn dies in der Werkzeugleiste mit einem Werkzeug zum Hinzuf??gen eines Modellelementes verwendet wird, wird das markierte Modellelement dem Zeichenbereich mehrmals hinzugef??gt. Einmal f??r jeden weiteren Tastenklick, bis das Werkzeug erneut markiert oder ein anderes Werkzeug ausgew??hlt wird.

Wenn er innerhalb des Zeichenbereiches auf einem Modellelement mit Subkomponenten verwendet wird, wird der Doppelklick die Subkomponente zum Editieren ausw??hlen (wenn notwendig, wird eine erstellt).

Das Doppelklicken ??ber einem Operationsbereich einer Klasse wird die Operation ausw??hlen. Oder eine erstellen, sofern noch keine vorhanden ist.

Eine spezielle Anwendung gibt es mit Paket-Modellelementen im Klassendiagramm. Ein Doppelklick auf ein Paket bringt Sie zu dem mit einem Paket verkn??pften Klassendiagramm (das erste wird erstellt, wenn es mehr als eines gibt) oder bietet Ihnen an, eines f??r Sie zu erstellen, wenn keines vorhanden ist. Siehe Abbildung 12.2, „ Der Dialog f??r das Hinzuf??gen eines neuen Klassendiagrammes “

Abbildung 12.2. Der Dialog f??r das Hinzuf??gen eines neuen Klassendiagrammes

Der Dialog f??r das Hinzuf??gen eines neuen Klassendiagrammes


12.2.3. Taste 1-Bewegung

Wo das Modellelement hinzugef??gt wurde, wird mit dem Taste 1- Klick ??ber dem abschliessenden Modellelement eine besondere Form eines Verbinders mit seinem Endpunkt angezeigt. Der Taste 1- Klick darf auch im Raum zwischen den Modellelementen verwendet werden, um Verbindungspunkte an einem Verbinder zu erstellen. Dies ist immer dann n??tzlich, wo Verbinder auf sich selbst erstellt werden m??ssen.

??ber grafischen Modellelementen wird die Taste 1-Bewegung das Modellelement an eine neue Position bewegen.

Grafische, markierte Modellelemente zeigen Griffe an den Ecken oder Enden an. Diese k??nnen f??r Gr????en??nderungen verwendet werden.

Einige Modellelemente (z.B. Akteur, Klasse) zeigen spezielle Griffe („Auswahl-Aktionsschaltfl??chen“, siehe Abschnitt 12.6, „Auswahl-Aktionsschaltfl??chen“) an den Seiten, oben und unten an, die gezogen werden k??nnen, um Beziehungstypen zwischen anderen Modellelementen zu bilden.

Wo das Modellelement eine Form von Verbinder zwischen anderen Elementen ist, verursacht die Taste 1-Bewegung neben den Griffen die Erstellung eines neuen Griffes, der es dem Verbinder erlaubt, sich mit diesem Punkt zu verbinden. Dies funktioniert nur, wenn die verbindende Linie nicht gerade rechtwinklig ist. Solche neuen Griffe k??nnen durch das Bewegen auf das Ende des Verbinders entfernt werden.

Es gibt verschiedene noch detailliertere Effekt, die in den Beschreibungen der verschiedenen Werkzeuge diskutiert werden (siehe Abschnitt 12.4, „Die Werkzeugleiste“).

12.2.4. Umschalt- und Strg-Taste und die Taste 1

Wo mehrere Markierungen zu erstellen sind, wird die Strg-Taste mit der Taste 1 verwendet, um unmarkierte Modellelemente den aktuell markierten hinzuzuf??gen. Wo ein Modellelement bereits markiert ist, wird es aus der aktuellen Markierung entfernt.

Klicken auf die Taste 1 w??hrend die Umschalttaste gedr??ckt ist, aktiviert das Werkzeug Besen. Dieses veranlasst, dass die markierten Modellelemente (und alles andere mitbewegt wird) durch den Besen verschoben wird (siehe Abschnitt 12.4.1, „Layout-Werkzeuges“).

12.2.5. Alt Gr mit Taste 1-Bewegung

Das Dr??cken der Taste 1 im Diagramm, w??hrend die "ALT Gr"-Taste gedr??ckt ist, erlaubt es, die Leinwand mit der Taste 1- Bewegung in alle Richtungen zu scrollen.

12.2.6. Taste 2-Aktionen

Wenn sie ??ber Modellelementen im Editierfenster verwendet wird, wird ein kontextabh??niges Popup-Men?? erscheinen. Die Men??eintr??ge sind aktiviert (aber nicht ausgew??hlt) und die Untermen??s werden durch die fortgesetzte Mausbewegung aufgeblendet (ohne irgend eine Taste). Die Men??eintr??ge werden mit Taste 1 oder Taste 2 ausgew??hlt. Details ??ber die spezifischen Popup-Men??s siehe Abschnitt 12.10, „Pop-Up Men??'s“.

F??r den Fall, dass mehrere Elemente markiert sind, erscheint das Popup-Men?? nur, wenn alle Elemente von der gleichen Art sind. In diesem Fall, wirken die Funktionen auf alle markierten Elemente.

12.2.7. Taste 2-Doppelklick

Dies hat keinen anderen Effekt als der einfache Taste 2-Klick.

12.2.8. Taste 2-Bewegung

Sie wird verwendet, um Elemente in einem mit Hilfe eines Taste 2-Klicks ge??ffneten kontextsensitiven Men?? zu markieren.

12.3. Das Verhalten der Tastatur im Editierfenster

Viele Tastenk??rzel k??nnen verwendet werden, wenn das Editierfenster aktiv ist. Haupts??chlich, um die Markierung zu ??ndern oder sich durch die Modellelemente zu bewegen.

12.3.1. Schrittweises bewegen eines Modellelementes

Sie k??nnen ein Gebilde durch das markieren eines Elementes und die Verwendung der Pfeiltasten schrittweise bewegen. Das gedr??ckt halten der Umschalt- oder Alt-Taste wird eine gr??ssere Bewegung produzieren.

12.3.2. Durch die Modellelemente bewegen

Sie k??nnen das dem markierten am n??chsten stehende Modellelement markieren, indem Sie die Pfeiltasten verwenden, w??hrend Sie die rechte Maustaste anklicken. Sie k??nnen auch das n??chste Modellelement mit Hilfe der Tab-Taste markieren oder das vorhergehende mit Hilfe der Strg+Tab-Tasten.

12.4. Die Werkzeugleiste

Die Werkzeugleiste im oberen Bereich des Editierfensters enth??lt die Hauptfunktionen des Fensters. Das Standardwerkzeug ist das Auswahl-Werkzeug ( ). Generell w??hlt ein Taste 1-Klick auf irgendein Werkzeug dieses f??r die einmalige Verwendung aus, bevor es zum Standardwerkzeug zur??ckkehrt. Und ein Taste 1-Doppelklick w??hlt ein Werkzeug f??r die wiederholte Nutzung aus.

Die Werkzeuge fallen in vier Kategorien.

  • Layout-Werkzeuge. Geben Unterst??tzung bei der Anordnung der Modellelemente im Diagramm.

  • Kommentierungswerkzeuge. Werden zum Kommentieren von Modellelementen im Diagramm verwendet.

  • Zeichen-Werkzeuge. Werden zum Hinzuf??gen grafischer Objekte in Diagrammen verwendet.

  • Diagrammspezifische Werkzeuge. Werden zum Hinzuf??gen von diagrammspezifischen UML-Modellelementen in das Diagramm verwendet.

Einige Werkzeuge, die normalerweise nicht so oft verwendet werden, sind in ein Pulldown-Men?? aufgenommen worden, damit sie in der Werkzeugleiste weniger Platz beanspruchen. Siehe z.B. Abbildung 12.3, „Die Zeichen-Werkzeuge ausw??hlen.“. Das Dr??cken des Symboles auf der rechten Seite des Werkzeuges ??ffnet das Pulldown-Men??. Diese Pulldown-Werkzeuge erinnern sich dauerhaft, welches Werkzeug zuletzt verwendet wurde. Das hei??t, wenn ArgoUML startet zeigen sie das zuletzt aktivierte Werkzeug an.

12.4.1. Layout-Werkzeuges

Die folgenden beiden Werkzeuge werden in allen Diagrammen dieser Kategorie vorausgesetzt.

  • Ausw??hlen. Dieses Werkzeug sorgt f??r die generelle Auswahl von Modellelementen im Diagramm. Der Taste 1-Klick wird ein Modellelement markieren. Strg und die Taste 1 kann dazu verwendet werden, mehrere Modellelemente zu markieren (oder die Markierung aufzuheben). Die Taste 1-Bewegung wird markierte 2D-Elemente bewegen oder hinzuf??gen und bewegen eines neuen Griffes auf einer Verkn??pfung. Die Taste 1-Bewegung auf einem markierten Griff einer Komponente wird die Form der Komponente dehnen.

  • Besen. Die Taste 1-Bewegung mit diesem Werkzeug liefert einen „Besen“, der alle Modellelemente mitnimmt. Dies ist ein sehr schneller Weg, Dinge auszurichten.

    Der Besen kann auch durch die Umschalttaste mit der Taste 1-Bewegung ausgel??st werden, wenn das Werkzeug Ausw??hlen aktiv ist.

    Der Besen wird ausf??hrlich in seinem eigenen Kapitel diskutiert, siehe Abschnitt 12.5, „Der Besen“

[Tipp]Tipp

Zus??tzliche Beeinflussungsm??glichkeiten des Modellelementelayout sind ??ber das Men?? Anordnen verf??gbar (siehe Abschnitt 10.7, „Das Men?? Anordnen“).

12.4.2. Kommentierungs-Werkzeug

Das Kommentierungs-Werkzeug Kommentar ( ) wird dazu verwendt, einen Kommentar zu einem markierten UML- Modellelement hinzuzuf??gen.

[Achtung]Achtung

Wie bei den meisten anderen Werkzeugen verwenden Sie das Werkzeug Ausw??hlen, um ein Modellelement zu markieren und dann den Taste 1-Klick auf Kommentar , um einen Kommentar zu erstellen. Wenn kein Element markiert ist, wenn das Werkzeug Kommentar angeklickt wird, dann wird der Kommetar erstellt und in die linke obere Ecke plaziert.

Der Kommetar wird neben dem markierten Modellelement erstellt und ist standardm????ig leer. Die Texteingabe kann mit einem Taste 1- Doppelklick aktiviert und der Text anschliessend mit Hilfe der Tastatur eingegeben werden.

Der UML-Standard erlaubt es, Kommentare zu jedem Modellelement hinzuzuf??gen.

Sie k??nnen jeden Kommentar mit weiteren Elementen mit Hilfe des Werkzeuges Neue Kommentar-Verkn??pfung ( ) verbinden.

12.4.3. Zeichen-Werkzeuge

Dies sind eine Reihe von Werkzeugen, die grafische Zus??tze zu Diagrammen liefern. Obwohl sie keine UML-Modellelemente sind, erlaubt der UML-Standard solche Ausschm??ckungen, um die Lesbarkeit der Diagramme zu verbessern.

[Tipp]Tipp

Diese Zeichen-Werkzeuge stellen einen n??tzlichen Weg dar, einige der in der aktuellen Release von ArgoUML fehlenden UML-Eigenschaften (wie z.B. generelle Zweck-Hinweise )teilweise zu unterst??tzen.

Acht Werkzeuge sind vorhanden, alle in einem Pulldown-Men?? gruppiert. Siehe Abbildung 12.3, „Die Zeichen-Werkzeuge ausw??hlen.“. Ein Taste 1-Klick auf das Diagramm wird eine Instanz des grafischen Elementes in der gleichen Gr????e wie das letzte plazieren. Die Gr????e kann durch eine Taste 1-Bewegung w??hrend des Plazierens eingestellt werden. Eine Seite oder Ende des Elementes wird durch Taste 1-gedr??ckt die andere Seite oder Ende durch Taste 1- loslassen beeinflusst. Nachdem sie im Diagramm plaziert wurden, k??nnen die grafischen Elemente mit dem Werkzeug Ausw??hlen und der Taste 1 verschoben und in der Gr????e durch eine Taste 1-Bewegung ??ber die Griffe nach dem markieren ver??ndert werden.

Abbildung 12.3. Die Zeichen-Werkzeuge ausw??hlen.

Die Zeichen-Werkzeuge ausw??hlen.


  • Rechteck. Erzeugt ein Rechteck.

  • Abgerundetes Rechteck. Erzeugt ein Rechteck mit abgerundeten Ecken. Der Grad der Rundung kann nicht eingestellt werden.

  • Kreis. Erzeugt einen Kreis.

  • Gerade. Erzeugt eine Gerade.

  • Text. Erzeugt ein Textfeld. Der Text wird durch markieren des Feldes und schreiben eingegeben. Der Text wird nach der Eingabe horizontal zentriert. Das Feld passt sich an die Gr????e des Textes an. Es kann jedoch in der Gr????e durch ziehen an den Ecken ver??ndert werden.

  • Polygon. Erzeugt ein Polygon. Die Punkte des Polygons werden durch Taste 1-Klicks markiert. Das Polygon wird durch einen Taste 1-Doppelklick abgeschlossen (dies verbindet den letzten mit dem ersten Punkt).

  • Segmentierte Linie. Erzeugt eine segmentierte Linie. Die Punkte der segmentierten Linie werden mit Taste 1-Klicks markiert und der letzte Punkt mit einem Taste 1-Doppelklick ausgew??hlt.

  • Punktierte Linie. Erzeugt eine punktierte Linie. Die Punkte werden durch eine Taste 1-Bewegung erzeugt.

12.4.4. Anwendungsfalldiagrammspezifische Werkzeuge

Verschiedene Werkzeuge sind speziell f??r UML-Modellelemente in Anwendungsfalldiagrammen vorhanden. Die detaillierten Eigenschaften dieser Modellelemente sind im Abschnitt ??ber Modellelemente von Anwendungsfalldiagrammen beschrieben (siehe Kapitel 17, Use Case Diagram Model Element Reference).

  • Akteur. F??r dem Diagramm einen Akteur hinzu. Wenn sich die Maus ??ber einem markierten Akteur befindet, werden aus Gr??nden des Komforts links und rechts zwei Griffe angezeigt, die gezogen werden k??nnen, um Assoziationsbeziehungen herzustellen.

  • Anwendungsfall. F??gt dem Diagramm einen Anwendungsfall hinzu. Wenn sich die Maus ??ber einem markierten Anwendungsfall befindet, werden aus Gr??nden des Komforts links und rechts zwei Griffe angezeigt, die gezogen werden k??nnen, um Assoziationsbeziehungen herzustellen und zwei Griffe oben und unten, die gezogen werden k??nnen, um Generalisierungen und Spezialisierungen herzustellen.

  • Assoziation. F??gt zwischen zwei Modellelementen eine Assoziation mit Hilfe einer Taste 1- Bewegung ein (vom ersten bis zum zweiten Modellelement). Es werden hier 6 Assoziationstypen angeboten, siehe Abbildung 12.4, „Die Assoziations-Werkzeuge ausw??hlen.“: Assoziation, Aggregation und Komposition, und all diese drei k??nnen bidirektional oder unidirektional sein.

    Abbildung 12.4. Die Assoziations-Werkzeuge ausw??hlen.

    Die Assoziations-Werkzeuge ausw??hlen.


  • Abh??ngigkeit. F??gt eine Abh??ngigkeit zwischen zwei Modellelementen mit Hilfe der Taste 1- Bewegung ein (vom abh??ngigen Modellelement).

  • Generalisierung. F??gt eine Generalisierung zwischen zwei Modellelementen mit Hilfe der Taste 1- Bewegung ein (vom Kind zu den Eltern).

  • Extend. F??gt eine Extend-Beziehung zwischen zwei Modellelementen mit Hilfe der Taste 1- Bewegung ein (vom erweiterten zum zu erweiternden Anwendungsfall).

  • Include. F??gt eine Include-Beziehung zwischen zwei Modellelementen mit Hilfe der Taste 1- Bewegung ein (vom einschliessenden zum eingeschlossenen Anwendungsfall).

  • Erweiterungspunkt hinzuf??gen. Einen Erweiterungspunkt zu einem markierten Anwendungsfall hinzuf??gen. Dem Erweiterungspunkt wird der Standardname neuerEP gegeben und der Ort ort . Wo ein Erweiterungspunktbereich angezeigt wird, kann der Erweiterungspunkt mit Hilfe eines Taste 1- Doppelklicks und der Tastatur, oder durch markieren mit einem Taste 1-Klick (nachdem der Anwendungsfall markiert wurde) und Verwendung des Registers Eigenschaften editiert werden. Ansonsten kann es ??ber sein Register Eigenschaften editiert werden, welches ??ber das Register Eigenschaften des besitzenden Anwendungsfalles ausgew??hlt wird.

    [Anmerkung]Anmerkung

    Dieses Werkzeug ist deaktiviert, es sei denn, ein Anwendungsfall ist markiert.

12.4.5. Klassendiagrammspezifische Werkzeuge

Einige Werkzeuge sind speziell f??r UML-Modellelemente in Klassendiagrammen gedacht. Die detaillierten Eigenschaften dieser Modellelemente sind im Abschnitt ??ber Klassendiagramm-Modellelemente beschrieben (siehe Kapitel 18, Class Diagram Model Element Reference).

  • Paket. F??gt dem Diagramm ein Paket hinzu.

  • Klasse. F??gt dem Diagramm eine Klasse hinzu. Wenn sich die Maus ??ber einer markierten Klasse befindet, werden links und rechts zwei Griffe angezeigt, die angeklickt oder gezogen werden k??nnen, um eine Assoziations-Beziehung herzustellen (oder eine Komposition, sofern die Umschalt-Taste gedr??ckt wurde) und oben und unten zwei Griffe, die angeklickt oder gezogen werden k??nnen, um eine Generalisierungs- und Spezialisierungs-Beziehung herzustellen.

  • Assoziation. F??gt zwischen zwei Modellelemente mit Hilfe einer Taste 1-Bewegung eine Assoziation ein (vom ersten Modellelement zum zweiten). Es werden hier 2 Typen von Assoziationen angeboten, die bidirektionale oder die unidirektionale.

  • Aggregation. F??gt zwischen zwei Modellelemente mit Hilfe einer Taste 1-Bewegung eine Aggregation ein (vom ersten Modellelement zum zweiten). Es werden hier 2 Typen von Aggregationen angeboten, die bidirektionale oder die unidirektionale.

  • Komposition. F??gt zwischen zwei Modellelemente mit Hilfe einer Taste 1-Bewegung eine Komposition ein (vom ersten Modellelement zum zweiten). Es werden hier 2 Typen von Kompositionen angeboten, die bidirektionale oder die unidirektionale.

  • Assoziationsende. F??gt mit Hilfe der Taste 1 ein anderes Ende zu einer bereits existierenden Assoziation ein (von der Assoziation einer Klasse, oder umgekehrt). Auf diesem Weg werden sogenannte N-wertige Assoziationen erstellt.

  • Generalisierung. F??gt mit Hilfe der Taste 1 zwischen zwei Modellelementen eine Generalisierung ein (vom Kind zum Vater).

  • Schnittstelle. F??gt in das Diagramm eine Schnittstelle ein. Wenn sich die Maus ??ber einer markierten Schnittstelle befindet, wird unten ein Griff angezeigt, der gezogen werden kann, um eine Realisierungs-Beziehung herzustellen (das Ziel wird die zu realisierende Klasse).

  • Realisierung. F??gt eine Realisierung mit Hilfe einer Taste 1-Bewegung zwischen eine Klasse und einer Schnittstelle ein (von der realisierenden Klasse zur realisierten Schnittstelle).

  • Abh??ngigkeit. F??gt eine Abh??ngigkeit mit Hilfe einer Taste 1-Bewegung zwischen zwei Modellelementen ein (vom abh??ngigen Modellelement). Es werden hier auch 2 spezielle Typen von Abh??ngigkeiten angeboten, Erlaubnis Add a dependency between two model elements selected using button 1 motion (from the dependent model element). There are also 2 special types of dependency offered here, Permission ( ) und Verwendung ( ). Eine Erlaubnis wird standardm????ig mit dem Stereotyp Import erstellt und wird verwendet, um Elemente von einem Paket in ein anderes zu importieren.

  • Attribut. F??gt ein Attribut zu der aktuell markierten Klasse hinzu. Das Attribut erh??lt den Standardnamen neuesAttr vom Typ int und kann durch einen Taste 1-Doppelklick und der Tastatur editiert werden oder durch ausw??hlen mit einem Taste 1- Klick (nachdem die Klasse markiert wurde) und anschliessender Nutzung des Registers Eigenschaften.

    [Anmerkung]Anmerkung

    Dieses Werkzeug ist deaktiviert, au??er wenn eine Klasse markiert ist.

  • Operation. F??gt der aktuell markierten Klasse oder Schnittstelle eine Operation hinzu. Die Operation erh??lt den Standardnamen neueOperation ohne Argumente und dem R??ckgabewert void und kann mit Hilfe eines Taste 1-Doppelklicks und der Tastatur editiert werden, oder durch ausw??hlen mit einem Taste 1-Klick (nachdem die Klasse markiert wurde) und der Nutzung des Registers Eigenschaften.

    [Anmerkung]Anmerkung

    Dieses Werkzeug ist deaktiviert, es sei denn, eine Klasse oder eine Schnittstelle ist markiert.

  • Assoziationsklasse. F??gt eine neue Assoziationsklasse mit Hilfe einer Taste 1-Bewegung zwischen zwei Modellelemente ein (vom ersten Modellelement zum zweiten).

  • Datentyp. F??gt in das Diagramm einen Datentyp ein. Wenn sich eine Maus ??ber einem markierten Datentyp befindet werden oben und unten Griffe angezeigt, die angeklickt oder gezogen werden k??nnen, um eine Generalisierungs-Beziehung herzustellen (das Ziel kann ein anderer Datentyp sein). Es sind hier 2 andere Elemente verf??gbar, Aufz??hlung und Stereotyp. Diese haben identische Griffe, au??er dem oben an einem Stereotyp befindlichen: wenn er angeklickt wird, erstellt er eine Metaklasse, die ??ber eine mit «stereotype» markierte Abh??ngigkeit verkn??pft ist. Dies erleichtert die Erstellung von "Stereotyp-Deklarations"-Diagrammen - n??heres entnehmen Sie bitte der Literatur.

12.4.6. Sequenzdiagrammspezifische Werkzeuge

Sieben Werkzeuge sind speziell f??r UML-Modellelemente in Sequenzdiagrammen vorhanden. Die detaillierten Eigenschaften dieser Modellelemente sind im Abschnitt ??ber Sequenzdiagramm-Modellelemente beschrieben (siehe Kapitel 19, Sequence Diagram Model Element Reference).

  • Klassifizierte Rolle. F??gt dem Diagramm eine klassifizierte Rolle hinzu.

  • Nachricht mit Aufruf einer Aktion. F??gt eine Aufruf-Nachricht zwischen zwei klassifizierten Rollen mit Hilfe einer Taste 1-Bewegung ein (von der verursachenden klassifizierten Rolle zur empfangenden klassifizierten Rolle).

  • Nachricht mit Antwort-Aktion. F??gt eine Antwort-Nachricht mit Hilfe einer Taste 1-Bewegung zwischen zwei klassifizierten Rollen ein (von der verursachenden klassifizierten Rolle zur empfangenden klassifizierten Rolle).

  • Nachricht mit einer Erzeugen-Aktion. F??gt eine Erzeugungs-Nachricht mit Hilfe einer Taste 1-Bewegung zwischen zwei klassifizierten Rollen ein (von der verursachenden klassifizierten Rolle zur empfangenden klassifizierten Rolle).

  • Nachricht mit Destruktions-Aktion. F??gt eine Destruktions-Nachricht mit Hilfe einer Taste 1-Bewegung zwischen zwei klassifizierten Rollen ein (von der verursachenden klassifizierten Rolle zur empfangenden klassifizierten Rolle).

  • Vertikalen Zwischenraum in Diagramm einf??gen. F??gen Sie vertikalen Zwischenraum in ein Diagramm ein, indem Sie alle nachfolgenden Nachrichten nach unten verschieben. Klicken Sie mit der Maus auf den Punkt, wo Sie den Zwischenraum einf??gen wollen und ziehen Sie auf dem Bildschirm vertikal um den Abstand nach unten, der der H??he des gew??nschten hinzuzuf??genden Zwischenraumes entspricht.

  • Vertikalen Zwischenraum im Diagramm entfernen . Entfernt den vertikalen Zwischenraum im Diagramm und bewegt alle nachfolgenden Elemente vertikal nach oben. Klicken und ziehen Sie die Maus vertikal ??ber den Zwischenraum, den Sie l??schen wollen.

12.4.7. Kollaborationsdiagrammspezifische Werkzeuge

Drei Werkzeuge sind speziell f??r UML-Modellelemente in Kollaborationsdiagrammen vorhanden. Die detaillierten Eigenschaften dieser Modellelemente sind im Abschnitt ??ber Kollaborationsdiagramm- Modellelemente beschrieben (siehe Kapitel 21, Collaboration Diagram Model Element Reference ).

  • Klassifizierte Rolle. F??gt dem Diagramm eine klassifizierte Rolle hinzu.

  • Assoziation. F??gt eine Assoziation mit Hilfe einer Taste 1-Bewegung zwischen zwei klassifizierten Rollen ein (von der verursachenden Rolle zur empfangenden Rolle). Es werden hier 6 Typen von Assoziationen angeboten, siehe Abbildung 12.4, „Die Assoziations-Werkzeuge ausw??hlen.“: Assoziation, Aggregation und Komposition, und all diese drei k??nnen bidirektional oderr unidirektional sein.

  • Generalisierung. F??gt eine Generalisierung zwischen zwei Modellelementen ein, die mit der Taste 1 markiert wurden (von Kind zum Vater).

  • Abh??ngigkeit. F??gt eine Abh??ngigkeit zwischen zwei Modellelementen ein, die mit einer Taste 1- Bewegung markiert wurden (vom abh??ngigen Modellelement).

  • Nachricht hinzuf??gen. F??gt zum markierten Assoziatationstyp eine Nachricht hinzu.

    [Anmerkung]Anmerkung

    Dieses Werkzeug ist deaktiviert, es sei denn, eine Assoziation ist markiert.

12.4.8. Zustandsdiagrammspezifische Werkzeuge

Elf Werkzeuge speziell f??r UML-Modellelemente in Zustandsdiagrammen sind vorhanden. Die detaillierten Eigenschaften dieser Modellelemente sind im Abschnitt Zustandsdiagramm-Modellelemente beschrieben (siehe Kapitel 20, Statechart Diagram Model Element Reference).

  • Zustand. F??gt dem Diagramm einen Zustand hinzu.

  • Zusammengesetzter Zustand. F??gt dem Diagramm einen zusammengesetzten Zustand hinzu. Alle Modellelemente die nachfolgend im Diagramm auf dem zusammengesetzten Zustand plaziert werden, werden Teil des zusammengesetzten Zustandes.

  • Transition (??bergang). F??gt eine Transition (einen ??bergang) mit Hilfe einer Taste 1-Bewegung zwischen zwei Zust??nden ein (von dem verursachenden Zustand zu dem empfangenden Zustand).

  • Synchronistations-Zustand. F??gt dem Diagramm einen Synchronisations-Zustand hinzu.

  • Teilautomatenzustand. F??gt dem Diagramm einen Teilautomatenzustand hinzu.

  • Teilzustand. F??gt dem Diagramm einen Teilzustand hinzu.

  • Startzustand. F??gt in das Diagramm einen Pseudo-Startzustand ein.

    [Achtung]Achtung

    Es gibt nichts zu stoppen, wenn Sie dem Diagramm mehr als einen Startzustand oder zusammengesetzten Zustand hinzuf??gen. So etwas zu tun ist bedeutungslos und es wird eine der Kritiken erscheinen.

  • Endzustand. F??gt in das Diagramm einen Endzustand ein.

  • Kreuzung. F??gt in das Diagramm einen Pseudo-Kreuzungszustand ein.

    [Achtung]Achtung

    Eine wohlgeformte Kreuzung sollte mindestens eine kommende und mindestens ein ausgehende Transition haben. ArgoUML erzwingt dies nicht, aber es erscheint eine Kritik bei jeder Kreuzung, die dieser Regel nicht folgt.

  • Entscheidung. F??gt in das Diagramm einen Entscheidungs-Pseudozustand ein.

    [Achtung]Achtung

    Eine wohlgeformte Entscheidung sollte mindestens eine kommende und mindestens ein ausgehende Transition haben. ArgoUML erzwingt dies nicht, aber es erscheint eine Kritik bei jeder Entscheidung, die dieser Regel nicht folgt.

  • Gabelung. F??gt in das Diagramm einen Gabelungs-Pseudozustand ein.

    [Achtung]Achtung

    Eine wohlgeformte Gabelung sollte genau eine kommende und und zwei oder mehr ausgehende Transitionen haben. ArgoUML erzwingt dies nicht, aber es erscheint eine Kritik bei jeder Gabelung, die dieser Regel nicht folgt.

  • Vereinigung. F??gt in das Diagramm einen Vereinigungs-Pseudozustand ein.

    [Achtung]Achtung

    Eine wohlgeformte Vereinigung sollte genau eine kommende und zwei oder mehr ausgehende Transitionen haben. ArgoUML erzwingt dies nicht, aber es erscheint eine Kritik bei jeder Vereinigung, die dieser Regel nicht folgt.

  • Flache Historie. F??gt in ein Diagramm eine flache Historie ein.

  • Tiefgehende Historie. F??gt in das Diagramm eine tiefgehende Historie ein.

  • Aufruf-Ereignis. F??gt einer Transition ein Aufruf-Ereignis als Trigger hinzu. Es werden hier 4 Ereignisarten angeboten: Aufruf-Ereignis, ??nderungs-Ereignis, Signal-Ereignis und Zeit-Ereignis.

  • W??chter. F??gt einer Transition einen W??chter hinzu.

  • Aufruf-Aktion. F??gt einer Transition (z.B. einem Effekt) eine Aufruf-Aktion hinzu. Es werden hier 7 Arten von Aktionen angeboten: Aufruf-Aktion, Erzeugungs-Aktion, Zerst??ren-Aktion, Antwort-Aktion, Sende-Aktion, Beenden-Aktion, Uninterpretierte Aktion und Aktionsfolge.

12.4.9. Aktivit??tsdiagrammspezifische Werkzeuge

Es sind sieben Werkzeuge vorhanden, die speziell f??r UML- Modellelemente in Aktivit??tsdiagrammen geschaffen wurden. Die detaillierten Eigenschaften dieser Modellelemente werden im Abschnitt Modellelemente in Aktivit??tsdiagrammen beschrieben (siehe Kapitel 22, Activity Diagram Model Element Reference).

  • Aktion. Sie f??gen dem Diagramm eine Aktion hinzu.

  • Transition. Sie f??gen mit Hilfe einer Taste 1-Bewegung eine Transition zwischen zwei markierten Aktionen ein (von der verursachenden Aktion zur empfangenden Aktion).

  • Startknoten. Sie f??gen dem Diagramm einen Startknoten hinzu.

    [Achtung]Achtung

    Es gibt nichts, was Sie daran hindert, dem Diagramm mehr als einen Startknoten hinzuzuf??gen. Wenn Sie es doch tun, ist es bedeutunglos und es wird eine der Kritiken ausgel??st.

  • Endknoten. Sie f??gen dem Diagramm einen Endknoten hinzu.

  • Entscheidungs-/Verbindungsknoten. Sie f??gen dem Diagramm einen Entscheidungs-/Verbindungsknoten (Entscheidung) hinzu.

    [Achtung]Achtung

    Ein wohlgeformter Entscheidungs-/Verbindungsknoten sollte eine eingehende Transition und zwei oder mehrere ausgehende Transitionen aufweisen. ArgoUML erzwingt dies nicht, aber es wird eine ArgoUML-Kritik bei jedem Entscheidungs-/ Verbindungsknoten ausgel??st, der dieser Regel nicht entspricht.

  • Gabelung. Sie f??gen dem Diagramm eine Gabelung hinzu.

    [Achtung]Achtung

    Ein wohlgeformte Gabelung sollte eine eingehende Transition und zwei oder mehrere ausgehende Transitionen aufweisen. ArgoUML erzwingt dies nicht, aber es wird eine ArgoUML- Kritik bei jeder Gabelung ausgel??st, die dieser Regel nicht entspricht.

  • Vereinigung. Sie f??gen dem Diagramm eine Vereinigung hinzu.

    [Achtung]Achtung

    Ein wohlgeformte Vereinigung sollte eine eingehende Transition und zwei oder mehrere ausgehende Transitionen aufweisen. ArgoUML erzwingt dies nicht, aber es wird eine ArgoUML- Kritik bei jeder Vereinigung ausgel??st, die dieser Regel nicht entspricht.

  • Aufrufknoten. Sie f??gen dem Diagramm einen Aufrufknoten hinzu. Ein Aufrufknoten ist eine Aktion, die eine einzelne Operation aufruft. Folglich wird der Name der aufzurufenden Operation, zusammen mit dem in Klammern stehenden Namen des Klassifizierers, der die Operation ausf??hrt, in das Symbol geschrieben.

  • Objektknoten. Sie f??gen dem Diagramm einen Objektknoten hinzu. Ein Objektknoten ist ein Objekt, das Eingabe oder Ausgabe einer Aktion ist.

12.4.10. Verteilungsdiagrammspezifische Werkzeuge

Zehn Werkzeuge sind speziell f??r UML-Modellelemente in Verteilungsdiagrammen vorhanden. Die detaillierten Eigenschaften dieser Modellelemente sind im Abschnitt ??ber Modellelemente in Verteilungsdiagrammen beschrieben (siehe Kapitel 23, Deployment Diagram Model Element Reference).

[Anmerkung]Anmerkung

Erinnern Sie sich daran, dass ArgoUML's Verteilungsdiagramme auch als Komponentendiagramme verwendet werden.

  • Knoten. Sie f??gen dem Diagramm einen Knoten hinzu. Befindet sich die Maus ??ber einem markierten Knoten, zeigt dieser vier Griffe, jeweils einer links, rechts, oben und unten. Diese Griffe k??nnen auf andere Objekte gezogen werden, um Assoziationen einzurichten.

  • Knoteninstanz. Sie f??gen dem Diagramm eine Knoteninstanz hinzu. Befindet sich die Maus ??ber einer markierten Knoteninstanz, zeigt diese vier Griffe, jeweils einer links, rechts, oben und unten. Diese Griffe k??nnen auf andere Objekte gezogen werden, um Verkn??pfungen einzurichten.

  • Komponente. Sie f??gen dem Diagramm eine Komponente hinzu. Befindet sich die Maus ??ber einer markierten Komponente, zeigt diese vier Griffe, jeweils einer links, rechts, oben und unten. Diese Griffe k??nnen auf andere Objekte gezogen werden, um Abh??nigkeiten einzurichten.

  • Komponenteninstanz. Sie f??gen dem Diagramm eine Komponenteninstanz hinzu. Befindet sich die Maus ??ber einer markierten Komponenteninstanz, zeigt diese vier Griffe, jeweils einer links, rechts, oben und unten. Diese Griffe k??nnen auf andere Objekte gezogen werden, um Abh??ngigkeiten einzurichten.

  • Generalisierung. Sie f??gen eine Generalisierung zwischen zwei, mit der Taste 1 markierten Modellelementen ein (vom Kind zur Mutter).

  • Realisierung. Sie f??gen eine Realisierung zwischen einer Klasse und einer Schnittstelle ein (von der realisierenden Klasse zur realisierten Schnittstelle).

  • Abh??ngigkeit. Sie f??gen eine Abh??ngigkeit zwischen zwei Modellelementen ein (vom abh??ngigen Modellelement).

  • Assoziation. Sie f??gen eine Assoziation zwischen zwei Modellelementen (Knoten, Komponente, Klasse oder Schnittstelle) ein (vom ersten Modellelement zum zweiten Modellelement) Es gibt 6 Arten von Assoziationen, die hier angeboten werden. Siehe Abbildung 12.4, „Die Assoziations-Werkzeuge ausw??hlen.“: Assoziation, Aggregation und Komposition, und alle diese drei k??nnen bidirektional oder unidirektional sein.

    [Achtung]Achtung

    Die Randbedingung, dass Assoziationen zwischen Klassen und Schnittstellen von der Schnittstelle nicht navigierbar sein d??rfen, gilt auch in Verteilungsdiagrammen.

  • Objekt. Sie f??gen dem Diagramm ein Objekt hinzu. Befindet sich die Maus ??ber einem markierten Objekt, zeigt dieses vier Griffe, jeweils einer links, rechts, oben und unten. Diese Griffe k??nnen auf andere Objekte gezogen werden, um Verkn??pfungen einzurichten.

  • Verkn??pfung. Sie f??gen eine Verkn??pfung zwischen zwei Modellelementen (Knoteninstanz, Komponenteninstanz oder Objekt) ein.

12.5. Der Besen

ArgoUML's Besen-Ausrichtungswerkzeug ist spezialisiert darauf, die Bed??rfnisse von Designern hinsichtlich der Ausrichtung von Modellelementen in UML-Diagrammen zu unterst??tzen. H??ufig richten Designer Objekte beim Erzeugen grob aus oder tun dies ??ber einfache Bewegungskommandos. Der Besen ist ein einfacher Weg, grob ausgerichtete Objekte pr??zise auszurichten. Dar??ber hinaus sind die Verteilungsoptionen des Besen's auf die Bed??rfnisse von Designern zugeschnitten: zusammengeh??rende Objekte haben einen gleich grossen Zwischenraum, b??ndelt Objekte, um Diagrammplatz einzusparen, und schafft Platz f??r neue Objekte. Der Besen macht es auch einfach, von der horizontalen in die vertikale Ausrichtung oder von linksb??ndiger zu rechtsb??ndiger Ausrichtung zu wechseln.

Das T-f??rmige Symbol in ArgoUML's Diagrammwerkzeugleiste ruft das Besen-Ausrichtungswerkzeug auf. Wird die Maustaste 1 im Besenmodus gedr??ckt, wird die erste Mausbewegung des Designers den Besen in einer der vier Richtungen: Norden, S??den, Osten oder Westen ausrichten. Danach verursachen Mausbewegungen, dass der Besen sich in die gew??hlte Richtung vorw??rts, r??ckw??rts oder seitw??rts bewegt. Wie ein Schieber in der realen Welt, verschiebt das Besen- Werkzeug Diagrammelemente, die mit ihm in Kontakt kommen. Dies hat zur Folge, dass die Objekte entsprechend der Besenvorderseite ausgerichtet werden und dies unmittelbar visualisiert wird (siehe nachfolgendes Bild). Im Gegensatz zu einem Besen in der realen Welt, erlaubt die R??ckw??rtsbewegung, dass Diagrammelemente in ihre urspr??ngliche Position zur??ckkehren k??nnen. Das Vergr????ern des Besens macht es m??glich, Objekte, die nicht nahe beieinander sind, auszurichten. Wird die Maustaste losgelassen, verschwindet der Besen , die Objekte bleiben markiert, um diese weiterhin ver??ndern zu k??nnen.

Abbildung 12.5. Der Besen.

Der Besen.
Der Besen.
Der Besen.
Der Besen.


Wenn der Designer die Leertaste w??hrend der Nutzung des Besens dr??ckt, werden die Objekte an der Vorderseite des Besens gleichm????ig verteilt (z.B. gleichm????iger Zwischenraum). ArgoUML's Besen unterst??tzt drei Verteilungsmodi: Objekte k??nnen gleichm????ig auf den Raum, den sie nutzen, verteilt werden, Objekte k??nnen gepackt werden, nur mit einem kleinen Zwischenraum dazwischen, oder Objekte k??nnen gleichm????ig ??ber die gesamte L??nge der Besenvorderseite verteilt werden. Wiederholtes Dr??cken der Leertaste wechselt zwischen diesen drei Verteilungsmodi und gibt eine Kurzinformation aus, welche Operation gerade ausgef??hrt wird: Gleichm????iger Zwischenraum, komprimieren, spreizen und Ursprung.

Wenn der Designer die Taste Enter w??hrend der Nutzung des Besens dr??ckt, wird der Besen rot (anstelle des normalen blau) und es werden keine Objekte w??hrend der Vorw??rtsbewegung des Besens mitgenommen. Dies wirkt wie das Anheben des Besens. Durch erneutes Dr??cken der Taste Enter kehrt man in den normalen Modus zur??ck.

Das Bet??tigen der Taste Tab arbeitet genauso wie die Taste Enter.

12.6. Auswahl-Aktionsschaltfl??chen

Wenn der Anwender ein Modellelement in einem UML-Diagramm markiert, dann werden mehrere Griffe dargestellt, um anzuzeigen, dass es markiert ist und um die Anwenderschnittstelle mit der F??higkeit zu versehen, die Gr????e des Knotens zu ver??ndern. ArgoUML zeigt auch einige „Auswahl-Aktionsschaltfl??chen“ entlang des markierten Modellelementes an. In den nachfolgenden Bildern sehen Sie einige Beispiele von Griffen und „Auswahl- Aktionsschaltfl??chen“. Die beiden Bilder f??r eine Klasse unterscheiden sich, weil beim Erzeugen der zweiten Klasse die Umschalt-Taste gedr??ckt wurde.

Abbildung 12.6. Einige Beispiele f??r „Auswahl-Aktionsschaltfl??chen“.

Einige Beispiele f??r Auswahl-Aktionsschaltfl??chen.
Einige Beispiele f??r Auswahl-Aktionsschaltfl??chen.
Einige Beispiele f??r Auswahl-Aktionsschaltfl??chen.
Einige Beispiele f??r Auswahl-Aktionsschaltfl??chen.
Einige Beispiele f??r Auswahl-Aktionsschaltfl??chen.
Einige Beispiele f??r Auswahl-Aktionsschaltfl??chen.


Auswahl-Aktionsschaltfl??chen bieten h??ufig erforderliche Operationen auf das markierte Objekt an. Zum Beispiel: Eine Klasse hat eine Schaltfl??che bei 12 Uhr, um eine Superklasse hinzuf??gen zu k??nnen; eine bei 6 Uhr, um eine Subklasse hinzuzuf??gen und Schaltfl??chen bei der 3 Uhr- und 9 Uhr-Position, um Assoziationen hinzuf??gen zu k??nnen. Diese Schaltfl??chen unterst??tzen eine "Klick und Ziehen"- Interaktion: Ein einziger Klick erzeugt eine neue verkn??pfte Klasse an der Standardposition, relativ zur Originalklasse und erzeugt eine Vererbung oder eine Assoziation; das Ziehen von der Schaltfl??che zu einer existierenden Klasse erzeugt nur eine Vererbung oder Assoziation; und das Ziehen in einen leeren Raum des Diagrammes erzeugt eine neue Klasse an der Mausposition mit der Vererbung oder Assoziation. ArgoUML enth??lt eine automatische Layout-Unterst??tzung, so da?? das Klicken auf die Schaltfl??che Subklasse die neue Klasse an einer Stelle positioniert, so dass sie sich nicht ??berlappen.

Auswahl-Aktionsschaltfl??chen sind transparent. Sie haben einen sichtbaren rechteckigen Rahmen und enthalten ein Symbol, welches dem Symbol des entsprechenden Designelementes in der Standard-Symbolleiste entspricht. Diese Symbole sind jedoch ungef??llte Zeilen-Symbole mit vielen transparenten Pixeln. Dies erlaubt es, da?? Auswahl-Aktionsschaltfl??chen die Zeichenfl??che ??berlappen, ohne das Diagramm zu verdecken. Aus diesem Grund werden die Schaltfl??chen nur angezeigt, wenn sich die Maus ??ber dem Symbol des markierten Modellelementes befindet; wenn ein Teil des Diagrammes verdeckt ist, kann die Maus einfach fortbewegt werden, um eine klarere Sicht auf das Diagramm zu erhalten.

12.7. Erl??uterungen (Clarifiers)

Eine Schl??sseleigenschaft von ArgoUML sind die Kritiken, die parallel zum ArgoUML-Werkzeug arbeiten. Wenn diese ein Problem finden, erzeugen sie ein Zu-Bearbeiten-Element und heben das Problem im Editierfenster hervor. Die f??r das Hervorheben verwendete grafische Technik wird Erl??uterungen genannt.

  • Hinweis-Symbol ( ). Wird in der oberen linken Ecke eines Modellelementes angezeigt und signalisiert eine Kritik zu diesem Modellelement. Das Bewegen der Maus ??ber dieses Symbol blendet die ??berschrift der Kritik ein.

  • Farbige Wellen-Linie ( ). Wird f??r Kritiken verwendet, die spezifisch f??r Subkomponenten von grafischen Modellelementen sind. Zum Beispiel unterstreichen sie die Attribute einer Klasse mit einem Problem.

  • Durchgehende farbige Linie ( ). Nicht sichtbar beim normalen editieren, wird aber verwendet, wenn ein Zu-Bearbeiten-Element im Zu-Bearbeiten-Fenster (siehe Kapitel 14, Der Bereich Zu-Bearbeiten) durch einen Taste 1 Doppelklick hervorgehoben wird. Die durchgehende Linie kennzeichnet alle von der Kritik betroffenen Modellelemente. Zum Beispiel alle Stimuli, die sich au??erhalb der Reihenfolge befinden.

12.8. Das Zeichengitter

Das Editierfenster ist mit einem Hintergrundgitter ausgestattet, das auf verschiedene Arten ??ber das Men?? (siehe Abschnitt 10.5.4, „Gitter einstellen“) eingestellt oder auch ausgeschaltet werden kann.

Welches Gitter auch immer aktuell eingestellt ist, das Plazieren der Elemente im Diagramm wird immer durch die Einstellungen der Gitterrastung bestimmt, die sich im Bereich zwischen 4 und 32 Pixeln bewegt. (siehe Abschnitt 10.5.5, „Einrasten einrichten“).

12.9. Der Reiter Diagramm

Unterhalb des Editierfensters befindet sich ein kleiner Reiter, der mit Als Diagramm beschriftet ist. Das Konzept ist, da?? ein UML-Diagramm auf unterschiedliche Art und Weise dargestellt werden kann. Zum Beispiel als grafisches Diagramm oder als Tabelle. Jede Darstellung h??tte seinen eigenen Reiter und kann durch einen Taste 1-Klick auf den Reiter ausgew??hlt werden.

Fr??here Versionen von ArgoUML implementierten eine tabellarische Darstellung, das aktuelle Release aber unterst??tzt nur die Diagramm-Darstellung, so da?? dieser Reiter keinerlei Funktion hat.

12.10. Pop-Up Men??'s

Ein Taste 2-Klick ??ber einem Modellelement im Editierfenster ??ffnet ein Pop-up-Men?? mit Men??elementen, viele davon mit einem Untermen??.

12.10.1. Kritiken

Dieses Untermen?? gibt eine Liste aller Kritiken aus, die von diesem Modellelement ausgel??st wurden. Die Auswahl eines der Men??eintr??ge bewirkt, da?? der Eintrag im Zu-Bearbeiten-Fenster hervorgehoben und die ausf??hrliche Erl??uterung im Detailfenster des Zu-Bearbeiten-Reiters plaziert wird. Eine durchgezogene farbige Linie markiert das entsprechende Element.

12.10.2. Reihenfolge

Dieses Men?? steuert die Reihenfolge der sich ??berlappenden Modellelemente im Diagramm. Es entspricht dem Untermen?? Reihenfolge des Men??s Anordnen (siehe Abschnitt 10.7.3, „Reihenfolge“). Es enth??lt vier Eintr??ge.

  • Nach vorne. Das markierte Modellelement wird hinsichtlich der es ??berlappenden Modellelemente in der Reihenfolgenhierarchie eine Ebene nach oben bewegt.

  • Nach hinten. Das markierte Modellelement wird hinsichtlich der es ??berlappenden Modellelemente in der Reihenfolgenhierarchie eine Ebene nach unten bewegt.

  • In den Vordergrund. Das markierte Modellelement wird hinsichtlich der es ??berlappenden anderen Modellelemente an die vorderste Stelle bewegt.

  • In den Hintergrund. Das markierte Modellelement wird hinsichtlich der es ??berlappenden anderen Modellelemente an die hinterste Stelle bewegt.

12.10.3. Hinzuf??gen

Dieses Untermen?? erscheint nur bei Modellelementen, denen Erl??uterungen hinzugef??gt werden k??nnen (Klassen, Schnittstellen, Objekte, Zust??nde, Pseudozust??nde) oder denen Methoden oder Attribute hinzugef??gt wurden (Klassen, Schnittstellen). Es hat meistens drei Eintr??ge.

  • Neues Attribut. Erscheint nur, wenn das markierte Modellelement eine Klasse ist. Es erzeugt ein neues Attribut im Modellelement.

  • Neue Methode. Erscheint nur, wenn das markierte Modellelement eine Klasse oder eine Schnittstelle ist. Erzeugt eine neue Methode im Modellelement.

  • Neuer Kommentar. F??gt zu dem markierten Modellelement einen Kommentar hinzu.

  • Alle Assoziationen hinzuf??gen. Erscheint nur, wenn das markierte Element eine Klasse oder eine Schnittstelle ist. Macht alle im Modell existierenden Beziehungen sichtbar, die mit dem markierten Modellelement verkn??pft sind.

  • Alle Assoziationen entfernen. Erscheint nur, wenn das markierte Modellelement eine Klasse oder eine Schnittstelle ist. Entfernt alle verkn??pften Beziehungen aus dem Diagramm (ohne sie aus dem Modell zu entfernen).

12.10.4. Darstellung

Dieses Untermen?? erscheint nur bei bestimmten Modellelementen. Es ist vollst??ndig kontextabh??ngig. Es gibt viele m??gliche Eintr??ge, je nach markiertem Modellelement und dessen Zustand.

  • Erweiterungspunkte ausblenden. Erscheint nur, wenn der Erweiterungspunkt eines Anwendungsfalles eingeblendet ist. Blendet den Erweiterungspunkt aus.

  • Erweiterungspunkte einblenden. Erscheint nur, wenn der Erweiterungspunkt eines Anwendungsfalles ausgeblendet ist. Blendet den Erweiterungspunkt ein.

  • Alles ausblenden. Erscheint nur, wenn Attribut- und Methoden-Bereiche einer Klasse oder eines Objektes angezeigt werden. Verbirgt beide Bereiche.

  • Alles einblenden. Erscheint nur, wenn Attribut- und Methoden-Bereiche einer Klasse oder eines Objektes ausgeblendet sind. Blendet beide Bereiche ein.

  • Attribute ausblenden. Erscheint nur, wenn die Attribute einer Klasse oder eines Objektes eingeblendet sind. Blendet die Attribute aus.

  • Attribute einblenden. Erscheint nur, wenn die Attribute einer Klasse oder eines Objektes ausgeblendet sind. Blendet die Attribute ein.

  • Operationen ausblenden. Erscheint nur, wenn die Operationen einer Klasse oder eines Objektes eingeblendet sind. Blendet die Operationen aus.

  • Operationen einblenden. Erscheint nur, wenn die Operationen einer Klasse oder eines Objektes ausgeblendet sind. Blendet die Operationen ein.

  • Aufz??hlung ausblenden. Erscheint nur, wenn die Aufz??hlung eingeblendet ist. Blendet die Aufz??hlung aus.

  • Aufz??hlung einblenden. Erscheint nur, wenn die Aufz??hlung ausgeblendet ist. Blendet die Aufz??hlung ein.

  • Alle Kanten einblenden. Erscheint nur bei Klassen. Blendet alle Assoziationen ein (zu angezeigten Modellelementen) die aktuell nicht eingeblendet sind. Dies ist die selbe Funktion wie "Zum Diagramm hinzuf??gen " einer Assoziation im Explorer-Kontextmen??.

  • Alle Kanten ausblenden. Erscheint nur bei Klassen. Blendet alle Assoziationen aus. Dies ist die gleiche Funktion wie die Funktion „Aus Diagramm entfernen“ auf alle Assoziationen dieser Klasse.

  • Stereotypen ausblenden. Erscheint nur, wenn die Stereotypen eines Paketes eingeblendet sind. Blendet die Stereotypen aus.

  • Stereotypen einblenden. Erscheint nur, wenn die Stereotypen eines Paketes ausgeblendet sind. Blendet die Stereotypen ein.

  • Sichtbarkeit ausblenden. Erscheint nur, wenn die Sichtbarkeit eines Paketes eingeblendet ist. Blendet die Sichtbarkeit aus.

  • Sichtbarkeit einblenden. Erscheint nur, wenn die Sichtbarkeit eines Paketes ausgeblendet ist. Blendet die Sichtbarkeit ein.

12.10.5. Modifikatoren

Dieses Untermen?? erscheint nur bei Klassen, Schnittstellen, Paketen und Anwendungsfall-Modellelementen. Es wird verwendet, um die Werte verschiedener verf??gbarer Modifikatoren einzustellen oder zu l??schen.

  • Abstrakt. Wird bei einem abstrakten Modellelement eingestellt.

  • Blatt. Wird bei einem abschliessendem Modellelement gesetzt. Zum Beispiel eines ohne Sub-Modellelemente.

  • Wurzel. Wird bei einem Wurzel-Modellelement gesetzt. Zum Beispiel eines ohne ??bergeordnetes Modellelement.

  • Aktiv. Wird bei einem Modellelement mit dynamischem Verhalten gesetzt.

    [Anmerkung]Anmerkung

    Dies sollte nat??rlich automatisch bei Modellelementen mit Zustandsautomaten oder Aktivit??tsdiagrammen gesetzt werden.

12.10.6. Kardinalit??t

Dieses Untermen?? erscheint nur bei Assoziations-Modellelementen, beim Anklicken eines Assoziationsendes. Es wird dazu verwendet, die Kardinalit??t am dem Assoziationsende zu steuern, das dem Mausklick am n??chsten liegt. Es gibt nur vier Eintr??ge, eine Untermenge einer Menge von Kardinalit??ten, die ??ber die Eigenschaftstabelle eines Assoziationsendes verf??gbar sind (siehe Abschnitt 17.6, „Association End“).

  • 1

  • 0..1

  • 1..*

  • 0..*

12.10.7. Aggregation

Dieses Untermen?? erscheint nur bei Assoziations-Modellelementen, beim Anklicken eines Assoziationsendes. Es wird dazu verwendet, die Aggregation an dem Assoziationsende zu steuern, das dem Mausklick am n??chsten liegt. Es gibt drei Eintr??ge.

  • keine. Entfernt alle Aggregationen.

  • Aggregation. Macht dieses Ende zu einer Aggregation (gew??hnlich als „Aggregation“ bekannt).

  • Komposition. Macht dieses Ende zu einer untrennbaren Aggregation (gew??hnlich als „Komposition“ bekannt).

[Achtung]Achtung

UML fordert, dass ein Ende einer Komposition die Kardinalit??t 1 aufweisen muss (der Standard).

12.10.8. Navigierbarkeit

Dieses Untermen?? erscheint nur bei Assoziations-Modellelementen beim Anklicken auf ein Assoziationsende. Es wird verwendet, um die Navigierbarkeit der Assoziation zu steuern. Es gibt drei Eintr??ge.

  • bidirektional. Macht die Assoziation in beide Richtungen navigierbar.

  • <Klasse1> nach <Klasse2>. Macht die Assoziation nur von <Klasse1> nach <Klasse2> navigierbar. Mit anderen Worten, <Klasse1> kann die <Klasse2> referenzieren, aber nicht umgekehrt.

  • <Klasse2> nach <Klasse1>. Macht die Assoziation nur von <Klasse2> nach <Klasse1> navigierbar. Mit anderen Worten, <Klasse2> kann die <Klasse1> referenzieren, aber nicht umgekehrt.

[Anmerkung]Anmerkung

UML erlaubt keine nicht-navigierbaren Assoziation in beide Richtungen. ArgoUML wird dies zulassen, aber Sie m??ssen die Navigationseigenschaft aller ??ber den Reiter Eigenschaften der Assoziation erreichbaren Assoziationsenden einstellen - und das Diagramm wird in diesem Fall keine Pfeile anzeigen.

Dies wird als schlechte Design-Praxis betrachtet (es wird in ArgoUML eine Kritik ausl??sen), so dass dies nur von theoretischem Interesse ist.

[Anmerkung]Anmerkung

UML erlaubt keine Navigierbarkeit von einer Schnittstelle zu einer Klasse. ArgoUML verhindert dies nicht.

12.11. Notation

Eine Notation ist die textuelle Darstellung in einem Diagramm eines Modellelementes oder seiner Eigenschaften.

12.11.1. Notation Sprachen

ArgoUML unterst??tzt die Darstellung der Notation in unterschiedlichen Sprachen. Standardm????ig wird jeder Text in UML-Notation dargestellt, Men??s erhalten jedoch einen Eintrag um zwischen UML und Java ausw??hlen zu k??nnen. ??ber Plugin-Module ist es auch m??glich andere Sprachen auszuw??hlen; wie zum Beispiel C++.

Abbildung 12.7, „Eine Klasse in UML-Notation“ zeigt eine Klasse in UML-Notation, w??hrend Abbildung 12.8, „Eine Klasse in Java-Notation“ die gleiche Klasse in Java-Notation darstellt.

Abbildung 12.7. Eine Klasse in UML-Notation

Eine Klasse in UML-Notation


Abbildung 12.8. Eine Klasse in Java-Notation

Eine Klasse in Java-Notation


12.11.2. Editieren im Diagramm

Der in einem Diagramm gezeigte Text kann durch einen Doppelklick auf den Text editiert werden. Dies blendet ein Editierfenster mit dem zuvor markierten Text auf, in dem der Text ge??ndert werden kann.

Zus??tzlich zeigt die Statuszeile von ArgoUML (z.B. der kleine Bereich unten im ArgoUML-Fenster) einen Hilfetext an, der die Syntax des einzugebenden Textes beschreibt. Die Texteingabe kann durch Dr??cken der Taste F2, oder bei einzeiligen Felder durch Dr??cken der Taste Return abgeschlossen werden. Zus??tzlich kann das Editieren durch Anklicken eines Bereiches ausserhalb des Diagrammes beendet werden.

Das Editieren im Diagramm ist eine sehr leistungsf??hige Art und Weise eine Menge Modellinformationen auf kompakte Art einzugeben. Es ist zum Beispiel m??glich, eine Operation, den Stereotypen, alle Parameter und deren Typen, sowie die Eigenschaften der Operationen (Sichtbarkeit, Gleichzeitigkeit) auf einmal einzugeben:

+Auftrag(kundenID : int,positionen : List) : void {sequential}

Eine Assoziation (z.B. zwischen zwei Klassen) zeigt viele Texte in der N??he seiner Mitte und der Enden an, die zus??tzliche Erl??uterungen liefern. Abbildung 12.9, „Eine Menge von Assoziationen mit Eingabefeldern“ zeigt zwei Assoziationen, um folgendes zu erl??utern:

Abbildung 12.9. Eine Menge von Assoziationen mit Eingabefeldern

Eine Menge von Assoziationen mit Eingabefeldern


Die rechte Assoziation zeigt, dass unsichtbare Felder in die Text eingegeben werden kann sichtbar werden, wenn das Modellelement markiert wird. Die Felder sind als blaue Rechtecke gekennzeichnet - ein Doppelklick auf diese Felder mit der rechten Maustaste 1 erm??glicht das Editieren.

Die Sichtbarkeit (das +, -, # oder ~) wird im Zusammenhang mit dem Namen des Assoziationsendes angezeigt. Bei unbenannten Assoziationsenden wird sie nicht angezeigt.

Die Kardinalit??t wird nicht angezeigt, wenn sie 1 ist, es sei denn, die Einstellung "1" Kardinalit??ten anzeigen im Men?? Datei=>Projekteigenschaften ist markiert.

Das Beispiel-Bild demonstriert dies nicht, weil Stereotypen einer Assoziation im Diagramm angezeigt werden, aber nicht editierbar sind. Und Stereotypen von Assoziationsenden werden zusammen mit dem Namen des Assoziationsendes angezeigt.

12.11.3. Parsen

(noch zu beschreiben)

Kapitel 13. Der Bereich Details

13.1. Einleitung

Abbildung 13.1, „??berblick ??ber den Bereich Details“ zeigt das ArgoUML-Fenster mit dem hervorgehobenen Bereich Details.

Abbildung 13.1. ??berblick ??ber den Bereich Details

??berblick ??ber den Bereich Details


F??r jedes Modellelement innerhalb des Systems, werden alle mit ihm verkn??pften Daten innerhalb dieses Bereiches angezeigt und eingegeben.

Der Bereich enth??lt eine Reihe von Registern, die mit einem Taste 1-Klick ausgew??hlt werden. Der Rumpf des Reiters ist ein Men?? von Eintr??gen, die je nach ausgew??hltem Register markiert, ausgew??hlt oder eingegeben werden, .

Von diesen, ist das Register Eigenschaften das komplexeste. Mit unterschiedlichen Darstellungen f??r jedes Modellelement im System. Die detaillierte Beschreibung des Registers Eigenschaften f??r jedes Modellelement ist Inhalt separater Kapitel, welche die Modellelemente beschreiben, die in den verschiedenen Diagrammen erscheinen k??nnen (siehe Kapitel 16, Modellreferenz auf h??chster Ebene bis Kapitel 23, Deployment Diagram Model Element Reference).

13.2. Das Register "Zu Bearbeiten"

Dieses Register erlaubt die Steuerung ??ber die verschiedenen, vom Anwender erzeugten Zu-Bearbeiten-Eintr??ge oder automatisch von ArgoUML generierten Kritiken (wird detaillierter im Abschnitt Kritiken-Men?? diskutiert. Siehe Abschnitt 10.9, „Das Men?? Kritiken“). Abbildung 13.2, „Beispiel eines Zu-Bearbeiten-Elementes zeigt einen typischen Ausschnitt. Das Zu-Bearbeiten-Element wird mit der Taste 1 im Detailbereich markiert (siehe Kapitel 14, Der Bereich Zu-Bearbeiten) oder mit Hilfe des kontextsensitiven Popup-Men??s Kritiken im Editierfenster.

Abbildung 13.2. Beispiel eines Zu-Bearbeiten-Elementes

Beispiel eines Zu-Bearbeiten-Elementes


Benutzerspezifische Anpassungen des Verhaltens von Kritiken ist ??ber das Kritiken anzeigen...-Men?? m??glich (siehe Abschnitt 10.9.4, „Kritiken anzeigen...“).

Der Rumpf des Registers beschreibt das Problem und beschreibt, wie es gel??st werden kann. Links befinden sich vier Schaltfl??chen.

  • Neue Kritik... ??ffnet ein Dialogfenster (siehe Abbildung 13.3, „Dialogfenster f??r Neue Kritik), das es Ihnen erlaubt, Ihre eigene Kritik zu schreiben, mit eigener ??berschrift (die im Zu-Bearbeiten-Bereich erscheint), eigener Priorit??t f??r den Zu-Bearbeiten-Bereich, Referenz-URL und detaillierter Beschreibung f??r weitere Informationen.

    Abbildung 13.3. Dialogfenster f??r Neue Kritik

    Dialogfenster f??r Neue Kritik


  • Kritik aufl??sen... ??ffnet einen Dialog, der es dem Anwender erm??glicht, das markierte Zu-Bearbeiten-Element aufzul??sen (siehe Abbildung 13.4, „Dialogfenster f??r Kritik aufl??sen). Dies ist ein wichtiger Dialog, weil er es erlaubt, die Zu-Bearbeiten-Elemente auf andere Art und Weise zu behandeln, wie im Zu-Bearbeiten-Element empfohlen (was der Grund ihrer Existenz ist).

    Dieses Dialogfenster ist f??r folgende F??lle gedacht: L??schen von Zu-Bearbeiten-Elementen, die manuell erzeugt wurden, verhindern, dass sich eine Kritik nur auf ein Objekt bezieht und aufl??sen von ganzen Kategorien von Zu-Bearbeiten-Elementen durch herabstufen von Designbedingungen oder Designzielen.

    Abbildung 13.4. Dialogfenster f??r Kritik aufl??sen

    Dialogfenster f??r Kritik aufl??sen


    Oben befinden sich drei Auswahlfelder, von denen das letzte standardm????ig markiert ist. Sie sind wie folgt bezeichnet: 1) es ist f??r meine Ziele nicht relevant, 2) es ist Momentan nicht von Belang und 3) die Gr??nde sind nachfolgend beschrieben. Wenn Sie die 3. Option ausw??hlen, sollten Sie die Gr??nde in dem nachfolgendem Textbereich beschreiben.

    [Tipp]Tipp

    Wenn Sie ein Zu-Bearbeiten-Element aufl??sen wollen (das durch eine Kritik generiert wurde) indem Sie dessen Empfehlung folgen, dann f??hren Sie die empfohlenen ??nderungen durch und das Zu- Bearbeiten-Element wird von selbst verschwinden. Es gibt dann keine Notwendigkeit, diesen Dialog zu verwenden.

    [Warnung]Warnung

    Die Version V0.20 der ArgoUML-Implementierung ist unvollst??ndig: Die angegebenen Gr??nde werden beim Speichern des Projektes nicht mitgespeichert. Und es gibt keinen Weg, die aufgel??sten Zu-Bearbeiten-Elemente wiederherzustellen. Aus diesem Grund ist es aktuell nicht ratsam eine Begr??ndung einzugeben.

    Wenn eine generiertes Zu-Bearbeiten-Element aufgel??st wird, dann gibt es keinen Weg dies ungeschehen zu machen (es sei denn, durch erneutes erzeugen des Kritik-ausl??senden Objektes).

  • Kritik deaktivieren Dies unterdr??ckt die Aktivit??t der Kritik, die das aktuelle Zu-Bearbeiten-Element generiert. Das Zu-Bearbeiten-Element (und alle anderen von der Kritik generierten Zu-Bearbeiten-Elemente) werden aus dem Bereich Zu-Bearbeiten verschwinden.

    Die Kritik wird nach einer gewissen Zeit wieder aufleben. Zu Beginn ist diese Periode auf 10 Minuten eingestellt, aber sie wird bei jedem Anklicken der Schaltfl??che verdoppelt. Die Kritik kann ausdr??cklich durch Kritiken > Kritiken anzeigen... wieder zum Leben erweckt werden (siehe Abschnitt 10.9.4, „Kritiken anzeigen...“).

    [Tipp]Tipp

    Einige Kritiken k??nnen w??hrend der gesamten Erstellungszeit eines grossen Diagrammes erscheinen. Einige Anwender finden es daher n??tzlich, diese Kritiken zu deaktivieren bis das Diagramm vollst??ndig ist.

13.2.1. Assistenten

Einige der am h??ufigsten vorkommenden Kritiken haben einen „Assistenten“, der dabei hilft, das Problem zu l??sen. Der Assistent umfasst im Zu-Bearbeiten-Element eine Reihe von Seiten (eine oder mehrere), die Sie Schritt f??r Schritt durch die ??nderungen f??hren. Sie starten den Assistenten durch Anklicken der Schaltfl??che Weiter >>.

Abbildung 13.5. Beispiel eines Assistenten

Beispiel eines Assistenten


Der Assistent wird durch die ersten drei Schaltfl??chen im unteren Bereich des Zu-Bearbeiten-Elementes gesteuert.

  • << Zur??ck. Dies bringt Sie in der vorhergehenden Schritt des Assistenten zur??ck. Die Schaltfl??che ist deaktiviert, wenn es sich um den 1. Schritt handelt.

  • Weiter >>. Dies bringt Sie zum n??chsten Schritt des Assistenten. Wenn es sich um den letzten Schritt des Assistenten handelt, ist diese Schaltfl??che deaktiviert.

  • Fertigstellen. Dieser Schritt vollzieht die von Ihnen im Assistenten in den vorhergehenden Schritten vorgenommenen ??nderungen und/oder verwendet die Standardwerte f??r alle folgenden Schritte.

[Anmerkung]Anmerkung

Nicht alle Zu-Bearbeiten-Elemente haben Assistenten. Wenn es keinen Assistenten gibt, sind alle drei Schaltfl??chen deaktiviert.

Die ArgoUML-Assistenten sind nicht-model, d.h. einmal gestartet, k??nnen Sie andere Zu-Bearbeiten-Elemente ausw??hlen oder andere Aktionen ausf??hren. Und dies alles, w??hrend sich der Assistent daran erinnert, wo er war. Sie k??nnen somit zu diesem Zu-Bearbeiten-Element zur??ckkehren und der Assistent wird mit dem gleichen Schritt fortfahren, in dem er war, bevor Sie ihn verlassen haben.

13.2.2. Die Schaltfl??che Hilfe

Es gibt noch eine verbliebene Schaltfl??che im unteren Bereich des Registers Zu-Bearbeiten-Element, mit Hilfe bezeichnet. Diese wird k??nftig einen Browser ??ffnen, mit einer URL f??r eine weitergehende Hilfe.

13.3. Das Register Eigenschaften

??ber dieses Register werden die Eigenschaften eines im Explorer oder im Editierbereich markierten Modellelementes eingestellt. Die Eigenschaften eines Modellelementes k??nnen auf folgende Art und Weise angezeigt werden:

  1. Markieren des Modellelementes im Explorer oder im Editierbereich, gefolgt von der Auswahl des Registers Eigenschaften im Bereich Details; oder

  2. ??ber die Navigationsschaltfl??chen werden unterschiedliche Modellelemente markiert. Zum Beispiel, die Schaltfl??che Nach oben im Register Eigenschaften, die Schaltfl??chen Zur??ck und Vorw??rts in der Symbolleiste und die verschiedenen Men??eintr??ge unter Bearbeiten - Markieren.

Abbildung 13.6, „ Ein typisches Register Eigenschaften im Bereich Details “ zeigt ein typisches Register Eigenschaften f??r ein Modellelement in ArgoUML (in diesem Fall eine Klasse).

Abbildung 13.6. Ein typisches Register Eigenschaften im Bereich Details

Ein typisches Register Eigenschaften im Bereich Details


Oben links befindet sich das Symbol und der Name des Modellelement-Typs (z.B. die UML-Metaklasse, nicht der aktuelle Name dieses bestimmten Modellelementes). In diesem Beispiel ist es das Register Eigenschaften f??r eine Klasse.

Rechts davon befindet sich eine Symbolleiste mit Symbolen, die in diesem Register Eigenschaften relevant sind. Das Erste ist immer die Schaltfl??che Nach oben. Das Letzte ist immer die Schaltfl??che L??schen, um das markierte Modellelement aus dem Modell zu l??schen. Die Symbole dazwischen, h??ngen vom jeweiligen Modellelement ab.

Der Rest des Registers enth??lt Felder, die in zwei oder drei Spalten angeordnet sind. Jedes Feld ist links davon bezeichnet. Die Felder k??nnen Textfelder, Textbereiche, DropDown-Felder, Auswahlfelder oder Markierfelder sein. In den meisten (aber nicht in allen F??llen) F??llen k??nnen die Werte ge??ndert werden. Bei Textfeldern ist dies manchmal nur das Eingeben des erforderlichen Wertes.

Jedoch bei vielen Textfeldern und Textbereichen erfolgt die Dateneingabe ??ber ein kontextsensitives Popup-Men?? (mit Hilfe des Taste 2-Klicks), welches die Optionen anbietet, um neue Eintr??ge hinzuzuf??gen, einen Eintrag zu l??schen oder Eintr??ge nach oben oder nach unten zu bewegen (in Textbereichen mit Mehrfach-Eintr??gen).

Das erste Feld ist meist immer ein Textfeld mit der Bezeichnung Name, wo der Name des spezifischen Modellelementes eingegeben werden kann. Die verbleibenden Felder variieren, je nach markiertem Modellelement.

Die detaillierten Eigenschaftstabellen f??r alle ArgoUML-Modellelemente werden in separaten Kapiteln f??r jeden Diagrammtyp diskutiert ( Anwendungsfalldiagramm (Kapitel 17, Use Case Diagram Model Element Reference, Klassendiagramm (Kapitel 18, Class Diagram Model Element Reference, Sequenzdiagramm (Kapitel 19, Sequence Diagram Model Element Reference, Zustandsdiagramm ( Kapitel 20, Statechart Diagram Model Element Reference, Kollaborationsdiagramm ( Kapitel 21, Collaboration Diagram Model Element Reference, Aktivit??tsdiagramm ( Kapitel 22, Activity Diagram Model Element Reference, Verteilungsdiagramm ( Kapitel 23, Deployment Diagram Model Element Reference). Eigenschaftstabellen f??r Modellelemente, die sehr h??ufig in allen Diagrammtypen erscheinen, haben ihr eigenes Kapitel (Kapitel 16, Modellreferenz auf h??chster Ebene).

[Achtung]Achtung

ArgoUML wird immer versuchen, alle Felder auf dem Register Eigenschaften auszugeben. Ist die Gr????e des Registers Eigenschaften zu klein, wird es unhandlich. Die L??sung ist, entweder das Register Eigenschaften durch vergr????ern des Hauptfensters oder durch verschieben der Bereichsteiler nach links und nach oben ebenfalls zu vergr????ern

13.4. Das Register Dokumentation

Innerhalb des UML 1.4-Standards sind alle Modellelemente Subelemente der Metaklasse Element. Die Metaklasse Element definiert einen gekennzeichneten Wert Dokumentation f??r einen Kommentar, eine Beschreibung oder eine Erl??uterung eines jeden Elementes. Da dieser gekennzeichnete Wert zu jedem Modellelement geh??rt, hat er sein eigenes Register im Bereich Details erhalten und nicht im Bereich Eigenschaftswerte.

Abbildung 13.7, „Ein typisches Register Dokumentation im Bereich Details“ zeigt ein typisches Register Dokumentation f??r ein Modellelement in ArgoUML.

Abbildung 13.7. Ein typisches Register Dokumentation im Bereich Details

Ein typisches Register Dokumentation im Bereich Details


Wie Sie sehen k??nnen, wurden sehr viel mehr Felder dem Dokumentationsfeld hinzugef??gt. Die anderen Felder speichern Ihre Informationen gew??hnlich unter Eigenschaftswerte: Autor, Version, Seit, Veraltet, Siehe.

Die Felder in diesem Register sind f??r alle Modellelemente die gleichen.

Da UML-Kommentare eine Art von Dokumentation sind, werden sie auch in diesem Register mit ihrem Namen und Erl??uterungen angezeigt.

  • Autor: Ein Textfeld f??r den Autor der Dokumentation.

  • Version: Ein Textfeld f??r die Version dieser Dokumentation.

  • Seit: Ein Textfeld, das angibt, seit wann die Dokumentation g??ltig ist.

  • Veraltet: Ein Markierfeld, das angibt, ob das Modellelement veraltet ist (z.B. soll in k??nftigen Versionen des Designmodelles entfernt werden).

  • Siehe: Referenzen auf Dokumentationen ausserhalb dieses Systems.

  • Dokumentation: Der Text einer Dokumentation.

  • Kommentarbezeichnung: Die Namen aller Kommentare, die diesem Modellelement hinzugef??gt wurden.

  • Kommentar: Die diesem Modellelement hinzugef??gten Kommentare.

[Tipp]Tipp

ArgoUML ist prim??r kein Dokumentationssystem. Bei Modellelementen, die eine umfangreiche Dokumentation erfordern, zum Beispiel Anwendungsf??lle, verwenden Sie das Feld Siehe:, um auf externe Dokumente zu verweisen. Dies ist praktischer.

13.5. Das Register Darstellung

Dieses Register enth??lt eine begrenzte Steuerung der grafischen Darstellung von Modellelementen im Diagramm des Editierbereiches.

Modellelemente, die keine spezifische grafische Repr??sentation auf dem Bildschirm (neben ihrer Textbeschreibung) haben, weisen keine Register Darstellung auf. Die Darstellungs-Tabelle einer Operation einer Klasse, zum Beispiel, wird deaktiviert.

Darstellungstabellen variieren etwas von Modellelement zu Modellelement, aber Abbildung 13.8, „ Eine typisches Register Darstellung im Bereich Details “ zeigt ein typisches Register Darstellung f??r ein Modellelement in ArgoUML (in diesem Fall eine Klasse).

Abbildung 13.8. Eine typisches Register Darstellung im Bereich Details

Eine typisches Register Darstellung im Bereich Details


In einigen F??llen k??nnen weitere Felder vorhanden sein, z.B. f??r ein Paket. Aber die meisten Felder sind den Modellelementen gemeinsam.

  • Pfad Dieses Markierfeld erlaubt es, den Pfad vor dem Namen des Modellelementes auszugeben oder nicht. Er wird in der UML-Notation durch ::-Trenner dargestellt. Zum Beispiel w??rde die Klasse Main von ArgoUML wie folgt angezeigt: org::argouml::application::Main.

  • Attribute Dieses Markierfeld erlaubt es, den Attributbereich einer Klasse ein- und auszublenden.

  • Operation Dieses Markierfeld erlaubt es, den Operationsbereich einer Klasse oder einer Schnittstelle ein- und auszublenden.

  • Stereotyp Dieses Markierfeld erlaubt es, die ??ber dem Namen dargestellten Stereotypen eines Paketes ein- und auszublenden.

  • Sichtbarkeit Dieses Markierfeld erlaubt es, die Sichtbarkeit eines Paketes ein- und auszublenden. Die Sichtbarkeit wird in der UML-Notation als +, -, # oder ~ dargestellt.

  • Erweiterungspunkte Das Markierfeld erlaubt es Ihnen, die Erweiterungspunkte von Anwendungsf??llen ein- und auszublenden.

  • Begrenzung: Sie definiert die Ecken des 2D-Modellelementes. Es besteht aus vier, durch Kommas separierte Nummern. Diese vier Nummern sind: i) die X-Koordinate der linken oberen Ecke; ii) die Y-Koordinate der linken oberen Ecke; iii) die Breite des Feldes und iv) die H??he des Feldes. Alle Einheiten sind Pixel im Editierbereiches.

    Dieses Feld hat bei 1D-Modellelementen, die andere Modellelemente verbinden (Assoziationen, Vererbungen, usw.) keine Auswirkung, da deren Position durch ihre Verbindungspartner bestimmt wird. In diesem Fall ist dieses Feld deaktiviert.

  • F??llfarbe: Diese DropDown-Auswahl bestimmt die F??llfarbe der 2D-Modellelemente. Sie ist bei Linien-Modellelementen nicht vorhanden. Die Auswahl Keine F??llfarbe macht das Modellelement transparent. Die Auswahl Benutzerdefiniert erlaubt es andere Farben auszuw??hlen, als die derzeit aufgelisteten. Die Auswahl dieses Eintrages ??ffnet den Farbauswahl-Dialog, siehe Abbildung 13.9, „ Der Dialog Benutzerdefinierte F??ll-/Linienfarbe.

  • Linienfarbe: Diese DropDown-Auswahl bestimmt die Linienfarbe der Modellelemente. Die Auswahl Keine Linienfarbe macht das Modellelement transparent. Die Auswahl Benutzerdefiniert erlaubt es andere Farben auszuw??hlen, als die derzeit aufgelisteten. Die Auswahl dieses Eintrages ??ffnet den Farbauswahl-Dialog, siehe Abbildung 13.9, „ Der Dialog Benutzerdefinierte F??ll-/Linienfarbe.

Abbildung 13.9. Der Dialog Benutzerdefinierte F??ll-/Linienfarbe

Der Dialog Benutzerdefinierte F??ll-/Linienfarbe


Abbildung 13.10. Der Dialog Benutzerdefinierte F??ll-/Linienfarbe

Der Dialog Benutzerdefinierte F??ll-/Linienfarbe


Abbildung 13.11. Der Dialog Benutzerdefinierte F??ll-/Linienfarbe

Der Dialog Benutzerdefinierte F??ll-/Linienfarbe


13.6. Das Register Quellcode

Dieses Register zeigt den Quellcode, der f??r dieses Modellelement in der ausgew??hlten Sprache generiert wurde. ArgoUML generiert den Code zum Beispiel f??r Klassen und Schnittstellen. Der hier gezeigte Code kann in den angezeigten Dateien mit Hilfe der Funktionen im Men?? Generieren gespeichert werden.

Abbildung 13.12. Das Register Quellcode einer Klasse.

Das Register Quellcode einer Klasse.


Jeder von Ihnen hinzugef??gte Code geht verloren - das ist nicht die Absicht von ArgoUML - verwenden Sie stattdessen eine IDE.

Das rechte Auswahlfeld erlaubt die Auswahl der Ausgabedatei. Diese Funktion ist nicht sehr sinnvoll f??r Sprachen, die den gesamten Code einer Klasse in einer Datei speichern, aber sie erf??llt seinen Zweck f??r z.B. C++, wo eine .h und .cpp-Datei generiert wird. Sie nachfolgendes Bild.

Abbildung 13.13. Ein C++ Beispiel.

Ein C++ Beispiel.


13.7. Das Register Randbedingungen

Randbedingungen sind einer der in UML enthaltenen Erweiterungsmechanismen. ArgoUML ist mit einem leistungsf??higen Randbedingungseditor ausger??stet, der auf der im UML 1.4-Standard definierten Objekt Randbedingungssprache (Object Constraint Language; OCL) basiert.

[Achtung]Achtung

Die OCL-Editorimplementierung f??r ArgoUML V0.24 unterst??tzt keine OCL-Randbedingungen au??er Klassen und Eigenschaften.

Dies ist machmal eine sehr starke Einschr??nkung von OCL. Obwohl die UML-Spezifikation bestimmt, dass es f??r jedes Modellelement Randbedingungen geben kann, spezifiziert die OCL-Spezifikation diese nur f??r Klassen/Schnittstellen und Operationen im zul??ssigen Kontext.

Vor OCL 2.0 wird keine generellere Definition von erlaubten Kontexten eingef??hrt. Der Schl??ssel ist, dass Sie f??r jede ben??tigte Kontextdefinition einen kontextspezifischen Klassifizierer definieren m??ssen. Zum Beispiel einen Klassifizierer, der mit dem gleichen Schl??sselwort verkn??pft wird. Die Ersteller der OCL-Spezifikation f??hren aus, dass dies kein Fehler der OCL-Spezifikation ist, aber selbst f??r UML einige Integrationsschritte erfordert. Es sieht so aus, das die Personen, die UML spezifizierten dachten, das dies in OCL spezifiziert wird (aus diesem Grund tun wir einen ersten Schritt in Richtung OCL 2.0).

Um die Geschichte abzuk??rzen, scheint es so, dass es im Moment die einfachste L??sung f??r ArgoUML ist, den OCL-Eigenschaftsbereich nur f??r solche Modellelemente freizugeben, f??r die es aktuell eine Definition der kontextsensitiven Klassifizierer in der OCL 1.4 gibt. Dies sind (siehe oben) Klassen/Schnittstellen und Eigenschaften.

Der Standard definierte eine kleine Anzahl von Randbedingungen vor ( zum Beispiel die Bedingung xor ??ber einen Satz von Assoziationen, was anzeigt, dass nur einer in einer bestimmten Instanz bekannt ist).

Der Standard hat auch eine Anzahl von Umst??nden im Auge, in denen generelle Randbedingungen hilfreich sein k??nnen:

  • Um zu kennzeichenen, dass sich Klassen und Typen im Klassenmodell nicht ??ndern (Invarianz);

  • Um zu kennzeichnen, dass sich Typen von Stereotypen nicht ??ndern (Invarianz);

  • Um Vor- und Nachbedingungen in Operationen und Methoden zu beschreiben;

  • Um W??chter zu beschreiben;

  • Als Sprachnavigation; und

  • um Bedingungen in Operationen zu spezifizieren.

Abbildung 13.14, „ Ein typisches Register Randbedingungen im Bereich Details “ zeigt ein typisches Register Randbedingungen f??r ein Modellelement in ArgoUML (in diesem Fall eine Klasse).

Abbildung 13.14. Ein typisches Register Randbedingungen im Bereich Details

Ein typisches Register Randbedingungen im Bereich Details


Im oberen Bereich des Registers befinden sich eine Reihe von Symbolen.

  • Neue Randbedingung. Erzeugt eine neue Randbedingung und startet den Bedingungseditor im Register Randbedingung f??r diese neue Randbedingung ( siehe Abschnitt 13.7.1, „Der Bedingungs-Editor“). Die neue Randbedingung wird mit einer Kontextdeklaration f??r das aktuell markierte Modellelement erstellt.

    [Warnung]Warnung

    Es scheint logisch, dass eine neue erstellte Randbedingung editiert werden muss. Aber ArgoUML V0.24 l??uft beim Starten des OCL-Editors auf einen Fehler; sie m??ssen dies wie folgt tun: Erstens: die neue Randbedingung zuerst markieren, Zweitens: diese umbenennen und Drittens: die Schaltfl??che Bearbeiten Randbedingung dr??cken. Es ist wesentlich f??r das erfolgreiche Erzeugen einer Randbedingung diesen vier Schritt akkurat zu folgen: erzeugen, markieren, umbenennen und editieren. Der Schritt des Umbenennens ist notwendig, weil die G??ltigkeitspr??fung diese Randbedingung ablehnt, weil ihr Name von dem im Randbedingungstext benannten Namen abweicht. Aus dem gleichen Grund ist eine sp??tere Umbenennung einer Bedingung nicht m??glich.

  • Bedingung l??schen. Die aktuell im Feld Name der Bedingung markierte Bedingung (siehe unten) wird gel??scht.

    [Achtung]Achtung

    In der V0.24 von ArgoUML wird diese Schaltfl??che nicht deaktiviert, wenn sie inaktiv ist, z.B., wenn keine Bedingung markiert ist.

  • Bedingung editieren. Dies startet den Bedingungseditor im Register Randbedingungen (siehe Abschnitt 13.7.1, „Der Bedingungs-Editor“). Der Editor wird mit dem aktuell im Feld Name Bedingung markierten Randbedingung aufgerufen.

    [Achtung]Achtung

    In der V0.24 von ArgoUML wird diese Schaltfl??che nicht deaktiviert, wenn sie inaktiv ist, z.B., wenn keine Bedingung markiert ist.

  • Bedingungseditor konfigurieren. Dies ist ein Dialog, um die Optionen des Bedingungseditors zu konfigurieren (siehe Abbildung 13.15, „Dialog zum Konfigurieren von Bedingungen“).

    Abbildung 13.15. Dialog zum Konfigurieren von Bedingungen

    Dialog zum Konfigurieren von Bedingungen


    Der Dialog hat ein Markierfeld f??r die folgende Option.

    • Typkonformit??t von OCL-Bedingungen pr??fen . OCL ist strikt typisiert. Zu fr??hen Designzeitpunkten kann es hilfreich sein, die Typpr??fung auszuschalten. Dies ist besser, als allen ben??tigten, detaillierten Spezifikationen zu folgen, die erforderlich sind um Typkonsistenz zu erreichen.

    Am unteren Ende befinden sich zwei Schaltfl??chen, die mit OK (um die Options??nderungen zu akzeptieren) und Abbrechen (um die ??nderungen r??ckg??ngig zu machen).

Der Rumpf des Registers Randbedingungen enth??lt zwei Felder, ein kleineres auf der linken Seite und ein gr??sseres auf der rechten Seite. Die beiden sind durch zwei kleine Pfeil-Schaltfl??chen getrennt, welche die Gr??sse der Felder steuern.

  • Linkes Feld verkleinern. Ein Taste 1-Klick auf dieses Symbol verkleinert das linke Feld. Dieser Effekt kann durch die Schaltfl??che Rechtes Feld verkleinern aufgehoben werden (siehe unten).

  • Rechtes Feld verkleinern. Ein Taste 1-Klick auf dieses Symbol verkleinert das rechte Feld. Dieser Effekt kann durch die Schaltfl??che Linkes Feld verkleinern aufgehoben werden (siehe oben).

Eine feiner abgestimmte Steuerung kann durch eine Taste 1- Bewegung erfolgen, indem Sie die Trennungsleiste nach links und nach rechts verschieben.

Das linke Feld ist mit Name Bedingung bezeichnet und listet alle Bedingungen auf (wenn es welche gibt) so weit sie f??r das markierte Modellelement definiert wurden. Eine Bedingung kann durch einen Taste 1-Klick markiert werden.

Das rechte Feld ist mit Vorschau bezeichnet und enth??lt den Text der Bedingung. Dieses Feld zeigt nur einen Inhalt an, wenn eine Bedingung markiert wurde. Ist eine Bedingung f??r das Feld zu gro??, erscheint rechts eine Scrollleiste.

13.7.1. Der Bedingungs-Editor

Dieser wird durch die Schaltfl??che Editiere Bedingung im Register Bedingungen aufgerufen. Der Bedingungseditor nimmt das ganze Register ein (siehe Abbildung 13.16, „Dialog f??r das Konfigurieren der Bedingungen“).

Abbildung 13.16. Dialog f??r das Konfigurieren der Bedingungen

Dialog f??r das Konfigurieren der Bedingungen


Im oberen Bereich des Registers befinden sich eine Reihe von Symbolen.

  • Editieren abbrechen. Dies beendet den Bedingungseditor ohne die ??nderungen abzuspeichern und kehrt zum Haupt-Bedingungen-Register zur??ck.

  • Pr??fe OCL-Syntax. Diese Schaltfl??che ruft eine vollst??ndige Syntaxpr??fung der im Editor geschriebenen OCL auf. Ist die Syntax g??ltig, wird die Bedingung gespeichert und kehrt zum Haupt-Bedingungen-Register zur??ck. Wenn die Syntax ung??ltig ist, erl??utert ein Dialogfenster das Problem.

    [Warnung]Warnung

    Ob die Typpr??fung eingebunden wird, sollte mit der Schaltfl??che Bedingungseditor konfigurieren einstellbar sein (siehe unten). ArgoUML V0.20 pr??ft aber immer und lehnt jede Bedingung mit dem kleinsten Fehler ab.

  • Bedingungseditor konfigurieren. Dies ist ein Dialog, um die Optionen des Bedingungseditors zu konfigurieren. Er ist auch im Haupt-Bedingungen -Register verf??gbar und wird dort detailliert beschrieben (siehe Abschnitt 13.7, „Das Register Randbedingungen“ ).

Rechts von der Symbolleiste befindet sich ein Markierfeld, das als Syntaxunterst??tzung bezeichnet ist (standardm????ig nicht markiert). Dieses schaltet die Syntaxunterst??tzung im Bedingungseditor ein.

Wenn die Syntaxunterst??tzung eingeschaltet ist, erscheinen sechs DropDown-Men??s in einer Zeile unmittelbar unterhalb der Symbolleiste. Diese enthalten Standardtemplates f??r OCL, die in die editierte Bedingung eingef??gt werden, sofern sie ausgew??hlt werden.

Die Syntaxunterst??tzung kann in ein separates Fenster gebracht werden, indem man mit einer Taste 1-Bewegung des kleinen, links befindlichen Trenners die Zeile mit den DropDown-Men??s aus dem Fenster bewegt.

  • Allgemein. Allgemeine OCL Konstrukte. Eintr??ge: inv (f??gt eine Invarianz ein); pre (f??gt eine Vorbedingung ein); post (f??gt eine Nachbedingung ein); self (f??gt eine Referenz auf sich selbst ein); @pre (f??gt eine Referenz auf einen Wert beim Start einer Operation ein); und result (f??gt eine Referenz auf ein vorhergehendes Ergebnis ein).

  • Operatoren. Relationale Operatoren und Klammern. Eintr??ge: =; <>; <; >; <=; >=; und ().

  • Nummern. Arithmetische Operatoren und Funktionen. Eintr??ge: +; -; *; /; mod; div; abs; max; min; round; und floor.

  • Zeichenketten. Funktionen f??r Zeichenketten. Eintr??ge: concat; size; toLower; toUpper; und substring.

  • Booleans. Logische Funktionen. Eintr??ge: or; and; xor; not; implies; und if then else.

  • Sammlungen. Operatoren und Funktionen f??r Sammlungs—Mengen , S??tzen und Sequenzen. Die grosse Anzahl von Funktionen ist in Untergruppen unterteilt.

    • Allgemein. Funktionen, die auf alle Sammlungstypen anwendbar sind. Eintr??ge: Collection {} (f??gt eine neue Sammlung ein); Set {} (f??gt einen neuen Satz ein); Bag {} (f??gt eine neue Menge ein); Sequence {} (f??gt eine neue Sequenz ein); size; count; isEmpty; notEmpty; includes; includesAll; iterate; exists; forAll; collect; select; reject; union; intersection; including; excluding; und sum.

    • S??tze. Operatoren und Funktionen die nur auf S??tze anwendbar sind. Eintr??ge: - (set difference); und symmetricDifference.

    • Sequenzen. Funktionen, die nur auf Sequenzen anwendbar sind. Eintr??ge: first; last; at; append; prepend; und subSequence.

Der Rest des Registers beinhaltet ein beschreibbares Textfeld, welches den zu editierenden Text enth??lt. Die Maus-Schaltfl??chen weisen innerhalb des editierbaren Textfeldes ihr Standardverhalten auf (siehe Abschnitt 8.2, „Generelles Verhalten der Maus in ArgoUML“).

Zus??tzlich k??nnen Ausschneiden-, Kopieren- und Einf??gen-Operationen ??ber die Tastenk??rzel Strg-X, Strg-C und Strg-V aufgerufen werden.

13.8. Das Register Stereotypen

Dieses Register zeigt die verf??gbaren und anwendbaren Stereotypen f??r das aktuell markierte Modellelement. Es besteht aus zwei Feldern und zwei Schaltfl??chen. Die Schaltfl??chen erlauben es, die Stereotypen von einer Liste in die andere zu bewegen.

Abbildung 13.17. Ein Beispiel eines Registers Stereotypen f??r eine Klasse.

Ein Beispiel eines Registers Stereotypen f??r eine Klasse.


In den Listen, zwischen [] wird die Basisklasse der Stereotypen angezeigt. Zum Beispiel in dem obigen Bild kann der Stereotyp thread[Classifier] auf alle Typen von Klassifizierern wie Klassen, Anwendungsf??lle, ... angewendet werden.

13.9. Das Register Eigenschaftswerte

Eigenschaftswerte sind ein anderer Erweiterungsmechanismus der in UML enthalten ist. Der Anwender kann Name-Wert-Paare definieren, die mit Modellelementen verkn??pft sind und die Eigenschaften dieses Modelles definieren. Die Namen sind als tags bekannt. UML definiert eine Anzahl von Tags vor, die f??r viele seiner Modellelemente n??tzlich sind.

[Anmerkung]Anmerkung

Die Tag-Dokumentation ist f??r die Top-UML- Metaklasse Element definiert und ist so in allen Modellelementen verf??gbar. In ArgoUML sind Dokumentationswerte im Register Dokumentation enthalten, so dass diese nicht mit Hilfe der Eigenschaftswerte definiert werden m??ssen.

Das Register Eigenschaftswerte in ArgoUML umfasst eine zweispaltige Tabelle mit einem Kombinationsfeld links, um die Tag- Definition in einem editierbaren Feld auszuw??hlen und rechts f??r den damit verkn??pften Wert. Es gibt immer mindestens eine leere Zeile, die f??r einen neuen Tag bereit steht.

Die Schaltfl??che oben in diesem Register erlaubt das Erzeugen einer neuen Tag-Definition. Nach dem Anklicken dieser Schaltfl??che gehen Sie zuerst in das Register Eigenschaften, um den Namen der neuen Tag- Definition festzulegen.

die Maus-Schaltfl??chen weisen ihr Standardverhalten innerhalb des editierbaren Wertebereiches auf (siehe Abschnitt 8.2, „Generelles Verhalten der Maus in ArgoUML“). Zus??tzlich k??nnen Sie auch die Tastenk??rzel Strg-X, Strg-C und Strg-V in einem Wertefeld aufrufen.

13.10. Das Register Checkliste

Das Durchf??hren von Designreviews und Inspektionen ist eine der effektivsten Arten Fehler w??hrend der Softwareentwicklung zu entdecken. Ein Designreview besteht typischerweise aus einer kleinen Zahl von Designern, Implementierern oder anderen Projektbeteiligter, die eine Besprechung durchf??hren, um ein St??ck Softwareentwicklung zu reviewen. Viele Entwicklungsorganisationen haben Checklisten von h??ufigen Designproblemen f??r solche Reviews entwickelt. Die Vergangenheit zeigt auf, dass die Reviewer den Code ohne Besprechung mit Hilfe dieser Checklisten ??berpr??fen und dies genauso effektiv ist, wie die Design- Reviews in Form einer Besprechung.

Aus diesem Grund wurden ArgoUML Checklisten hinzugef??gt, die den Gedanken von der Design-Review-Checkliste unterst??tzen. Jedoch, sind die ArgoUML-Checklisten in die Anwenderschnittstelle des Design- werkzeuges und in die Designarbeit integriert.

Ein Softwaredesigner, der ArgoUML verwendet, kann f??r jedes Designelement eine Checkliste sehen. Das Register „Checkliste “ pr??sentiert eine Liste von unmarkierten Elementen, die zum aktuell markierten Designelement geh??ren. Zum Beispiel, wenn eine Klasse in einem Designdiagramm markiert ist, zeigt das Register Checklisten Elemente, die zum kritischen Nachdenken ??ber diese Klasse anregen. Siehe nachfolgendes Bild. Designer k??nnen Elemente als betrachtet markieren. Markierte Elemente verbleiben in der Liste, um darzustellen, dass Sie bereits betrachtet wurden, w??hrend unmarkierte Elemente den Designer auffordern, ??ber diesen neuen Designaspekt nachzudenken. ArgoUML unterst??tzt unterschiedliche Checklisten mit vielen m??glichen Elementen.

Abbildung 13.18. Ein Beispiel f??r eine Checkliste einer Klasse.

Ein Beispiel f??r eine Checkliste einer Klasse.


[Achtung]Achtung

In der Release V0.22 von ArgoUML ist dieses Register nicht vollst??ndig implementiert. Zum Beispiel werden die Markierungen nicht gespeichert.

Kapitel 14. Der Bereich Zu-Bearbeiten

14.1. Einleitung

Abbildung 14.1, „??berblick ??ber den Bereich Zu-Bearbeiten“ zeigt das ArgoUML-Fenster mit dem hervorgehobenen Bereich Zu-Bearbeiten.

Abbildung 14.1. ??berblick ??ber den Bereich Zu-Bearbeiten

??berblick ??ber den Bereich Zu-Bearbeiten


Dieser Bereich hat Zugriff auf die Ergebnisse des Kritikenprozesses, der innerhalb von ArgoUML abl??uft.

Ein Auswahlfeld oben erlaubt die Einstellung, wie die Daten dargestellt werden, eine Schaltfl??che erlaubt es, die Darstellung der Hierarchie zu ??ndern und es gibt eine Anzeige, wie viele Zu-Bearbeiten-Elemente identifiziert wurden.

Mehr Informationen ??ber Kritiken k??nnen Sie in der Diskussion des Kritiken-Men??s (siehe Abschnitt 10.9, „Das Men?? Kritiken“) finden.

14.2. Das Verhalten der Maus im Bereich Zu-Bearbeiten

Das generelle Verhalten der Maus und die Benennung der Tasten ist im Kapitel ??ber die gesamte Anwenderschnittstelle ausgef??hrt (siehe Kapitel 8, Einleitung).

14.2.1. Taste 1-Klick

Diese Aktion wird generell dazu verwendet, ein Element f??r darauf folgende Operationen zu markieren.

Innerhalb der hierarchischen Anzeige, k??nnen Elemente mit Unter- Hierarchien durch angezeigt werden, wenn die Hierarchie versteckt und wenn die Hierarchie ge??ffnet ist.

Wenn diese Symbole angezeigt werden, wechselt die Anzeige der Hierarchie bei jedem Taste 1-Klick auf diese Symbole.

Ein Taste 1-Klick ??ber der ??berschrift eines Zu-Bearbeiten- Elementes wird dessen Details im Register Zu-Bearbeiten- Element des Bereiches Details anzeigen. Dieses Register wird automatisch ausgew??hlt, wenn es aktuell nicht sichtbar ist.

14.2.2. Taste 1-Doppelklick

Wenn dies auf ein Verzeichnissymbol in der Hierarchie ausgef??hrt wird, wird sich die Darstellung dieser Hierarchie ??ndern.

Wenn dies auf eine ??berschrift ausgef??hrt wird, wird der Taste  1-Doppelklick das Diagramm f??r das Modellelement anzeigen, zu dem das Zu-Bearbeiten-Element geh??rt und das Modellelement im Diagramm mit Hilfe des entsprechenden Elementes markieren (das Modellelement kann hervorgehoben, mit einer Wellenlinie unterstrichen oder mit einem farbigem Rahmen umgeben sein).

14.2.3. Taste 2-Aktionen

Es gibt keine Taste 2-Funktionen im Bereich Zu-Bearbeiten.

14.2.4. Taste 2-Doppelklick

Es gibt keine Taste 2-Funktionen im Bereich Zu-Bearbeiten.

14.3. Auswahl der Darstellung

Oben im Bereich befindet sich ein Kombinationsfeld, was die Darstellung der Zu-Bearbeiten-Elemente steuert. Die Zu-Bearbeiten-Elemente k??nnen auf sechs unterschiedliche Arten dargestellt werden. Diese Einstellung wird nicht dauerhaft gespeichert. Zum Beispiel ist sie auf den Standardwert beim Start von ArgoUML eingestellt.

  • Nach Priorit??t. Dies ist die Standardeinstellung. Die Zu-Bearbeiten-Elemente werden nach Priorit??t in drei Hierarchien organisiert: Hoch, Mittel und Niedrig. Die Priorit??t, die mit den durch eine bestimmte Kritik generierten Zu-Bearbeiten-Elementen verkn??pft sind, k??nnen ??ber das Men?? Kritiken > Kritiken anzeigen... ge??ndert werden (siehe Abschnitt 10.9.4, „Kritiken anzeigen...“).

  • Nach Entscheidung. Die Zu-Bearbeiten-Elemente sind in 17 Hierarchien anhand von Designmerkmalen organisiert: Unkategorisiert, Klassenauswahl, Verhalten, Benennung, Speicher, Vererbung, Containment, Geplante Erweiterungen, Zustandsautomaten, Design Patterns, Beziehungen, Instantiation, Modularit??t, Expected Usage, Methoden, Codegenerierung und Stereotypen. Die Details der Kritiken in jeder Kategorie werden in Abschnitt 10.9.2, „Design-Wichtungen...“ diskutiert.

  • Nach Ziel. ArgoUML verfolgt das Konzept, dass Kritiken entsprechend der sie beeinflussenden Benutzerziele gruppiert werden. Diese Darstellung gruppiert die Zu-Bearbeiten- Elemente in einer Hierarchie entsprechend der Ziele.

    [Achtung]Achtung

    In der aktuellen Release von ArgoUML gibt es nur ein Ziel Unspezifiziert. Alle Zu-Bearbeiten-Elemente werden unter dieser ??berschrift erscheinen.

  • Nach Problemen. Die Zu-Bearbeiten-Elemente werden hierarchisch entsprechend des Modellelementes organisiert, welches das Problem verursachte. Zu-Bearbeiten-Elemente, die manuell mit der Schaltfl??che "Neues Zu-Bearbeiten-Element" erzeugt wurden (z.B. nicht durch eine Kritik) werden hier nicht aufgelistet.

  • Nach Kurzbezeichnung. Die Zu-Bearbeiten-Elemente werden danach hierarchisch organisiert, welche Kritik das Zu-Bearbeiten-Element generierte. Der Klassenname der Kritik wird anstelle seiner ??berschrift aufgelistet.

  • Nach Wissensgebiet. ArgoUML hat das Konzept, dass Kritiken einen Ausschnitt eines Wissensgebietes reflektieren. Diese Darstellungsoptionen gruppieren die Kritiken entsprechend der Kategorie des Wissensgebietes: Entwurf, Korrektheit, Vollst??ndigkeit, Konsistenz, Syntax, Semantik, Optimierung, Darstellbarkeit, Organisierbarkeit, Experiencial und Werkzeug. Die Hauptkategorie (Entw??rfe) enth??lt die manuell eingegebenen Zu-Bearbeiten-Elemente.

14.4. Element-Z??hler

Rechts von der Schaltfl??che flach/hierarchisch befindet sich ein Z??hler, der die Anzahl der aktuell gefundenen Zu-Bearbeiten-Elemente ausgibt. Er wird gelb hervorgehoben, wenn die Anzahl der Zu-Bearbeiten- Elemente auf ??ber 50 Zu-Bearbeiten-Elemente anw??chst und rot, wenn es ??ber 100 sind.

Kapitel 15. Die Kritiken

15.1. Einleitung

Die Schl??sselfunktion, die ArgoUML von anderen UML-Werzeugen unterscheidet, ist die Verwendung von Konzepten der kognitiven Psychologie. Die dahinter stehende Theroie ist in Jason Robbins' PhD Dissertation http://argouml.tigris.org/docs/robbins_dissertation/ beschrieben.

Kritiken sind einer der Hauptarten mit denen diese Ideen implementiert wurden. Im Hintergrund laufend, bieten Sie dem Designer Ratschl??ge an, die akzeptiert oder ignoriert werden k??nnen. Der Schl??sselpunkt ist, dass sie keine Entscheidung des Designers ausschliessen.

[Anmerkung]Anmerkung

Die Kritiken sind asynchrone Prozesse, die parallel zu ArgoUML ablaufen. ??nderungen ben??tigen eine oder zwei Sekunden, bis die Kritiken erneut erzeugt wurden.

15.1.1. Terminologie

Die Kritiken sind Hintergrundprozesse, die das aktuelle Modell anhand verschiedener „guter“ Designkriterien ??berpr??fen. Es gibt eine Kritik f??r jedes Designkriterium.

Die Ausgabe einer Kritik ist eine Kritik— eine Anweisung ??ber einige Aspekte des Modelles, die nicht der guten Designpraxis folgen.

Nat??rlich wird eine Kritik nur vorschlagen, wie der gefundene Designmangel behoben werden kann, in dem es ein Zu-Bearbeiten-Element erzeugt.

15.1.2. Design-Mangel

ArgoUML kategorisiert Kritiken entsprechend der von ihnen adressierten Designm??ngel (einige Kritiken k??nnen in mehr als einer Kategorie erscheinen). Aktuell gibt es 16 solcher Kategorien.

In diesen Handbuch sind die Beschreibungen der Kritiken entsprechend ihres Designmangels in Abschnitten gruppiert.

15.2. Unkategorisiert

Diese Kritiken passen zu keiner der anderen Kategorien.

ArgoUML hat keine Kritik mit dieser Kategorie. Vielleicht werden einige in sp??teren Versionen hinzugef??gt.

15.3. Klassenauswahl

Dies sind Kritiken, die sich darauf beziehen, wie Klassen ausgew??hlt und verwendet wurden.

ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.3.1. Datentyp verbergen

Datentypen sind innerhalb von UML 1.4 keine vollst??ndigen Klassen. Sie k??nnen nur Aufz??hlungsliterale als Werte haben und nur Abfrage-Operationen unterst??tzen (Das sind Operationen, die nicht den Zustand des Datentyps ver??ndern).

Datentypen k??nnen nicht mit Klassen assoziiert werden, es sei denn, der Datentyp ist Teil einer Komposition (schwarzer Diamant). So eine Assoziation reflektiert die feste Verbindung einer Sammlung von Datentyp-Instanzen zu einer Klasseninstanz. In der Konsequenz ist so ein Datentyp ein Attribut der Klasse mit einer Kardinalit??t.

Eine gute OOA&D h??ngt von der richtigen Auswahl der Entities ab, welche die vollst??ndigen Objekte und welche die Attribute von Objekten repr??sentieren.

Es gibt zwei Optionen, um dieses Problem zu l??sen.

  • Ersetze den Datentyp durch eine ganze Klasse.

  • oder ??ndere die Aggregation in eine Komposition am Ende das Datentyps.

15.3.2. Veringere die Anzahl der Klassen im Namensraum <Namensraum>

Ein Vorschlag, die Verst??ndlichkeit durch weniger Klassen in einem Namensraum zu verbessern. Wenn ein Namensraum (wie ein Modell, ein Paket, oder eine Klasse) zu viele Klassen aufweist, wird es f??r Menschen sehr schwierig dies zu verstehen. Einen verst??ndlichen Satz von Namensr??umen zu definieren ist ein wichtiger Teil Ihres Designs.

Der Assistent dieser Kritik erlaubt das Setzen eines Schwellwertes, z.B. die maximale Anzahl von Klassen, ab der die Kritik ausgel??st wird.

[Achtung]Achtung

Diese Anzahl wird nicht dauerhaft gespeichert und es gibt keinen Weg, diese zu reduzieren, nachdem sie hochgesetzt wurde. Es sei denn, man erzeugt mehr Klassen, bis die Kritik erneut ausgel??st wird. Der Neustart von ArgoUML setzt dieses Anzahl wieder auf seinen Standardwert: 20.

15.3.3. Diagramm aufr??umen

Vorschlag, dass das Diagramm verbessert werden sollte, indem man sich ??berlappende Modellelemente auseinander zieht.

15.4. Benennung

Dies sind Kritiken, die sich auf die Benennung von Modellelementen beziehen. Die aktuelle Version von ArgoUML hat 18 Kritiken in dieser Kategorie.

15.4.1. L??se Assoziations-Namenskonflikt auf

Hinweis, dass zwei Assoziationen im gleichen Namensraum den gleichen Namen haben. Dies ist in UML nicht erlaubt.

15.4.2. ??berarbeite die Attributnamen, um einen Konflikt zu vermeiden

Hinweis, dass zwei Attribute einer Klasse den gleichen Namen haben. Dies ist in UML nicht erlaubt.

[Anmerkung]Anmerkung

Das Problem kann durch vererben eines Attributes ??ber eine Vererbungsbeziehung verursacht werden.

15.4.3. ??ndere Namen oder Signaturen in einem Modellelement

Zwei Operationen in einem <Modellelement> haben die gleiche Signatur. Das hei??t, die Namen sind gleich und die Liste der Parameter hat den gleichen Typ.

Wo es Signaturkonflikte gibt, kann kein korrekter Code in den haupts??chlich verwendeten OO-Sprachen generiert werden. Es f??hrt auch zu einer sehr unklaren Semantik des Designs.

Beim Vergleichen von Signaturen betrachtet die Kritik:

  1. den Namen;

  2. die Liste der Ein-, Aus- und Ein-Ausgabeparamtertypen in ihrer Reihenfolge;

Nur wenn diese sowohl in Typ und Reihenfolge ??bereinstimmen, wird die Signatur als gleich betrachtet.

Dies folgt der Linie von Java/C++, welche die R??ckgabeparameter bei der Signatur ignorieren. Dies kann bei einigen funktionalen OO-Sprachen unvorteilhaft sein.

[Anmerkung]Anmerkung

Einige Puristen w??rden argumentieren, dass der Vergleich zwischen Ein-, Aus- und Ein-Ausgabeparametern differenzieren sollte. Jedoch kann keine praktische Programmiersprache so etwas tun, wenn sie einen ??berladenen Methodenaufruf aufl??st. Aus diese Grund behandelt diese Kritik sie alle pauschal.

15.4.4. Doppelte End- (Rollen-) Namen in einer Assoziation

Die angegebene Assoziation hat zwei (oder mehrere) Enden (Rollen) mit dem gleichen Namen. Eine der wohlgeformten Regeln f??r Assoziationen in UML 1.4 ist, dass alle Enden (Rollen)-Namen eindeutig sein m??ssen.

Dies stellt sicher, dass es keine mehrdeutige Referenz auf die Enden einer Assoziation geben kann.

Um dies zu beheben, markieren Sie die Assoziation manuell und ??ndern die Namen von einer oder mehreren der betroffenen Enden (Rollen) mit Hilfe des Taste 2-Popup-Men??s oder der Eigenschaftstabelle.

15.4.5. Rollenname steht im Konflikt mit einem Element

Ein Hinweis, dass ein gutes Design Rollenname f??r Assoziationen verhindert, die mit Attributen oder Operationen der Quellklasse kollidieren. Rollen k??nnen im Code als Attribute oder Operationen realisiert werden, die dann Codegenerierungsprobleme ausl??sen.

15.4.6. Einen Namen ausw??hlen (Klassen und Schnittstellen)

Der betrachteten Klasse oder Schnittstelle wurde kein Name gegeben (sie wird im Modell als Unbenannt erscheinen). Hinweis, dass gutes Design fordert, dass alle Schnittstellen und Klassen benannt werden.

15.4.7. W??hlen Sie einen eindeutigen Namen f??r ein Modellelement aus (Klassen und Schnittstellen)

Hinweis, dass die angegebene Klasse oder Schnittstelle den gleichen Namen wie eine andere (im Namensraum) aufweist. Dies ist schlechtes Design und wird eine g??ltige Codegenerierung verhindern.

15.4.8. W??hlen Sie einen Namen aus (Attribute)

Das betrachtete Attribut hat keinen Namen erhalten (es wird im Modell als (Unbenanntes Attribute) erscheinen). Hinweis, dass gutes Design fordert, dass alle Attribute benannt werden.

15.4.9. W??hlen Sie einen Namen aus (Operationen)

Die betrachtete Operation hat keinen Namen erhalten (sie wird im Modell als (Unbenannte Operation) erscheinen). Hinweis, dass gutes Design fordert, dass alle Operationen benannt werden.

15.4.10. W??hlen Sie einen Namen aus (Zust??nde)

Das betrachtete Zustand hat keinen Namen erhalten (es wird im Modell als (Unbenannter Zustand) erscheinen). Hinweis, dass gutes Design fordert, dass alle Zust??nde benannt werden.

15.4.11. W??hlen Sie einen eindeutigen Namen f??r ein (zustandsbehaftetes) Modellelement aus.

Hinweis, dass der angegebene Zustand den gleichen Namen wie ein anderer aufweist (im aktuellen Zustandsdiagramm). Dies ist schlechtes Design und wird die g??ltige Codegenerierung verhindern.

15.4.12. ??ndern Sie den Namen, um eine Konfusion zu verhindern

Zwei Namen im gleichen Namensraum haben sehr ??hnliche Namen (sie unterscheiden sich nur durch ein Zeichen voneinander). Hinweis, dass dies potentiell zu einer Konfusion f??hrt.

[Achtung]Achtung

Diese Kritik kann manchmal st??rend sein, da es manchmal n??tzlich und gutes Design ist, eine Serie von Modellelemente var1, var2 usw. zu haben.

Es ist wichtig sich daran zu erinnern, dass Kritiken Anleitungen anbieten, die nicht immer korrekt sein m??ssen. ArgoUML l????t es zu, dass Sie die entsprechenden Zu-Bearbeiten-Elemente ??ber den Zu-Bearbeiten-Bereich verlassen (siehe Kapitel 14, Der Bereich Zu-Bearbeiten).

15.4.13. W??hlen Sie einen legalen Namen aus

Alle Modellelementnamen in ArgoUML d??rfen nur aus Buchstaben, Ziffern und Unterstrichen bestehen. Diese Kritik weist Sie darauf hin, dass eine Entit??t nicht dieser Anforderung entspricht.

15.4.14. ??ndern Sie den Namen des Modellelementes in ein nicht-reserviertes Wort

Hinweis, dass der Name dieses Modellelementes dem Namen eines in UML resevierten Wortes entspricht (or within one character of one). Dies ist nicht erlaubt.

15.4.15. W??hlen Sie einen besseren Namen f??r die Operation aus

Hinweis, dass der Name einer Operation nicht der Namenskonvention entspricht, dass Namen von Operationen mit einem Kleinbuchstaben beginnen.

[Achtung]Achtung

Der Java und C++-Konvention folgend, geben die meisten Designer Ihren Konstruktoren den gleichen Namen wie der Klasse, die mit einem Grossbuchstaben gebinnt. In ArgoUML wird dies diese Kritik ausl??sen, es sei denn, der Konstruktor erh??lt den Stereotyp «create» .

Es ist wichtig sich daran zu erinnern, dass Kritiken Anleitungen anbieten, die nicht immer korrekt sein m??ssen. ArgoUML l????t es zu, dass Sie die entsprechenden Zu-Bearbeiten-Elemente ??ber den Zu-Bearbeiten-Bereich verlassen (siehe Kapitel 14, Der Bereich Zu-Bearbeiten).

15.4.16. W??hlen Sie einen besseren Attributnamen aus

Hinweis, dass ein Attribut nicht der Namenskonvention entspricht, dass Namen von Attributen mit einem Kleinbuchstaben beginnen.

15.4.17. Klassenname gro?? schreiben

Hinweis, dass eine Klasse nicht der Namenskonvention entspricht, dass Klassen mit einem Gro??buchstaben beginnen.

[Anmerkung]Anmerkung

Obwohl sie diese Kritik nicht ausl??st, sollte die gleiche Konvention auf Schnittstellen angewendet werden.

15.4.18. Paketname ??berarbeiten

Hinweis, dass ein Paket nicht der Namenskonvention entspricht, dass Kleinbuchstaben mit Punkten verwendet werden, um Subpakete zu kennzeichnen.

15.5. Speicher

Kritiken, die sich auf die Attribute von Klassen beziehen.

Die aktuelle Version von ArgoUML hat in dieser Kategorie die folgenden Kritiken.

15.5.1. ??berarbeiten Sie die Attributnamen, um einen Konflikt zu vermeiden

Diese Kritik wurde in einer fr??heren Designmangel-Kategorie diskutiert (siehe Abschnitt 15.4.2, „??berarbeite die Attributnamen, um einen Konflikt zu vermeiden“).

15.5.2. F??gen Sie Instanzvariablen zu einer Klasse hinzu

Hinweis, dass f??r die angegebene Klasse keine Instanzvariable spezifiziert wurde. Solche Klassen k??nnen erzeugt werden, um statische Attribute und Methoden zu spezifizieren, aber sie sollten per Konvention das Stereotyp «utility» erhalten.

15.5.3. F??gen Sie der Klasse einen Konstruktor hinzu

Sie haben bis jetzt keinen Konstruktor f??r die Klasse Klasse definiert. Konstruktoren initialisieren neue Instanzen, soda?? deren Attribute g??ltige Werte aufweisen. Diese Klasse ben??tigt wahrscheinlich einen Konstruktor, weil nicht alle seiner Attribute initiale Werte aufweisen.

Das Definieren guter Konstruktoren ist der Schl??ssel f??r das Einrichten unver??nderlicher Klassen und unver??nderliche Klassen sind eine leistungsf??hige Hilfe beim Schreiben soliden Codes.

Um dies zu beheben, f??gen Sie manuell einen Konstruktor hinzu, indem Sie im Explorer auf die Klasse klicken und eine Operation mit Hilfe des kontextsensitiven Popup-Men??s des Eigenschaftsregisters hinzuf??gen, oder die Klasse im Diagramm markieren und das Werkzeug Operation hinzuf??gen verwenden.

Im UML 1.4 Standard ist ein Konstruktor eine Operation mit dem Stereotypen «create». Obwohl kein strikter Standard, wird ArgoUML auch «Create» als Stereotyp f??r Konstruktoren akzeptieren.

Gem???? Java und C++-Konvention hat ein Konstruktor den gleichen Namen wie die Klasse, ist nicht statisch und gibt keinen Wert zur??ck. ArgoUML wird auch jede Operation akzeptieren, die diesen Konventionen eines Konstruktors folgt, auch wenn sie nicht den Stereotypen «create» aufweist.

[Achtung]Achtung

Operatoren werden in ArgoUML mit einem Standard-R??ckgabeparameter (return genannt) erzeugt. Sie m??ssen diesen Parameter entfernen, um der Java/C++-Konvention zu entsprechen.

15.5.4. Reduzieren Sie die Zahl der Attribute in der Klasse

Hinweis, dass die Klasse f??r ein gutes Design zu viele Attribute aufweist und das Risiko eines Designengpa?? in sich birgt.

Der Assistent dieser Kritik erlaubt das Einstellen eines Schwellwertes, z.B. die maximal erlaubte Anzahl von Attributen bevor diese Kritik ausgel??st wird.

[Achtung]Achtung

Diese Anzahl wird nicht dauerhaft gespeichert und es gibt keinen Weg, diese zu reduzieren, nachdem sie hochgesetzt wurde. Es sei denn, man erzeugt mehr Attribute, bis die Kritik erneut ausgel??st wird. Der Neustart von ArgoUML setzt dieses Anzahl wieder auf seinen Standardwert: 7.

15.6. Geplante Erweiterungen

Kritiken, die sich auf Schnittstellen und Subklassen beziehen.

[Anmerkung]Anmerkung

Es ist nicht klar, warum diese Kategorie den Namen „Geplante Erweiterungen“ hat.

Die aktuelle Version von ArgoUML hat drei Kritiken in dieser Kategorie.

15.6.1. Operationen in Schnittstellen m??ssen public sein

Hinweis, dass es keinen Punkt gibt, non-public Operationen in Schnittstellen haben zu m??ssen, da sie in einer realisierten Klasse sichtbar sein m??ssen.

15.6.2. Schnittstellen d??rfen nur Operationen haben

Hinweis, dass in einer Schnittstelle Attribute definiert wurden. Der UML-Standard definiert Schnittstellen nur mit Operationen.

[Achtung]Achtung

ArgoUML erlaubt es Ihnen nicht, Schnittstellen Attribute hinzuzuf??gen, soda?? dies in einem ArgoUML-Modell niemals auftreten sollte. Sie kann ausgel??st werden, wenn ein Projekt mit XMI geladen wurde, die durch ein anderes Werkzeug erzeugt wurde.

15.6.3. Entferne die Referenz auf die spezifische Subklasse

Hinweis, dass eine Klasse in einem guten Design seine Subklassen nicht direkt ??ber Attribute, Operationen oder Assoziationen referenzieren soll.

15.7. Zustandsautomaten

Kritiken, die sich auf Zustandsautomaten beziehen.

ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.7.1. Reduzieren Sie die Anzahl der Transitionen im <Zustand>

Hinweis, das der angegebene Zustand so viele Transitionen aufweist, dass er zu einem Leistungsengpass werden d??rfte.

Der Assistenz dieser Kritik erlaubt das Einstellen eines Schwellwertes, z.B. die maximale Anzahl von Transitionen bevor diese Kritik ausgel??st wird.

[Achtung]Achtung

Diese Anzahl wird nicht dauerhaft gespeichert und es gibt keinen Weg, diese zu reduzieren, nachdem sie hochgesetzt wurde. Es sei denn, man erzeugt mehr Transitionen, bis die Kritik erneut ausgel??st wird. Der Neustart von ArgoUML setzt dieses Anzahl wieder auf seinen Standardwert: 10.

15.7.2. Reduzieren Sie die Anzahl der Zust??nde im Automaten <Automat>

Hinweis, dass der angegebene Zustandsautomat so viele Zust??nde aufweist, da?? er bereits Konfusion ausl??st und vereinfacht ( vielleicht durch unterteilen in mehrere Automaten, oder durch Nutzung einer Hierarchie) werden sollte.

Der Assistenz dieser Kritik erlaubt die Einstellung eines Schwellwertes, z.B. die maximale Anzahl von erlaubten Zust??nden bevor diese Kritik ausgel??st wird.

[Achtung]Achtung

Diese Anzahl wird nicht dauerhaft gespeichert und es gibt keinen Weg, diese zu reduzieren, nachdem sie hochgesetzt wurde. Es sei denn, man erzeugt mehr Zust??nde, bis die Kritik erneut ausgel??st wird. Der Neustart von ArgoUML setzt dieses Anzahl wieder auf seinen Standardwert: 20.

15.7.3. F??gen Sie dem <Zustand> Transitionen hinzu

Hinweis, da?? der angegebene Zustand ankommende und abgehende Transitionen ben??tigt.

15.7.4. F??gen Sie ankommende Transitionen dem Modellelement <Modellelement> hinzu

Hinweis, da?? der angegebene Zustand ankommende Transitionen ben??tigt.

15.7.5. F??gen Sie abgehende Transitionen dem Modellelement <Modellelement> hinzu

Hinweis, da?? der angegebene Zustand abgehende Transitionen ben??tigt.

15.7.6. Entfernen Sie den zus??tzlichen Initialzustand

Hinweis, da?? es mehr als einen Initialzustand in dem Zustandsautomaten oder dem zusammengesetzten Zustand gibt, was in UML nicht erlaubt ist.

15.7.7. F??gen Sie einen initialen Zustand ein

Hinweis, da?? es keinen initialien Zustand in dem Zustandsautomaten oder dem zusammengesetzten Zustand gibt.

15.7.8. Einer Transition ein Signal oder einen W??chter hinzuf??gen

Hinweis, dass eine Transition entweder ein Signal oder einen W??chter vermisst. Einer davon ist mindestens notwendig.

15.7.9. ??ndere Vereinigungs-Transitionen

Hinweis, dass der Pseudozustand "Vereinigen" eine ung??ltige Anzahl von Transitionen aufweist. Normalerweise sollten es eine abgehende und zwei oder mehrere ankommende sein.

15.7.10. ??ndere Gabelungs-Transitionen

Hinweis, dass der Pseudozustand "Gabelung" eine ung??ltige Anzahl von Transitionen aufweist. Normalerweise sollten es eine ankommende und zwei oder mehrere abgehende sein.

15.7.11. Entscheidungs-/Kreuzungstransitionen hinzuf??gen

Hinweis, dass der Pseudozustands-Zweig (Entscheidung oder Kreuzung) eine ung??ltige Zahl von Transitionen aufweist. Normalerweise sollten es mindestens eine ankommende Transition und mindestens eine abgehende Transition sein.

15.7.12. Einer Transition W??chter hinzuf??gen

Hinweis, dass die Transition einen W??chter ben??tigt.

[Achtung]Achtung

Es ist nicht klar, ob dies eine g??ltige Kritik ist. Es ist sicherlich akzeptabel, eine Transistion ohne W??chter zu haben — die Transition wird immer genommen, wenn das Signal ausgel??st wird.

15.7.13. Das Diagramm aufr??umen

Diese Kritik wurde unter einer fr??heren Design-Kategorie diskutiert ( siehe Abschnitt 15.3.3, „Diagramm aufr??umen“).

15.7.14. Eine Kante sichtbarer machen

Hinweis, dass ein Kanten-Modellelement, wie zum Beispiel eine Assoziation oder Abstraktion so kurz ist, dass sie vermisst werden k??nnte. Ziehen Sie die verbundenen Modellelemente auseinander, um die Kanten sichtbarer zu machen.

15.7.15. Zusammengesetztes Assoziationsende mit der Kardinalit??t > 1

Eine Instanz kann durch eine Komposition nicht zu mehr als einer Kompositions-Instanz geh??ren. Sie m??ssen die Kardinalit??t am zusammengesetzten Ende der Assoziation entweder auf 0..1 oder 1..1 (1) setzen, damit das Modell Sinn macht.

Erinnern Sie sich, dass die Komposition die strengere Aggregationsart ist und die Aggregation schw??cher ist. Das Problem kann mit einem Modell verglichen werden, in dem ein Finger der integrale Teil von mehreren H??nden gleichzeitig sein kann.

Dies ist die zweite wohlgeformte Regel bei Assoziationsenden in UML 1.4.

15.8. Designmuster

Kritiken ??ber die Nutzung von Designmustern in ArgoUML.

Diese beziehen sich auf die Nutzung von Mustern, wie sie durch die sogenannte „Viererbande“ beschrieben wurden. ArgoUML nutzt diese Kategorie auch f??r Kritiken, die sich auf Verteilungs- und Sequenzdiagramme beziehen. Die aktuelle Version von ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.8.1. Die Nutzung des Singleton-Musters f??r eine <class> in Betracht ziehen.

Die Klasse hat keine nicht-statischen Attribute noch Assoziationen, die von der Instanz dieser Klasse abgehen. Das bedeutet, dass jede Instanz dieser Klasse identisch mit jeder anderen Instanz sein wird, da es nichts ??ber die Instanz gibt, was sie voneinander unterscheidbar macht.

Unter diesen Umst??nden sollten sie in Betracht ziehen, dass Sie genau eine Instanz dieser Klsse haben, indem Sie das Singleton-Muster verwenden. Die Nutzung des Singleton-Musters kann Zeit und Speicherplatz einsparen. Innerhalb von ArgoUML kann dies durch Nutzung des Stereotyps «singleton» auf diese Klasse umgesetzt werden.

Wenn es nicht Ihre Absicht ist nur eine Instanz zu haben, sollten Sie Instanzvariablen definieren (z.B. nicht-statische Attribute) und/oder abgehende Assoziationen, welche die Unterschiede zwischen den Instanzen repr??sentieren.

Wenn Sie eine Klasse als Singleton spezifiziert haben, m??ssen Sie die Klasse so definieren, dass sie nur eine Instanz haben kann. Dies wird die Informationsdarstellung Ihres Designs vervollst??ndigen. Um dies zu erreichen, m??ssen Sie folgendes tun.

  1. Sie m??ssen ein statisches Attribut definieren (eine Klassenvariable), welche die Instanz aufnimmt. Diese muss aus diesem Grund den Typ Klasse aufweisen.

  2. Sie d??rfen nur einen privaten Konstruktor haben, so dass keine neuen Instanzen durch anderen Code erzeugt werden kann. Das Erzeugen der einzigen Instanz kann durch eine passende Hilfsoperation erfolgen, die diesen privaten Konstruktor genau einmals aufruft.

  3. Sie m??ssen mindestens einen Konstruktor haben, um den Standardkonstruktor zu ??berschreiben, so dass der Standardkonstruktor nicht dazu verwendet wird mehrere Instanzen zu erzeugen.

Die Definition eines Konstruktors gem???? UML-Standard 1.4 und dessen Erweiterungen, so dass die Definition durch ArgoUML akzeptiert wird, siehe Abschnitt 15.5.3, „F??gen Sie der Klasse einen Konstruktor hinzu“.

15.8.2. Singleton Stereotyp-Verletzung in <Klasse>

Diese Klasse ist mit dem «singleton»-Stereotyp versehen, stimmt aber nicht mit den f??r Singletons geltenden Randbedingungen ??berein (ArgoUML akzeptiert auch den Stereotyp «Singleton » beim Definieren eines Singletons). Eine Singletonklasse kann maximal eine Instanz haben. Das bedeutet, dass die Klasse den Designkriterien f??r ein Singleton entsprechen muss (siehe Abschnitt 15.8.1, „ Die Nutzung des Singleton-Musters f??r eine <class> in Betracht ziehen. “).

Immer, wenn Sie eine Klasse mit einem Stereotypen kennzeichnen, sollte die Klasse allen Bedingungen dieses Stereotyps entsprechen. Die ist ein wichtiger Teil bei der Erstellung eines konsitenten und verst??ndlichen Designs. Die Nutzung des Singletonmusters kann Zeit und Speicherplatz einsparen.

Wenn Sie diese Klasse nicht l??nger als Singleton ben??tigen, entfernen Sie den Stereotypen «singleton» indem Sie auf die Klasse klicken und die leere Auswahl im Stereotyp-Kombinationsfeld des Registers Eigenschaften ausw??hlen.

Bei der Anwendung eines Singletonmusters sollten Sie den Anweisungen in Abschnitt 15.8.1, „ Die Nutzung des Singleton-Musters f??r eine <class> in Betracht ziehen. “ folgen.

15.8.3. Knoten haben normalerweise keine H??lle

Ein Hinweis, dass Knoten nicht innerhalb anderer Modellelemente im Verteilungsdiagramm eingezeichnet werden sollten, da sie ein autonomes physikalisches Objekt repr??sentieren.

15.8.4. Knoteninstanzen haben normalerweise keine H??lle

Ein Hinweis, dass Knoteninstanzen nicht innerhalb anderer Modellelemente im Verteilungsdiagramm eingezeichnet werden sollten, da sie ein autonomes physikalisches Objekt repr??sentieren.

15.8.5. Komponenten befinden sich normalerweise innerhalb von Knoten

Ein Hinweis, dass Komponenten logische Entit??ten innerhalb physikalischer Knoten repr??sentieren und innerhalb eines Knoten eingezeichnet werden sollten, wobei Knoten in einem Verteilungsdiagramm dargestellt werden.

15.8.6. Komponenteninstanzen befinden sich normalerweise innerhalb von Knoten

Ein Hinweis, dass Komponenteninstanzen logische Entit??ten innerhalb physikalischer Knoten repr??sentieren und innerhalb einer Knoteninstanz eingezeichnet werden sollten, wobei Knoteninstanzen in einem Verteilungsdiagramm dargestellt werden.

15.8.7. Klassen befinden sich normalerweise innerhalb von Komponenten

Ein Hinweis, dass Klassen als Modellelemente Komponenten bilden und innerhalb von Komponenten in Verteilungsdiagrammen eingezeichnet werden sollten.

15.8.8. Schnittstellen befinden sich normalerweise innerhalb von Komponenten

Ein Hinweis, dass Schnittstellen als Modellelemente Komponenten bilden und innerhalb von Komponenten in Verteilungsdiagrammen eingezeichnet werden sollten.

15.8.9. Objekte befinden sich normalerweise innerhalb von Komponenten

Ein Hinweis, dass Objekte als Instanzen von Modellelementen Komponenten bilden, die innerhalb von Komponenten oder Komponenteninstanzen in Verteilungsdiagrammen eingezeichnet werden sollten.

15.8.10. Verkn??pfungsenden haben nicht die gleiche Ebene

Ein Hinweis, dass eine Verkn??pfung (z.B. eine Assoziation), die Objekte in einem Verteilungsdiagramm verbindet, ein Ende in einer Komponente und das andere Ende in einer Komponenteninstanz (da Objekte in beiden auftreten k??nnen) hat. Dies macht keinen Sinn.

15.8.11. Klassifizierung einstellen (Verteilungsdiagramm)

Hinweis, dass es in einem Verteilungsdiagramm eine Instanz (Objekt) ohne eine verkn??pfte Klassifizierung gibt (Klasse, Datentyp).

15.8.12. Return-Aktionen werden vermisst

Hinweis, dass ein Sequenzdiagramm eine Sende- oder Aufrufaktion ohne entsprechende Return-Aktion enth??lt.

15.8.13. Vermisse Aufruf(Sende)-Aktion

Hinweis, dass ein Sequenzdiagramm eine Return-Aktion enth??lt, aber keine vorhergehende Aufruf- oder Sende-Aktion.

15.8.14. Kein Ausl??seimpuls bei diesen Verkn??pfungen

Hinweis, dass ein Sequenzdiagramm eine Objekte verbindende Verkn??pfung ohne verkn??pften Ausl??seimpuls aufweist (ohne den die Verkn??pfung bedeutungslos ist).

[Warnung]Warnung

Das Ausl??sen dieser Kritik weist auf schwerwiegendes Probleme hin, da ArgoUML keine Mechanismen f??r das Erzeugen einer Verkn??pfung ohne einen Ausl??seimpuls enth??lt. Es weist wahrscheinlich darauf hin, dass das Diagramm durch Laden eines defekten Projektes mit einer XMI-Datei erzeugt wurde, welche eine Verkn??pfung ohne Ausl??seimpuls beschreibt. Diese wurde m??glicherweise durch ein anderes Werkzeug erzeugt.

15.8.15. Klassifizierung einstellen (Sequenzdiagramm)

Hinweis, dass es in einem Sequenzdiagramm ein Objekt ohne eine damit verkn??pfte Klassifizierung (Klasse, Datentyp) gibt.

15.8.16. Falsche Position dieses Ausl??seimpulses

Hinweis, dass in einem Sequenzdiagramm die Initiierung eines Sende/Aufruf-Return-Nachrichtaustausches nicht richtig von links nach rechts initiiert wurde.

15.9. Beziehungen

Kritiken, die sich in ArgoUML auf Assoziationen beziehen.

Die aktuelle Version von ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.9.1. Zirkul??re Assoziation

Hinweis, dass eine Assoziationsklasse eine Rolle aufweist, die auf sich selbst verweist. Dies ist nicht erlaubt.

[Warnung]Warnung

Diese Kritik ist in der V0.14 von ArgoUML bedeutungslos, da sie Assoziationsklassen nicht unterst??tzt.

15.9.2. <Assoziation> navigierbar machen

Hinweis, dass die betreffende Assoziation in keine Richtung navigierbar ist. Dies ist im UML-Standard erlaubt, aber es hat in einem praktischen Design keinerlei Bedeutung.

15.9.3. Entferne die Navigation von der Schnittstelle via <Assoziation>

Assoziationen die eine Schnittstelle beinhalten k??nnen nicht von der Schnittstelle aus navigierbar sein. Dies ist so, weil Schnittstellen nur Operationsdeklarationen enthalten und keine Zeiger auf andere Objekte halten k??nnen.

Dieser Teil des Designs sollte ge??ndert werden, bevor Sie Code von diesem Design generieren. Wenn Sie den Code generieren, bevor Sie dieses Problem l??sen, wird der Code nicht mit dem Design ??bereinstimmen.

Um dies zu beheben markieren Sie die Assoziation und nutzen das Register Eigenschaften, um nach und nach jedes Assoziationsende auszuw??hlen, das nicht mit der Schnittstelle verbunden ist. Entfernen Sie die Markierung Navigierbar f??r jedes dieser Enden.

Die Assoziation sollte dann mit einem Pfeil in Richtung der Schnittstelle erscheinen.

Wenn eine Assoziation zwischen einer Klasse und einer Schnittstelle in ArgoUML erzeugt wird, ist diese standardm????ig nur von der Klasse zur Schnittstelle navigierbar. Jedoch verhindert es ArgoUML nicht, wenn die Navigierbarkeit danach fehlerhaft ge??ndert wird. Was diese Kritik ausl??sen w??rde.

15.9.4. Dem <Modellelement> eine Assoziation hinzuf??gen

Hinweis, dass das spezifizierte Modellelement (Akteur, Anwendungsfall oder Klasse) keine verbindenden Assoziationen zu anderen Modellelementen aufweist. Dies ist aber erforderlich, wenn das Modellelement in einem Design n??tzlich sein soll.

15.9.5. Referenz auf ein spezifische Subklasse entfernen

Diese Kritik wird unter einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.6.3, „Entferne die Referenz auf die spezifische Subklasse“).

15.9.6. Reduzieren Sie die Assoziationen des <Modellelementes>

Hinweis, dass das betreffende Modellelement (Akteur, Anwendungsfall, Klasse oder Schnittstelle) so viele Assoziationen aufweist, dass diese zu einem Wartungsengpass f??hren k??nnen.

Der Assistent dieser Kritik erlaubt das Einstellen eines Schwellwertes, z.B. die maximale Anzahl von erlaubten Assoziationen bevor diese Kritk ausgel??st wird.

[Achtung]Achtung

Diese Zahl wird nicht dauerhaft gespeichert. Es gibt keinen Weg sie zu reduzieren, nachdem sie nach oben gesetzt wurde. Es sei denn, man erzeugt mehr Assoziationen bis die Kritik erneut ausgel??st wird. Ein Restart von ArgoUML setzt diese Zahl auf seinen Standard zur??ck: 7.

15.9.7. Kanten sichtbarer machen

Diese Kritik wird in einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.7.14, „Eine Kante sichtbarer machen“).

15.10. Instanzen bilden

Kritiken, die sich auf das Bilden von Instanzen bei Klassifizierern in ArgoUML beziehen.

Die aktuelle Version von ArgoUML hat keine Kritiken in dieser Kategorie.

15.11. Modularit??t

Kritiken, die sich auf die modulare Entwicklung in ArgoUML beziehen.

Die aktuelle Version von ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.11.1. Der Klassifizierer befindet sich nicht im Namensraum seiner Assoziation.

Eine der wohlgeformten Regeln in UML 1.4 f??r Assoziationen lautet, dass alle Klassifizierer, die den Enden einer Assoziation zugewiesen werden, zum gleichen Namensraum geh??ren m??ssen wie die Assoziation.

Wenn dies nicht der Fall w??re, w??rde es keine Bezeichnung geben, ??ber das jedes Ende alle anderen referenzieren kann.

Diese Kritik wird ausgel??st, wenn eine Assoziation nicht mit diesem Kriterium ??bereinstimmt. Die L??sung ist, die Assoziation zu l??schen und im Diagramm neu zu erzeugen, sodass der Namensraum alle zugewiesenen Klassifizierer enth??lt.

[Achtung]Achtung

Diese Kritik kann in der aktuellen Implementierung von ArgoUML keine hierarchischen Namensr??ume verarbeiten. Als Konsequenz daraus, wird die Kritik f??r Assoziationen ausgel??st, bei denen der sich unmittelbare Namensraum der zugewiesenen Klassifizierer von dem der Assoziation unterscheidet, auch wenn sie Teil der gleichen Namensraumhierarchie sind.

15.11.2. F??gen Sie Elemente zum Paket <Paket> hinzu.

Hinweis, dass das angegebene Paket keinen Inhalt hat. Gutes Desgin weist Pakete auf, die erzeugt wurden, Dinge hinein zu tun.

[Anmerkung]Anmerkung

Diese Kritik wird immer ausgel??st, wenn Sie erstmalig ein Paket erzeugen, da Sie kein Paket erzeugen k??nnen, das nicht leer ist.

15.12. Erwartete Verwendung

Kritiken, die sich auf eine generell akzeptierte, gute Praxis beziehen.

Die aktuelle Version von ArgoUML hat eine Kritik in dieser Kategorie.

15.12.1. Diagramm aufr??umen

Diese Kritik wird in einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.3.3, „Diagramm aufr??umen“).

15.13. Methoden

Kritiken, die sich auf Operationen in ArgoUML beziehen.

Die aktuelle Version von ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.13.1. ??ndere Namen oder Signaturen im <Modellelement>

Diese Kritik wird in einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.4.3, „??ndere Namen oder Signaturen in einem Modellelement“).

15.13.2. Die Klasse mu?? abstrakt sein

Hinweis, dass eine Klasse, die abstrakte Operationen erbt oder definiert als abstrakte Klasse bezeichnet sein mu??.

15.13.3. F??gen Sie der <Klasse> Operationen hinzu

Hinweis, dass in der angegebenen Klasse keine Operationen definiert wurden. Dies ist f??r die Klasse aber erforderlich, damit sie im Design einen Nutzen hat.

15.13.4. Reduzieren Sie die Anzahl der Operationen im <Modellelement>

Hinweis; dass das Modellelement (Klasse oder Schnittstelle) zu viele Operationen aufweist, um gutem Design zu entsprechen. Dar??ber hinaus beinhaltet es das Risiko, zum Design-Wartungsengpa?? zu werden.

Der Assistent dieser Kritik erlaubt das Setzen eines Schwellwertes, z.B. die maximale Anzahl von erlaubten Operationen bevor diese Kritik ausgel??st wird.

[Achtung]Achtung

Diese Anzahl wird nicht dauerhaft gespeichert. Es gibt keinen Weg diese Anzahl zu reduzieren, nachdem sei einmal hochgesetzt wurde. Au??er, Sie erzeugen weitere Operationen bis diese Kritik erneut ausgel??st wird. Der Neustart von ArgoUML setzt diese Anzahl auf den Standardwert: 20 zur??ck.

15.14. Code-Generierung

Kritiken, die sich auf die Code-Generierung in ArgoUML beziehen.

Die aktuelle Version von ArgoUML hat eine Kritik in dieser Kategorie.

15.14.1. ??ndern Sie die Mehrfachvererbung in Schnittstellen

Hinweis, dass eine Klasse mehrere Vererbungen aufweist, was in UML erlaubt ist, aber nicht in Java-Code umgesetzt werden kann, da Java keine Mehrfachvererbung unterst??tzt.

15.15. Stereotypen

Kritiken, die sich auf Stereotypen in ArgoUML beziehen.

Die aktuelle Version von ArgoUML hat keine Kritiken in dieser Kategorie.

15.16. Vererbung

Kritiken, die sich mit der Generalisierung und Spezialisierung in ArgoUML befassen.

Die aktuelle Version von ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.16.1. ??berpr??fen Sie die Attributnamen, um einen Konflikt zu vermeiden.

Diese Kritik wird unter einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.4.2, „??berarbeite die Attributnamen, um einen Konflikt zu vermeiden“).

15.16.2. Entfernen Sie die zirkul??re Vererbung der Klasse <Klasse>

Hinweis, dass eine Klasse ??ber eine Kette von Vererbungen von sich selbst erbt, was nicht erlaubt ist.

[Achtung]Achtung

Diese Kritik ist in der aktuellen Release von ArgoUML standardm????ig als inaktiv markiert (die einzige so markierte Kritik). Sie wird nicht ausgel??st, bis sie aktiviert wird.

15.16.3. Die Klasse mu?? abstrakt sein

Diese Kritik wird in einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.13.2, „Die Klasse mu?? abstrakt sein“).

15.16.4. Entfernen Sie das Schl??sselwort final oder entfernen Sie Subklassen

Hinweis, das eine als final deklarierte Klasse Spezialisierungen aufweist, was in UML nicht erlaubt ist.

15.16.5. Illegale Generalisierung

Hinweis, dass es eine Generalisierung zwischen Modellelementen unterschiedlicher UML-Metaklassen gibt, was nicht erlaubt ist.

[Achtung]Achtung

Es ist nicht klar, wie so eine Generalisierung in ArgoUML erzeugt werden k??nnte. Wahrscheinlich zeigt sie auf, dass das Diagramm durch Laden eines defekten Projektes, mit einer XMI- Datei erzeugt wurde, die so eine Generalisierung beschreibt. Wahrscheinlich wurde diese durch ein anderes Tool als ArgoUML erzeugt.

15.16.6. Enferne unn??tige Realisierungen aus der Klasse <Klasse>

Hinweis, das die angegebene Klasse eine realisierte, direkte und indirekte Beziehung auf die gleiche Schnittstelle hat (durch Realisierung von zwei Schnittstellen, eine davon ist die Generalisierung der anderen, zum Beispiel). Ein gutes Design vermeidet solche Duplizierungen.

15.16.7. Definiere eine konkrete (Sub-)Klasse

Hinweis, dass eine Klasse als abstrakt deklariert ist, und keine konkrete Subklassen aufweist, so dass sie niemals realisiert (erzeugt) werden kann.

15.16.8. Definieren Sie eine Klasse, um die Schnittstelle <Schnittstelle> zu implementieren

Hinweis, dass die referenzierte Schnittstelle keine Auswirkung auf das laufende System hat, da sie nicht durch eine Klasse implementiert wurde.

15.16.9. ??ndere Mehrfachvererbung in Schnittstellen

Diese Kritik wird unter einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.14.1, „??ndern Sie die Mehrfachvererbung in Schnittstellen“).

15.16.10. Machen Sie die Kanten sichtbarer

Diese Kritik wird unter einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.7.14, „Eine Kante sichtbarer machen“).

15.17. Containment

Kritiken, die sich auf das Containment in ArgoUML beziehen. D.h., wo ein Modellelement den Komponententeil eines anderen bildet.

Die aktuelle Version von ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.17.1. Entferne zirkul??re Komposition

Hinweis, das es eine Reihe von Kompositionen (Assoziationen mit einem schwarzen Diamanten) gibt, die einen Zirkelbezug bilden, was nicht erlaubt ist.

15.17.2. Duplizieren Sie den Parameternamen

Hinweis, dass eine Parameterliste einer Operation oder eines Ereignisses zwei oder mehr Parameter mit dem gleichen Namen aufweist, was nicht erlaubt ist.

15.17.3. Zwei Aggregatenden (Rollen) in bin??rer Assoziation

Nur ein Ende (Rolle) einer bin??ren Assoziation kann Aggregat oder Komposition sein. Dies ist eine wohlgeformte Regel des UML 1.4- Standards.

Aggregation und Komposition werden verwendet, um Ganzes-Teil- Beziehungen darzustellen und der „Teil“ kann per Definition kein Aggregat(Zusammenfassung) sein.

Um dies zu l??sen, identifizieren Sie das „Teil“-Ende der Assoziation und verwenden Sie im Kritikassistenten die Schaltfl??che Weiter >, setzen seine Aggregation manuell mit Hilfe des Taste 2-Popup-Men??s oder des Eigenschaftsregisters auf none.

Eine Komposition (korrekter verbundene Aggregation genannt) wird verwendet, wenn es eine Ganzes-Teil-Beziehung gibt, die eins-zu-eins oder eins-zu-viele sind und die Lebensdauer des Teils unaufl??sbar von der Lebensdauer des Ganzen abh??ngt. Instanzen des Ganzen sind f??r das Erzeugen und L??schen der Instanzen der verknpften Teile verantwortlich. Das bedeutet auch, dass eine Klasse nur Teil einer verbundenen Aggregation sein kann.

Ein Beispiel einer verbundenen Aggregation k??nnte eine Datenbank von Autos mit deren Reifen sein. Dies ist eine eins-zu-vier- Beziehung und der Datenbankeintrag f??r einen Reifen ist mit seinem Auto verkn??pft. Wenn ein Auto in der Datenbank aufh??rt zu existieren, dann trifft dies auch auf seine Reifen zu.

Die Aggregation (korrekter aufgeteilte Aggregation genannt) wird verwendet, wenn es eine Ganzes-Teil-Beziehung gibt, die nicht den Kriterien f??r eine verbunden Aggregation ??bereinstimmt. Ein Beispiel k??nnte eine Datenbank von Universit??tskursen und den Studenten sein, die diese belegen. Es gibt eine Ganzes-Teil-Beziehung zwischen den Kursen und den Studenten. Jedoch gibt es keine Lebensdauerbeziehung zwischen den Studenten und den Kursen (ein Student existiert weiter, nachdem er den Kurs absolviert hat) und die Beziehung lautet viele-zu-viele.

15.17.4. Aggregatende (Rolle) in 3-Wege (oder mehr) Assoziation

Drei-Wege- (oder mehr) Assoziationen k??nnen keine Aggregatenden (Rollen) haben. Dies ist eine wohlgeformte Regel des UML 1.4- Standards.

Aggregation und Komposition werden verwendet, um Ganzes-Teile- Beziehungen darzustellen. Diese k??nnen per Definition nur auf bin??re Assoziationen zwischen Modellelementen angewendet werden.

Um dies zu l??sen, markieren Sie die Assoziation manuell und setzen Sie jedes Ende (Rolle) dieser Aggregation mit Hilfe des Taste 2- Popup-Men??s oder dem Eigenschaftsregister auf none.

15.17.5. Datentyp verbergen

Diese Kritik wird unter einer fr??heren Designkategorie diskutiert (siehe Abschnitt 15.3.1, „Datentyp verbergen“).

Teil 3. Modellreferenz

Kapitel 16. Modellreferenz auf h??chster Ebene

16.1. Einleitung

Dieses Kapitel beschreibt jedes Modellelement, dass innerhalb von ArgoUML erzeugt werden kann. Das Kapitel deckt die „ generellen“ Modellelemente auf h??chster Ebene ab. Die folgenden Kapitel (siehe Kapitel 17, Use Case Diagram Model Element Reference bis Kapitel 23, Deployment Diagram Model Element Reference) decken jedes der ArgoUML- Diagramme ab.

Es gibt eine enge Beziehung zwischen diesem Material und dem Register Eigenschaften des Detailfensters (siehe Abschnitt 13.3, „Das Register Eigenschaften“). Dieser Abschnitt deckt die Eigenschaften im Allgemeinen ab, in diesem Kapitel werden sie mit den spezifischen Modellelementen verkn??pft.

16.2. Das Modell

Das Modell ist in ArgoUML ein Modellelement auf h??chster Ebene. Im UML-Metamodell ist es eine Subklasse von package. In vielerlei Hinsicht weist es innerhalb von ArgoUML ??hnlichkeiten mit einem package auf (siehe Abschnitt 18.2, „Package“).

[Anmerkung]Anmerkung

ArgoUML ist auf ein Modell beschr??nkt.

Standard-Datentypen, Klassen und Pakete werden (der Standard, siehe Kapitel 24, Built In DataTypes, Classes, Interfaces and Stereotypes) als Sub-Pakete des Modells geladen. Diese Subpakete sind im Modell zu Beginn nicht pr??sent, werden aber zum Modell hinzugef??gt, wenn sie verwendet werden.

16.2.1. Die Register Modelldetails

Die Details-Register sind f??r das Modell wie folgt aktiv.

Zu-Bearbeiten-Element

Standard-Register.

Eigenschaften

Siehe Abschnitt 16.2.2, „Symbolleiste Modelleigenschaften“ und Abschnitt 16.2.3, „Eigenschaftsfelder des Modelles“ unten.

Dokumentation

Standard-Register. Siehe Abschnitt 13.4, „Das Register Dokumentation“.

Stereotypen

Standard-Register. Dies enth??lt eine Liste von Stereotypen, die diesem Modell zugeordnet sind und eine Liste der verf??gbaren Stereotypen, die auf dieses Modell angewendet werden k??nnen.

Eigenschaftswerte

Standard-Register. Im UML-Metamodell hat das Modell die folgenden Standard-Eigenschaftswerte definiert.

  • derived (von der Superklasse, Modellelement).

    Werte true, bedeutet: die Klasse ist redundant — sie kann formal von anderen Elementen abgeleitet werden oder, false bedeutet: sie kann nicht von anderen Elementen abgeleitet werden.

    Abgeleitete Modelle haben ihren Wert in der Analyse, um n??tzliche Namen oder Konzepte einzuf??hren und im Design, um eine Nachverarbeitung zu verhindern.

16.2.2. Symbolleiste Modelleigenschaften

Nach oben

Navigiert durch die zusammengesetzte Struktur des Modelles nach oben.

Das das Modell das oberste Paket ist, kann nichts passieren. Aus diesem Grund ist die Schaltfl??che immer deaktiviert.

Neues Paket

Dies erzeugt eine neues Paket (siehe Abschnitt 18.2, „Package“) innerhalb des Modelles (das in keinem Diagramm erscheint), und springt sofort in das Register Eigenschaften des Paketes.

[Tipp]Tipp

Da es Sinn machen kann, Pakete f??r diese Modell auf diese Weise zu erzeugen, ist es gew??hnlich deutlich klarer, diese innerhalb der Diagramme zu erzeugen, wenn Sie welche ben??tigen.

Neuer Datentyp

Dies erzeugt einen neuen Datentyp (siehe Abschnitt 16.3, „Datentyp“) innerhalb des Modelles (der in keinem Diagramm erscheint) und springt sofort in das Register Eigenschaften dieses Datentyps.

Neue Aufz??hlung

Dies erzeugt eine neue Aufz??hlung (siehe Abschnitt 16.4, „Enumeration“) innerhalb des Modelles (die in keinem Diagramm erscheint) und springt sofort in das Register Eigenschaften dieser Aufz??hlung.

Neuer Stereotyp

Dies erzeugt einen neuen Stereotypen (siehe Abschnitt 16.6, „Stereotype“) innerhalb des Modelles und springt sofort in das Register Eigenschaften dieses Stereotypen.

L??schen

Dieses Symbol ist immer deaktiviert, da es keinen Sinn macht, das Modell zu l??schen!

16.2.3. Eigenschaftsfelder des Modelles

Name

Textfeld. Name des Modelles. Der Name des Modelles, wie alle anderen Pakete, wird per Konvention in Kleinbuchstaben geschrieben.

[Anmerkung]Anmerkung

Der Standardname, der einem neuen Modell in ArgoUML zugwiesen wird ist unbenanntesModell. Er ist daher fehlerfrei und garantiert, dass ArgoUML immer mit mindestens einem Problem startet, was durch die Design- Kritiken ausgestellt wird.

Stereotyp

DropDown-Auswahl. Das Modell ist standardm????ig mit den UML-Standard-Stereotypen f??r Modelle ( systemModel und metamodel) und dem Paket ( facade, framework, stub) ausgestattet.

Das stereotypisieren von Modellen ist n??tzlich, obwohl es in ArgoUML nur von eingeschr??nktem Wert ist, da Sie nur ein einziges Modell haben.

Stereotypen steuern

Symbol. Wenn ein Stereotyp markiert wurde, wird dieser ??ber das Stereotyp-Eigenschaftsfenster gesteuert (siehe Abschnitt 16.6, „Stereotype“).

Namensraum

Textfeld. Nimmt den Namensraum des Modelles auf. Dies ist die Pakethierarchie. Da sich das Modell an der Spitze der Hierarchie befindet, ist dieses Feld immer leer.

Sichtbarkeit

Auswahlbereich mit den Eintr??gen public, private, protected und package.

Zeichnet die Sichtbarkeit des Modelles auf. Da ArgoUML nur ein Modell erlaubt, hat diese Eigenschaft keine besondere Bedeutung.

Modifizierer

Markier-Bereich mit den Eintr??gen Abstract, Leaf und Root.

  • abstract wird verwendet, um zu deklarieren, dass dieses Modell nicht instantiiert werden kann. Aber es mu?? immer spezialisiert werden.

    Die Bedeutung von abstract, wenn es auf ein Modell angewendet wird ist nicht klar. Es k??nnte bedeuten, dass das Modell Schnittstellen oder abstrakteKlassen ohne Realiserung enth??lt. Da ArgoUML nur ein Modell erlaubt, ist das markieren dieses Feldes bedeutungslos.

  • Leaf gibt an, dass diese Modell keine weiteren Subpakete haben darf, w??hrend root angibt, das es das Modell auf oberster Ebene ist.

    Innerhalb von ArgoUML kann root nur auf das Modell sinnvoll angewendet werden, da alle Pakete sich innerhalb des Modelles befinden. In Abwesenheit des Stereotypen topLevel, kann dies dazu verwendet werden, herauszustellen dass das Modell sich auf der obersten Ebene befindet.

Generalisierungen

Textbereich. Listet jedes Modell auf, das dieses Modell generalisiert.

[Anmerkung]Anmerkung

Da es in ArgoUML nur ein Modell gibt, gibt es keine Spezialisierung oder Generalisierung, die erzeugt werden k??nnte.

Spezialisierung

Textbereich. Listet jedes spezialisiertes Modell auf (z.B. f??r welches Modell diese Modell eine Generalisierung ist).

[Anmerkung]Anmerkung

Da es in ArgoUML nur ein Modell gibt, gibt es keine Spezialisierung oder Generalisierung, die erzeugt werden k??nnte.

Eigene Elemente

Textbereich. Eine Liste der Pakte, Klassen, Schnittstellen, Datentypen, Akteure, Anwendungsf??lle, Assoziationen, Generalisierungen und Stereotypen innerhalb des Modelles auf oberster Ebene.

Ein Taste 1-Klick auf jedes dieser Modellelemente veranlasst, dass zu diesem Modellelement gesprungen wird.

16.3. Datentyp

Datentypen kann man sich als einfache Klassen denken. Sie haben keine Attribute und jede Operation von Ihnen darf keine Seiteneffekte aufweisen. Eine n??tzliche Analogie sind primitive Datentypen in einer Sprache wie Java. Die Integerzahl „3“ steht f??r sich selbst— sie hat keine innere Struktur. Es gibt Operationen (z.B. Addition) auf Integerzahlen, aber wenn sie 3 + 4 ausf??hren, ist das Ergebnis eine neue Zahl, „3“ und „4“ bleiben in diesem Beispiel unver??ndert.

Innerhalb von UML 1.4 ist ein Datentyp eine Subklasse der Metaklasse Klassifizierer. Dieser umfasst die vordefinierten primitiven Typen (byte , char, double, float, int, long und short), die vordefinierte Aufz??hlung, boolean und die anwenderdefinierten enumeration Typen.

[Anmerkung]Anmerkung

Auch void ist als Datentyp innerhalb von ArgoUML definiert.

Innerhalb von ArgoUML k??nnen neue Datentypen mit Hilfe der Schaltfl??che Neuer Datentyp im Register Eigenschaften des Modelles und Paketen (in diesem Fall ist der neue Datentyp auf den Scope des Paktes beschr??nkt), als auch im Register Eigenschaften f??r Datentypen erzeugt werden. Datentypen k??nnen auch mit dem Symbol in der Diagrammsymbolleiste eines Klassendiagrammes erzeugt werden.

Der UML 1.4-Standard erlaubt das Plazieren von benutzerdefinierten Datentypen in Klassendiagrammen, um deren Vererbungsstruktur zu definieren. Dies ist auch in ArgoUML m??glich. Er wird im Diagramm durch einen Rahmen mit zwei Bereichen dargestellt, wobei der oberste mit «Datentyp» gekennzeichnet ist und den Namen enth??lt. Der untere enth??lt die Operationen.

16.3.1. Register Datentyp-Details

Die Register Details, die f??r Datentypen aktiv sind, sind folgende:

Zu-Bearbeiten-Element

Standard-Register.

Eigenschaften

Siehe Abschnitt 16.3.2, „Datatype Property Toolbar“ und Abschnitt 16.3.3, „Property Fields For Datatype“ unten.

Dokumentation

Standard-Register. Siehe Abschnitt 13.4, „Das Register Dokumentation“.

Quelldatei

Standard-Register. Nicht im Einsatz. Es w??rde eine Klassendeklaration f??r den neuen Datentyp erwarten, um die Code-Generierung zu erm??glichen.

Eigenschaftswerte

Standard-Register. Das UML-Metamodell hat die folgenden Eigenschaftswerte f??r Datentyp definiert.

  • persistence (von der Superklasse , Classifier). Werte transitory, geben an, dass der Zustand gel??scht wird, wenn eine Instanz gel??scht oder persistent wird, der markierte Zustand wird erhalten, wenn eine Instanz gel??scht wird.

    [Tipp]Tipp

    Da benutzerdefinierte Datentypen Aufz??hlungen sind, haben sie keinen zu erhaltenden Zustand und der Wert dieses Eigenschaftswertes ist irrelevant.

  • semantics (von der Superklasse , Classifier). Der Wert ist eine Spezifikation der Semantik des Datentyps.

  • derived (von der Superklasse , Modell-Element). Werte mit true bedeuten, dass die Klasse redundant ist— sie kann formal von anderen Elementen abgeleitet werden. false bedeutet, dass sie nicht abgeleitet werden kann.

    [Tipp]Tipp

    While formally available, a derived datatype does not have an obvious value, and so datatypes should always be marked with derived=false.

16.3.2. Datatype Property Toolbar

Go up

Navigate up through the package structure.

New datatype

This creates a new datatype (see Abschnitt 18.6, „Class“) within the same package as the current datatype.

[Tipp]Tipp

While it can make sense to create datatypes this way, it can be clearer to create them within the package or model where you want them.

New Enumeration

This creates a new Enumeration (see Abschnitt 16.4, „Enumeration“) in the same package as the datatype, navigating immediately to the properties tab for that Enumeration.

New Operation

This creates a new operation within the datatype, navigating immediately to the properties tab for that operation.

New Stereotype

This creates a new Stereotype (see Abschnitt 16.6, „Stereotype“) within the same package as the datatype, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the datatype from the model.

16.3.3. Property Fields For Datatype

Name

Text box. The name of the datatype. The primitive datatypes all have lower case names, but there is no formal convention.

[Anmerkung]Anmerkung

The default name supplied for a newly created datatype is the empty string „“. Datatypes with empty string names will appear with the name (Unnamed Datatype) in the explorer.

Namespace

Drop down selector with navigate button. Allows changing the namespace for the datatype. This is the package hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that this datatype cannot be instantiated, but must always be specialized.

    [Anmerkung]Anmerkung

    ArgoUML provides no mechanism for specializing datatypes, so this check box is of little use.

  • Leaf indicates that this datatype can have no further sub-types, while Root indicates it is a top level datatype.

    [Tipp]Tipp

    You can define the specialization of datatypes in a class diagram by drawing generalizations between them.

Visibility

Radio box, with entries public, private, protected, and package.

Records the visibility for the Datatype.

Client Dependencies

Text area. Lists any elements that depend on this datatype.

[Achtung]Achtung

It is not clear that dependencies between datatypes makes much sense.

Supplier Dependencies

Text area. Lists any elements that this datatype depends on.

[Achtung]Achtung

It is not clear that dependencies between datatypes makes much sense.

Generalizations

Text area. Lists any datatype that generalizes this datatype.

Specializations

Text box. Lists any specialized datatype (i.e. for which this datatype is a generalization.

Operations

Text area. Lists all the operations defined on this datatype. Button 1 double click navigates to the selected operation. button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more operations, and the operation selected is not at the top. It is moved up one.

  • Move Down. Only available where there are two or more operations listed, and the operation selected is not at the bottom. It is moved down one.

See Abschnitt 18.8, „Operation“ for details of operations.

[Achtung]Achtung

ArgoUML treats all operations as equivalent. Any operations created here will use the same mechanism as operations for classes. Remember that operations on datatypes must have no side effects (they are read-only). This means the query modifier must be checked for all operations.

16.4. Enumeration

An enumeration is a primitive datatype that can have a fixed short list of values. It has no attributes, and any operations on them must have no side-effects. A useful analogy is the primitive datatype boolean in a language like Java. The boolean stands on its own—it has no inner structure. There are operations (for example logical xor) on the booleans, but when I perform true xor true the result is a new boolean, and the original 2 booleans „true“ are unchanged by the exercise.

Within UML 1.4, Enumeration is a sub-class of the DataType metaclass.

The big difference with other DataTypes, is that an Enumeration has EnumerationLiterals. E.g. the Enumeration „boolean“ is defined as having 2 EnumerationLiterals, „true“ and „false“.

Within ArgoUML new enumerations may be created using the New Enumeration button on the property tabs of the model and packages (in which case the new enumeration is restricted in scope to the package), as well as the properties tab for datatype and enumeration. Enumerations can also be created with the tool in the diagram toolbar of a class diagram.

The UML 1.4 standard allows user defined enumerations to be placed on class diagrams to define their inheritence structure. This is also possible in ArgoUML. It is represented on the diagram by a box with three compartments, of which the top one is marked with «enumeration», and contains the name. The middle compartment shows the enumeration literals. The lower one contains operations.

16.4.1. Enumeration Details Tabs

The details tabs that are active for enumerations are as follows.

ToDoItem

Standard tab.

Properties

See Abschnitt 16.4.2, „Enumeration Property Toolbar“ and Abschnitt 16.4.3, „Property Fields For Enumeration“ below.

Documentation

Standard tab. See Abschnitt 13.4, „Das Register Dokumentation“.

Presentation

Standard tab.

Source

Standard tab.

Stereotype

Standard tab. The UML metamodel has the following stereotypes defined by default for a Classifier, which also apply to an Enumeration:

  • metaclass (from the superclass, Classifier).

  • powertype (from the superclass, Classifier).

  • process (from the superclass, Classifier).

  • thread (from the superclass, Classifier).

  • utility (from the superclass, Classifier).

Tagged Values

Standard tab. In the UML metamodel, Enumeration has no standard tagged values defined.

16.4.2. Enumeration Property Toolbar

Go up

Navigate up through the composition structure.

New datatype

This creates a new datatype (see Abschnitt 18.6, „Class“) within the same package as the current enumeration.

New enumeration

This creates a new enumeration within the same namespace as the current enumeration, navigating immediately to the properties tab for new enumeration.

New enumeration literal

This creates a new enumeration literal within the enumeration, navigating immediately to the properties tab for that literal.

New Operation

This creates a new operation within the enumeration, navigating immediately to the properties tab for that operation.

New Stereotype

This creates a new Stereotype (see Abschnitt 16.6, „Stereotype“) within the same package as the enumeration, navigating immediately to the properties tab for that stereotype.

Delete from Model

This deletes the datatype from the model.

16.4.3. Property Fields For Enumeration

Name

Text box. The name of the enumeration. The primitive enumerations all have lower case names, but there is no formal convention.

[Anmerkung]Anmerkung

The default name supplied for a newly created datatype is the empty string „“. Enumerations with empty string names will appear with the name (Unnamed Enumeration) in the explorer.

Namespace

Drop down selector with navigation button. Allows changing the namespace for the enumeration. This is the composition hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that this enumeration cannot be instantiated, but must always be specialized.

  • Leaf indicates that this enumeration can have no further sub-types, while Root indicates it is a top level enumeration.

Visibility

Radio box, with entries public, private, protected, and package.

Records the visibility for the Enumeration.

Client Dependencies

Text area. Lists any elements that depend on this enumeration. Button 1 double click navigates to the selected modelelement. Button 2 click brings up a pop up menu with following entry.

  • Add.... This brings up a dialog box that allows to create dependencies from other modelelements.

Supplier Dependencies

Text area. Lists any elements that this enumeration depends on. Button 1 double click navigates to the selected modelelement. Button 2 click brings up a pop up menu with the following entry.

  • Add.... This brings up a dialog box that allows to create dependencies to other modelelements.

Generalizations

Text area. Lists any enumeration that generalizes this enumeration.

Specializations

Text box. Lists any specialized enumerations (i.e. for which this enumeration is a generalization.

Operations

Text area. Lists all the operations defined on this enumeration. Button 1 double click navigates to the selected operation. Button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more operations, and the operation selected is not at the top. It is moved up one.

  • Move Down. Only available where there are two or more operations listed, and the operation selected is not at the bottom. It is moved down one.

See Abschnitt 18.8, „Operation“ for details of operations.

[Achtung]Achtung

ArgoUML treats all operations as equivalent. Any operations created here will use the same mechanism as operations for classes. Remember that operations on enumerations must have no side effects (they are read-only). This means the query modifier must be checked for all operations.

Literals

Text area. Lists all the enumeration literals defined for this enumeration. Button 1 double click navigates to the selected literal, button 2 click brings up a pop up menu with two entries.

  • Move Up. Only available where there are two or more literals, and the literal selected is not at the top. It is moved up one.

  • Move Down. Only available where there are two or more literals listed, and the literal selected is not at the bottom. It is moved down one.

16.5. Enumeration Literal

An enumeration literal is one of the predefined values of an Enumeration.

16.6. Stereotype

Stereotypes are the main extension mechanism of UML, providing a way to derive specializations of the standard metaclasses. Stereotype is a sub-class of GeneralizableElement in the UML metamodel. Stereotypes are supplemented by constraints and tagged values.

New stereotypes are added from the property tab of almost any model element. Properties of existing stereotypes can be reached by selecting the property tab for any model element with that stereotype and using the navigate button ( ) within the property tab.

16.6.1. Stereotype Details Tabs

The details tabs that are active for stereotypes are as follows.

ToDoItem

Standard tab.

Properties

See Abschnitt 16.6.2, „Stereotype Property Toolbar“ and Abschnitt 16.6.3, „Property Fields For Stereotype“ below.

Documentation

Standard tab. See Abschnitt 13.4, „Das Register Dokumentation“.

Stereotype

Standard tab.

[Warnung]Warnung

Here you can set stereotypes of stereotypes, not a very usefull thing to do.

Tagged Values

Standard tab. In the UML metamodel, Stereotype has the following standard tagged values defined.

  • derived (from the superclass, ModelElement). Values true, meaning the class is redundant—it can be formally derived from other elements, or false meaning it cannot.

    [Anmerkung]Anmerkung

    This indicates any element with this stereotype has the derived tag set accordingly.

[Achtung]Achtung

Tagged values for a stereotype are rather different to those for elements in the UML core architecture, in that they apply to all model elements to which the stereotype is applied, not just the stereotype itself.

16.6.2. Stereotype Property Toolbar

Go up

Navigate up through the package structure of the model.

Add stereotype

This creates a new stereotype (see Abschnitt 16.6, „Stereotype“) within the model (which appears on no diagram), navigating immediately to the properties tab for that stereotype.

New Tag Definition

This creates a new tag definition (see Abschnitt 16.7, „Tag Definition“) within the model (which appears on no diagram), navigating immediately to the properties tab for that tagdefinition.

Delete

This deletes the stereotype from the model.

16.6.3. Property Fields For Stereotype

Name

Text box. The name of the stereotype. There is no convention for naming stereotypes, beyond starting them with a lower case letter. Even the standard UML stereotypes vary between all lower case (e.g. metamodel), bumpy caps (e.g. systemModel) and space separated (e.g. object model).

[Anmerkung]Anmerkung

ArgoUML does not enforce any naming convention for stereotypes

Base Class

Drop down selector. Any stereotype must be derived from one of the metaclasses in the UML metamodel or the model element classes that derive from them. The stereotype will then be available to model elements that derive from that same metaclass or that model element.

Namespace

Drop down selector with navigation button. Records the namespace for the stereotype. This is the package hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that model elements that use this stereotype cannot be instantiated, but must always be specialized.

  • Leaf indicates that model elements that use this stereotype can have no further sub-types, while Root indicates it is a top level model element.

[Achtung]Achtung

Remember that these modifiers apply to the model elements using the stereotype, not just the stereotype.

[Warnung]Warnung

ArgoUML neither imposes, nor checks that model elements using a stereotype adopt the stereotype's modifiers.

Visibility

Radio box, with entries public, private, protected, and package.

Records the visibility for the stereotype.

Generalizations

Text area. Lists any stereotype that generalizes this stereotype.

Specializations

Text area. Lists any specialized stereotype (i.e. for which this stereotype is a generalization.

Tag Definitions

Text area. Lists any tag definitions that are defined for this stereotype.

Extended Elements

Text area. Lists all modelelements that are stereotyped by this stereotype.

16.7. Tag Definition

(To Be Written)

16.8. Diagram

The UML standard specifies eight principal diagrams, all of which are supported by ArgoUML.

  • Use case diagram. Used to capture and analyse the requirements for any OOA&D project. See Kapitel 17, Use Case Diagram Model Element Reference for details of the ArgoUML use case diagram and the model elements it supports.

  • Class diagram. This diagram captures the static structure of the system being designed, showing the classes, interfaces and datatypes and how they are related. Variants of this diagram are used to show package structures within a system (the package diagram) and the relationships between particular instances (the object diagram).

    The ArgoUML class diagram provides support for class and package diagrams. See Kapitel 18, Class Diagram Model Element Reference for details of the model elements it supports. The object diagram is suported on the Deployment diagram.

  • Behavior diagrams. There are four such diagrams (or strictly speaking, five, since the use case diagram is a type of behavior diagram), which show the dynamic behavior of the system at all levels.

    • Statechart diagram. Used to show the dynamic behavior of a single object (class instance). This diagram is of particular use in systems using complex communication protocols, such as in telecommunications. See Kapitel 20, Statechart Diagram Model Element Reference for details of the ArgoUML statechart diagram and the model elements it supports.

    • Activity diagram. Used to show the dynamic behavior of groups of objects (class instance). This diagram is an alternative to the statechart diagram, and is better suited to systems with a great deal of user interaction. See Kapitel 22, Activity Diagram Model Element Reference for details of the ArgoUML activity diagram and the model elements it supports.

    • Interaction diagrams. There are two diagrams in this category, used to show the dynamic interaction between objects (class instances) in the system.

      • Sequence diagram. Shows the interactions (typically messages or procedure calls) between instances of classes (objects) and actors against a timeline. Particularly useful where the timing relationships between interactions are important. See Kapitel 19, Sequence Diagram Model Element Reference for details of the ArgoUML sequence diagram and the model elements it supports.

      • Collaboration diagram. Shows the interactions (typically messages or procedure calls) between instances of classes (objects) and actors against the structural relationships between those instances. Particularly suitable where it is useful to relate interactions to the static structure of the system. See Kapitel 21, Collaboration Diagram Model Element Reference for details of the ArgoUML collaboration diagram and the model elements it supports.

  • Implementation diagrams. UML defines two implementation diagrams to show the relationship between the software components that make up a system (the component diagram) and the relationship between the software and the hardware on which it is deployed at run-time (the deployment diagram.

    The ArgoUML deployment diagram provides support for both component and deployment diagrams, and additionally for object diagrams. See Kapitel 23, Deployment Diagram Model Element Reference for details of the diagram and the model elements it supports.

Diagrams are created using the Create drop down menu (see Abschnitt 10.6, „Das Men?? "Neues Diagramm"“ ), or with the tools on the toolbar (see Abschnitt 9.4, „Neues Diagramm“), or with the pop-up menus in the explorer.

[Anmerkung]Anmerkung

ArgoUML uses its deployment diagram to create the UML 1.4 component, deployment and object diagrams.

[Achtung]Achtung

Statechart and activity diagrams are associated with a particular class or operation (or the latter also with a package), and can only be created when this modelelement has been selected.

[Warnung]Warnung

In ArgoUML version 0.24, the UML 1.4 object diagram as a variant of the class diagram is not directly supported. However, it is possible to create simple object diagrams within the ArgoUML deployment diagram.

16.8.1. Diagram Details Tabs

The details tabs that are active for diagrams are as follows.

ToDoItem

Standard tab.

Properties

See Abschnitt 16.8.3, „Property Fields For Diagram“ below.

16.8.2. Diagram Property Toolbar

Go up

Navigate up through the package structure of the model.

Delete

This deletes the diagram from the model. As a consequence, in case of a statechart diagram or an activity diagram, all contained elements are deleted, too.

16.8.3. Property Fields For Diagram

Name

The name of the diagram. There are no conventions for naming diagrams. By default, ArgoUML uses the (space separated) diagram name and a sequence number, thus Use Case Diagram 1.

[Tipp]Tipp

This name is used to generate a filename when activating the „Save Graphics...“ menu-item.

Home Model

The Home Model of the diagram is not something defined in the UML specification. The Home Model is the modelelement represented by the diagram. Hence its type depends on the type of diagram: e.g. it is the namespace represented by a class diagram, or the statemachine in case of a Statechart diagram.

Kapitel 17. Use Case Diagram Model Element Reference

17.1. Introduction

This chapter describes each model element that can be created within a use case diagram. Note that some sub-model elements of model elements on the diagram may not actually themselves appear on the diagram.

There is a close relationship between this material and the properties tab of the details pane (see Abschnitt 13.3, „Das Register Eigenschaften“). That section covers properties in general, in this chapter they are linked to specific model elements.

Abbildung 17.1, „Typical model elements on a use case diagram.“ shows a use case diagram with all typical model elements displayed.

Abbildung 17.1. Typical model elements on a use case diagram.

Typical model elements on a use case diagram.


17.1.1. ArgoUML Limitations Concerning Use Case Diagrams

Use case diagrams are now well supported within ArgoUML. There still are some minor limitations though, especially with extension points.

[Anmerkung]Anmerkung

Earlier versions of ArgoUML (0.9 and earlier) implemented extend and include relationships by using a stereotyped dependency relationship. Although such diagrams will show correctly on the diagram, they will not link correctly to the use cases, and should be replaced by proper extend and include relationships using the current system.

17.2. Actor

An actor represents any external entity (human or machine) that interacts with the system, providing input, receiving output, or both.

Within the UML metamodel, actor is a sub-class of classifier.

The actor is represented by a „stick man“ figure on the diagram (see Abbildung 17.1, „Typical model elements on a use case diagram.“).

17.2.1. Actor Details Tabs

The details tabs that are active for actors are as follows.

ToDoItem

Standard tab.

Properties

See Abschnitt 17.2.2, „Actor Property Toolbar“ and Abschnitt 17.2.3, „Property Fields For Actor“ below.

Documentation

Standard tab. See Abschnitt 13.4, „Das Register Dokumentation“.

Presentation

Standard tab. The fill color is used for the stick man's head.

Source

Standard tab. Usually, no code is provided for an actor, since it is external to the system.

Stereotype

Standard tab.

Tagged Values

Standard tab. In the UML metamodel, Actor has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.

    [Tipp]Tipp

    Actors sit outside the system, and so their internal behavior is of little concern, and this tagged value is best ignored.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the actor.

  • derived (from the superclass, ModelElement). Values true, meaning the actor is redundant—it can be formally derived from other elements, or false meaning it cannot.

    [Anmerkung]Anmerkung

    Derived actors have limited value, since they sit outside the system being designed. They may have their value in analysis to introduce useful names or concepts.

Checklist

Standard tab for a Classifier.

17.2.2. Actor Property Toolbar

Go up

Navigate up through the package structure of the model.

Add Actor

This creates a new actor within the model, (but not within the diagram), navigating immediately to the properties tab for that actor.

[Tipp]Tipp

This method of creating a new actor may be confusing. It is much better to create an actor on the diagram.

New Reception

This creates a new reception within the model,(but not within the diagram), navigating immediately to the properties tab for that rception.

[Tipp]Tipp

A reception is a declaration that the actor handles a signal, but the actual handling is specified by a state machine.

Delete

This deletes the selected actor from the model.

[Warnung]Warnung

This is a deletion from the model not just the diagram. To delete an actor from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.2.3. Property Fields For Actor

Name

Text box. The name of the actor. The diagram shows this name below the stick man figure. Since an actor is a classifier, it would be conventional to Capitalize the first letter (and initial letters of any component words), e.g. RemoteSensor.

[Anmerkung]Anmerkung

ArgoUML does not enforce any naming convention for actors

Namespace

Text box with navigation button. Records the namespace for the actor. This is the package hierarchy.

Modifiers

Check box, with entries Abstract, Leaf and Root.

  • Abstract is used to declare that this actor cannot be instantiated, but must always be specialized.

    [Achtung]Achtung

    While actors can be specialized and generalized, it is not clear that an abstract actor has any meaning. Perhaps it might be used to indicate an actor that does not itself interact with a use case, but whose children do.

  • leaf indicates that this actor can have no further children, while Root indicates it is a top level actor with no parent.

Generalizations

Text area. Lists any actor that generalizes this actor.

Button 1 double click navigates to the generalization and opens its property tab.

Specializations

Text box. Lists any specialized actor (i.e. for which this actor is a generalization. The specialized actors can communicate with the same use case instances as this actor.

Button 1 double click navigates to the generalization and opens its property tab.

Association Ends

Text area. Lists any association ends of associations connected to this actor.

Button 1 double click navigates to the selected entry.

17.3. Use Case

A use case represents a complete meaningful „chunk“ of activity by the system in relation to its external users (actors), human or machine. It represents the primary route through which requirements are captured for the system under construction

Within the UML metamodel, use case is a sub-class of classifier.

The use case icon is an oval (see Abbildung 17.1, „Typical model elements on a use case diagram.“). It may be split in two, with the lower compartment showing extension points

[Achtung]Achtung

By default ArgoUML does not show the extension point compartment. It may be revealed by the context sensitive Show menu (using button 2 click), or from the Presentation tab.

17.3.1. Use Case Details Tabs

The details tabs that are active for use cases are as follows.

ToDoItem

Standard tab.

Properties

See Abschnitt 17.3.2, „Use Case Property Toolbar“ and Abschnitt 17.3.3, „Property Fields For Use Case“ below.

Documentation

Standard tab. See Abschnitt 13.4, „Das Register Dokumentation“.

Presentation

Standard tab. The Fill color is used for the use case oval.

The Display: Extension Points check box is used to control whether an extension point compartment is displayed.

Source

Standard tab. It would not be usual to provide any code for a use case, since it is primarily a vehicle for capturing requirements about the system under construction, not creating the solution.

Stereotype

Standard tab.

Tagged Values

Standard tab. In the UML metamodel, UseCase has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.

    [Tipp]Tipp

    In general the instantiation of use cases is not a major aspect of any design method (they are mostly concerned with requirements capture. For most OOA&D methodologies, this tag can safely be ignored.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the use case.

  • derived (from the superclass, ModelElement). Values true, meaning the use case is redundant—it can be formally derived from other elements, or false meaning it cannot.

    [Anmerkung]Anmerkung

    Derived use cases still have their value in analysis to introduce useful names or concepts.

Checklist

Standard tab for a Classifier.

17.3.2. Use Case Property Toolbar

Go up

Navigate up through the package structure of the model.

New use case

This creates a new use case within the model, (but not within the diagram), and shows immediately the properties tab for that use case.

[Tipp]Tipp

This method of creating a new use case can be confusing. It is much better to create a new use case on the diagram of your choice.

New extension point

This creates a new use extension point within the namespace of the current use case, with the current use case as its associated use case, navigating immediately to the properties tab for that extension point.

New Attribute

This creates a new attribute within the current use case, navigating immediately to the properties tab for that attribute.

New Operation

This creates a new operation within the current use case, navigating immediately to the properties tab for that operation.

New Reception

This creates a new reception within the current use case, navigating immediately to the properties tab for that reception.

New Stereotype

This creates a new stereotype within the current use case, navigating immediately to the properties tab for that stereotype.

Delete

This deletes the selected use case from the model.

[Warnung]Warnung

This is a deletion from the model not just the diagram. To delete a use case from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.3.3. Property Fields For Use Case

Name

Text box. The name of the use case. Since a use case is a classifier, it would be conventional to Capitalize the first letter (and initial letters of any component words), e.g. RemoteSensor. The name is shown inside the oval representation of the use case on the diagram.

[Anmerkung]Anmerkung

ArgoUML does not enforce any naming convention for use cases

Namespace

Text box with navigation button. Records the namespace for the use case. This is the package hierarchy.

Modifiers

Check box, with entries Abstract Leaf and Root.

  • Abstract is used to declare that this actor cannot be instantiated, but must always be specialized. .

  • Leaf indicates that this use case can have no further children, while Root indicates it is a top level use case with no parent.

Client Dependencies

Text area. Lists the „depending“ ends of the relationship, i.e. the end that makes use of the other end.

Button 1 double click navigates to the dependency and opens its property tab.

Button 2 click shows a pop-up menu with one entry Add... that opens a dialog box where you can add and remove depending modelelements.

Supplier Dependencies

Text area. Lists the „supplying“ ends of the relationship, i.e. the end supplying what is needed by the other end.

Button 1 double click navigates to the dependency and opens its property tab.

Button 2 click shows a pop-up menu with one entry Add... that opens a dialog box where you can add and remove dependent modelelements.

Generalizations

Text area. Lists use cases which are generalizations of this one. Will be set whenever a generalization is created on the from this Use Case. Button 1 Double Click on a generalization will navigate to that generalization.

Specializations

Text box. Lists any specialized use case (i.e. for which this use case is a generalization.

Button 1 double click navigates to the generalization and opens its property tab.

Extends

Text box. Lists any class that is extended by this use case.

Where an extends relationship has been created, button 1 double click will navigate to that relationship.

Includes

Text box. Lists any use case that this use case includes.

Where an include relationship has been created, button 1 Double Click will navigate to that relationship.

Attributes

Text area. Lists all the attributes (see Abschnitt 18.7, „Attribute“) defined for this use case. Button 1 double click navigates to the selected attribute. Button 2 gives a pop up menu with two entries, which allow reordering the attributes.

  • Move Up. Only available where there are two or more attributes listed, and the attribute selected is not at the top. It moves the attribute up one position.

  • Move Down. Only available where there are two or more attributes listed, and the attribute selected is not at the bottom. It moves the attribute down one position.

Association Ends

Text box. Lists any association ends (see Abschnitt 18.12, „Association“) of associations connected to this use case.

Button 1 double click navigates to the selected entry.

Operations

Text area. Lists all the operations (see Abschnitt 18.8, „Operation“) defined on this use case. Button 1 click navigates to the selected operation. Button 2 gives a pop up menu with two entries, which allow reordering the operations.