Glossar

A

Aktivitätsdiagramm

Ein UML-Diagramm, welches das dynamische Verhalten eines Systems oder Subsystems beschreibt. Weitere Informationen, siehe Abschnitt 6.10, „ Aktivitätsdiagramme (Noch zu beschreiben).

Aktion

Verhalten, verknüpft mit Zuständen oder Transitionen in Zustandsdiagrammen . Diese Aktionen sind Aufrufe von Methoden und erscheinen in Sequenz- und Kollaborationsdiagrammen.

Akteur

Die Darstellung eines Agenten (animiert oder nicht animiert) in einem Anwendungsfalldiagramm, der ausserhalb des zu entwerfenden Systems steht.

Analyse

Analyse ist der Prozess die „Kunden“-Anforderungen aufzunehmen und diese aus der Perspektive der mutmaßlichen Lösung in die Sprache der mutmaßlichen Lösung umzuwandeln.

Anforderungserfassung

Die Anforderungserfassung ist der Prozess des Identifizierens was der „Kunde“ von dem gewünschten System wünscht. Eine ausführlichere Beschreibung, siehe Kapitel 4, Erfassen der Anforderungen .

Anwendungsfall

Eine UML-Notation, welche die Anforderungen an ein System oder Subsystem beinhaltet. Weitere Informationen, siehe Abschnitt 4.3, „ Ergebnis des Anforderungs-Erfassungs-Prozesses .

Anwendungsfalldiagramm

Ein UML-Diagramm, welches die Beziehungen zwischen Akteuren und Anwendungsfällen darstellt. Weitere Informationen, siehe Abschnitt 4.3, „ Ergebnis des Anforderungs-Erfassungs-Prozesses .

Anwendungsfallspezifikation

Das Dokument beinhaltet die detaillierten Anforderungen eines Anwendungsfalles.

Assoziationsklasse

Eine Klasse, die eine Assoziation zwischen zwei anderen Klassen charakterisiert.

Assoziation

Eine Beziehung zwischen zwei Klassen in einem Klassendiagramm oder zwischen Anwendungsfällen oder Anwendungsfällen und Akteuren in einem Anwendungsfalldiagramm.

Attribut (einer Klasse oder eines Objektes)

Ein Attribut einer Klasse oder eines Objektes ist eine Spezifikation eines Datenelementes, gekapselt durch dieses Objekt.

C

CASE

Computer Aided Software Engineering (Computergestützte Softwareentwicklung).

E

Ergänzende Anforderungsspezifikation

Das Dokument beinhaltet nicht-funktionale Anforderungen, die nicht mit einem Anwendungsfall verknüpft werden können.

Extend-Beziehung

Eine Beziehung zwischen zwei Anwendungsfällen, wo der erweiterte Anwendungsfall eine spezielle Variante des zu erweiternden Anwendungsfalles beschreibt.

F

Fenster

Ein Subfenster im Hauptfenster der ArgoUML-Anwenderschnittstelle.

G

Generalisierungs-Beziehung

Eine Beziehung zwischen einem generalisierenden Anwendungsfall und einem oder mehreren generalisierten Anwendungsfällen, bei dem der generalisierte Anwendungsfall besondere Beispiele des generalisierten Anwendungsfalles sind.

GUI

Graphical User Interface (Grafische Anwenderschnittstelle).

H

Hierarchisches Zustandsdiagramm

Ein Zustandsdiagramm, das untergeordnete Zustandsdiagramme mit individuellen Zuständen enthält.

I

Include-Beziehung

Eine Beziehung zwischen zwei Anwendungsfällen, wo der eingefügte Anwendungsfall Teile der Funktionalität des einfügenden Anwendungsfalles beschreibt.

Iterativer Designprozess

Ein Designprozess, in dem alle Phasen (Anforderungen, Analyse, Design, Build, Test) partiell in einer Abfolge von Iterationen durchlaufen werden. Mehr Informationen, siehe Abschnitt 3.2.1, „ Prozesstypen.

J

Java

Eine vollständig objektorientierte Programmiersprache, die von Sun Microsystems eingeführt wurde. Strenger typisiert wie C++, übersetzt sie in einen interpretierenden Code, der Java Virtual Machine (JVM). Die JVM bedeutet, dass Javacode auf jeder Maschine ablaufen kann, auf der eine JVM implementiert ist.

Die wichtigsten Komponente von Java war die Integration der JVM in Webbrowsern, die es erlaubt, Code (Applets) herunterzulasen und über das Web auszuführen.

ArgoUML ist in Java geschrieben.

K

Klasse

Die Kapselung von Daten verbunden mit einem Modellelement (seine Attribute) und die Aktionen, die mit dem Modellelement verbunden sind (seine Methoden).

