- Project tools
-
-
- Nightly builds of docs
-
- The ArgoUML Project
-
-
- Using ArgoUML
-
- How do I...
-
Category |
Featured projects |
scm |
Subversion,
Subclipse,
TortoiseSVN,
RapidSVN
|
issuetrack |
Scarab |
requirements |
xmlbasedsrs |
design |
ArgoUML |
techcomm |
SubEtha,
eyebrowse,
midgard,
cowiki |
construction |
antelope,
scons,
frameworx,
build-interceptor,
propel,
phing
|
testing |
maxq,
aut
|
deployment |
current |
process |
ReadySET |
libraries |
GEF,
Axion,
Style,
SSTree
|
Over 500 more tools... |
|
Eine Lern- und ReferenzbeschreibungAlejandro RamirezPhilippe VanpeperstraeteAndreas RueckertKunle OdutolaJeremy BennettLinus TolkeMichiel van der Wulp??bersetzung: Harald BraunCopyright © 2004, 2005, 2006, 2007, 2008 Michiel van der Wulp Copyright © 2003 Linus Tolke Copyright © 2001, 2002 Jeremy Bennett Copyright © 2001 Kunle Odutola Copyright © 2000 Philippe Vanpeperstraete Copyright © 2000 Alejandro Ramirez Copyright © 2000 Andreas Rueckert
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
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:
Reflektion-w??hrend-Aktion; Opportunistisches Design; und 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“
.
1.1. Die Anf??nge und der ??berblick ??ber ArgoUML1.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.
Es ist frei.
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.
ArgoUML nutzt sehr stark offene Standards - UML, XMI,
SVG, OCL und andere.
ArgoUML ist eine 100%ige Java-Anwendung. Dadurch kann ArgoUML auf
allen Plattformen laufen, auf denen die Laufzeitumgebung der
Java2-Plattform verf??gbar ist.
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-Projekt1.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
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,
die das Design erlernen und mit einem OOA&D-Prozess
beginnen wollen, der die UML-Notation unterst??tzt und
Personen, die an einem modularisiertem Design mit Hilfe
einer GUI interessiert sind.
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 Anwenderhandbuch1.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.
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.
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.
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 UMLObjektorientierung 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.
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.
Die Entwicklung leistungsf??higer Workstations und das
Erscheinen von fensterbasierten Anwenderumgebungen.
Grafische Anwenderschnittstellen (GUI) haben eine
eingebaute Objektstruktur.
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.
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“.
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.
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.
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.
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-ProzessIn 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.
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.
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.
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]](images/note.png) | 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
Telefonleitungen zu belegen,
Anrufe zu verarbeiten,
Anrufe zu verarbeiten,
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.
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.
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.
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:
es macht Gebrauch von den Ideen der kognitiven Psychologie,
es basiert auf offenen Standards;
es ist 100% reines Java; und
es ist ein Open-Source-Projekt.
3.3.1. Kognitive Psychologie
ArgoUML ist teilweise durch die drei Theorien der kognitiven
Psychologie inspiriert:
Reflektion-w??hrend-Aktion, Opportunistisches Design und 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:
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.
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.
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.
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.
Die Nutzung von „zu bearbeiten“ Listen
, die dem Anwender Vorschl??ge aus den Designkritiken
unterbreiten und es ihm auch erlauben, k??nftige Aktionsbereiche
aufzuzeichnen.
Die Verwendung von Checklisten, um den Anwender durch einen
komplexen Prozess zu f??hren.
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.
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.
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.
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 bekommen3.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-OptionenEs gibt drei Optionen, wie Sie ArgoUML bekommen k??nnen.
Sie starten ArgoUML direkt von der Web Seite mit Hilfe von Java
Web Start. Dies ist die einfachste M??glichkeit.
Sie laden den bin??ren, ausf??hrbaren Code herunter. Dies ist die
richtige Option, wenn Sie beabsichtigen, ArgoUML regul??r zu
benutzen.
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 aufrufenHierf??r sind zwei Schritte auszuf??hren.
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.
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.
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.
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.
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.
Datei=>Projekt speichern r??ckg??ngig machen.
Dies hat den gleichen Effekt wie Datei=>Projekt ??ffnen...
und dann das aktuelle Projekt ausw??hlen.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Bearbeiten=>Einstellungen...=>Benutzer
. Geben Sie Ihren Namen und Ihre E-Mailadresse ein.
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.
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.
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.
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.
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.
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.
Ansicht=>Raster einstellen.
Ansicht=>Einrasten einstellen.
Ansicht=>Seitenumbr??che.
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.
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]](images/note.png) | 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.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 arbeiten3.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
“.
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“.
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.1. Laden und Speichern3.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]](images/warning.png) | 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 Drucken3.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.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
W??hlen Sie .svg als Dateityp aus.
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]](images/note.png) | 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!
|
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-Generierung3.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.
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.
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.
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
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]](images/note.png) | 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.
Bargeld lagern, Bargeld abheben und Kontoabfragen durch Kunden.
Warten des Equipments durch Bank-Ingenieure und leeren der
Kassen und Bargeld nachf??llen durch die lokale Bankfiliale.
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.
Die Schritte im Anforderungs-Erfassungs-Prozess k??nnen wie folgt
zusammengefasst werden.
Das Visions-Dokument beinhaltet eine
Gesamtsicht auf das Problem und die gew??nschten Charakteristika
seiner L??sung.
Identifizieren Sie die Anwendungsf??lle und
Akteure aus dem Visions-Dokument und
stellen deren Beziehungen zueinander in einem oder mehreren
Anwendungsfalldiagrammen dar.
Erstellen Sie f??r jeden Anwendungsfall eine detaillierte
Anwendungsfall-Spezifikation, die das
normale und alternative Verhalten, die Vor- und Nachbedingungen
beinhaltet.
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.
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]](images/note.png) | Anmerkung |
---|
Nicht alle Analytiker m??chten einen Rahmen um die
Anwendungsf??lle verwenden. Dies ist ein Fall pers??nlicher
Vorlieben.
|
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.
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.
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.
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.
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]](images/note.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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:
Der Kunde gibt an, dass eine Quittung erforderlich ist.
Der Kunde gibt die gew??nschte Bargeldmenge ein. Der Geldautomat ??berpr??ft mit dem Zentralcomputer, dass
der Kunde diese Auszahlung durchf??hren kann. Der Geldautomat gibt das Bargeld an den Kunden. 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]](images/note.png) | 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.
Der Kunde ben??tigt keine Quittung. Das Kundenkonto unterst??tzt keine Auszahlung. Die Kommunikation mit dem Zentralcomputer ist
unterbrochen. Der Kunde unterbricht die Transaktion.
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:
Der Kunde ben??tigt keine Quittung.
In Schritt 1 des Standardablaufes sagen die Kunden,
dass Sie keine Quittung ben??tigen.
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]](images/note.png) | 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.
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.
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.
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 .
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.
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]](images/note.png) | Anmerkung |
---|
Das Symbol Erweiterungspunkt hinzuf??gen
ist inaktiv, bis ein Anwendungsfall markiert ist.
|
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.
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.
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.
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.
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.
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]](images/note.png) | 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.
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..* .
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.
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.
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]](images/note.png) | 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 Bedingung s-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.
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.
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]](images/warning.png) | 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.
|
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]](images/warning.png) | 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.
|
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]](images/note.png) | 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).
|
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.
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.
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.
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.
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.
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.
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". 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)
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.
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)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.2.2.1. Assoziationsklassen (Noch zu beschreiben)5.3. Klassendiagramme in ArgoUML erzeugen5.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]](images/warning.png) | Warnung |
---|
Beachten Sie, dass Ihr Kommentar nicht im Sourcecoderegister
erscheint.
|
5.3.2. Assoziationen (Noch zu beschreiben)5.3.2.1. Aggregation (Noch zu beschreiben)5.3.3. Klassenattribute und Operationen (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)5.3.3.3. Klassenoperationen (Noch zu beschreiben)5.3.4. Erweiterte Klasseneigenschaften (Noch zu beschreiben)5.3.4.1. Assoziationsklassen (Noch zu beschreiben)5.3.4.2. Stereotypen (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 erzeugen5.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)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.6.2.1. Hierarchische Zustandsdiagramme (Noch zu beschreiben
)5.7. Zustandsdiagramme in ArgoUML5.7.1. Zustandsdiagramme (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)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)5.7.4. Aktionen (Noch zu beschreiben)5.7.5. Erweiterte Zustandsdiagramme (Noch zu beschreiben)5.7.5.1. Hierarchische 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)
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
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.
...
5.10.2. Klassendiagramme konzipieren (Noch zu beschreiben)5.10.2.1. Klassen identifizieren (Noch zu beschreiben)5.10.2.2. Assoziationen identifizieren (Noch zu beschreiben)5.10.3. System-Sequenzdiagramme (Noch zu beschreiben)5.10.3.1. Aktionen identifizieren (Noch zu beschreiben)5.10.4. System-Zustandsdiagramme (Noch zu beschreiben)5.10.5. Realisierungs-Anwendungsf??lle (Noch zu beschreiben)
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)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.2.2.1. Subpakete (Noch zu beschreiben)6.2.2.2. Datentypen hinzuf??gen (Noch zu beschreiben)6.2.2.3. Stereotypen hinzuf??gen (Noch zu beschreiben)6.3. Paketdiagramme in ArgoUML erstellen6.3.1.1. Subpakete (Noch zu beschreiben)6.3.2. Beziehungen zwischen Paketen (Noch zu beschreiben)6.3.2.1. Abh??ngigkeit (Noch zu beschreiben)6.3.2.2. Generalisierung (Noch zu beschreiben)6.3.2.3. Realisierung und Abstraktion (Noch zu beschreiben)6.3.3. Erweiterte Paketeigenschaften (Noch zu beschreiben)6.3.3.1. Neue Datentypen erstellen (Noch zu beschreiben)6.3.3.2. Neue Stereotypen erstellen (Noch zu beschreiben)6.4. Mehr ??ber Klassendiagramme (Noch zu beschreiben)6.4.1. Das Klassendiagramm (Noch zu beschreiben)6.4.1.1. Klassenattribute (Noch zu beschreiben)6.4.1.2. Klassenoperationen (Noch zu beschreiben)6.4.2. Erweiterte Klassendiagramme (Noch zu beschreiben)6.4.2.1. Realisierung und Abstraktion (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.2.1. Klassenattribute (Noch zu beschreiben)6.5.2.2. Klassenoperationen (Noch zu beschreiben)6.5.3. Erweiterte Klasseneigenschaften6.5.3.1. Operationen bei Schnittstellen6.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“).
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.
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.
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.
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)6.6. Sequenz- und Kollaborationsdiagramme (
Noch zu beschreiben)![[Anmerkung]](images/note.png) | Anmerkung |
---|
Sequenzdiagramme funktionieren in der ArgoUML-Version
0.14 nicht. |
6.6.1. Mehr ??ber das Sequenzdiagramm (Noch zu beschreiben)6.6.2. Das Kollaborationsdiagramm (Noch zu beschreiben)6.6.2.1. Nachrichten (Noch zu beschreiben)6.6.2.2. Aktionen (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.2.1. Aktionen (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.8.2.1. Aktionen (Noch zu beschreiben)6.8.2.2. Transitionen (Noch zu beschreiben)6.8.2.2.1. Trigger (Noch zu beschreiben)6.8.2.2.2. W??chter (Noch zu beschreiben)6.8.2.2.3. Effekte (Noch zu beschreiben)6.8.2.3. Pseudo-Zust??nde (Noch zu beschreiben)6.8.2.3.1. Junction and Choice (Noch zu beschreiben)6.8.2.3.2. Verzweigen und Verkn??pfen (Noch zu beschreiben)6.8.2.4. Hierarchische Zustandsautomaten (Noch zu beschreiben)6.8.2.5. Modelle f??r die Zustandshistorie (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.9.5.1. Transitionen (Noch zu beschreiben)6.9.5.1.1. Trigger (Noch zu beschreiben)6.9.5.1.2. W??chter (Noch zu beschreiben)6.9.5.1.3. Effekte (Noch zu beschreiben)6.9.5.2. Pseudozust??nde (Noch zu beschreiben)6.9.5.2.1. Junction and Choice (Noch zu beschreiben)6.9.5.2.2. Verzweigen und Verkn??pfen (Noch zu beschreiben)6.9.5.3. Hierarchische Zustandsautomaten (Noch zu beschreiben)6.9.5.4. Historie (Noch zu beschreiben)6.10. Aktivit??tsdiagramme (Noch zu beschreiben)6.10.1. Das Aktivit??tsdiagramm (Noch zu beschreiben)6.10.1.1. Aktionszust??nde (Noch zu beschreiben)6.11. Aktivit??tsdiagramme in ArgoUML erstellen (
Noch zu beschreiben)6.11.1. Aktivit??tsdiagramme (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)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.1.1. Knoten-Instanzen (Noch zu beschreiben)6.13.2. Komponenten (Noch zu beschreiben)6.13.2.1. Komponenten-Instanzen (Noch zu beschreiben)6.13.3. Beziehungen zwischen Knoten und Komponenten (
Noch zu beschreiben)6.13.3.1. Abh??ngigkeit (Noch zu beschreiben)6.13.3.2. Assoziationen (Noch zu beschreiben)6.13.3.3. Verkn??pfungen (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.2.1. Pakete identifzieren (Noch zu beschreiben)6.15.2.2. Datentypen und Stereotypen (Noch zu beschreiben)6.15.3. Klassendiagramme (Noch zu beschreiben)6.15.3.1. Klassen identifizieren (Noch zu beschreiben)6.15.3.2. Assoziationen identifizieren (Noch zu beschreiben)6.15.3.3. Attribute und Operationen spezifizieren (
Noch zu beschreiben)6.15.4. Sequenzdiagramme (Noch zu beschreiben)6.15.4.1. Aktionen identifzieren (Noch zu beschreiben)6.15.5. Kollaborationsdiagramme (Noch zu beschreiben)6.15.5.1. Nachrichten identifizieren (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)Kapitel 7.
Codegenerierung, Reverse Engineering und Round Trip Engineering
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.
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 generieren7.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.
Reverse Engineering wird in zwei F??llen verwendet:
Um die vorher entwickelte Klasse in das aufzubauende Modell zu
bekommen.
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
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.
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.
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:
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.
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.
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.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 18.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]](images/caution.png) | 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.
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.
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.
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
Diese Schaltfl??chen haben wie ihre Gegenst??cke im Men??
Datei identische Funktionen.
Diese Schaltfl??chen haben mit Ihren Gegenst??cken im Men??
Bearbeiten identische Funktionen.
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.
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%.
Diese Schaltfl??chen haben wie Ihre Gegenst??cke im Men??
Neues Diagramm identische Funktionen.
Kapitel 10. Die Men??zeile
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.
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]](images/caution.png) | 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.
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... .
“).
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]](images/note.png) | 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.
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.
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.
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... .“.
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).
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.
![[Warnung]](images/warning.png) | 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:
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.
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:
Die folgenden Optionen sind nur verf??gbar, wenn das entsprechende
Plugin installiert wurde.
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.
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.
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.
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.
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.
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".
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.
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.
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]](images/tip.png) | Tipp |
---|
Dies ist eine Textdatei, die Sie zum Konfigurieren von ArgoUML
bearbeiten k??nnen.
|
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.
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.
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.
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.
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.
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) 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.
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) 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.
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.
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]](images/warning.png) | 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.
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
im Diagramm 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]](images/tip.png) | 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]](images/warning.png) | 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.
|
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]](images/note.png) | Anmerkung |
---|
Es gibt keine Option das Einrasten auf das Gitter abzustellen.
|
![[Anmerkung]](images/note.png) | 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“).
|
Mit dieser Men??option werden die Seitenumbr??che im Diagramm
dargestellt oder nicht (durch weiss gepunktete Linien).
![[Warnung]](images/warning.png) | Warnung |
---|
Diese Men??option funktioniert in ArgoUML V0.24 nicht. |
Dieses Men?? erlaubt es dem Anwender beliebige Symbolleisten zu
verbergen oder anzuzeigen. Standardm????ig werden alle angezeigt.
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]](images/tip.png) | 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]](images/tip.png) | 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]](images/tip.png) | 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]](images/tip.png) | 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.
|
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.
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]](images/tip.png) | 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.
|
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.
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.
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]](images/note.png) | 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]](images/warning.png) | 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 ... .
“
).
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.3. Gesamtes Projekt generieren... (Noch zu beschreiben)10.8.4.
Einstellungen zur Codegenerierung im Projekt... (Noch zu
beschreiben)
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]](images/note.png) | 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]](images/note.png) | 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... .
“).
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]](images/note.png) | Anmerkung |
---|
Die Regler sind f??r alle Designkategorien standardm????ig auf
Hoch eingestellt.
|
Dieser Men??eintrag ??ffnet einen Dialog, der steuert, wie Designziele
behandelt werden (siehe Abbildung 10.28, „
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]](images/tip.png) | 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]](images/warning.png) | 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... .
“).
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]](images/note.png) | 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]](images/warning.png) | 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]](images/note.png) | 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]](images/caution.png) | 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]](images/tip.png) | 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.
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 .“
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.
Dieser Men??eintrag ??ffnet das Hilfefenster von ArgoUML (siehe
Abbildung 10.31, „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]](images/caution.png) | 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).
|
Der Explorer wurde vorher Navigationsfenster/-baum genannt oder machmal
Navigatorfester/-baum.
Abbildung 11.1, „??berblick ??ber den Explorer“
zeigt das ArgoUML-Fenster mit dem hervorgehobenen 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).
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]](images/note.png) | 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.
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.
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“).
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.
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]](images/tip.png) | 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]](images/caution.png) | 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]](images/warning.png) | 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]](images/caution.png) | 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.
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
Abbildung 12.1, „??berblick ??ber das Editierfenster“
zeigt das ArgoUML-Fenster mit dem hervorgehobenen 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).
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
“
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.
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.
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.
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“
12.4.2. Kommentierungs-Werkzeug
Das Kommentierungs-Werkzeug Kommentar (
)
wird dazu verwendt, einen Kommentar zu einem markierten UML-
Modellelement hinzuzuf??gen.
![[Achtung]](images/caution.png) | 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]](images/tip.png) | 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.
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.
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]](images/note.png) | 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]](images/note.png) | 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]](images/note.png) | 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]](images/note.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/note.png) | 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]](images/caution.png) | 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.
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.
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.
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.
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.
Ein Taste 2-Klick ??ber einem Modellelement im Editierfenster
??ffnet ein Pop-up-Men?? mit Men??elementen, viele davon mit einem
Untermen??.
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.
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.
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).
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.
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]](images/note.png) | Anmerkung |
---|
Dies sollte nat??rlich automatisch bei Modellelementen
mit Zustandsautomaten oder Aktivit??tsdiagrammen gesetzt
werden.
|
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“).
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]](images/caution.png) | Achtung |
---|
UML fordert, dass ein Ende einer Komposition die Kardinalit??t 1
aufweisen muss (der Standard).
|
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]](images/note.png) | 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]](images/note.png) | Anmerkung |
---|
UML erlaubt keine Navigierbarkeit von einer Schnittstelle zu
einer Klasse. ArgoUML verhindert dies nicht.
|
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.
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:
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.
Kapitel 13. Der Bereich Details
Abbildung 13.1, „??berblick ??ber den Bereich Details“ zeigt das ArgoUML-Fenster mit
dem hervorgehobenen 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.
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.
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.
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]](images/tip.png) | 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]](images/warning.png) | 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]](images/tip.png) | 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.
|
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 >> .
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]](images/note.png) | 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:
Markieren des Modellelementes im Explorer oder im Editierbereich,
gefolgt von der Auswahl des Registers Eigenschaften im Bereich
Details; oder
??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).
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]](images/caution.png) | 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.
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]](images/tip.png) | 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).
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
“.
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.
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.
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]](images/caution.png) | 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).
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]](images/warning.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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“).
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“).
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]](images/warning.png) | 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.
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]](images/note.png) | 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.
![[Achtung]](images/caution.png) | 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
Abbildung 14.1, „??berblick ??ber den Bereich Zu-Bearbeiten“ zeigt das ArgoUML-Fenster mit dem
hervorgehobenen 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).
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).
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]](images/caution.png) | 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.
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.
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]](images/note.png) | Anmerkung |
---|
Die Kritiken sind asynchrone Prozesse, die parallel zu ArgoUML
ablaufen. ??nderungen ben??tigen eine oder zwei Sekunden, bis die
Kritiken erneut erzeugt wurden.
|
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.
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.
Diese Kritiken passen zu keiner der anderen Kategorien.
ArgoUML hat keine Kritik mit dieser Kategorie. Vielleicht werden
einige in sp??teren Versionen hinzugef??gt.
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. 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]](images/caution.png) | 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.
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]](images/note.png) | 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: den Namen;
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]](images/note.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/note.png) | 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.
Kritiken, die sich auf die Attribute von Klassen beziehen.
Die aktuelle Version von ArgoUML hat in dieser Kategorie die
folgenden Kritiken.
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]](images/caution.png) | 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]](images/caution.png) | 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 ErweiterungenKritiken, die sich auf Schnittstellen und Subklassen beziehen. ![[Anmerkung]](images/note.png) | 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]](images/caution.png) | 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.
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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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.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.
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.
Sie m??ssen ein statisches Attribut definieren (eine
Klassenvariable), welche die Instanz aufnimmt. Diese muss aus
diesem Grund den Typ Klasse aufweisen.
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.
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]](images/warning.png) | 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.
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]](images/warning.png) | 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.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]](images/caution.png) | 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.
|
Kritiken, die sich auf das Bilden von Instanzen bei Klassifizierern
in ArgoUML beziehen.
Die aktuelle Version von ArgoUML hat keine Kritiken in dieser
Kategorie.
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]](images/caution.png) | 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]](images/note.png) | 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.
Kritiken, die sich auf Operationen in ArgoUML beziehen.
Die aktuelle Version von ArgoUML hat die folgenden Kritiken in
dieser Kategorie.
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]](images/caution.png) | 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.
|
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.
Kritiken, die sich auf Stereotypen in ArgoUML beziehen.
Die aktuelle Version von ArgoUML hat keine Kritiken in dieser
Kategorie.
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.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]](images/caution.png) | 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.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]](images/caution.png) | 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.
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 .
Kapitel 16. Modellreferenz auf h??chster Ebene
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]](images/note.png) | 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 ModelldetailsDie 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]](images/tip.png) | 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 ModellesName
Textfeld. Name des Modelles. Der Name des Modelles, wie
alle anderen Pakete, wird per Konvention in Kleinbuchstaben
geschrieben.
![[Anmerkung]](images/note.png) | 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]](images/note.png) | 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]](images/note.png) | 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.
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]](images/note.png) | 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]](images/tip.png) | 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]](images/tip.png) | 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]](images/tip.png) | 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 DatatypeName Text box. The name of the datatype. The primitive
datatypes all have lower case names, but there is no
formal convention. ![[Anmerkung]](images/note.png) | 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]](images/note.png) | 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]](images/tip.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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]](images/caution.png) | 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. |
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 EnumerationLiteral s.
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 TabsThe 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 EnumerationName Text box. The name of the enumeration. The primitive
enumerations all have lower case names, but there is no
formal convention. ![[Anmerkung]](images/note.png) | 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. 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. 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]](images/caution.png) | 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 LiteralAn enumeration literal is one of the predefined values
of an Enumeration. 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 TabsThe 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]](images/warning.png) | 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]](images/note.png) | Anmerkung |
---|
This indicates any element with this
stereotype has the derived tag
set accordingly. |
![[Achtung]](images/caution.png) | 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 StereotypeName 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]](images/note.png) | 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]](images/caution.png) | Achtung |
---|
Remember that these modifiers apply to the
model elements using the stereotype, not just the
stereotype.
|
![[Warnung]](images/warning.png) | 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.
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]](images/note.png) | Anmerkung |
---|
ArgoUML uses its deployment diagram to create the UML
1.4 component, deployment and object diagrams. |
![[Achtung]](images/caution.png) | 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]](images/warning.png) | 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 TabsThe details tabs that are active for diagrams are as
follows. 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 DiagramName 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]](images/tip.png) | 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 ReferenceThis 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. 17.1.1. ArgoUML Limitations Concerning Use Case
DiagramsUse case diagrams are now well supported within
ArgoUML. There still are some minor limitations though,
especially with extension points. ![[Anmerkung]](images/note.png) | 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. |
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 TabsThe 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]](images/tip.png) | 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]](images/note.png) | 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]](images/tip.png) | 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]](images/tip.png) | 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]](images/warning.png) | 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 ActorName 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]](images/note.png) | 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]](images/caution.png) | 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.
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]](images/caution.png) | 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 TabsThe 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]](images/tip.png) | 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]](images/note.png) | 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]](images/tip.png) | 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]](images/warning.png) | 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 CaseName 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]](images/note.png) | 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.
|