Eine Klasse spezifiziert die Charakteristika eines Modellelementes. Ein Objekt repräsentiert eine Instanz eines Modellelementes.

Klassen und Objekte werden in UML in Aktivitätsdiagrammen, Klassendiagrammen, Kollaborationsdiagrammen und Sequenzdiagrammen dargestellt.

Klassendiagramm

Ein UML-Diagramm, das die strukturelle Beziehung zwischen Klassen darstellt. Weitere Informationen, siehe Abschnitt 5.2, „ Klassendiagramme (Noch zu beschreiben).

Kollaboration

Ein Prozess, indem mehrere Objekte kooperieren, um ein höherwertiges Verhalten anzubieten, das umfangreicher ist als die Summe der Verhaltensweisen von Objekten.

Kollaborationsdiagramm

Ein UML-Diagramm, welches das dynamische Verhalten darstellt, wie Botschaften die zwischen Objekten ausgetauscht werden. Ähnlich einem Sequenzdiagramm. Dessen Darstellung ist ähnlich, abhängig vom betrachteten Problem.

Kollaborator

Ein Objekt das an einer Kollaboration teilnimmt.

Konzept Klassendiagramm

Ein, während der Analysephase konstruiertes Klassendiagramm zeigt die strukturellen Hauptkomponenten des Problems, das in der Anforderungsphase identifiziert wurde. Weitere Informationen, siehe Kapitel 5, Analyse .

Kritik

Ein Prozess innerhalb von ArgoUML, der Hinweise anbietet, wie das Design verbessert werden kann. Die Hinweise basieren auf den Prinzipien der drei Theorien der kognitiven Psychologie Reflektion während der Aktion, Opportunistisches Design und Verstehen und Problemlösung.

M

Mealy Machine

Ein Zustandsdiagramm, in dem Aktionen mit Zuständen verküpft sind.

Methode (einer Klasse oder eines Objektes)

Eine Methode einer Klasse oder eines Objektes ist eine Spezifikation des Verhaltens, gekapselt durch das Objekt.

Moore Machine

Ein Zustandsdiagramm, in dem Aktionen mit Transitionen verknüpft sind.

O

Objekt

Eine Instanz einer Klasse.

Klassen und Objekte werden in der UML in Aktivitätsdiagrammen, Klassendiagrammen , Kollaborationsdiagrammen und Sequenzdiagrammen dargestellt.

OCL

Object Constraint Language. Eine Sprache zur Beschreibung von Bedingungen in der UML.

OMG

Die Object Management Group. Ein internationales Standardisierungsgremium der Industrie. Am Besten bekannt durch CORBA und UML.

OOA&D

Objektorientierte Analyse und Design. Ein Ansatz, um Softwareprobleme zu analysieren und basierend auf Objekten zu entwerfen, der sowohl die Daten als auch den Code kapselt. Siehe Abschnitt 1.1.1, „ Objektorientierte Analyse und Design oder jedes andere Buch über Software Engineering.

UML ist eine Notation, welche die OOA&D unterstützt.

Opportunistisches Design

Eine Theorie aus der kognitiven Psychologie, die aussagt, dass obwohl Designer ihre Arbeit auf eine geordnete, hierarchische Art planen und beschreiben, sie aufeinanderfolgende Tätigkeiten auf Basis der Kriterien der kognitiven Kosten auswählen. Einfach gesagt, Designer folgen nicht ihren eigenen Plänen und Reihenfolgen, sondern wählen ihre Schritte danach, welche davon mental weniger aufwändig sind im Gegensatz zu den Alternativen.

R

Realisation Anwendungsfall

Ein Anwendungsfall bei dem das Anwendungsfalldiagramm und die Anwendungsfallspezifikation in der Sprache des Lösungsbereiches und nicht in der Sprache des Problembereiches beschrieben wurde.

Reflektion-während-Aktion

Eine Theorie innerhalb der kognitiven Psychologie, die beobachtete, dass Designer komplexer Systeme ein Design in seiner Gesamtheit nicht vollständig begreifen. Stattdessen müssen sie Teilentwürfe konstruieren, evaluieren, reflektieren und überarbeiten, bis sie in der Lage sind ihn zu erweitern. Als Entwickler arbeiten sie spielerisch mit dem Entwurf, dadurch verbessert sich ihr mentales Modell der Problemsituation und ihr Design.

S

Szenario

Eine spezifische Abfolge von Aktionen, die das Verhalten illustriert.

Sequenzdiagramm

Ein UML-Diagramm, welches das dynamische Verhalten darstellt, wie Botschaften, die zwischen Objekten ausgetauscht werden. Ähnlich dem Kollaborationsdiagramm. Welche Darstellung angemessen ist, hängt von dem betrachteten Problem ab. Weitere Informationen, siehe Abschnitt 5.4, „ Sequenzdiagramme (Noch zu beschreiben).

SGML

Standard Graphical Markup Language. In ISO 8879:1986 definiert.

Simula 67

Eine prozedurale Programmiersprache für Simulationen. A procedural programming language intended for simulation. Aufgeführt wegen seiner Einführung in Objekte und Co-Routinen.

Stereotypen und Stereotypisieren

In UML kann jedem Modellelement ein Stereotyp gegeben werden, um seine Beziehung mit einer bestimmten Rolle im Design darzustellen. Ein Stereotyp spqr wird allgemein in der Notation <<spqr>> dargestellt.

Ein Stereotyp definiert einen Namensraum innerhalb des Entwurfes. Beispiele für Stereotypen sind <<business>> und <<realization>> für Anwendungsfälle, um zwischen Anwendungsfällen der Anforderungsphase, die in den Begrifflichkeiten des Problembereiches definiert sind und den Anwendungsfällen der Analysephase, die in den Begrifflichkeiten des Lösungsbereiches definiert wurden, zu unterscheiden.

SVG

Skalierbares Vektor-Grafik-Format. Eine Standarddarstellung von grafischen Diagrammen die Vektoren verwendet. ArgoUML kann Diagramme in SVG exportieren.

Systemsequenzdiagramm

Ein Sequenzdiagramm zeigt in der Analysephase das dynamische Verhalten des Systems als Ganzes. Weitere Informationen, siehe Kapitel 5, Analyse .

Systemzustandsdiagramm

Ein Zustandsdiagramm zeigt in der Analysephase das dynamische Verhalten eines aktiven Systemobjektes der obersten Ebene. Weitere Informationen, siehe Kapitel 5, Analyse .

T

To-Do Liste

Eine Eigenschaft von ArgoUML, die es dem Anwender erlaubt, Aktivitäten aufzunehmen, die noch vervollständigt werden müssen.

Transition

Die Änderung zwischen Zuständen in einem Zustandsdiagramm.

U

UML

Universal Modeling Language. Eine grafische Notation für OOA&D- Prozesse, standardisiert durch die OMG. ArgoUML unterstützt UML 1.4. UML 2.0 befindet sich in den abschliessenden Runden der Standardisierung und sollte im Verlauf des Jahres 2006 vollständig sein.

V

Verantwortlichkeit

Ein Verhalten, für das ein Objekt verantwortlich ist. Eine Verantwortlichkeit bezeichnet die Verpflichtung eines Objektes, ein bestimmtes Verhalten sicherzustellen.

Verstehen und Problemlösung

Eine Designvisualisierungstheorie innerhalb der kognitiven Psychologie. Die Theorie besagt, dass Designer den Schritt zwischen Ihrem mentalen Modell und dem Problem oder der Situation und dem formalen Modell der Lösung oder des Systems überbrücken müssen.

Diese Theorie besagt, dass Programmierer einen Vorteil haben von:

  1. Mehrere Darstellungen wie die syntaktische Zerlegung eines Programmes, Zustandstransitionen, Steuerflüsse und Datenflüsse. Diese erlauben es dem Programmierer die Elemente und Beziehungen des Problemes und der Lösung besser zu identifizieren und können somit die Zuordnung zwischen ihren Situationsmodellen und dem ausführenden Systemmodellen leichter herstellen.

  2. Vertraute Aspekte eines Situationsmodelles, verbessert die Fähigkeiten des Designers, die Lösung zu formulieren.

Visions-Dokument

Das Toplevel-Dokument, das beschreibt, was das zu entwickelnde System leisten können soll.

W

W3C

Das World Wide Web Konsortium, www.w3c.org. Ein internationales Standardisierungsgremium für alle Dinge, die mit dem Word Wide Web zu tun haben.

Wasserfall-Designprozess

Ein Designprozess, bei dem jede Phase (Anforderungen, Analyse, Design, Build, Test) vollständig bearbeitet wird, bevor die nächste beginnt. Weitere Informationen, siehe Abschnitt 3.2.1, „ Prozesstypen.

X

XMI

XML-Model Interchange format. Ein Format für die Speicherung von UML-Modellen in einer Datei. Aktuell unvollständig, weil sie nicht alle grafischen Layoutinformationen enthält, so dass sie durch Dateien ergänzt werden muss, die diese Informationen enthalten.

XML

eXtensible Markup Language. Eine, durch die W3C vereinfachte Ableitung von SGML.

Z

Zustand

Innerhalb eines Zustandsdiagrammes eine der möglichen Konfigurationen des Automaten.

Zustandsdiagramm

Ein UML-Diagramm, welches das dynamische Verhalten eines aktiven Objektes darstellt. Weitere Informationen, siehe Abschnitt 5.6, „ Zustandsdiagramme (Noch zu beschreiben).