Glossar
über alle Themengebiete
Das Gesamtglossar enthält Einträge folgender Einzelglossare:
| Glossar | Beschreibung |
| UML 1.4 |
Glossar der oose.de GmbH für UML (Unified Modeling Language) Version 1.4
|
| OEP |
Spezifische Begriffe des Object Engineering Process (OEP) sowie allgemeine Begriffe zu Vorgehensmodellen, siehe http://www.oose.de/oep. |
| EmOO |
Glossareinträge aus dem Buch Erfolgreich mit Objektorientierung, Vorgehensmodelle und Managementpraktiken für objektorientierte Softwareentwicklung, B. Oestereich et. al., Oldenbourg Wissenschaftsverlag, 1999. |
| engl. |
Englischsprachige OO- und UML-Begriffe.
Entnommen aus Objektorientierte Softwareentwicklung, B. Oestereich, Oldenbourg Wissenschaftsverlag, 1999 und Developing Software with UML, B. Oestereich, Addison Wesley, 1999. |
| OO allg. |
Allgemeines OO-Glossar der oose.de GmbH
|
| Komponenten |
Spezifische Begriffe zum Thema Komponenten
|
| Qualitätssicherung |
Spezifische Begriffe zu den Themen Softwaretest, Qualitätssicherung und Qualitätsmanagement |
| Extreme Programming |
Spezifische Begriffe zum Thema XP: Extreme Programming |
| Modewörterbuch |
Aktuelle Abkürzungen und modische Begriffe aus dem Umfeld der Objektorientierung, insbesondere Java. Ohne Anspruch auf Vollständigkeit oder formal korrekte Definition. |
| GPM |
Glossareinträge zum Thema Objektorientierte Geschäftsprozessmodellierung mit der UML |
| UML 2.0 |
Glossar der oose.de GmbH für UML (Unified Modeling Language) Version 2.0
|
Copyright © 1999 - 2003 by oose.de GmbH.
Dieses Glossar darf in vollständiger Form und unverändert jederzeit kopiert und kostenlos weitergegeben werden. Der Hinweis auf die Originalquelle http://www.oose.de/glossar muß ebenso wie dieser Copyright-Hinweis stets angegeben werden.
Es ist nicht zulässig das Glossar kommerziell zu vertreiben, gegen Entgeld weiterzugeben oder Inhalte zu verändern.
Im Rahmen nicht-kommerzieller Verwendungen, beispielsweise Diplomarbeiten, darf das Glossar gerne übernommen werden. Die Verwendung in kommerziellen Zusammenhängen, beispielsweise in öffentlichen oder internen Schulungen, firmen-internen Netzwerken, Publikationen, Produkten etc. ist prinzipiell gestattet, wenn eine entsprechende Meldung an boe@oose.de gesendet wird.
Die Weitergabe ist sowohl in elektronischer als auch gedruckter Form zulässig. Im Internet zugängliche Kopien sind ebenfalls zu melden.
Fehlerhinweise, Verbesserungs- und Ergänzungsvorschläge sind willkommen und zu senden an boe@oose.de
(Ergänzungsvorschläge werden jedoch kritisch geprüft).
Jeder Glossareintrag ist wie folgt aufgebaut:
| Begriff [Glossar] (ID)
|
| Beschreibung |
| Siehe auch
|
| Letzte Änderung von .. am .. ,
[Anmerkungen/Kommentare]
|
[Glossar] beschreibt aus welchem Einzelglossar der Begriff stammt, dies ist
relevant, weil einige Begriffe in verschiedenen Kontexten unterschiedlich
definiert sind.
(ID) ist eine eindeutige Bezeichnung des Begriffes.
Siehe auch listet ähnliche, verwandte oder aber auch zu beachtende konträre
begriffe auf.
Unter Anmerkungen/Kommentare gelangen Sie auf das OEP-Wiki, hier können Sie Ihre Anmerkungen
hinterlassen bzw. die von anderen lesen.
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Ä
Ö
Ü
| Abgeleitetes Attribut [UML 2.0] (G-816)
|
| Ein abgeleitetes Attribut wird aus den Werten anderer Attribute berechnet. Abgeleitete Attribute können nicht direkt geändert werden und werden durch eine Berechnungsoperation implementiert oder gesetzt. |
| Siehe auch
Attribut [UML 2.0]
Abgeleitetes Element [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 11:56:16 GMT+1,
[Anmerkungen/Kommentare]
|
| Abgeleitetes Attribut [UML 1.4] (G-408)
|
| Ein abgeleitetes Attribut wird aus den Werten anderer Attribute berechnet. Abgeleitete Attribute können nicht direkt geändert werden und werden durch eine Berechnungsoperation implementiert oder gesetzt. |
| Siehe auch
Attribut [OO allg.]
Abgeleitetes Element [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Abgeleitetes Element [UML 2.0] (G-817)
|
| Ein Modellelement, das jederzeit durch ein anderes Element berechnet werden kann und nur der Klarheit wegen gezeigt wird oder für Designzwecke zugefügt wird, ohne daß es jedoch weitere semantische Information zufügt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 11:57:58 GMT+1,
[Anmerkungen/Kommentare]
|
| Abgeleitetes Element [UML 1.4] (G-409)
Alias für
derived element [UML 1.4]
|
| Ein Modellelement, das jederzeit durch ein anderes Element berechnet werden kann und nur der Klarheit wegen gezeigt wird oder für Designzwecke zugefügt wird, ohne daß es jedoch weitere semantische Information zufügt. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Abhängigkeit [UML 2.0] (G-818)
|
| Eine Abhängigkeit ist eine Beziehung zwischen zwei Modellelemen-ten, die zeigt, daß eine Änderung in dem einen (unabhängigen) Element eine Änderung in dem anderen (abhängigen) Element notwendig macht. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 11:59:06 GMT+1,
[Anmerkungen/Kommentare]
|
| Abhängigkeitsbeziehung [UML 1.4] (G-412)
|
| Eine Abhängigkeitsbeziehung ist eine Beziehung zwischen zwei Modellelementen, die zeigt, daß eine Änderung in dem einen (unabhängigen) Element eine Änderung in dem anderen (abhängigen) Element notwendig macht. |
| Siehe auch
Beziehung [UML 1.4]
Depends on-Beziehung [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Ablaufmodell [GPM] (G-743)
Alias für
Aktivitätsmodell [GPM]
|
| Ein Modell oder Diagramm, das einen Ablauf beschreibt, beispielsweise ein UML-Aktivitätsdiagramm. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 14:55:01 GMT+2,
[Anmerkungen/Kommentare]
|
| Ablauforganisation [OEP] (G-209)
|
| Ablauforganisation ist die zeitliche und räumliche Ordnung betrieblicher Prozesse innerhalb des durch die Aufbauorganisation geschaffenen Rahmens. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Abnahmetest [Qualitätssicherung] (G-636)
|
| Systemtest durch den Kunden zur Übergabe eines neuen oder modifizierten System s in die Produktionsumgebung des Kunden mit dem Ziel der Abnahme der Version durch den Kunden nach den allgemeinen Test - Kriterien. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/07 13:01:11 GMT+2,
[Anmerkungen/Kommentare]
|
| Abstrakte Klasse [UML 2.0] (G-819)
|
| Von einer abstrakten Klasse werden niemals Exemplare erzeugt; sie ist bewußt unvollständig und bildet somit die Basis für weitere Unterklassen, die Exemplare haben können. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:01:09 GMT+1,
[Anmerkungen/Kommentare]
|
| Abstrakte Operation [OO allg.] (G-402)
|
| Eine Operation, für die nur eine Signatur, jedoch keine Anweisungsfolge definiert ist, d.h. Die Operation ist definiert, aber noch nicht implementiert. Sie wird in einer abgeleiteten Klassen implementiert. |
| Siehe auch
Operation [UML 1.4]
Virtuelle Operation [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Abstrakte Operation [UML 2.0] (G-820)
|
| Eine Operation, für die nur eine Signatur, jedoch keine Anweisungsfolge definiert ist, d.h. die Operation ist definiert, aber noch nicht implementiert. Sie wird in einer abgeleiteten Klasse implementiert. C++: virtuelle Operation. |
| Siehe auch
Operation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 12:02:18 GMT+1,
[Anmerkungen/Kommentare]
|
| Abstrakter Datentyp [OO allg.] (G-415)
|
| Das Konzept des abstrakten Datentyps ähnelt dem der Klasse. Unter einem abstrakten Datentyp versteht man die Zusammenfassung von Daten und der mit ihnen ausführbaren Operationen. |
| Siehe auch
Klasse [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Abstrakter Datentyp [UML 2.0] (G-821)
|
| Das Konzept des abstrakten Datentyps ähnelt dem der Klasse. Unter einem abstrakten Datentyp versteht man die Zusammenfassung von Daten und der mit ihnen ausführbaren Operationen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:03:53 GMT+1,
[Anmerkungen/Kommentare]
|
| Abstraktion [OO allg.] (G-5)
|
| Abstraktion ist eine Methode, bei der unter einem bestimmten Gesichtspunkt die wesentlichen Merkmale eines Gegenstandes oder Begriffes herausgesondert werden. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Abstraktion [UML 2.0] (G-822)
|
| Abstraktion ist eine Methode, bei der unter einem bestimmten Gesichtspunkt die wesentlichen Merkmale eines Gegenstandes oder Begriffes herausgesondert werden. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:04:55 GMT+1,
[Anmerkungen/Kommentare]
|
| Aggregation [UML 2.0] (G-823)
|
| Eine Aggregation ist eine Assoziation, bei der die beteiligten Klassen keine gleichwertige Bezihung führen, sondern eine Ganze-Teile-Hierarchie darstellen. Eine Aggregation bechreibt, wie sich etwas Ganzes aus seinen Teilen zusammensetzt. Formal ist eine Assoziation der Aggregation gleichwertig, die Besonderheit der Ganze-Teile-Beziehung hat keine formale Semantik, sondern lediglich hilfreichen Kommentarcharakter. |
| Siehe auch
Assoziation [UML 2.0]
Komposition [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 12:05:46 GMT+1,
[Anmerkungen/Kommentare]
|
| Aggregation [UML 1.4] (G-6)
|
| Eine Aggregation ist eine Assoziation, bei der die beteiligten Klassen keine gleichwertige Beziehung führen, sondern eine Ganze-Teile-Hierarchie darstellen. Eine Aggregation beschreibt, wie sich etwas Ganzes aus seinen Teilen zusammensetzt. Formal ist eine Assoziation der Aggregation gleichwertig, die Besonderheit der Ganze-Teile-Beziehung hat keine formale Semantik, sondern lediglich hilfreichen Kommentarcharakter. |
| Siehe auch
Assoziation [UML 1.4]
Komposition [UML 1.4]
|
| Letzte Änderung von cj am 2003/04/07,
[Anmerkungen/Kommentare]
|
| Akteur [UML 1.4] (G-7)
Alias für
actor [UML 1.4]
|
| Englisch Actor. Ein Akteur ist ein außerhalb des Systems agierender Beteiligter, der an der in einem Anwendungsfall beschriebenen Interaktion beteiligt ist. Akteure nehmen in der Interaktion gewöhnlich eine definierte Rolle ein. Es sind Benutzer des Systems oder andere Systeme. Ein Akteur ist eine stereotypisierte Klasse. |
| Siehe auch
Anwendungsfall [UML 1.4]
Klasse [OO allg.]
Stereotyp [UML 1.4]
|
| Letzte Änderung von cj am 2003/04/07,
[Anmerkungen/Kommentare]
|
| Akteur [UML 2.0] (G-824)
|
| Ein Akteur ist eine gewöhnlich außerhalb des betrachteten bzw. zu realisierenden Systems liegende Einheit, die an der in einem Anwendungsfall beschriebenen Interaktion mit einem System beteiligt ist. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:07:07 GMT+1,
[Anmerkungen/Kommentare]
|
| Aktive Klasse [UML 1.4] (G-420)
|
| Eine Klasse, deren Instanzen nebenläufig ausgeführt werden und ihren eigenen Kontrollfokus (Thread) besitzen. |
| Siehe auch
Aktives Objekt [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Aktiver Geschäftspartner [GPM] (G-744)
|
| Ein Akteur, der außerhalb des Modellierungsbereiches der Geschäftsprozessmodellierung steht und aktiv Geschäftsprozesse initiiert. |
| Siehe auch
Geschäftspartner [GPM]
Akteur [OEP]
|
| Letzte Änderung von cj am 2003/04/08 14:57:28 GMT+2,
[Anmerkungen/Kommentare]
|
| Aktivitästübergang [UML 1.4] (G-745)
|
| Ein Wechsel von einer Aktivität zur nächsten innerhalb eines Ablaufmodells. |
| Siehe auch
Transition [UML 1.4]
|
| Letzte Änderung von cj am 2003/04/08 15:00:19 GMT+2,
[Anmerkungen/Kommentare]
|
| Aktivität [UML 1.4] (G-9)
|
| Ein Zustand mit einer internen Aktion und einer oder mehreren ausgehenden Transitionen, die automatisch dem Abschluß der internen Aktion folgen. Eine Aktivität ist ein einzelner Schritt in einem Ablauf. Eine Aktivität kann mehrere ausgehende Transitionen haben, wenn diese durch Bedingungen unterschieden werden können. |
| Siehe auch
Zustand [UML 1.4]
Transition [UML 1.4]
Aktivitätsdiagramm [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Aktivität [UML 2.0] (G-827)
|
| Eine Aktivität beschreibt einen Ablauf und enthält verschiedene Arten von Knoten, die durch Objekt- und Kontrollflüsse miteinander verbunden sind. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:11:44 GMT+1,
[Anmerkungen/Kommentare]
|
| Aktivitätsdiagramm [UML 2.0] (G-828)
|
| Ein Aktivitätsdiagramm stellt eine Aktivität dar, die Begriffe werden synonym verwendet. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:12:27 GMT+1,
[Anmerkungen/Kommentare]
|
| Aktivitätstyp [OEP] (G-216)
|
| Ein Aktivitätstyp ist eine abstrakte Beschreibung von Tätigkeiten, um ein oder mehrere definierte Ergebnisse zu erzeugen. Ein Aktivitätstyp ist somit eine Art Arbeitsanleitung. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Analyse [OEP] (G-811)
|
| Mit (objektorientierter) Analyse werden alle Aktivitäten im Rahmen des Softwareentwicklungsprozesses bezeichnet, die der Ermittlung, Klärung und Beschreibung der Anforderungen an das System dienen (d.h. die Klärung, was das System leisten soll). Im Gegensatz zur Anforderungsanalyse findet dies in der Sprache der Softwareentwickler statt (z.B. UML). |
| Siehe auch
Analyse [GPM]
Anforderungsanalyse [OEP]
|
| Letzte Änderung von boe am 2003/04/12 19:30:32 GMT+2,
[Anmerkungen/Kommentare]
|
| Analyse [UML 2.0] (G-829)
|
| Mit (objektorientierter) Analyse werden alle Aktiviäten im Rahmen des Softwareentwicklungsprozesses bezeichnet, die der Ermittlung, Klärung und Beschreibung der Anforderungen an das System dienen (d.h. die Klärung, was das System leisten soll). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:23:16 GMT+1,
[Anmerkungen/Kommentare]
|
| Anforderung [UML 2.0] (G-830)
|
| Eine Anforderung beschreibt eine oder mehrere Eigenschaften oder Verhaltensweisen, die stets erfüllt sein sollen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:24:12 GMT+1,
[Anmerkungen/Kommentare]
|
| Anforderungsanalyse [OEP] (G-388)
|
| Teil des Softwareentwicklungsprozesses und Menge von Entwicklungsaktivitäten, die der Identifizierung, Analyse und Beschreibung von Anforderungen an die zu erstellende Software dienen. |
| Siehe auch
Analyse [GPM]
Analyse [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Ant [Modewörterbuch] (G-701)
|
| Plattformunabhängiges Buildtool für Java (ähnlich: Make). Buildfiles in XML. |
| Siehe auch
|
| Letzte Änderung von boe am 2002/11/11 11:40:03 GMT+1,
[Anmerkungen/Kommentare]
|
| Anwendungsfall [UML 2.0] (G-831)
|
| Ein Anwendungsfall beschreibt an-hand eines zusammenhängenden Arbeitsablaufes die Interaktionen mit einem (geschäftlichen oder technischen) System. Ein Anwendungsfall wird stets durch einen Akteur initiiert und führt gewöhnlich zu einem für die Akteure wahrnehmbaren Ereignis. |
| Siehe auch
Geschäftsanwendungsfall [UML 2.0]
Systemanwendungsfall [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 12:25:43 GMT+1,
[Anmerkungen/Kommentare]
|
| Anwendungsfalldiagramm [UML 2.0] (G-832)
|
| Ein Anwendungsfalldiagramm zeigt Akteure, Anwendungsfälle und die Beziehungen zwischen diesen Elementen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:26:41 GMT+1,
[Anmerkungen/Kommentare]
|
| Anwendungsfallmodell [UML 2.0] (G-833)
|
| Ein Modell, das die funktionalen Anforderungen an ein System in Form von Anwendungsfällen beschreibt (meist in Form eines oder mehrerer Anwendungsfalldiagramme). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:32:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Apache [Modewörterbuch] (G-702)
|
| Verbreiteter Webserver |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:33:28 GMT+1,
[Anmerkungen/Kommentare]
|
| Applet [Modewörterbuch] (G-703)
|
| Im Browser ablauffähiges Java-Programm. Starke Restiktionen. Über HTML-Tag einzubetten |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:36:54 GMT+1,
[Anmerkungen/Kommentare]
|
| Application Server [Komponenten] (G-618)
|
| Ein Applikations-Server stellt den Lebensraum für serverseitige Komponenten
zur Verfügung. Es werden technische Dienste zur Verfügung gestellt (Names-Dienst,
Transaktions-Dienst u.s.w.) die von den entsprechenden Komponenten genutzt werden
können. |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:30:12 GMT+1,
[Anmerkungen/Kommentare]
|
| Arbeitsauftrag [OEP] (G-225)
|
| Ein Arbeitsauftrag definiert ein möglichst objektiv nachprüfbares Ergebnis, das von einer oder wenigen Personen erstellt werden soll. Typischerweise hat jeder Mitarbeiter pro Iteration an mehreren Arbeitsaufträgen beteiligt, ein Arbeitsauftrag ist häufig kürzer, aber nie länger als eine Iteration.
Rahmenbedingungen wie geschätzter bzw. geplanter Aufwand, Start- und Endtermin, Form und Qualität des Ergebnisses, ggf. einzusetzende Werkzeuge u. Ä. werden beschrieben. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Arbeitspaket [OEP] (G-226)
|
| Eine Menge von konkreten Arbeitsaufträgen oder die Beschreibung einer Aufgabe, die in mehrere konkrete Arbeitsaufträge zerlegbar ist. |
| Siehe auch
Arbeitsauftrag [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Architektur [UML 2.0] (G-835)
|
| Die Architektur ist die Spezifikation der grundlegenden Struktur eines Systems. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 12:34:14 GMT+1,
[Anmerkungen/Kommentare]
|
| Artefakt [OEP] (G-24)
|
| Ein Artefakt ist ein Synonym für Produkt. Als Artefakte werden jegliche Produkte bezeichnet, die im Rahmen des Softwareentwicklungsprozesses erzeugt werden (Klassen, Testfälle, Projektpläne, Code etc.). |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| assertion [engl.] (G-425)
Alias für
Zusicherung [engl.]
|
| Assertions sind boolesche Ausdrücke, die niemals unwahr werden sollen und anderenfalls auf Fehler hinweisen. Typischerweise sind Assertions nur zur Entwicklungszeit aktiviert. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Assessment [Qualitätssicherung] (G-641)
|
| Beurteilung eines System s oder Prozesses |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 12:47:15 GMT+2,
[Anmerkungen/Kommentare]
|
| Assoziation [UML 1.4] (G-25)
|
| Eine Assoziation beschreibt eine Relation zwischen Klassen, d.h. die gemeinsame Semantik und Struktur einer Menge von Objektbeziehungen. Es werden gerichtete Assoziationen (nur einseitig direkt navigierbar) und bidirektionale Assoziationen (beidseitig direkt navigierbar) unterschieden. Die beiden Enden einer Assoziation sind Assoziationsrollen. |
| Siehe auch
Objektverbindung [UML 1.4]
Klasse [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Assoziation [UML 2.0] (G-838)
|
| Eine Assoziation beschreibt eine Relation zwischen Klassen, d.h. die gemeinsame Semantik und Struktur einer Menge von Objektbeziehungen. Es werden gerichtete Assoziationen (nur einseitig direkt navigierbar) und bidirektionale Assoziationen (beidseitig direkt navigierbar) unterschieden. |
| Siehe auch
Gerichtete Assoziation [UML 2.0]
Bidirektionale Assoziation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 13:10:45 GMT+1,
[Anmerkungen/Kommentare]
|
| Assoziationsklasse [UML 1.4] (G-427)
|
| Ein Modellelement, das sowohl über die Eigenschaften einer Klasse als auch über die einer Assoziation verfügt. Es kann gesehen werden als Assoziation mit zusätzlichen Klasseneigenschaften (Attributierte Assoziation) oder als Klasse mit zusätzlichen Assoziationseigenschaften (Assoziationsklasse). |
| Siehe auch
Attributierte Assoziation [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Assoziationsrolle [UML 2.0] (G-840)
|
| Die Rolle, die ein Typ oder eine Klasse in einer Assoziation spielt. D.h. eine Rolle repräsentiert eine Klasse in einer Assoziation. Gewöhnlich befinden sich Assoziationen zwischen zwei Klassen. Eine Klasse kann aber auch eine Assoziation zu sich selbst haben; in diesem Fall sind die beiden Enden der Assoziation nur durch die Rollenangabe zu unterscheiden. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 13:28:54 GMT+1,
[Anmerkungen/Kommentare]
|
| Assoziationsrolle [UML 1.4] (G-405)
|
| Die Rolle, die ein Typ oder eine Klasse in einer Assoziation spielt. D.h. eine Rolle repräsentiert eine Klasse in einer Assoziation. Gewöhnlich befinden sich Assoziationen zwischen zwei Klassen. Eine Klasse kann aber auch eine Assoziation zu sich selbst haben kann; in diesem Fall sind die beiden Enden der Assoziation nur durch die Rollenangabe zu unterscheiden. |
| Siehe auch
Assoziation [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Attribut [OO allg.] (G-26)
|
| Eine benannte Eigenschaft eines Typs. Ein Attribut ist ein Datenelement, das in jedem Objekt einer Klasse gleichermaßen enthalten ist und von jedem Objekt mit einem individuellen Wert repräsentiert wird. Im Gegensatz zu Objekten haben Attribute außerhalb des Objektes, von dem sie Teil sind, keine eigene Identität. Attribute sind vollständig unter der Kontrolle der Objekte, von denen sie Teil sind. |
| Siehe auch
Objekt [OO allg.]
Typ [UML 1.4]
Klasse [OO allg.]
Identität [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Attribut [UML 2.0] (G-841)
|
| Ein Attribut ist ein (Daten-) Element, das in jedem Objekt einer Klasse gleichermaßen enthalten ist und von jedem Objekt mit einem individuellen Wert repräsentiert wird. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 13:30:53 GMT+1,
[Anmerkungen/Kommentare]
|
| Audit [OEP] (G-233)
|
| Ein Audit ist eine Untersuchung einer Organisationseinheit oder eines Projektes, um die Einhaltung und Wirksamkeit von Regelungen, Verfahren und Standards zu ermitteln und zu dokumentieren. |
| Siehe auch
Review [OEP]
Inspektion [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Automated Testing Life-Cicle Methodology (ATLM) [Qualitätssicherung] (G-638)
|
| Prozessmodell bei der Entwicklung automatisierter Tests |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/07 14:48:13 GMT+2,
[Anmerkungen/Kommentare]
|
| AWT [Modewörterbuch] (G-704)
|
| Abstract Windowing Toolkit. Alte leider nicht plattformunabhängige UI-Bibliothek von Java. Grundlage für Swing |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:38:05 GMT+1,
[Anmerkungen/Kommentare]
|
| Balanced Scorecard [GPM] (G-742)
|
| Die Balanced Scorecard wird als Instrument für das Management zur konsequenten Ausrichtung der Handlungen und Maßnahmen einer Gruppe von Menschen auf ein gemeinsames Ziel verwendet. |
| Siehe auch
Strategiekarte [GPM]
|
| Letzte Änderung von cj am 2003/04/07 16:27:49 GMT+2,
[Anmerkungen/Kommentare]
|
| Baseline [Qualitätssicherung] (G-647)
|
| Überprüfte und genehmigte §Spezifikation |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 13:04:26 GMT+2,
[Anmerkungen/Kommentare]
|
| Bean [Modewörterbuch] (G-705)
|
| siehe JavaBean |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:39:23 GMT+1,
[Anmerkungen/Kommentare]
|
| Bean Managed Persistence [Komponenten] (G-600)
|
| Bean Managed Persistence bezeichnet einen Mechanismus zur Abbildung der
Daten einer Enitity Bean auf einer Datenbank. Im Gegensatz zur Container Managed Persistence
ist die Bean selbst dafür verantwortlich die Daten in einer Datenbank zu speichern. Dafür müssen
Methoden zur Verfügung gestellt werden um Daten zu laden und zu speichern. |
| Siehe auch
Entity-Bean [OO allg.]
Container Managed Persistence [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:20:25 GMT+1,
[Anmerkungen/Kommentare]
|
| Benchmark [Qualitätssicherung] (G-648)
|
| Test zur Messung der Leistungsfähigkeit eines System s oder Modul s. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 13:08:39 GMT+2,
[Anmerkungen/Kommentare]
|
| Benutzerarbeitskreis [EmOO] (G-700)
|
| Der Benutzerarbeitskreis ist ein Gremium aus zukünftigen Anwendern und Fachexperten des zu realisierenden Systems, welches das Projekt bei der Aufnahme der fachlichen Anforderungen unterstützen soll. Der Benutzerarbeitskreis wird vom Projekt zur Klärung offener fachlicher Fragen einberufen und kann verbindliche Entscheidungen über die fachlichen Anforderungen treffen. In der Regel ist der Benutzerarbeitskreis auch für die fachliche Abnahme der Benutzeroberflächenentwürfe zuständig. |
| Siehe auch
|
| Letzte Änderung von bst am 2002/08/23 09:19:26 GMT+2,
[Anmerkungen/Kommentare]
|
| Beziehung [UML 2.0] (G-844)
|
| UML-Modellelemente können verschiedene Arten von Beziehungen untereinander haben. Klassen können beispielsweise Spezialisierungsbeziehungen, Assoziationen, Realisierungs- und Abhängigkeitsbeziehungen haben. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 14:32:01 GMT+1,
[Anmerkungen/Kommentare]
|
| Bidirektionale Assoziation [UML 2.0] (G-845)
|
| Eine bidirektionale Assoziation ist eine beidseitig direkt navigierbare Assoziation, d.h. eine Assoziation, bei der von beiden beteiligten Assoziationsrollen zur jeweils anderen direkt navigiert werden kann. |
| Siehe auch
Assoziation [UML 2.0]
Assoziationsrolle [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 14:37:05 GMT+1,
[Anmerkungen/Kommentare]
|
| BMP [Modewörterbuch] (G-707)
|
| Bean Managed Persistence |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:40:34 GMT+1,
[Anmerkungen/Kommentare]
|
| Build [OEP] (G-236)
|
| Ein Build ist eine gewöhnlich unvollständige und vorübergehende, aber ausführbare Version eines in Entwicklung befindlichen Systems. |
| Siehe auch
Version [OEP]
Release [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Businessmodell [UML 2.0] (G-1011)
|
| Ein Businessmodell ist ein Klassenmodell, daß ausschließlich oder vorwiegend Businessklassen (fachlich elementare Begriffe) in Form von Klassen enthält. |
| Siehe auch
Fachklassenmodell [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/19 15:45:14 GMT+1,
[Anmerkungen/Kommentare]
|
| Businessobjekt [UML 2.0] (G-847)
|
| Ein Businessobjekt repräsentiert einen Gegenstand, ein Konzept, einen Ort oder eine Person aus dem realen Geschäftsleben in einem fachlichen geringen Detaillierungsgrad, d.h. einen fachlich elementaren Begriff (Vertrag, Rechnung etc.). Für die praktische Umsetzung sind Businessobjekte auf rein fachlich motivierte Eigenschaften reduzierte Aggregationen fundamentaler Fachobjekte (Fachklassen: Rechnungspositionen, Anschrift etc.), zu denen alles weitere delegiert wird. Sie definieren typischerweise vor allem Schnittstellen und sind eine Art Fassade. |
| Siehe auch
Objekt [UML 2.0]
Fachklasse [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 14:45:39 GMT+1,
[Anmerkungen/Kommentare]
|
| C# [Modewörterbuch] (G-706)
|
| Programmiersprache für Microsofts DotNet-Plattform. Ähnlich: Java |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:40:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Capability Maturity Model (CMM) [Qualitätssicherung] (G-654)
|
| Bewertungsmodell für die Qualität von Prozessen, welche auf §Reifegraden beruht. Es lässt sich direkt ein Maßnahmenkatalog ableiten, um von einer Stufe auf die nächsthöhere zu gelangen, wobei Stufen jedoch nicht übersprungen werden können. Das Erreichen einer höheren Stufe dauert ca. zwei Jahre. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 13:51:46 GMT+2,
[Anmerkungen/Kommentare]
|
| Cash Flow [GPM] (G-746)
|
| Diese Kennzahl dient der Beurteilung des Innenfinanzierungspotenzials und der Ertragskraft des Unternehmens. Sie errechnet sich wie folgt: Cash Flow = Jahresüberschuss bzw. –fehlbetrag - Erträge aus Verlustübernahme + Abgeführte Gewinne + Abschreibungen und Wertberichtigungen auf Sachanlagen und immaterielle Anlagenwerte + Abschreibungen und Wertberichtigungen auf Finanzanlagen mit Ausnahme des Betrages, der in die Pauschalwertberichtigung zu Forderungen eingestellt ist + Zuführung zu Pensionsrückstellungen. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:02:05 GMT+2,
[Anmerkungen/Kommentare]
|
| Chance [GPM] (G-747)
|
| Die Chance ist die Aussicht auf Erfolg. Eine Chance kann ausgedrückt werden durch die Wahrscheinlichkeit ihres Auftretens und einem Gewinn im Eintrittfalls. Vgl. Risiko. |
| Siehe auch
Risiko [GPM]
|
| Letzte Änderung von cj am 2003/04/08 15:03:01 GMT+2,
[Anmerkungen/Kommentare]
|
| Change Control Board [Qualitätssicherung] (G-658)
|
| Gremium, das gemäß der Change Control die Änderungen an einem System genehmigt oder ablehnt. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 13:57:46 GMT+2,
[Anmerkungen/Kommentare]
|
| Change Management [Qualitätssicherung] (G-659)
Alias für
Änderungsmanagement [Qualitätssicherung]
|
| Management von Änderungen an einem System oder einem Teil davon. Die Änderungen erfolgen gezielt, dokumentiert, geplant und versioniert, um jederzeit Überblick über Art, Umfang, Umfeld, Beteiligte und Grund von Änderungen zu haben. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 13:58:43 GMT+2,
[Anmerkungen/Kommentare]
|
| CMP [Modewörterbuch] (G-708)
|
| Container Managed Persistence. Für EJB |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:41:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Configuration Control [Qualitätssicherung] (G-661)
|
| Formaler Prozess, bei dem alle Änderungen am System genau protokolliert werden: wer wann was warum wo und in welcher Version geändert hat. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:02:44 GMT+2,
[Anmerkungen/Kommentare]
|
| Configuration Item [Qualitätssicherung] (G-662)
|
| Eindeutig identifizierbarer Teil oder Sammlung identifizierbarer Teile, die vom Konfigurationsmanagement als eine Einheit betrachtet wird. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:06:32 GMT+2,
[Anmerkungen/Kommentare]
|
| Container Managed Persistence [Komponenten] (G-697)
|
| Container Managed Persistence bezeichet einen Persistenz-Mechanismus für EntityBeans
bei der die Daten einer EntityBean automatisch vom Container in einer Datenbank gespeichert
(oder von ihr geladen) werden. |
| Siehe auch
Enterprise Java Beans [Komponenten]
Entity-Bean [OO allg.]
|
| Letzte Änderung von 29.8.2001 am 2001/08/29 09:55:37 GMT+2,
[Anmerkungen/Kommentare]
|
| CORBA [Modewörterbuch] (G-709)
|
| Common Object Request Broker Architecture. RPC für Objekte. Plus diverse wenig genutzte Standards und Protokolle. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:41:26 GMT+1,
[Anmerkungen/Kommentare]
|
| Corba [Komponenten] (G-605)
|
| Common Object Request Broker Architekture. Corba bezeichnet eine Architektur für
verteilte, sprachunabhängige Objekte. Die Corba Spezifikation definiert verschiedene
Dienste (Transaktions-Dienst, Names-Dienst, Ereignis-Dienst ...) die ein entsprechender
Applikations-Server bieten muss. |
| Siehe auch
Application Server [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:22:22 GMT+1,
[Anmerkungen/Kommentare]
|
| Corba Component Modell [Komponenten] (G-604)
|
| Das Corba Component Model ist eine Spezifikation zur Erstellung von serverseitig skalierbaren,
sprachunabhängigen, transaktions-sicheren Mehrbenutzer-Applikationen.
Es beinhaltet ein konsistentes Rahmenwerk zur Erstellung der Middleware Komponenten
in einer Multi-Tier Applikation. |
| Siehe auch
Corba [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:22:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Corporate Identity [GPM] (G-749)
|
| Die Corporate Identity stellt die anzustrebende Einmaligkeit bzw. Persönlichkeit eines Unternehmens dar und hat den Zweck das Unternehmen für seine relevanten Bezugsgruppen unverwechselbar zu machen. Sie wird explizit definiert und niedergeschrieben und trägt dadurch zu einem einheitlichen Auftreten, einheitlicher Haltung und gemeinsamen Werteverständnis bei. Mit den Mitteln der Corporate Communications, des Corporate Designs, der Corporate Culture sowie des Corporate Behaviours wird versucht, ein ganz bestimmtes Image betriebsintern und -extern aufzubauen. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:05:36 GMT+2,
[Anmerkungen/Kommentare]
|
| CRC-Karten [OO allg.] (G-28)
|
| Karteikarten, auf denen der Name der Klasse (Class), ihre Aufgaben (Responsibilities) und ihre Beziehungen (Collaborations) beschrieben werden. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| CRC-Karten [UML 2.0] (G-848)
|
| Karteikarten, auf denen der Name der Klasse (Class), ihre Aufgaben (Responsibilities) und ihre Beziehungen (Collaborations) beschrieben werden. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 14:47:47 GMT+1,
[Anmerkungen/Kommentare]
|
| Critical Design Review [Qualitätssicherung] (G-663)
|
| Review mit dem Kunden am Ende der Designphase unmittelbar vor Beginn der Kodierungsphase. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:10:26 GMT+2,
[Anmerkungen/Kommentare]
|
| Datenabstraktion [OO allg.] (G-29)
|
| Hierunter versteht man das Prinzip, nur die auf ein Objekt anwendbaren Operationen nach außen sichtbar zu machen. Die tatsächliche innere Realisierung der Operationen und die innere Struktur des Objektes werden verborgen, d.h. man betrachtet abstrakt die eigentliche Semantik und läßt die tatsächliche Implementierung außer acht. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Datenabstraktion [UML 2.0] (G-849)
|
| Hierunter versteht man das Prinzip, nur die auf ein Objekt anwendbaren Operationen nach außen sichtbar zu machen. Die tatsächliche innere Re-alisierung der Operationen und die innere Struktur des Objektes werden verborgen, d.h. man betrachtet abstrakt die eigentliche Semantik und läßt die tatsächliche Implementierung außer acht. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 14:49:35 GMT+1,
[Anmerkungen/Kommentare]
|
| Debugging [Qualitätssicherung] (G-664)
|
| Lokalisieren und Beseitigen eines Fehler im Programm-Code. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:11:50 GMT+2,
[Anmerkungen/Kommentare]
|
| Delegation [UML 2.0] (G-851)
|
| Eine Delegation ist ein Mechanismus, bei dem ein Objekt eine Nachricht nicht (vollständig) selbst interpretiert, sondern an ein anderes Objekt weiterleitet (propagiert). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:36:57 GMT+1,
[Anmerkungen/Kommentare]
|
| Delegation [OO allg.] (G-31)
|
| Delegation ist ein Mechanismus, bei dem ein Objekt eine Nachricht nicht (vollständig) selbst interpretiert, sondern an ein anderes Objekt weiterleitet (propagiert). |
| Siehe auch
Objekt [OO allg.]
Nachricht [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Depends on-Beziehung [UML 1.4] (G-553)
|
| Eine Beziehung zwischen Anwendungsfällen mit dem Stereotyp «depends on».
Eine Depends on-Beziehung zwischen Anwendungsfällen besagt, daß ein Anwendungsfall ganz allgemein oder indirekt von einem anderen abhängig ist, d.h. erst in Zusammenhang mit diesem ein sinnvolles Gesamtsystem bzw. -modell existiert. |
| Siehe auch
Anwendungsfall [UML 1.4]
Abhängigkeitsbeziehung [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Design [OEP] (G-32)
|
| Mit Design werden alle Aktivitäten im Rahmen des Softwareentwicklungsprozesses bezeichnet, mit denen ein Modell logisch und physisch strukturiert wird und die dazu dienen, zu beschreiben, wie das System die in der Analyse beschriebenen Anforderungen erfüllt. Ein Design ist ein Lösungskonzept. |
| Siehe auch
Analyse [GPM]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Design [UML 2.0] (G-852)
|
| Mit (objektorientiertem) Design werden alle Aktiviäten im Rahmen des Softwareentwicklungsprozesses bezeichnet, mit denen ein Modell logisch und physisch strukturiert wird und die dazu dienen zu beschreiben, wie das System die in der Analyse beschriebenen Anforderungen erfüllt. |
| Siehe auch
Analyse [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 15:39:31 GMT+1,
[Anmerkungen/Kommentare]
|
| Diagramm [OEP] (G-750)
|
| Ein Diagramm ist die grafische Repräsentation eines Modells bzw. Ausschnitt eines Modells. |
| Siehe auch
Modell [OEP]
|
| Letzte Änderung von cj am 2003/04/08 15:07:27 GMT+2,
[Anmerkungen/Kommentare]
|
| Diskriminator [UML 2.0] (G-853)
|
| Ein Diskriminator ist ein Unterscheidungsmerkmal für die Strukturierung der Modellsemantik in Generalisierungs- bzw. Spezialisierungsbeziehungen. |
| Siehe auch
Generalisierung [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 15:41:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Doclet [Modewörterbuch] (G-710)
|
| Programm, welches javadoc-Kommentar-Tags verwertet |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:41:48 GMT+1,
[Anmerkungen/Kommentare]
|
| DOM [Modewörterbuch] (G-711)
|
| Document Object Model. Komfortable Bibliothek zur Verarbeitung von XML-Dateien. Erzeugt ein Abbild der gesamten XML-Datei als Objektbaum im Hauptspeicher. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:42:13 GMT+1,
[Anmerkungen/Kommentare]
|
| Domänenexperte [OEP] (G-751)
Alias für
Fachexperte [OEP]
|
| Ein Experte in einem bestimmten Fachgebiet (einer Domäne). |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:08:53 GMT+2,
[Anmerkungen/Kommentare]
|
| Domänenmodell [OEP] (G-34)
|
| Ein Modell, beispielsweise ein Klassenmodell, welches die fachlich relevanten Sachverhalte repräsentiert, nicht aber technisch oder fachfremd motivierte Sachverhalte. |
| Siehe auch
Fachklassenmodell [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| DotNet [Modewörterbuch] (G-712)
|
| Microsoft Integrationsplattform für verteilte Anwendung. Plattform- und Sprachunabhängig. Vorwiegend freilich für Microsoft Betriebssysteme. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:42:42 GMT+1,
[Anmerkungen/Kommentare]
|
| Dynamische Bindung [OO allg.] (G-491)
|
| Hierunter ist zu verstehen, daß eine Nachricht erst zur Programmlaufzeit einer konkreten Operation zugeordnet wird, die diese Nachricht dann interpretiert. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Dynamische Bindung, späte Bindung [UML 2.0] (G-854)
|
| Hierunter ist zu verstehen, daß eine Nachricht erst zur Programmlaufzeit einer konkreten Operation zugeordnet wird, die diese Nachricht dann interpretiert. |
| Siehe auch
Nachricht [UML 2.0]
Operation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 15:45:19 GMT+1,
[Anmerkungen/Kommentare]
|
| Dynamische Klassifikation [UML 2.0] (G-855)
|
| Ein Objekt ist nacheinander Instanz unterschiedlicher Klassen einer Untertypenstruktur, d.h. es kann seine Klassenzugehörigkeit während seiner Lebenszeit ändern. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:46:51 GMT+1,
[Anmerkungen/Kommentare]
|
| EAI [Modewörterbuch] (G-713)
|
| Enterprise Application Integration. Oberbegriff für allen möglichen Kram, der gerade so In ist. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:43:08 GMT+1,
[Anmerkungen/Kommentare]
|
| EBIT [GPM] (G-752)
|
| Abk. für Earnings Before Interest and Taxes. Die Gewinnkennzahl EBIT entspricht dem Jahresüberschuss vor Zinsaufwand, außerordentlichem Ergebnis und Steuern eines Unternehmens und stellt ein Maß an Bargeldrentabilität dar. Das EBIT kann auch als betriebliches Ergebnis bezeichnet werden. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:14:10 GMT+2,
[Anmerkungen/Kommentare]
|
| Eclipse [Modewörterbuch] (G-714)
|
| Open Source Java Entwicklungsumgebung (von IBM). Offene Plattform zu integration beliebiger Tools und Programmiersprachen vie Plug-Ins. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:43:32 GMT+1,
[Anmerkungen/Kommentare]
|
| effektiv [GPM] (G-753)
|
| Die Effektivität bezeichnet die Wirksamkeit im Hinblick darauf, ob man das Richtige getan hat. Etwas ist ineffektiv, wenn das Ergebnis wenig wirksam ist. |
| Siehe auch
effizient [GPM]
|
| Letzte Änderung von cj am 2003/04/08 15:15:34 GMT+2,
[Anmerkungen/Kommentare]
|
| effizient [GPM] (G-754)
|
| Die Effizienz bezeichnet die Wirksamkeit im Hinblick darauf, wie man etwas macht. Etwas ist ineffizient, wenn man das richtige beispielsweise umständlich ausführt. |
| Siehe auch
effektiv [GPM]
|
| Letzte Änderung von cj am 2003/04/08 15:16:23 GMT+2,
[Anmerkungen/Kommentare]
|
| Eigenschaftswert [UML 1.4] (G-434)
Alias für
tagged value [UML 1.4]
|
| Eigenschaftswerte sind benutzerdefinierte, sprach- oder werkzeugspezifische Schlüsselwort-Wert-Paare, die die Semantik einzelner Modellelemente um spezielle Eigenschaften erweitern. Der Unterschied zum Stereotyp besteht darin, daß durch ein Stereotyp das Metamodell um ein neues Element erweitert wird. Mit Eigenschaftswerten hingegen können einzelne Ausprägungen bestehender Modellelemente (z.B. eine bestimmte Operation) um bestimmte Eigenschaften erweitern. |
| Siehe auch
Stereotyp [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Eigenschaftswert [UML 2.0] (G-856)
|
| Eigenschaftswerte sind benutzerdefinierte, sprach- und werkzeugspezifische Schlüsselwörter, die die Semantik einzelner Modellelemente um spezielle charakteristische Eigenschaften erweitern. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:49:08 GMT+1,
[Anmerkungen/Kommentare]
|
| Einfachvererbung [UML 2.0] (G-857)
|
| Bei der Einfachvererbung erbt eine Unterklasse nur von einer direkten Oberklasse. |
| Siehe auch
Vererbung [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 15:49:56 GMT+1,
[Anmerkungen/Kommentare]
|
| EJB [Modewörterbuch] (G-715)
|
| Enterprise Java Beans. Komponentenstandard für Java-basierte Application Server. Entity Beans (CMP/BMP). Session Beans. Message Driven Beans. Hat nichts mit JavaBeans zu tun. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:44:11 GMT+1,
[Anmerkungen/Kommentare]
|
| EJB QL [Komponenten] (G-626)
|
| Enterprise JavaBean Query Language. Zur Vereinheitlichung der Finder-Methoden Definition
in verschiedenen Applikations-Servern definiert die Enterprise JavaBean Spezifikation ab der
Version 2.0 eine einheitliche Abfragesprache zum Auffinden der Bean Instanzen. |
| Siehe auch
Enterprise Java Beans [Komponenten]
Finder [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:33:13 GMT+1,
[Anmerkungen/Kommentare]
|
| EJBQL [Modewörterbuch] (G-716)
|
| Abfragesprache für Enterprise Java Beans. Für CMP-EJB. Ähnlich: SQL |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:44:34 GMT+1,
[Anmerkungen/Kommentare]
|
| Enterprise Java Beans [Komponenten] (G-598)
|
| Enterprise Java Beans (EJB) bezeichnet ein Komponentenmodell für serverseitige, verteilte Komponenten Die EJB 1.0 Spezifikation wurde im Jahr 1998 von Sun veröffentlicht |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:19:26 GMT+1,
[Anmerkungen/Kommentare]
|
| Enthältbeziehung [UML 2.0] (G-858)
|
| Mit einer Enthältbeziehung wird ein Anwendungsfall in einen anderen Anwendungsfall eingebunden und logischer Teil von diesem. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:50:39 GMT+1,
[Anmerkungen/Kommentare]
|
| Entität [OEP] (G-806)
|
| Eine Entität bzw. Entitätsklasse ist eine Informationsklasse, d.h., ihre Verantwortlichkeit ist das Aufnehmen und Verwalten von Daten. Ein konkretes Exemplar wird als Entitätsobjekt bezeichnet. Entitätsklasse wird oft von Fachklassen abgeleitet bzw. synonym verwendet. |
| Siehe auch
Fachklasse [OEP]
|
| Letzte Änderung von twe am 2003/04/10 11:25:41 GMT+2,
[Anmerkungen/Kommentare]
|
| Entity-Bean [OO allg.] (G-591)
|
| Komponententyp der Komponentenarchitektur Enterprise JavaBeans. Entity-Beans sind Geschäftsobjekte, die persistente Daten und Geschäftslogik repräsentieren. |
| Siehe auch
Session-Bean [OO allg.]
|
| Letzte Änderung von boe am 2000/01/15 16:30:35 GMT+1,
[Anmerkungen/Kommentare]
|
| Entwicklungsprozeß [OEP] (G-41)
|
| Repräsentiert die zeitliche Perspektive und die Abfolge der Aktivitäten zur Erstellung eines Produktes. |
| Siehe auch
Vorgehensmodell [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Entwurfsmuster [OO allg.] (G-43)
|
| Entwurfsmuster sind generalisierte und bewährte Lösungsansätze zu immer wiederkehrenden Entwurfsproblemen. Sie sind keine fertig codierten Lösungen, sie beschreiben lediglich den Lösungsweg. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Entwurfsmuster [UML 2.0] (G-859)
|
| Entwurfsmuster sind generalisierte und bewährte Lösungsansätze zu immer wiederkehrenden Entwurfsproblemen. Sie sind keine fertig kodierten Lösungen, sie beschreiben lediglich den Lösungsweg bzw. die Lösungsidee. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:52:36 GMT+1,
[Anmerkungen/Kommentare]
|
| Entwurfsmuster [OO allg.] (G-755)
|
| Entwurfsmuster sind generalisierte und bewährte Lösungsansätze zu immer wiederkehrenden Entwurfsproblemen. Sie sind keine fertig codierten Lösungen, sie beschreiben lediglich den Lösungsweg bzw. die Lösungsidee. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:17:07 GMT+2,
[Anmerkungen/Kommentare]
|
| Enumeration [UML 2.0] (G-860)
|
| Eine Enumeration ist eine Menge fester Werte ohne weitere Eigenschaften. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:53:28 GMT+1,
[Anmerkungen/Kommentare]
|
| Enumeration [Komponenten] (G-540)
Alias für
Wertemenge [Komponenten]
|
Enumerationen sind Aufzählungstypen, hinter denen konfigiurierbare Wertemengen stehen.
TK-spezifische Aufzählungstypen werden im Rahmen von TKeasy als java-Klassen realisiert, die sich von sonstigen Objekten dadurch unterscheiden, daß sie per Wert und nicht per Referenz weitergeleitet werden. |
| Siehe auch
Enumeration [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Enumeration [OO allg.] (G-541)
Alias für
Wertemenge [OO allg.]
|
| Enumerationen sind Aufzählungstypen. Diese Aufzählungstypen können fest programmiert sein oder durch (ggf. datenbankgestützte) konfigiurierbare Wertemengen realisiert sein. Die Wertemengen ändern sich typischerweise nur selten. Beispiel: Familienstand = {ledig, verheiratet, geschieden, verwitwet}. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Ereignis [OO allg.] (G-452)
|
| Ein Geschehen, das in einem gegebenen Kontext eine Bedeutung hat und sich räumlich und zeitlich lokalisieren läßt. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Ereignis [UML 2.0] (G-861)
|
| Ein Ereignis ist ein zu beachtendes Vorkommnis, das in einem gegebenen Kontext eine Bedeutung hat, sich räumlich und zeitlich lokalisieren lässt und gewöhnlich einen Zustandsübergang (Transition) auslöst. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:56:02 GMT+1,
[Anmerkungen/Kommentare]
|
| Ergebnis, betriebswirtschaftliches [GPM] (G-756)
|
| Dieser Begriff wird meist synonym für eine Vielzahl von Erfolgsrechnungsergebnistypen verwendet. Je nach Erfolgsrechnung fällt das Ergebnis jedoch unterschiedlich aus und heißt auch anders. So wird das Ergebnis bei der handelsbillanziellen Gewinn und Verlustrechnung Jahresüberschuß bzw. –fehlbetrag oder Bilanzgewinn bzw. –verlust genannt, bei der Steuerbilanz spricht man vom steuerlichen Gewinn bzw. Verlust und bei einer Einnahmen-Ausgabenrechnung heißt das Ergebnis Einzahlungs- bzw. Auszahlungsüberschuß. |
| Siehe auch
EBIT [GPM]
|
| Letzte Änderung von cj am 2003/04/08 15:18:08 GMT+2,
[Anmerkungen/Kommentare]
|
| Ergebnis, eines Geschäftsprozesses [GPM] (G-757)
|
| Nutzen, der im Rahmen eines Geschäftsprozesses für einen Geschäftspartner entsteht, beispielsweise der Erhalt einer Leistung, Ware oder Wertes. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:19:01 GMT+2,
[Anmerkungen/Kommentare]
|
| Ergebnisstruktur [OEP] (G-48)
|
| Gliederung eines Ergebnisses |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Ergebnistyp [OEP] (G-246)
|
| Ein Ergebnistyp ist ein abstrahiertes Ergebnis, d. h., es wird damit definiert, welche Inhalte, Struktur und Form ein bestimmter Typ von Ergebnissen hat (syntaktische und semantische Beschreibung). Zur Beschreibung des Ergebnistyps gehören auch Aussagen zur Qualität und Granularität. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Ergonomie [Qualitätssicherung] (G-667)
|
| Ziehlt auf die Verbesserung der Leistungsfähigkeit von Arbeits System en bei gleichzeitiger Minimierung der auf den arbeitenden Menschen einwirkenden Belastungen. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:17:26 GMT+2,
[Anmerkungen/Kommentare]
|
| Error Seeding [Qualitätssicherung] (G-670)
|
| Methode zur Bestimmung eines Testabbruchkriterium s. Dabei werden von einer nicht an der Entwicklung beteiligten Gruppe bewusst Fehler in ein System eingebracht. Unter der Annahme, dass die bewusst eingebrachten Fehler äquivalent zu den unbewusst gemachten Fehlern ist, kann anhand der Anzahl der im Gesamttest gefundenen, bewussten fehler auf den Anteil der gefundenen echten Fehler geschlossen werden. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:19:36 GMT+2,
[Anmerkungen/Kommentare]
|
| Erweiterungsbeziehung [UML 2.0] (G-862)
|
| Mit einer Erweiterungsbeziehung läßt sich ausdrücken, dass ein Anwendungsfall unter bestimmten Umständen und an einer bestimmten Stelle (dem sog. Erweiterungspunkt, engl. extension point) durch einen anderen erweitert wird. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 15:59:07 GMT+1,
[Anmerkungen/Kommentare]
|
| Evolutionäres Vorgehen [OEP] (G-247)
|
| Vorgehen, bei dem ausgehend von zunächst unvollständigen Anforderungen ein Ergebnis in mehreren aufeinander aufbauenden Zwischenschritten erstellt wird. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Extend-Beziehung [UML 1.4] (G-548)
Alias für
Erweiterungsbeziehung [UML 1.4]
|
| Eine Beziehung zwischen Anwendungsfällen mit dem Stereotyp «extend».
Eine Extend-Beziehung zwischen Anwendungsfällen besagt, daß ein Anwendungsfall unter bestimmten Umständen bzw. an einer bestimmten Stelle (dem sog. "extension point") durch einen anderen erweitert wird. |
| Siehe auch
Anwendungsfall [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Extrovertierter Geschäftsmitarbeiter [GPM] (G-758)
|
| Extrovertierte Geschäftsmitarbeiter nennen wir solche, die sich innerhalb des Modellierungsfokusses (d. h. gewöhnlich innerhalb des zu modellierenden Unternehmens) befinden und die im Rahmen ihrer Leistungserbringung Kontakt zu Geschäftspartnern haben, die also beispielsweise mit Kunden und Lieferanten zu tun haben und für diese sichtbar. |
| Siehe auch
Geschäftsmitarbeiter [GPM]
Geschäftspartner [GPM]
|
| Letzte Änderung von cj am 2003/04/08 15:20:02 GMT+2,
[Anmerkungen/Kommentare]
|
| Fachabteilung [OEP] (G-249)
|
| Eine Fachabteilung ist eine aus Sicht der DV-Abteilung andere Organisationseinheit. Eine Fachabteilung kann ein möglicher Auftraggeber für DV-Projekte. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08,
[Anmerkungen/Kommentare]
|
| Facharchitektur [OO allg.] (G-251)
|
| Ein Modell, daß die grundsätzlichen fachlichen Zusammenhänge eines Anwendungsbereiches repräsentiert. |
| Siehe auch
Architektur [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Fachexperte [OEP] (G-814)
Alias für
Domänenexperte [OEP]
|
| Jemand, der sich in einem Fachgebiet gut auskennt. Nicht notwendigerweise ein Anwender. |
| Siehe auch
|
| Letzte Änderung von boe am 2003/04/14 08:13:24 GMT+2,
[Anmerkungen/Kommentare]
|
| Fachklasse [UML 2.0] (G-864)
|
| Fachlich motivierte Klasse, die einen Begriff aus dem Problembereich des zu entwickelnden Systems repräsentiert. Sie ist Bestandteil der Analysemodelle zur Systementwicklung. Fachklasse und Geschäftsklasse werden ift synonym verwendet. |
| Siehe auch
Klasse [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/06 16:03:17 GMT+1,
[Anmerkungen/Kommentare]
|
| Fachklasse [OEP] (G-53)
|
| Fachlich motivierte Klasse, die einen Begriff aus dem Problembereich des zu entwickelnden Systems repräsentiert. Sie ist Bestandteil der Analysemodelle zur Systementwicklung. Fachklasse und Geschäftsklasse werden oft synonym verwendet. |
| Siehe auch
Klasse [OO allg.]
Geschäftsklasse [OEP]
Entität [OEP]
|
| Letzte Änderung von twe am 2003/04/10,
[Anmerkungen/Kommentare]
|
| Failure [Qualitätssicherung] (G-671)
|
|
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:25:22 GMT+2,
[Anmerkungen/Kommentare]
|
| Fault [Qualitätssicherung] (G-672)
|
|
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:25:34 GMT+2,
[Anmerkungen/Kommentare]
|
| Feature [OEP] (G-759)
|
| Ein Feature ist eine Sammlung einer Menge einzelner Anforderungen jedweder Granularität. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:20:54 GMT+2,
[Anmerkungen/Kommentare]
|
| Fehler [Qualitätssicherung] (G-673)
|
| engl.: defect, failure, fault, aber auch bug) von impliziter oder expliziter §Spezifikation abweichendes Verhalten oder abweichender Zustand. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:25:53 GMT+2,
[Anmerkungen/Kommentare]
|
| Fehler [OO allg.] (G-252)
|
| Ein Fehler ist die Nicht-Erfüllung einer festgelegten Anforderung. |
| Siehe auch
Test [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Fehlererwartungsmethode [Qualitätssicherung] (G-674)
|
| Approximation eines idealten Test s auf Basis eines reichhaltigen Erfahrungsschatzes aus den Bereichen Test und Entwicklung und mit wahrscheinlichen Fehler quellen. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:27:37 GMT+2,
[Anmerkungen/Kommentare]
|
| Fehlerhaftigkeit [Qualitätssicherung] (G-675)
|
| Grad der Beeinflussung der Nutzbarkeit eines Produktes durch darin enthaltene Fehler. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:29:57 GMT+2,
[Anmerkungen/Kommentare]
|
| Fehlerklasse [Qualitätssicherung] (G-676)
|
| Einteilung von Fehler n nach ihren Auswirkungen und Konsequenzen. Erfahrungsgemäss ist eine Unterteilung in vier Klassen ausreichend und gut handhabbar:
- Fataler Fehler (z.B. System absturz, gefährdende Fehlfunktion oder Datenverluste)
- Schwerer Fehler ohne Workaround
- Schwerer Fehler mit Workaround
- Fehler |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:30:59 GMT+2,
[Anmerkungen/Kommentare]
|
| Fehlermodell [Qualitätssicherung] (G-677)
|
| Statistisches Rechenmodell, das anhand von Annahmen über eine durchschnittliche Fehlerdichte Rückschlüsse auf ein Fehlerabbruchkriterium sowie Test - und Korrekturaufwände ermöglicht. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:34:44 GMT+2,
[Anmerkungen/Kommentare]
|
| Fehlerrate [EmOO] (G-253)
|
| Die Zahl der während einer spezifischen Aktivität auftretenden Fehler. Die spezifische Aktivität ist z. B. eine Stunde Test, eine Stunde Benutzung, die Durchführung eines Testfalls o. ä. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Fertigstellungsgrad [EmOO] (G-254)
|
| Der Fertigstellungsgrad ist der bereits erbrachte Anteil vom Herstellungsaufwand. Ein Fertigstellungsgrad von 70% besagt, daß noch 30% des Herstellungsaufwandes zu leisten sind, bevor das Produkt vollständig hergestellt ist. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Finder [Komponenten] (G-625)
|
| Ein Enterprise JavaBean Klient benötigt Funktionalität zum Auffinden bereits bestehender
Bean Instanzen an Hand verschiedener Schlüsselmerkmale. Zu diesem Zweck beinhaltet
das Home Interface die sog. Finder-Methoden. Diese beginnen mit dem Prefix "findBy...".
Die Semantik der entsprechenden Methoden werden je nach Applikations-Server per
Java, SQL uder EJB QL definiert. |
| Siehe auch
EJB QL [Komponenten]
Enterprise Java Beans [Komponenten]
Home Interface [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:32:44 GMT+1,
[Anmerkungen/Kommentare]
|
| Freigabetest [Qualitätssicherung] (G-679)
|
| Systemtest durch eine dedizierte Instanz der System -Produktion zur Übergabe an den Produktionsbetrieb, Verkauf oder aber Abnahmetest durch den Kunden. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 14:57:30 GMT+2,
[Anmerkungen/Kommentare]
|
| Function Point [Qualitätssicherung] (G-680)
|
| Sprachunabhängige Aufwands Metrik anhand der Fein- §spezifikation. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:00:34 GMT+2,
[Anmerkungen/Kommentare]
|
| Funktionspunkte [EmOO] (G-256)
|
| Funktionspunkte sind ein extrinsisches Maß für den von außen sichtbaren Funktionsumfang und damit die Größe eines Softwareprodukts, das keine wesentliche verborgene Funktionalität enthält. Funktionspunkte sind von der International Function Points Users Group [IFPUG94] standardisiert. Vgl. auch Widgetpunkte. |
| Siehe auch
Maß [EmOO]
Widgetpunkte [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Generalisierung [OO allg.] (G-59)
|
Eine Generalisierung (bzw. Spezialisierung) ist eine taxonomische Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere weitere Eigenschaften hinzufügt, die Semantik erweitert und sich kompatibel zum allgemeinen verhält. Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Modellsemantik unter einem diskriminierenden Aspekt.
Die Generalisierung bzw. Spezialisierung wird vor allem auf Klassen und Anwendungsfälle angewendet. |
| Siehe auch
Spezialisierung [OO allg.]
Vererbung [OO allg.]
Diskriminator [UML 1.4]
Klasse [OO allg.]
Anwendungsfall [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Generische Programmierung [OO allg.] (G-60)
|
| Anwendung von Schablonen (engl. templates), parametrisierbaren Klassen u.ä. bei der Programmierung. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Generisches Design [OO allg.] (G-61)
|
| Anwendung von Schablonen oder Makros zum Design (in CASE-Tools). |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Generisches Design [UML 2.0] (G-866)
|
| Anwendung von Schablonen oder Makros zum Design (in CASE-Tools). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/06 16:04:59 GMT+1,
[Anmerkungen/Kommentare]
|
| Geordnete Assoziation [UML 2.0] (G-868)
|
| Assoziation, bei der die Objektverbindungen in bestimmter Weise geordnet sind. |
| Siehe auch
Assoziation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 08:40:32 GMT+1,
[Anmerkungen/Kommentare]
|
| Gesamttest [Qualitätssicherung] (G-681)
|
| Summe aller Testfälle für ein System |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:36:41 GMT+2,
[Anmerkungen/Kommentare]
|
| Geschäftsanfall [GPM] (G-805)
|
| Wahrnehmbare körperliche Muskelkontraktion, die mit einer exhorbitanten Zunahme an Gewaltbereitschaft gepaart ist. |
| Siehe auch
|
| Letzte Änderung von cl am 2003/04/09 15:23:00 GMT+2,
[Anmerkungen/Kommentare]
|
| Geschäftsanwendungsfall [UML 2.0] (G-870)
|
| Ein Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, wird von einem geschäftlichen Ereignis ausgelöst und endet mit einem Ergebnis, das für den Unternehmenszweck und die Gewinnerzielungsabsicht direkt oder indirekt einen geschäftlichen Wert darstellt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 08:53:29 GMT+1,
[Anmerkungen/Kommentare]
|
| Geschäftsklasse [OEP] (G-810)
|
| Fachliche motivierte Klasse, die einen Begriff aus dem Problembereich des Geschäfts repräsentiert. Sie ist Bestandteil der Geschäftsprozessmodellierung. Fachklasse und Geschäftsklasse werden oft synonym verwendet. |
| Siehe auch
Fachklasse [OEP]
|
| Letzte Änderung von md am 2004/07/22 15:20:42 GMT+2,
[Anmerkungen/Kommentare]
|
| Geschäftsobjekt [OO allg.] (G-62)
|
| Businessobjekt |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Geschäftspartner [GPM] (G-762)
|
| Ein Geschäftspartner ist ein Akteur. Es werden aktive und passive Geschäftspartner unterschieden. Sie stehen außerhalb des Modellierungsfokusses. Aktive Geschäftspartner stoßen Geschäftsvorfälle an, die zum Kerngeschäft des Unternehmens gehören und dem eigentlichen Geschäftszweck dienen, während die passiven Geschäftspartner solche Geschäftsvorfälle initiieren, die nicht direkt dem Geschäftszweck des Unternehmens zuzuordnen sind, jedoch unabdingbar sind, um das Kerngeschäft zu gewährleisten. D. h. die Geschäftsvorfälle des Kerngeschäfts würden ohne die unterstützenden Geschäftsvorfälle nicht funktionieren. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:28:20 GMT+2,
[Anmerkungen/Kommentare]
|
| Geschäftsprozess [UML 2.0] (G-871)
|
| Ein Geschäftsprozeß ist eine Zusammenfassung einer Menge fachlich verwandter Geschäftsanwendungsfälle. Dadurch bildet ein Ge-schäftsrozess gewöhnlich eine Zusammenfassug von organisatorisch evtl. verteilten, fachlich jedoch zusammenhängenden Aktivitäten, die notwendig sind, um einen Gessschäftsvorfall (z.B. einen konkreten Antrag) ergenbnisorientiert zu bearbeiten. Die Aktivitäten eines Geschäftsprozesses stehen gewöhnlich in zeitlichen und logischen Abhängigkeiten zueinander. |
| Siehe auch
Workflow [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 08:54:55 GMT+1,
[Anmerkungen/Kommentare]
|
| Geschäftsprozess [GPM] (G-763)
|
| Ein Geschäftsprozess ist eine Zusammenfassung einer Menge fachlich verwandter Geschäftsanwendungsfälle. Dadurch bildet ein Geschäftsprozess gewöhnlich eine Zusammenfassung von organisatorisch evtl. verteilten, fachlich jedoch zusammenhängenden Aktivitäten, die notwendig sind, um einen Geschäftsvorfall (z.B. einen konkreten Antrag) ergebnisorientiert zu bearbeiten. Die Aktivitäten eines Geschäftsprozesses stehen gewöhnlich in zeitlichen und logischen Abhängigkeiten zueinander. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:29:13 GMT+2,
[Anmerkungen/Kommentare]
|
| Geschäftsprozeß [OO allg.] (G-63)
|
Ein Geschäftsprozeß ist eine Zusammenfassung von organisatorisch evtl. verteilten, fachlich jedoch zusammenhängenden Aktivitäten, die notwendig sind, um einen Geschäftsvorfall (z.B. einen konkreten Antrag) ergebnisorientiert zu bearbeiten. Die Aktivitäten eines Geschäftsprozesses stehen gewöhnlich in zeitlichen und logischen Abhängigkeiten zueinander. Ein Geschäftsvorfall entsteht gewöhnlich durch ein Ereignis (z.B. Antragseingang) und hat mindestens ein sichtbares fachliches Ergebnis (z.B. einen Vertrag).
Im Unterschied zum Geschäftsprozeß beschreibt ein Anwendungsfall stets eine zeitlich ununterbrochene Interaktion eines oder mehrerer Akteure mit dem System. Ein Geschäftsprozeß kann also ein einer Menge von Anwendungsfällen bestehen. |
| Siehe auch
Workflow [GPM]
Geschäftsvorfall (Vorgang) [OO allg.]
Anwendungsfall [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Geschäftsprozessmodellierung [GPM] (G-765)
|
| Bei der Geschäftsprozessmodellierung werden Geschäftsprozesse analysiert und in abstrakter Form zur Veranschaulichung bildhaft oder textuell dargestellt. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:30:53 GMT+2,
[Anmerkungen/Kommentare]
|
| Geschäftsregel [GPM] (G-766)
|
| Eine Geschäftsregel ist die Beschreibung möglicher fachlicher Eigenschaften und Verhaltensweisen, die stets erfüllt sein sollen. Eine Geschäftsregel definiert Anforderungen an das modellierte Geschäft. |
| Siehe auch
Zusicherung [UML 1.4]
|
| Letzte Änderung von cj am 2003/04/08 15:31:48 GMT+2,
[Anmerkungen/Kommentare]
|
| Geschäftsvorfall [UML 2.0] (G-872)
|
| Ein Geschäftsvorfall bezeichnet das von einem konkreten, aktiven Geschäftspartner initiierte Ereignis, z.B. "Gabi Goldfisch beantragt eine Mitgliedschaft". Ein Auslöser kann mehrere Geschäftsvorfälle nach sich ziehen. Ereignisse, die innerhalb des Geschäftssystems entstehen, sind keine Geschäftsvorfälle. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 08:59:15 GMT+1,
[Anmerkungen/Kommentare]
|
| Geschäftsvorfall (Vorgang) [OO allg.] (G-64)
|
| Ein Geschäftsvorfall wird durch ein Ereignis (z.B. Antragseingang) ausgelöst und dann durch die definierten Aktivitäten eines Geschäftsprozesses bearbeitet. Während der Geschäftsprozeß eine abstrakte Beschreibung darstellt, ist ein Geschäftsvorfall eine konkrete Instanz und bezieht sich gewöhnlich auf ein oder mehrere konkrete Geschäftsobjekte (z.B. einen Vertrag). |
| Siehe auch
Geschäftsprozeß [OO allg.]
|
| Letzte Änderung von boe am 2000/04/14,
[Anmerkungen/Kommentare]
|
| Geschäftsvorgang [GPM] (G-767)
|
| Ein Geschäftsvorgang wird durch einen Geschäftsvorfall (z.B. Antragseingang) ausgelöst und dann durch die definierten Aktivitäten eines Geschäftsanwendungsfalles bearbeitet. Während der Geschäftsanwendungsfall eine abstrakte Beschreibung darstellt, ist ein Geschäftsvorgang eine konkrete Ausprägung (Instanz) davon. |
| Siehe auch
Geschäftsvorfall (Vorgang) [OO allg.]
|
| Letzte Änderung von cj am 2003/04/08 15:32:29 GMT+2,
[Anmerkungen/Kommentare]
|
| Gewinnerzielungsabsicht [GPM] (G-768)
|
| Womit beabsichtigt das Unternehmen bzw. die im Modellierungsfokus stehende Organisation Geld zu verdienen? Für gemeinnützige Organisationen ist die Gewinnerzielungsabsicht durch etwas entsprechendes zu ersetzen, beispielsweise „Beitrag zum festgelegten Gemeinnutz“ o.ä. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:54:06 GMT+2,
[Anmerkungen/Kommentare]
|
| GPM-Betrachtungsgegenstand [GPM] (G-771)
|
|
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 15:56:24 GMT+2,
[Anmerkungen/Kommentare]
|
| Granularität [Komponenten] (G-631)
|
| Das Verhältnis von Klassen/Komponente wird als Granularität bezeichnet. Eine fein-granulare
Komponente besteht aus einer oder nur sehr wenigen Klassen. Eine grob-granulare Komponente
besteht dagegen aus vielen Klassen und stellt ein komplettes Subsystem dar. |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:35:18 GMT+1,
[Anmerkungen/Kommentare]
|
| Grenzwertanalyse [Qualitätssicherung] (G-652)
|
| Gezielte Suche nach kritischen §Testdaten, den sog. Grenzwert en, die direkt auf oder aber direkt neben den Grenzen einer Äquivalenzklassen liegen. Kombinationen von Ein- und Ausgabewerten werden im Gegensatz zu Ursache/Wirkungs-Graphen nicht berücksichtigt. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 13:43:53 GMT+2,
[Anmerkungen/Kommentare]
|
| GUI [OO allg.] (G-65)
|
| Graphical User Interface, Grafische Benutzeroberfläche. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| GUI [Modewörterbuch] (G-717)
|
| Graphical User Interface |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:48:30 GMT+1,
[Anmerkungen/Kommentare]
|
| GUI [UML 2.0] (G-873)
|
| Graphical User Interface, Grafische Benutzeroberfläche |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 09:25:59 GMT+1,
[Anmerkungen/Kommentare]
|
| Hazard Analysis [Qualitätssicherung] (G-683)
|
| Untersuchung möglicher Unfälle, die durch das Versagen von System en eintreten können. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:40:50 GMT+2,
[Anmerkungen/Kommentare]
|
| Herstellungszeit [EmOO] (G-264)
|
| Die Zeitspanne zwischen dem Beginn der Produkterstellung und ihrem Ende, auch Projektdauer. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Heuristik [OEP] (G-265)
|
| Eine Heuristik ist eine wahrscheinlichkeitsbehaftete Regel, also eine sog. Daumen-Regeln, die nicht immer, aber in vielen oder den meisten Fällen zutrifft. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08,
[Anmerkungen/Kommentare]
|
| HI [Modewörterbuch] (G-719)
|
| Human Interface |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:49:17 GMT+1,
[Anmerkungen/Kommentare]
|
| Hilfsklasse [UML 2.0] (G-874)
|
| Hilfsklassen sind Sammlungen von globalen Variablen und Funktionen, die zu einer Klasse zusammengefaßt und dort als Klassenattribute und -operationen definiert sind. Insofern sind Hilfsklassen keine echten Klassen. Das Stereotyp «utility» kennzeichnet eine Klasse als Hilfsklasse. |
| Siehe auch
Stereotyp [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 09:26:22 GMT+1,
[Anmerkungen/Kommentare]
|
| Hilfsmittelklasse [UML 1.4] (G-484)
Alias für
utility [UML 1.4]
|
| Hilfsmittelklassen sind Sammlungen von globalen Variablen und Funktionen, die zu einer Klasse zusammengefaßt und dort als Klassenattribute und -operationen definiert sind. Insofern sind Hilfsmittelklassen keine echten Klassen. Das Stereotyp «utility» kennzeichnet eine Klasse als Hilfsmittelklasse. |
| Siehe auch
Klasse [OO allg.]
Stereotyp [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| HotSpot [Modewörterbuch] (G-718)
|
| Optimierungstechnologie für Java virtuelle Maschinen (VM). Häufig benutzte Stellen im Sourcecode werden zur Laufzeit in native Machinecode übersetzt und speziell optimiert. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:48:54 GMT+1,
[Anmerkungen/Kommentare]
|
| HTML [Modewörterbuch] (G-720)
|
| Hypertext Markup Language |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:49:40 GMT+1,
[Anmerkungen/Kommentare]
|
| HTTP [Modewörterbuch] (G-721)
|
| Hypertext Transfer Protocol |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:50:07 GMT+1,
[Anmerkungen/Kommentare]
|
| identifizieren [OO allg.] (G-596)
|
| Unter identifizieren wird der Vorgang verstanden, das Vorhandensein von etwas (einem Gegenstand, einem Konzept, einer Idee) zu erkennen und zu dokumentieren. Dies geschieht gewöhnlich dadurch, das dem Gegenstand oder der Idee ein eindeutiger unverwechselbarer Name gegeben wird. Dort wo ein Name alleine nicht ausreicht, um es eindeutig zu benennen ist ggf. eine kurze Beschreibung notwendig (Stichworte oder 1 - 2 Sätze). |
| Siehe auch
|
| Letzte Änderung von boe am 2001/03/03 10:54:15 GMT+1,
[Anmerkungen/Kommentare]
|
| IIOP [Modewörterbuch] (G-722)
|
| Internet Inter-ORB Protocol der OMG. Verbindet verteilte CORBA-Objekte über das Internet oder Intranet |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:50:27 GMT+1,
[Anmerkungen/Kommentare]
|
| IIOP [Komponenten] (G-629)
|
| Internet Inter Orb Protokoll. IIOP ist ein Kommunikationsprotokollstandard zwischen
Object Request Brokern. |
| Siehe auch
Corba [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:34:50 GMT+1,
[Anmerkungen/Kommentare]
|
| Inch-Pebble [OEP] (G-808)
Alias für
Checkpoint [OEP]
|
| Ein Inch-Pebble (Checkpoint) ist ein Zeitpunkt innerhalb einer Iteration, zu dem eine Menge zusammenlaufender Arbeitsaufträge synchronisiert wird. |
| Siehe auch
Meilenstein [OEP]
|
| Letzte Änderung von boe am 2003/04/10 14:26:54 GMT+2,
[Anmerkungen/Kommentare]
|
| Include-Beziehung [UML 1.4] (G-547)
Alias für
Enthalten-Beziehung [UML 1.4]
|
| Eine Beziehung zwischen Anwendungsfällen mit dem Stereotyp «include».
Eine Include-Beziehung zwischen Anwendungsfällen besagt, daß innerhalb eines Anwendungsfalles ein anderer vorkommt. Dieses Konstrukt dient dazu, Abschnitte, die in mehreren Anwendungsfällen gleichermaßen vorkommen, zu extrahieren, um so Redundanz zu vermeiden. |
| Siehe auch
Anwendungsfall [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Inkrement [OEP] (G-69)
|
| Ein Inkrement ist die Erweiterung eines Produktes. Ein Inkrement ist gewöhnlich gekennzeichnet durch die Differenz zwischen zwei Builds. Auch das Teilergebnis, das innerhalb einer Iteration entstanden ist, wird Inkrement genannt. |
| Siehe auch
Build [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Inkrementelles Vorgehen [OEP] (G-267)
|
| Eine Vorgehensweise, bei der ein Produkt schrittweise in wachsenden Zwischenprodukten entsteht. |
| Siehe auch
Inkrement [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Inspektion [Qualitätssicherung] (G-684)
|
| Überprüfung eines System s nach dessen Fertigstellung. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:43:34 GMT+2,
[Anmerkungen/Kommentare]
|
| Instantiierung [UML 2.0] (G-877)
|
| ist das Erzeugen eines Exemplars aus einer Klasse. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 09:38:44 GMT+1,
[Anmerkungen/Kommentare]
|
| Instrumentierung [Qualitätssicherung] (G-685)
|
| Nachträgliche Veränderung eines Programmes, um durch zusätzliche Informationen einen Fehler finden zu können. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:44:13 GMT+2,
[Anmerkungen/Kommentare]
|
| Integration [OEP] (G-270)
|
| Zusammenfügen von Teilsystemen oder Komponenten zu einem Gesamtsystem. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Integrationstest [Qualitätssicherung] (G-686)
|
| Den §Systembau abschließender Test, der die gelungene Integration aller Teile eines System s prüft, jedoch keinen vollständigen Systemtest umfasst. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:45:54 GMT+2,
[Anmerkungen/Kommentare]
|
| Interaktionsübersicht [UML 2.0] (G-879)
|
| Eine Interaktionsübersicht ist ein Aktivitätsdiagramm in den Teilabläufe durch referenzierte oder eingebettete Sequenzdiagramme repräsentiert sind. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 09:40:30 GMT+1,
[Anmerkungen/Kommentare]
|
| Interface Definition Language [Komponenten] (G-612)
|
| Die Interface Definition Laguage ist eine Art Programmiersprache, in der die
Schnittstellen einer Corba Anwendung definiert werden. Diese Schnittstellen
Definition wird dann von einem IDL Compiler in die entsprechende Zielsprache
übersetzt (Java, C++, u.s.w.). |
| Siehe auch
Corba [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:25:23 GMT+1,
[Anmerkungen/Kommentare]
|
| Introventierter Geschäftsmitarbeiter [GPM] (G-773)
|
| Ein introvertierter Geschäftsmitarbeiter befindet sich innerhalb des Modellierungsfokusses und ist ein Akteur, die bei seiner Leistungserstellung keinen nach außen gerichteten Kontakt zu den Geschäftspartnern unterhält, zumindest nicht im gewählten Modellierungsfokus. |
| Siehe auch
Geschäftsmitarbeiter [GPM]
Extrovertierter Geschäftsmitarbeiter [GPM]
|
| Letzte Änderung von cj am 2003/04/08 15:59:37 GMT+2,
[Anmerkungen/Kommentare]
|
| Invariante [OO allg.] (G-75)
|
| Eine Eigenschaft oder ein Ausdruck, der über den gesamten Lebenszeitraum eines Elementes, bspw. eines Objektes gegeben sein muß. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Invariante [UML 2.0] (G-880)
|
| Eine Eigenschaft oder ein Ausdruck, der über den gesamten Lebenszeitraum eines Elementes, bspw. eines Objektes gegeben sein muß. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 09:41:46 GMT+1,
[Anmerkungen/Kommentare]
|
| ISO 9000 ff [Qualitätssicherung] (G-687)
|
| Aus vier Normen bestehender Normenverbund, der die Grundlage zur Sicherung von Qualität branchenunabhängig in Produktions- und Dienstleistungsbereichen festlegt. Die ISO 9000ff von 1994 wurde 2000 in einer überarbeiteten Version erweitert und neu festgelegt. In einer Übergangszeit bis 2003 galten beide Varianten parallel. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:48:58 GMT+2,
[Anmerkungen/Kommentare]
|
| Iteration [OEP] (G-76)
|
| Eine Iteration ist ein in ähnlicher Weise mehrfach vorkommender Zeitabschnitt in einem Prozess. Iterationen können Timeboxen sein. Eine Iteration entsteht durch die zeitliche Einteilung des Entwicklungsprozesses in mehrere gleichartige Zeitabschnitte (Iterationen). Innerhalb jeder Iteration wird gewöhnlich ein Mikroprozess durchlaufen (Analyse - Design - Implementierung - Test). |
| Siehe auch
Inkrement [OEP]
Timebox [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Iteratives Vorgehen [OEP] (G-77)
|
| Ein Vorgehen, bei dem der Entwicklungsprozesses in mehrere gleichartige Zeitabschnitte (Iterationen) geteilt wird. |
| Siehe auch
Iteration [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| J2DKEE [Modewörterbuch] (G-726)
|
| J2EE plus Entwicklertools |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:52:27 GMT+1,
[Anmerkungen/Kommentare]
|
| J2DKME [Modewörterbuch] (G-727)
|
| J2ME plus Entwicklertools |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:52:52 GMT+1,
[Anmerkungen/Kommentare]
|
| J2EE [Modewörterbuch] (G-723)
|
| Java 2 Enterprise Edition. Framework und Referenzimplementierung für EJB Application Server. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:50:47 GMT+1,
[Anmerkungen/Kommentare]
|
| J2ME [Modewörterbuch] (G-724)
|
| Java 2 Mobile Edition. Bibliotheken und Werkzeuge für java in Kleinsystemen (Handys, Organizer) |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:51:08 GMT+1,
[Anmerkungen/Kommentare]
|
| J2SDK [Modewörterbuch] (G-725)
|
| J2SE plus Entwicklertools |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:51:35 GMT+1,
[Anmerkungen/Kommentare]
|
| J2SE [Modewörterbuch] (G-728)
|
| Java 2 Standard Edition. Basisklassen (JDK), Java-Laufzeitumgebung |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:53:18 GMT+1,
[Anmerkungen/Kommentare]
|
| JAR [Modewörterbuch] (G-733)
|
| JAR-Archive fassen Java-Klassen und weitere Ressourcen in einer komprimierten Datei zusammen. Dateiformat identisch mit ZIP-Dateien. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:55:21 GMT+1,
[Anmerkungen/Kommentare]
|
| JavaBeans [Komponenten] (G-616)
|
| Eine JavaBean ist eine wiederverwendbare Softwarekomponenten mit einem definierten Interface
um z.B. von einer Entwicklungsumgebung visuell werden zu können. JavaBeans werden meistens
als GUI-Komponenten implementiert, die bestimmte Anzeigefunktionen beinhalten. Es sind jedoch auch
JavaBeans ohne Visualisierungsfunktionalität möglich. |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:27:43 GMT+1,
[Anmerkungen/Kommentare]
|
| JavaBeans [Modewörterbuch] (G-729)
|
| plattformunabhängige Software-Komponenten. Hat nix mit EJB zu tun. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:53:41 GMT+1,
[Anmerkungen/Kommentare]
|
| Javadoc [Modewörterbuch] (G-730)
|
| Liest bestimmte javadoc-Tags aus dem Sourcecode und erzeugt daraus eine Documentation in z.B. HTML. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:54:10 GMT+1,
[Anmerkungen/Kommentare]
|
| JavaScript [Modewörterbuch] (G-731)
|
| Scriptsprache mit Java-vergleichbarer Syntax, aber kleinerem Umfang. Erfunden von Netscape. Wird benutzt um in HTML-Seiten dynamische Aspekte zu integrieren. Hat ansonsten wenig mit Java zu tun. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:54:34 GMT+1,
[Anmerkungen/Kommentare]
|
| JAX [Modewörterbuch] (G-732)
|
| Java API for XML. Einheitliches API, um unter Java auf XML zuzugreifen. Umfasst SAX und DOM. Auch Unterstütztung des Transfers von XML-Daten über HTTP, FTP und SMTP. |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:55:02 GMT+1,
[Anmerkungen/Kommentare]
|
| Jboss [Modewörterbuch] (G-734)
|
| Freier EJB Application Server |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:55:40 GMT+1,
[Anmerkungen/Kommentare]
|
| Jbuilder [Modewörterbuch] (G-735)
|
| Java-Entwicklungsumgebung inkl. GUI-Builder, Debugger und Build-Support |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:56:02 GMT+1,
[Anmerkungen/Kommentare]
|
| JCA [Modewörterbuch] (G-736)
|
| Java Connector Architecture. Host-Anbindung |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:56:26 GMT+1,
[Anmerkungen/Kommentare]
|
| JDBC [Modewörterbuch] (G-737)
|
| Java Database Connectivity. Anbindung an relationale Datenbanksysteme vis SQL |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:56:45 GMT+1,
[Anmerkungen/Kommentare]
|
| JDK [Modewörterbuch] (G-738)
|
| Java Development Kit. Älterer Name für J2SDK |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:57:25 GMT+1,
[Anmerkungen/Kommentare]
|
| JDO [Modewörterbuch] (G-739)
|
| Java Data Objects. Standard für transparente objektorientierte Persistenz implementiert durch z.B. Castor, TopLink, FastObjects |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:57:56 GMT+1,
[Anmerkungen/Kommentare]
|
| JFC [Modewörterbuch] (G-740)
|
| Java Foundation Classes. Enthält Swing, Collections und andere Basisklassen |
| Siehe auch
|
| Letzte Änderung von cj am 2002/11/18 11:58:15 GMT+1,
[Anmerkungen/Kommentare]
|
| JMS [Komponenten] (G-620)
|
| Java Messeging Service. JMS definiert einen Nachrichten-Dienst der den asyncronen Austausch von
Nachrichten zwischen verschiedenen Applikationsteilen ermöglicht. |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:31:04 GMT+1,
[Anmerkungen/Kommentare]
|
| JNDI [Komponenten] (G-624)
|
| Java Naming und Directory Interface. JNDI stellt dem Programmierer ein vereinheitlichtes Interface
zum Zugriff auf verschiedene Names- und Verzeichnisdienste zur Verfügung (LDAP,,NIS, DNS u.s.w.). |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:32:29 GMT+1,
[Anmerkungen/Kommentare]
|
| JTS [Komponenten] (G-621)
|
| Java Transaction Service. JTS spezifiziert die Implementation eines Transaktions-Managers,
der das "Java Transaction API" (JTA) unterstützt. Es handelt sich um die Java Variante des
"Object Transaction Service" aus der Corba Definition. |
| Siehe auch
Corba [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:31:29 GMT+1,
[Anmerkungen/Kommentare]
|
| Kern-Geschäftsanwendungsfall [GPM] (G-774)
|
| Ein Kern-Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, der von einem aktiven Geschäftspartner ausgelöst wird, ein Ergebnis von geschäftlichem Wert für mindestens einen aktiven Geschäftspartner erzeugt und direkt mit dem Unternehmenszweck und einer Gewinnerzielungsabsicht (bei gemeinnützigen Organisationen mit dem beabsichtigten Gemeinnutz) zusammenhängt. Eine zeitliche Kohärenz des Ablaufes wie bei einem Systemanwendungsfall ist nicht gefordert. In Kontrast zu den Kern-Geschäftsanwendungsfällen sind die unterstützenden Geschäftsanwendungsfälle zu sehen. In einem Handelsunternehmen ist der Verkauf von Waren gewöhnlich ein Kern-Geschäftsanwendungsfall, während beispielsweise die Finanzbuchhaltung oder der Wareneinkauf unterstützende Geschäftsanwendungsfälle darstellen. |
| Siehe auch
Geschäftsanwendungsfall [GPM]
Unterstützender Geschäftsanwendungsfall [GPM]
|
| Letzte Änderung von cj am 2003/04/08 16:01:15 GMT+2,
[Anmerkungen/Kommentare]
|
| Klasse [UML 2.0] (G-882)
|
| Eine Klasse ist die Definition der Attribute, Operationen und der Semantik für eine Menge von Objekten. Alle Objekte einer Klasse entsprechen dieser Definition. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 11:03:17 GMT+1,
[Anmerkungen/Kommentare]
|
| Klassenattibut, Klassenvariable [UML 2.0] (G-883)
|
| Klassenattribute gehören nicht einem einzelnen Objekt, sondern sind Attribut einer Klasse (gilt z.B. für Smalltalk). |
| Siehe auch
Attribut [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 11:04:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Klassenattribut [OO allg.] (G-508)
|
| Klassenattribute gehören nicht einem einzelnen Objekt, sondern sind Attribut einer Klasse und damit für alle Objekte dieser Klasse zugänglich. Einige Programmiersprachen unterstützen Klassenattribute direkt (z. B. Smalltalk), in anderen kann ein vergleichbarer Effekt erzielt werden (z. B. Static-Deklaration in C++). |
| Siehe auch
Klasse [OO allg.]
Attribut [OO allg.]
Objekt [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Klassenbibliothek [OO allg.] (G-80)
|
| Eine Klassenbibliothek ist eine Sammlung von Klassen. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Klassenbibliothek [UML 2.0] (G-884)
|
| Eine Klassenbibliothek ist eine Sammlung von Klassen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 11:04:48 GMT+1,
[Anmerkungen/Kommentare]
|
| Klassendiagramm [UML 2.0] (G-885)
|
| Ein Klassendiagramm zeigt eine Menge statischer Modellelemente, vor allem Klassen und ihre Beziehungen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 11:05:41 GMT+1,
[Anmerkungen/Kommentare]
|
| Klassenkarte [OO allg.] (G-512)
Alias für
CRC-Karten [OO allg.]
|
| Wird häufig gleichgesetzt mit CRC-Karte, kann jedoch von dieser dadurch unterschieden werden, daß Klassenkarten eher dem Lösungsraum zugeordnet sind und die Auflistung von Funktionalität (Operationen) und Daten (Attribute) in den Vordergrund stellt, während CRC-Karten eher dem Problemraum zuzuordnen sind, fachliche Begrifflichkeiten definieren und Verantwortlichkeiten und Beteiligte beschreiben. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Klassenmodell [UML 2.0] (G-886)
|
| Ein Klassenmodell beschreibt, wel-che Klassen existieren und in wel-chen Beziehungen sie zueinander stehen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 11:06:34 GMT+1,
[Anmerkungen/Kommentare]
|
| Klassenoperation [OO allg.] (G-509)
|
| Klassenoperationen sind Operationen, die nicht auf einem Objekt, sondern auf einer Klasse operieren. Dies ist sinnvoll für Sprachen, in denen Klassen wiederum durch normale Objekte repräsentiert werden, z. B. Smalltalk. |
| Siehe auch
Klasse [OO allg.]
Operation [UML 1.4]
Objekt [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Klassenoperation [UML 2.0] (G-887)
|
| Klassenoperationen sind Operationen, die nicht auf einem Objekt, sondern auf einer Klasse operieren (gilt z.B. für Smalltalk). |
| Siehe auch
Operation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 12:22:42 GMT+1,
[Anmerkungen/Kommentare]
|
| Knoten [UML 1.4] (G-82)
Alias für
node [UML 1.4]
|
| Ein Knoten ist ein physisches Laufzeit-Objekt, das über Rechnerleistung (Prozessor, Speicher) verfügt. Laufzeitobjekte und Komponenten können auf Knoten residieren. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Knoten [UML 2.0] (G-888)
|
| Ein Knoten ist ein physisches Laufzeit-Objekt, das über Rechnerleistung (Prozessor, Speicher) verfügt. Laufzeitobjekte und Komponenten können auf Knoten residieren. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 12:24:39 GMT+1,
[Anmerkungen/Kommentare]
|
| Kohärenz [OEP] (G-775)
|
| Zusammenhang, Zusammengehörigkeit |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 16:16:08 GMT+2,
[Anmerkungen/Kommentare]
|
| Kollaboration [UML 2.0] (G-889)
|
| Eine Kollaboration ist der Kontext einer Menge von Interaktionen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 12:25:39 GMT+1,
[Anmerkungen/Kommentare]
|
| Kommunikationsdiagramm [UML 2.0] (G-890)
|
| Ein Kommunikationsdiagramm zeigt eine Menge von Interaktionen zwischen ausgewählten Objekten in einer bestimmten begrenzten Situation (Kontext) unter Betonung der Beziehungen zwischen den Objekten und ihrer Topographie. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 12:26:21 GMT+1,
[Anmerkungen/Kommentare]
|
| Komponente [OEP] (G-587)
|
Eine Komponente ist ein unabhängig verwendbares Stück Software, bestehend aus einer Schnittstelle, einem Typmodell, einer Implementierung und einem Executable.
Komponenten bestehen wiederum aus einer Menge von Klassen. Während Klassen gewöhnlich eine Vielzahl von Beziehungen (vor allem Assoziationen) untereinander haben und dadurch voneinander abhängig sind, sind Komponenten voneinander unabhängig. Anstelle von Assoziationen kommunizieren Komponenten durch einen Beobachter-Mechanismus (Observer- bzw. Publish/Subscribe-Pattern).
Jede Komponente sellt eine funktionale Schnittstelle bereit, die definiert ist durch eine Schnittstellenklasse,
Vor- und Nachbedingungen, Invarianten sowie der Beschreibung möglicher Ausnahmen/Fehler (Exceptions).
Alle in der Schnittstellenbeschreibung vorkommenden Typen werden in einem Typmodell explizit definiert. Für jeden Typ werden die sichtbaren Attribute, Operationen, Zusicherungen und Beziehungen notiert. Zusätzliche Zusicherungen im Typmodell beschreiben die übergreifende, d.h. komponentenweite und die typspezfische Integrität der exportierten Objekte. Die Typen werden komponentenintern durch Klassen realisiert. |
| Siehe auch
Komponente [UML 1.4]
Klasse [OO allg.]
Typ [UML 1.4]
|
| Letzte Änderung von boe am 1999/12/30 15:05:29 GMT+1,
[Anmerkungen/Kommentare]
|
| Komponente [UML 1.4] (G-85)
Alias für
component [UML 1.4]
|
| Eine Komponente ist ein ausführbares Softwaremodul mit eigener Identität und wohldefinierten Schnittstellen (Sourcecode, Binärcode, DLL oder ausführbares Programm). Außerhalb der UML wird Komponente häufig anders, mehr im Sinne eines Paket definiert. |
| Siehe auch
Paket [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Komponente [UML 2.0] (G-891)
|
| (UML: component)
Eine Komponente ist eine fachliche Einheit, mit einer intern aus Klassen oder wiederum Komponenten bestehenden Struktur. Nach außen stellt eine Komponente Funktonalität über Schnittstellen bereit oder fordert Funktionalität über Schnittstellen an. Ein wesentliches Merkmal für Komponenten ist ihre prinzipielle Austauschbarkeit zur Laufzeit. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 12:27:31 GMT+1,
[Anmerkungen/Kommentare]
|
| Komponentendiagramm [UML 2.0] (G-892)
|
| Ein Komponentendiagramm zeigt die Organisation und Abhängigkeiten von Komponenten. |
| Siehe auch
Komponente [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 12:28:23 GMT+1,
[Anmerkungen/Kommentare]
|
| Komposition [UML 2.0] (G-893)
|
| Eine Komposition ist eine strenge Form der Aggregation, bei der die Teile vom Ganzen existenzabhängig sind. |
| Siehe auch
Aggregation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 12:29:14 GMT+1,
[Anmerkungen/Kommentare]
|
| Kompositionsstruktur [UML 2.0] (G-894)
|
| Ein Kompositionsstrukturdiagramm zeigt die interne Zusammensetzung und die Gruppierung von Schnittstellen einer Komponente oder Klasse. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/10 12:29:53 GMT+1,
[Anmerkungen/Kommentare]
|
| Konfigurationseinheit [EmOO] (G-285)
|
| Eine Konfigurationseinheit nennt man jeden einzeln versionierten und verwalteten Teil einer Software. In der Regel ist ein Entwickler für eine Konfigurationseinheit verantwortlich. |
| Siehe auch
Konfigurationsmanagement [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Konfigurationskontrolle [Qualitätssicherung] (G-688)
|
| Identifizierung von Teilen eines System s zu Configuration Item s, Verfolgung von Änderungen und deren lückenlose Dokumentation. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:52:36 GMT+2,
[Anmerkungen/Kommentare]
|
| Konfigurationskontrollsystem [EmOO] (G-287)
|
| Konfigurationskontrollsystem nennt man die Menge der Verfahren, Mechanismen und Werkzeuge, mit denen Konfigurationseinheiten verwaltet werden. |
| Siehe auch
Konfigurationseinheit [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Konfigurationsmanagement [OEP] (G-1)
|
| Vorgehensweise zur Überwachung und Kontrolle der unvermeidlichen Programmänderungen. Sie erfordert eine Festlegung der System- und Programmbestandteile einschließlich der Dokumentation von Änderungsprozeduren, Programmversionen und Freigabeprozeduren sowie eine laufende Verfolgung des jeweiligen Programmstatus (insbesondere der Fehler). |
| Siehe auch
Konfigurationsverwaltung [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Konfigurationsmanagement [Qualitätssicherung] (G-689)
|
| Verwaltung aller systemrelevanten Komponenten einer bestimmten Konfiguration zu zusammengehörigen, eindeutigen Version en. Grundlage ist eine §Versionsverwaltung aller modifizierbarer Elemente (Configuration Item s) einer Konfiguration wie dem Quell-Code, genutzten Komponenten, spezieller Hardware, Dokumenten usw. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:53:56 GMT+2,
[Anmerkungen/Kommentare]
|
| Konfigurationsverwaltung [EmOO] (G-2)
|
| Die Konfigurationsverwaltung von Software ist die Gesamtheit der Verfahren zur eindeutigen Kennzeichnung der Konfiguration eines Softwaresystems zu bestimmten Zeitpunkten des Software-Lebenszyklus mit dem Zweck, alle Änderungen dieser Konfiguration systematisch zu überwachen, die Konsistenz des Softwaresystems sicherzustellen und jederzeit die Möglichkeit der Rückverfolgung anzubieten. |
| Siehe auch
Konfigurationsmanagement [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Konsistenzzusicherung [UML 2.0] (G-896)
|
| Eine Zusicherung zwischen mehreren Assoziationen, die teilweise redundante Sachverhalte repräsentieren. Die Zusicherung gibt die Konsistenzbedingung an. |
| Siehe auch
Zusicherung [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/10 12:32:05 GMT+1,
[Anmerkungen/Kommentare]
|
| Lastenheft [OEP] (G-573)
|
Ein Lastenheft beschreibt Funktionen, Leistungen und Schnittstellen eines zu beschaffenden oder zu entwickelnden Produktes für potenzielle Auftragnehmer, so dass diese den Gebrauchszweck und die Eigenschaften erkennen können, die für die Abgabe von Angeboten erforderlich sind.
Während das Lastenheft vor allem in der Angebotsphase relevant ist, ist das Pflichtenheft hingegen meistens ein Vertragsbestandteil. |
| Siehe auch
Pflichtenheft [OEP]
|
| Letzte Änderung von boe am 1999/09/18 13:50:09 GMT+2,
[Anmerkungen/Kommentare]
|
| Legacy System [OO allg.] (G-289)
|
| Synonym für ein schwer wartbares, schwer anpaßbares oder inkompatibles Alt-System. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Leitziel eines Unternehmens [GPM] (G-778)
|
| Das Leitziel des Unternehmens beschreibt mit einem Satz die Vision des Unternehmens. Es ist das an erster Stelle stehende und markanteste Ziel das das Unternehmen hat. Gewöhnlich ist es mit einer Kennzahl, d.h. einer messbaren Größe verknüpft. |
| Siehe auch
Leitbild eines Unternehmens [GPM]
|
| Letzte Änderung von cj am 2003/04/08 16:29:33 GMT+2,
[Anmerkungen/Kommentare]
|
| Lenkungsausschuss [EmOO] (G-698)
|
| Der Lenkungsauschuss ist ein regelmäßig zusammenkommendes Gremium dem Vertreter des Auftraggebers, des Auftragnehmers und die Projektleitung angehören, das die Aufgabe hat, den Projektverlauf zu kontrollieren und zu steuern und Entscheidungen zu treffen, die den Kompetenzbereich der Projektleitung übersteigen (Rahmenbedingungen, Projektziele, Projektumfang und Projektauftrag).
Der Lenkungsauschuss wird bspw. am Ende jeder Iteration über die geplanten und tatsächlichen Ergebnisse der Arbeitsaufträge ausführlich informiert und erhält so regelmäßig detaillierte Informationen über den Status und Fortschritt des Projektes. |
| Siehe auch
|
| Letzte Änderung von bst am 2002/08/23 09:17:15 GMT+2,
[Anmerkungen/Kommentare]
|
| Life Cycle [Qualitätssicherung] (G-690)
|
| Lebenszyklus von System von der Anforderungsanalyse zum Abnahmetest über die Wartung bis zur Außerbetriebnahme. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 15:58:47 GMT+2,
[Anmerkungen/Kommentare]
|
| Lines of Code (LOC) [Qualitätssicherung] (G-691)
|
| Sprachabhängige Metrik zur Bestimmung der Komplexität und des Umfanges von Computerprogrammen. Lines of Code werden dabei im sinne von Einzelstatements benutzt. |
| Siehe auch
Lines of Code (LOC) [EmOO]
|
| Letzte Änderung von uvi am 2001/05/10 16:00:27 GMT+2,
[Anmerkungen/Kommentare]
|
| Lines of Code (LOC) [EmOO] (G-290)
|
| LOC ist ein intrinsisches Maß für die Größe eines Software-Programms. LOC mißt die Zeilen der textuellen Quelle (nicht dagegen die Zahl der Anweisungen). Wichtig ist noch die Unterscheidung in Brutto-LOC (inklusive aller Kommentare und Leerzeilen) und Netto-LOC (exklusive aller Kommentare und Leerzeilen). |
| Siehe auch
Maß [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| LOC [Qualitätssicherung] (G-692)
|
|
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 16:02:53 GMT+2,
[Anmerkungen/Kommentare]
|
| Makroschätzung [EmOO] (G-291)
|
| Die Schätzung des Herstellungsaufwandes anhand globaler Parameter von Projekt und Produkt. Sie benutzt wesentlich die Produktgröße, um die Herstellungszeit und/oder die notwendige Projektbesetung zu prognostizieren. Eine Makroschätzung setzt also eine Produktschätzung voraus. |
| Siehe auch
Schätzung [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Maß [EmOO] (G-292)
|
| Ein Maß dient dazu, Größen und Mengen festzustellen. Bei der Messung der Produktgröße von Software unterscheidet man zwischen intrinsischen und extrinsischen Maßen. Intrinsische Maße beziehen sich auf innere, von der Software-Produktionsumgebung abhängige Eigenschaften und sind deshalb nicht zwischen verschiedenen Umgebungen übertragbar. Extrinsische oder äußere Maße abstrahieren davon. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Meilenstein [OEP] (G-294)
|
| Ein Meilenstein definiert einen Termin, zu dem eine Menge von Ergebnissen in vorgegebener Detaillierung und Vollständigkeit nachprüfbar und formal dokumentiert vorliegen muss. Liegen die Ergebnisse zum geplanten Termin nicht vor, wird der Meilenstein verschoben. Ein Meilenstein ist ein Hilfsmittel zur Planung und Überwachung eines Entwicklungsprozesses. |
| Siehe auch
Phase [OEP]
Inch-Pebble [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Mengenverarbeitung [UML 2.0] (G-899)
|
| Ein Mengenverarbeitungsbereich ist ein zusammenhängender Teilbereich eines Aktivitätsdiagrammes über dessen Grenze mengenwertige Objektknoten fließen, deren Einzelelemente innerhalb des Bereiches nebenläufig oder sequenziell verarbeitet werden. |
| Siehe auch
|
| Letzte Änderung von chq am 2003/11/12 13:46:48 GMT+1,
[Anmerkungen/Kommentare]
|
| Message Driven Bean [Komponenten] (G-623)
|
| Die Enterprise JavaBeans Spezifikation führt ab der Version 2.0 einen neuen
Bean Typ ein. Eine Message Driven Bean ist ein Empfänger für asyncrone JMS Nachrichten.
Message Driven Beans haben keinen Zustand. Verschiedene Instanzen sind von aussen
nicht unterscheidbar. |
| Siehe auch
Enterprise Java Beans [Komponenten]
JMS [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:31:59 GMT+1,
[Anmerkungen/Kommentare]
|
| Message Oriented Middleware [Komponenten] (G-619)
|
|
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:30:38 GMT+1,
[Anmerkungen/Kommentare]
|
| Messung [EmOO] (G-295)
|
| Die Bestimmung einer Größe oder Menge durch Vergleich mit einem Maß. Das Ergebnis einer Messung wird als Produkt von Maßzahl und Maß angegeben. |
| Siehe auch
Maß [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Metaklasse [UML 2.0] (G-900)
|
| Eine Metaklasse ist eine Klasse, deren Exemplare wiederum Klassen sind. Dieses Konzept existiert nur in einigen objektorientierten Sprachen (z.B. in Smalltalk). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 13:53:47 GMT+1,
[Anmerkungen/Kommentare]
|
| Metaklasse [OO allg.] (G-462)
|
| Eine Metaklasse ist eine Klasse, deren Exemplare wiederum Klassen sind. Dieses Konzept existiert nur in einigen objektorientierten Sprachen (z. B. in Smalltalk). |
| Siehe auch
Klasse [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Metamodell [OO allg.] (G-96)
|
| Ein Modell, das die Sprache definiert, mit der ein Modell definiert werden kann. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Metamodell [UML 2.0] (G-901)
|
| Ein Modell, das die Sprache definiert, mit der ein Modell definiert werden kann. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 13:54:32 GMT+1,
[Anmerkungen/Kommentare]
|
| Metatyp [UML 1.4] (G-519)
|
| Ein Metatyp ist ein Typ (eine Klasse), dessen Instanzen Untertypen (Unterklassen) eines anderen Typs (einer anderen Klasse) darstellen. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Metatyp [UML 2.0] (G-902)
|
| Ein Metatyp ist ein Typ (eine Klas-se), dessen Instanzen Untertypen (Unterklassen) eines anderen Typs (einer anderen Klasse) sind. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 13:55:12 GMT+1,
[Anmerkungen/Kommentare]
|
| Methode [UML 2.0] (G-903)
|
| Eine Methode implementiert eine Operation, sie ist eine Sequenz von Anweisungen. Für die Praxis ist es unkritisch, Methode und Operation synonym zu verwenden. |
| Siehe auch
Operation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 13:56:07 GMT+1,
[Anmerkungen/Kommentare]
|
| Methode [OEP] (G-97)
|
| Eine Methode ist eine Handlungsvorschrift, die beschreibt, wie ein Ziel bzw. Ergebnis unter gegebenen Bedingungen erreicht werden kann. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Methode [UML 1.4] (G-98)
|
| In der UML wird eine Methode als Implementierung einer Operation definiert. Für die Praxis ist es unkritisch, Methode und Operation synonym zu verwenden. In Smalltalk werden Operationen Methoden genannt. |
| Siehe auch
Operation [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Methodik, Methode [GPM] (G-779)
|
| Eine Methode ist eine Handlungsvorschrift die beschreibt, wie ein Ziel bzw. Ergebnis unter gegebenen Bedingungen erreicht werden kann. Methode und Methodik sind synonym zu verwenden. Methodik klingt bedeutsamer. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 16:31:06 GMT+2,
[Anmerkungen/Kommentare]
|
| Metrik [EmOO] (G-301)
|
| Eine Meßmethode. Zu einer Metrik oder Meßmethode gehört ein Maß und eine Anleitung, wie bei der Messung zu verfahren ist. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Metrik [Qualitätssicherung] (G-693)
|
| Normiertes Messsystem zum Vergleich bestimmter Eigenschaften komplexer System e. |
| Siehe auch
Metrik [EmOO]
|
| Letzte Änderung von uvi am 2001/05/10 16:03:34 GMT+2,
[Anmerkungen/Kommentare]
|
| Modell [OEP] (G-780)
|
| Ein Modell ist ein Abbild einer konkreten Sache in vereinfachter Form mit dem Ziel, etwas zu veranschaulichen und zu einem besseren Verständnis beizutragen. Innerhalb eines Modellierungswerkzeuges (z.B. für UML) wird als Modell die Summe aller gespeicherten Informationen angesehen. Einzelne Diagramme repräsentieren grafisch einen bestimmten Ausschnitt dieses Modells. Nicht jede Modellinformation muss dabei in einem Diagramm enthalten sein. Eine Modellinformation kann jedoch in verschiedenen Diagrammen enthalten sein. |
| Siehe auch
Diagramm [OEP]
|
| Letzte Änderung von cj am 2003/04/08 16:31:59 GMT+2,
[Anmerkungen/Kommentare]
|
| Modellierungsfokus [GPM] (G-782)
|
| Mit dem Modellierungsfokus wird abgegrenzt welche Teile einer Organisation oder einer Gemeinschaft von Organisationen in der Geschäftsprozessmodellierung betrachtet werden sollen und welche nicht. Daher wird dieser Bereich auch Betrachtungsgegenstand genannt. Da in vielen Fällen der Modellierungsbereich auf ein einzelnes Unternehmen beschränkt ist, wird vereinfachend auch vom betrachteten Unternehmen oder vom zu modellierenden Unternehmen gesprochen. Zum Modellierungsfokus gehören alle direkt zu betrachteten Teile eines Organisationsgebildes und deren unmittelbar angrenzenden (außerhalb stehenden) Akteure. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 16:33:55 GMT+2,
[Anmerkungen/Kommentare]
|
| Moderator Pattern [Komponenten] (G-617)
|
| Um eine möglichst lose Kopplung zwischen Komponenten zu erreichen und damit eine
Austauschbarkeit zu gewährleisten, werden Komponenten meist durch einen Moderator
mit einander verbunden. |
| Siehe auch
Entwurfsmuster [OO allg.]
|
| Letzte Änderung von gl am 2001/03/05 10:28:30 GMT+1,
[Anmerkungen/Kommentare]
|
| Modul [Qualitätssicherung] (G-694)
|
| Im jeweiligen Betrachtungsmaßstab sinnvolle kleinste Einheit eines System s (eine sehr umfassende und eher pragmatische Definition). |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 16:07:47 GMT+2,
[Anmerkungen/Kommentare]
|
| Modultest [Qualitätssicherung] (G-695)
|
| White-Box-Test der Systementwicklung von einzelnen, funktionsfähigen Teilen. Diese können je nach Bedarf auf Methoden-, Klassen-, Paket-, Komponenten- oder Systemebene erfolgen (Die Begriffe Modul und System sind dabei sehr umfassend und pragmatisch gefasst.). |
| Siehe auch
White-Box-Test [Qualitätssicherung]
|
| Letzte Änderung von uvi am 2001/05/10 16:10:11 GMT+2,
[Anmerkungen/Kommentare]
|
| Multiple Klassifikation [UML 2.0] (G-904)
|
| Ein Objekt ist zur gleichen Zeit Instanz mehrerer Klassen (nicht mög-lich in C++, Java und Smalltalk) |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 13:56:39 GMT+1,
[Anmerkungen/Kommentare]
|
| Multiple Vererbung [UML 2.0] (G-905)
|
| Eine Klasse hat mehrere direkte Oberklassen (nicht möglich in Java und Smalltalk). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 13:57:29 GMT+1,
[Anmerkungen/Kommentare]
|
| Multiplizität [UML 2.0] (G-906)
|
| Bereich erlaubter Kardinalitäten. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 13:58:19 GMT+1,
[Anmerkungen/Kommentare]
|
| Mutationstest [Qualitätssicherung] (G-696)
|
| Test zur Güte eines Systemtest s oder Modultest s, also jedes Testfall es selber. Dazu wird die zu testende Software verändert (mutiert) und die Tests werden erneut durchgeführt. Die Testfälle sollten alle Veränderungen finden, ansonsten ist die §Testabdeckung oder aber die Aussagekraft der Testfälle zu gering. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 16:13:56 GMT+2,
[Anmerkungen/Kommentare]
|
| Nachbedingung [UML 2.0] (G-907)
|
| Eine Nachbedingung beschreibt einen Zustand, der nach Abschluß einer Tätigkeit, Aktivität, Operation o.ä. gegeben sein muss. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 13:59:03 GMT+1,
[Anmerkungen/Kommentare]
|
| Nachbedingung [OO allg.] (G-103)
|
| Eine Nachbedingung beschreibt einen Zustand, der nach Abschluss einer Tätigkeit, Aktivität, Operation o.ä. gegeben sein muss. |
| Siehe auch
Vorbedingung [OO allg.]
|
| Letzte Änderung von cj am 2003/04/08,
[Anmerkungen/Kommentare]
|
| Nachricht [UML 2.0] (G-908)
|
| Nachrichten sind ein Mechanismus, mit dem Objekte untereinander kommunizieren können. Eine Nachricht überbringt einem Objekt die Information darüber, welche Aktivität von ihm erwartet wird, d.h. eine Nachricht fordert ein Objekt zur Ausführung einer Operation auf. Eine Nachricht besteht aus einem Selektor (einem Namen), einer Liste von Argumenten und geht an genau einen Empfänger. Der Sender einer Nachricht erhält ggf. ein Antwort-Objekt zurück. Durch Polymorphismus kann eine Nachricht zum Aufruf einer von mehreren gleichlautenden Operationen führen. |
| Siehe auch
Operation [UML 2.0]
Methode [UML 2.0]
Polymorphismus [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 14:05:01 GMT+1,
[Anmerkungen/Kommentare]
|
| Nachricht [OO allg.] (G-104)
|
| Nachrichten sind ein Mechanismus, mit dem Objekte untereinander kommunizieren können. Eine Nachricht überbringt einem Objekt die Information darüber, welche Aktivität von ihm erwartet wird, d.h. eine Nachricht fordert ein Objekt zur Ausführung einer Operation auf. Eine Nachricht besteht aus einem Selektor (einem Namen), einer Liste von Argumenten und geht genau an einem Empfänger. Der Sender einer Nachricht erhält ggf. ein Antwort-Objekt zurück. Durch Polymorphismus kann eine Nachricht zum Aufruf einer von mehreren gleichlautenden Operation führen. |
| Siehe auch
Operation [UML 1.4]
Methode [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Navigation, Navigierbarkeit [UML 2.0] (G-909)
|
| Navigation ist die Betrachtung von Zugriffsmöglichkeiten auf Objekte (und ihre Attribute und Operationen) innerhalb eines Objektnetzes. Direkt navigierbar werden solche Zugriffe genannt, die ohne Umwege möglich sind. |
| Siehe auch
Navigationsangaben [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 14:06:17 GMT+1,
[Anmerkungen/Kommentare]
|
| Navigation, Navigierbarkeit [OO allg.] (G-105)
|
| Navigation ist die Betrachtung von Zugriffsmöglichkeiten auf Objekte (und ihre Attribute und Operationen) innerhalb eines Objektnetzes. Direkt navigierbar werden solche Zugriffe genannt, die ohne Umwege möglich sind. |
| Siehe auch
Navigationsangaben [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Navigationsangaben [UML 2.0] (G-910)
|
| Navigationsangaben sind Spezifikationen zur Navigation, d.h. Beschreibungen von Zugriffspfaden und -einschränkungen und der daraus resultierenden Zugriffsergebnisse (beispielsweise mit Hilfe der OCL) |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 14:12:35 GMT+1,
[Anmerkungen/Kommentare]
|
| Nebenläufigkeit [OO allg.] (G-107)
|
| Zwei oder mehr Aktivitäten werden zeitgleich (parallel) ausgeführt. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Nebenläufigkeit [UML 2.0] (G-911)
|
| Zwei oder mehr Aktionen können zeitgleich (parallel) ausgeführt werden. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 14:13:35 GMT+1,
[Anmerkungen/Kommentare]
|
| Norm [OEP] (G-305)
|
| Eine Norm ist die Vorgabe eines Handlungsmusters, das befolgt, oder einer Qualität, die eingehalten werden muss. Sie dient dazu, unabhängig voneinander entstehende Artefakte mit einheitlichen Eigenschaften oder Qualitäten herzustellen. |
| Siehe auch
Richtlinie [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Notiz [UML 1.4] (G-110)
|
| Kommentare bzw. Annotationen zu einem Diagramm oder einem oder mehreren beliebigen Modellelementen ohne semantische Wirkung. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Notiz [UML 2.0] (G-912)
|
| Kommentare bzw. Annotationen zu einem Diagramm oder einem oder mehreren beliebigen Modellelementen ohne semantische Wirkung. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 14:14:23 GMT+1,
[Anmerkungen/Kommentare]
|
| Oberklasse, Superklasse [UML 2.0] (G-913)
|
| Eine Oberklasse ist eine Verallgemeinerung ausgewählter Eigenschaften ihrer Unterklasse(n). |
| Siehe auch
Generalisierung [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 14:14:55 GMT+1,
[Anmerkungen/Kommentare]
|
| Object Engineering Process (OEP) [OEP] (G-311)
|
| Der OEP ist ein seit Mitte der 1990er Jahre existierendes Vorgehensmodell und Leitfaden zur agilen objektorientierten Softwareentwicklung, basierend auf UML und Unified Process. Siehe http://www.oose.de/oep. Wurde 2006 umbenannt in oose Engineering Process (OEP). |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08,
[Anmerkungen/Kommentare]
|
| Objekt [OO allg.] (G-112)
|
| Ein Objekt ist eine konkret vorhandene und agierende Einheit mit eigener Identität und definierten Grenzen das Zustand und Verhalten kapselt. Der Zustand wird repräsentiert durch die Attribut und Beziehungen, das Verhalten durch Operationen bzw. Methoden. Jedes Objekt ist ein Exemplar (Synonym: Instanz) einer Klasse. Das definierte Verhalten gilt für alle Objekte einer Klasse gleichermaßen, ebenso die Struktur ihrer Attribute. Die Werte der Attribute sind jedoch individuell für jedes Objekt. Jedes Objekt hat eine eigene, von seinen Attributwerten unabhängige, nicht veränderbare Identität. |
| Siehe auch
Attribut [OO allg.]
Operation [UML 1.4]
Objektverbindung [UML 1.4]
Objektidentität [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Objekt [UML 2.0] (G-915)
|
| Ein Objekt ist eine im laufenden System konkret vorhandene und agierende Einheit. Jedes Objekt ist Exemplar einer Klasse. |
| Siehe auch
Exemplar [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 14:55:40 GMT+1,
[Anmerkungen/Kommentare]
|
| Objektbasiert [UML 2.0] (G-916)
|
| Eine Programmiersprache oder Datenbank wird als objektbasiert bezeichnet, wenn sie das Konzept der Datenabstraktion unterstützt, weitergehende Konzepte wie Klassen, Vererbung, Polymorphie etc. aber teilweise oder vollständig fehlen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 14:57:56 GMT+1,
[Anmerkungen/Kommentare]
|
| Objektbeziehung [UML 2.0] (G-917)
|
| Eine konkrete Beziehung zwischen zwei Objekten, d.h. die Instanz einer Assoziation. Ein Objekt hat eine Beziehung zu einem anderen Objekt, wenn es eine Referenz darauf besitzt. Implementiert werden diese Referenzen gewöhnlich durch Attribute, was für die Modellierung jedoch unerheblich ist. |
| Siehe auch
Assoziation [UML 2.0]
Attribut [OO allg.]
|
| Letzte Änderung von ch am 2003/11/12 15:02:28 GMT+1,
[Anmerkungen/Kommentare]
|
| Objektdiagramm [UML 2.0] (G-918)
|
| Ein Objektdiagramm zeigt eine ähnliche Struktur wie das Klassendiagramm, jedoch statt der Klassen, exemplarisch eine Auswahl der zu einem bestimmten Zeitpunkt existierenden Objekte mit ihren augenblicklichen Werten. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:03:29 GMT+1,
[Anmerkungen/Kommentare]
|
| Objektidentität [OO allg.] (G-115)
|
| Objektidentität ist eine Eigenschaft, die ein Objekt von allen anderen unterscheidet, auch wenn es möglicherweise die gleichen Attributwerte besitzt. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Objektidentität [UML 2.0] (G-919)
|
| ist eine Eigenschaft, die ein Objekt von allen anderen unterscheidet, auch wenn es möglicherweise die gleichen Attributwerte besitzt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:04:31 GMT+1,
[Anmerkungen/Kommentare]
|
| Objektorientierte Programmiersprache [UML 2.0] (G-920)
|
| Objektorientierte Programmiersprachen erfüllen folgende Basiskonzepte:
·Objekte sind abstrakte Einheiten,
·Objekte sind Exemplare einer Klasse, d.h. von einer Klasse abgeleitet,
·die Klassen vererben ihre Eigenschaften und bilden so eineVererbungshierarchie,
·auf Objekte wird dynamisch verwiesen, d.h. die Bindung ist dynamisch und ermöglicht so Polymorphie. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:05:14 GMT+1,
[Anmerkungen/Kommentare]
|
| OMG [OO allg.] (G-315)
|
| OMG ist die Abkürzung für Object Management Group. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| OO [OO allg.] (G-314)
|
| OO ist die Abkürzung für Objektorientierung. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| OO [UML 2.0] (G-921)
|
| ist die Abkürzung für Objektorientierung. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:07:50 GMT+1,
[Anmerkungen/Kommentare]
|
| oose [OO allg.] (G-784)
|
| Abkürzung steht für objektorientierte Softwareentwicklung oder Object Oriented Software Engineering. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 16:38:46 GMT+2,
[Anmerkungen/Kommentare]
|
| oose Engineering Process [OEP] (G-1017)
Alias für
OEP [OEP]
|
| Der OEP ist ein seit Mitte der 1990er Jahre existierendes Vorgehensmodell und Leitfaden zur agilen objektorientierten Softwareentwicklung, basierend auf UML und Unified Process. Siehe http://www.oose.de/oep. Wurde 2006 umbenannt von Object Engineering Process in oose Enginering Process (OEP). |
| Siehe auch
|
| Letzte Änderung von boe am 2006/06/08 23:01:44 GMT+2,
[Anmerkungen/Kommentare]
|
| Operation [UML 1.4] (G-118)
|
| Operationen sind Dienstleistungen, die von einem Objekt mit einer Nachricht angefordert werden können, um ein bestimmtes Verhalten zu bewirken. Sie werden implementiert durch Methoden. In der Praxis werden Operation und Methode häufig synonym verwendet. |
| Siehe auch
Nachricht [OO allg.]
Methode [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Operation [UML 2.0] (G-922)
|
| Operationen sind Dienstleistungen, die von einem Objekt angefordert werden können, sie werden beschrieben durch ihre Signatur (Operationsname, Parameter, ggf. Rückgabetyp). |
| Siehe auch
Methode [UML 2.0]
Nachricht [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:08:54 GMT+1,
[Anmerkungen/Kommentare]
|
| Operativ, Operatives Ziel [GPM] (G-785)
|
| Als konkrete Maßnahme unmittelbar wirkend. Bezieht sich meist auf einen kürzeren Zeitraum. Ein operatives Ziel beschreibt einen gewünschten unmittelbare wirkenden Zustand. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/08 16:39:34 GMT+2,
[Anmerkungen/Kommentare]
|
| Ordnungszusicherung [UML 2.0] (G-924)
|
| Eine Zusicherung zu einer Assoziation, die angibt, daß ihre Elemente (Objektverbindungen) in bestimmter Weise geordnet sind. |
| Siehe auch
Zusicherung [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:18:19 GMT+1,
[Anmerkungen/Kommentare]
|
| Organisation [GPM] (G-786)
|
| Eine Organisation besteht aus Organisationseinheiten und strukturiert diese zielorientiert. Sie kann aufgabenbebezogen auch als ablauf- oder strukturbezogen als Aufbauorganisation in Form eines bildhaften Organigrammes dargestellt werden. |
| Siehe auch
Organisationseinheit [OEP]
|
| Letzte Änderung von cj am 2003/04/08 16:40:27 GMT+2,
[Anmerkungen/Kommentare]
|
| Organisationseinheit [OEP] (G-317)
|
| Eine Gruppe von Personen innerhalb eines Unternehmens, die eine definierte Rolle wahrnehmen. Die Organisationseinheit ist ein Element der Aufbauorganisation des Unternehmens. Die unterste Ebene ist gewöhnlich die Abteilung. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| OTS [Komponenten] (G-622)
|
| Object Transaction Service. Der OTS |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:31:39 GMT+1,
[Anmerkungen/Kommentare]
|
| Paket [UML 1.4] (G-119)
Alias für
package [UML 1.4]
|
| Pakete sind Ansammlungen von Modellelementen beliebigen Typs, mit denen das Gesamtmodell in kleinere überschaubare Einheiten gegliedert wird. Ein Paket definiert einen Namensraum, d.h. innerhalb eines Paketes müssen die Namen der enthaltenen Elemente sein. Jedes Modellelement kann in anderen Paketen referenziert werden, gehört aber zu genau einem (Heimat-) Paket. Pakete können wiederum Pakete beinhalten. Das oberste Paket beinhaltet das gesamte System. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Paket [UML 2.0] (G-925)
|
| Pakete sind Ansammlungen von Modellelementen beliebigen Typs, mit denen das Gesamtmodell in kleinere überschaubare Einheiten gegliedert wird. Ein Paket definiert einen Namensraum, d.h. innerhalb eines Paketes müssen die Namen der enthaltenen Elemente eindeutig sein. Jedes Modellelement kann in anderen Paketen referenziert werden, gehört aber zu genau einem (Heimat-) Paket. Pakete können wiederum Pakete beinhalten. Das oberste Paket beinhaltet das gesamte System. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:20:11 GMT+1,
[Anmerkungen/Kommentare]
|
| Parameter [UML 1.4] (G-424)
|
| Ein Parameter ist die Spezifikation einer Variablen, die Operationen, Nachrichten oder Ereignissen mitgegeben, von diesen verändert oder zurückgegeben wird. Ein Parameter kann aus einem Namen, einem Typ (einer Klasse) und einer Übergaberichtung (in, out, inout) bestehen. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Parameter [UML 2.0] (G-926)
|
| Ein Parameter ist die Spezifikation einer Variablen, die Operationen, Nachrichten oder Ereignissen mitgegeben, von diesen verändert oder zurückgegeben wird. Ein Parameter kann aus einem Namen, einem Typ (einer Klasse) und einer Übergaberichtung (in, out, inout) bestehen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:20:57 GMT+1,
[Anmerkungen/Kommentare]
|
| Parameterliste [UML 2.0] (G-929)
|
| Aufzählung der Namen von Argumenten sowie ggf. ihres Typs, Initialwertes u.ä. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:24:01 GMT+1,
[Anmerkungen/Kommentare]
|
| Parametrisierbare Klasse [UML 1.4] (G-480)
|
| Eine parametrisierbare Klasse ist eine mit generischen formalen Parametern versehene Schablone, mit der gewöhnliche (d.h. nicht-generische) Klassen erzeugt werden können. Die generischen Parameter dienen als Stellvertreter für die aktuellen Parameter, die Klassen oder einfache Datentypen repräsentieren. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Parametrisierbare Klasse [UML 2.0] (G-927)
|
| Eine parametrisierbare Klasse ist eine mit generischen formalen Parametern versehene Schablone, mit der gewöhnliche (d.h. nicht-generische) Klassen erzeugt werden können. Die generischen Parameter dienen als Stellvertreter für die aktuellen Parameter, die Klassen oder einfache Datentypen repräsentieren. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:21:39 GMT+1,
[Anmerkungen/Kommentare]
|
| Parametrisierte Klasse [UML 1.4] (G-481)
|
| Als parametrisierte Klasse wird die Instanz einer parametrisierbaren Klasse bezeichnet, d. h. das Ergebnis einer konkreten Parametrisierung. |
| Siehe auch
Parametrisierbare Klasse [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Parametrisierte Klasse [UML 2.0] (G-928)
|
| Als parametrisierte Klasse wird die Instanz einer Parametrisierbaren Klasse bezeichnet, d.h. das Ergebnis einer konkreten Parametrisierung. |
| Siehe auch
Parametrisierbare Klasse [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:23:02 GMT+1,
[Anmerkungen/Kommentare]
|
| Partition [UML 2.0] (G-930)
|
| Eine Partition (Verantwortlichkeits- bzw. Eigenschaftsbereich) beschreibt innerhalb eines Aktivitätsmodells, wer oder was für einen Knoten verantwortlich ist oder welche gemeinsame Eigenschaft sie kennzeichnet. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:24:53 GMT+1,
[Anmerkungen/Kommentare]
|
| Passiver Geschäftspartner [GPM] (G-787)
|
| Als passive Geschäftspartner werden Akteure bezeichnet, die außerhalb des Modellierungsfokusses (bzw. betrachteten Unternehmens) stehen und von Akteuren innerhalb des Modellierungsfokusses angesprochen werden. Passive Geschäftspartner reagieren auf ein geschäftliches Anliegen des betrachteten Unternehmens. Passive Geschäftspartner sind beispielsweise Lieferanten. |
| Siehe auch
Geschäftspartner [GPM]
|
| Letzte Änderung von cj am 2003/04/08 16:42:32 GMT+2,
[Anmerkungen/Kommentare]
|
| Persistentes Objekt [UML 2.0] (G-931)
|
| Persistente Objekte (persistent: lat. (anhaltend)) sind solche, deren Lebensdauer über die Laufzeit einer Programmsitzung hinausreicht. Die Objekte werden hierzu auf nichtflüchtigen Speichermedien (z.B. Datenbanken) gehalten. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:25:53 GMT+1,
[Anmerkungen/Kommentare]
|
| Persistentes Objekt [OO allg.] (G-122)
|
| Persistente Objekte (persistent: lat. "anhaltend") sind solche, deren Lebensdauer über die Laufzeit einer Programmsitzung hinausreicht. Die Objekte werden hierzu auf nichtflüchtigen Speichermedien (z.B. Datenbanken) gehalten. |
| Siehe auch
Transientes Objekt [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Persistenz [Komponenten] (G-613)
|
|
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:26:52 GMT+1,
[Anmerkungen/Kommentare]
|
| Pflichtenheft [OEP] (G-572)
Alias für
Anforderungsspezifikation [OEP]
|
Ein Pflichtenheft ist eine Anforderungsspezifikation für ein zu erstellendes Produkt. Es beschreibt Funktionen, Leistungen und Schnittstellen eines Produktes so weit, dass Auftragnehmer und Auftraggeber auf dieser Basis die Erfüllung der beschriebenen Eigenschaften nachweisen bzw. überprüfen können.
Während also das Lastenheft vor allem in der Angebotsphase relevant ist, ist das Pflichtenheft meistens ein Vertragsbestandteil. |
| Siehe auch
Lastenheft [OEP]
|
| Letzte Änderung von boe am 1999/09/18 13:49:17 GMT+2,
[Anmerkungen/Kommentare]
|
| Phase [OEP] (G-321)
|
| Eine Phase ist ein zeitlicher bzw. sachlogischer Gliederungsabschnitt eines Projektes. Eine Phase fasst eine Menge von Aktivitäten und Ergebnissen zu einer Planungs- und Kontrolleinheit zusammen. Am Ende jeder Phase steht ein Meilenstein, der die in der Phase zu erzielenden Inhalte definiert. |
| Siehe auch
Meilenstein [OEP]
Iteration [OEP]
Timebox [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Pilot, Pilotprojekt [OEP] (G-322)
|
| Ein Pilot ist ein mit einer bestimmten Verfahrensweise oder Architektur erstmals erstelltes vollständiges Ergebnis, mit dem gewöhnlich die Brauchbarkeit nachgewiesen werden soll. Während Prototyp nur ausgewählte Aspekte des endgültiges Produktes repräsentiert, ist ein Pilot ein vollständiges und rahmenbedingungskonformes Ergebnis. Ein Pilotprojekt ist ein Projekt, mit dem ein Pilot erstellt werden soll. |
| Siehe auch
Prototyp [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Polymorphismus [OO allg.] (G-125)
|
| Polymorphismus (Vielgestaltigkeit) heißt, daß gleichlautende Nachrichten an kompatible Objekte unterschiedlicher Klassen ein unterschiedliches Verhalten bewirken können. Beim dynamischen Polymorphismus wird eine Nachricht nicht zur Compilierzeit, sondern erst beim Empfang zur Programmlaufzeit einer konkreten Operation zugeordnet. Voraussetzung hierfür ist das dynamische Binden. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Polymorphismus [UML 2.0] (G-932)
|
| Polymorphismus (Vielgestaltigkeit) heißt, daß gleichlautende Nachrichten an kompatible Objekte unterschiedlicher Klassen ein unterschiedliches Verhalten bewirken können. Beim dynamischen Polymorphismus wird eine Nachricht nicht zur Compilierzeit, sondern erst beim Empfang zur Programmlaufzeit einer konkreten Operation zugeordnet. Voraussetzung hierfür ist das dynamische Binden. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:28:35 GMT+1,
[Anmerkungen/Kommentare]
|
| Primitive Datentypen [OO allg.] (G-543)
|
Primitive Datentypen fassen fachlich neutrale Basisfunktionalität zusammen, die in verschiedenen fachlichen Kontexten verwendet werden kann, beispielsweise Zeitraum, Geld oder Adresse. Es kann sich hierbei um solche handeln, die bereits durch die Programmiersprache und Entwicklungsumgebung bereitgestellt werden (String, Integer etc.) oder um solche, die unternehmens- bzw. projektspezifisch benötigt werden.
Primtive Datentypen unterscheiden sich von sonstigen Objekten dadurch, daß sie per Wert und nicht per Referenz weitergeleitet werden. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Problembereich [OEP] (G-127)
|
| Anwendungsgebiet bzw. Problembereich, innerhalb dessen die fachliche Modellierung stattfindet. Als Problembereichsmodell (Domänenmodell) wird in der Regel der Teil des Gesamtmodells verstanden, der sich auf den eigentlichen fachlichen Problembereich bezieht (auch fachliches Modell genannt). Technische, querschnittliche u. ä. Aspekte gehören nicht dazu. |
| Siehe auch
Domäne [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Problembereich [UML 2.0] (G-933)
|
| Anwendungsgebiet bzw. Problembereich, innerhalb dessen die fachliche Modellierung stattfindet. Als Problembereichsmodell (Domänenmodell) wird in der Regel der Teil des Gesamtmodells verstanden, der sich auf den eigentlichen fachlichen Problembereich bezieht (auch fachliches Modell genannt). Technische, querschnittliche u.ä. Aspekte gehören nicht dazu. Im Kontext von Anwendungsarchitektur ist zumeist das fachliche Klassenmodell gemeint (d.h. ohne Framework-, GUI-, Controler- u.ä. Klassen). |
| Siehe auch
Domäne [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:29:35 GMT+1,
[Anmerkungen/Kommentare]
|
| Produktivität [EmOO] (G-327)
|
| Produktivität ist der Quotient aus Produktgröße und Herstellungsaufwand. Da die Produktgröße extrinsisch oder intrinsisch angegeben werden kann, gibt es auch zwei "Arten" von Produktivität: Die intrinsische oder LOC-Produktivität und die "richtige" extrinsische Produktivität, die eine Messung der Produktgröße in Funktionspunkten oder Widgetpunkten voraussetzt. |
| Siehe auch
Lines of Code (LOC) [EmOO]
Widgetpunkte [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Produktkarton [OEP] (G-1015)
|
| Beschreibt den Namen, die Voraussetzungen und die Leistungen (Features) eines Produktes. |
| Siehe auch
|
| Letzte Änderung von CL am 2006/06/05 18:51:20 GMT+2,
[Anmerkungen/Kommentare]
|
| Projekt [OEP] (G-328)
|
| Ein Projekt ist ein einmaliges Vorhaben, das zeitlich, finanziell und personell begrenzt ist und zur Erreichung eines definierten Ziels geschaffen wird. Ein Projekt verfügt über eine projektspezifische Organisation. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Projektmanagement [OEP] (G-331)
|
| Gesamtheit der Aufgaben und Techniken zur Führung und Organisation eines Projektes. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Projektname [OEP] (G-1016)
|
| Der Projektname ist wichtig zur Identifikation der Beteiligten mit dem Projekt. |
| Siehe auch
|
| Letzte Änderung von cl am 2006/06/05 18:52:07 GMT+2,
[Anmerkungen/Kommentare]
|
| Projektorganisation [OEP] (G-332)
|
| Gesamtheit der Organisationseinheiten eines Projektes. Gewöhnlich setzt sich die Projektorganisation aus Bestandteilen der vorhandenen Betriebsorganisation zusammen. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Propagation [UML 2.0] (G-934)
|
| Ausdehnung der Eigenschaften einer Klasse durch Verwendung von
Operationen anderer Klassen. |
| Siehe auch
Delegation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:31:13 GMT+1,
[Anmerkungen/Kommentare]
|
| Protokoll [UML 2.0] (G-935)
|
| Eine Menge von Signaturen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:39:07 GMT+1,
[Anmerkungen/Kommentare]
|
| Protokollautomat [UML 2.0] (G-936)
|
| Ein Protokollautomat ist eine spezielle Form des Zustandsdiagrammes, dass dazu dient, lediglich die möglichen und verarbeitbaren Ereignisse ohne weitergehendes Verhalten zu beschreiben. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:39:47 GMT+1,
[Anmerkungen/Kommentare]
|
| Prototyp [OEP] (G-335)
|
| Ein Prototyp ist ein vorläufiges oder temporäres Produkt, mit dem ausgewählte Eigenschaften oder Aspekte des zu entwickelnden endgültigen Produktes erfahrbar und beurteilbar gemacht werden sollen. Prototypen können explorativ sein, d. h. zur Erforschung eines Sachverhaltes dienen, sie können experimentell sein, d. h. zur Überprüfung der Machbarkeit oder Funktionsfähigkeit dienen, oder evolutionär sein, d. h. vorab ein Teilprodukt bereitstellen. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Prozeßmodell [OEP] (G-134)
Alias für
Vorgehensmodell [OEP]
|
| Prozeßmodell kann gewöhnlich mit Vorgehensmodell gleichgesetzt werden, wobei der Begriff Vorgehensmodell häufiger für die Durchführung von Aktivitäten durch Menschen gebraucht wird und Prozeßmodell häufiger für die automatisierte Durchführung von Aktivitäten. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Qualifizierendes Attribut [UML 2.0] (G-937)
|
| Das Attribut, über welches in einer Assoziation der Zugriff auf die gegenüberliegende Seite erfolgt. Das qualifizierende Attribut ist definiert als Teil der Assoziation, jedoch muß in der Klasse, auf die darüber zugegriffen wird, dieses Attribut definiert sein. |
| Siehe auch
Qualifizierte Assoziation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:40:41 GMT+1,
[Anmerkungen/Kommentare]
|
| Qualifizierendes Attribut [UML 1.4] (G-135)
|
| Das Attribut, über welches in einer Assoziation der zugriff auf die gegenüberliegende Seite erfolgt. Das qualifizierende Attribut ist definiert als Teil der Assoziation, jedoch muß in der Klasse, auf die darüber zugegriffen wird, dieses Attribut definiert sein. |
| Siehe auch
Qualifizierte Assoziation [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Qualifizierte Assoziation [UML 2.0] (G-938)
|
| Eine qualifizierte Assoziation ist eine Assoziation, bei der die referenzierte Menge der Objekte durch qualifizierende Attribute in Partitionen unterteilt wird, wobei vom Ausgangsobjekt aus betrachtet jede Partition nur einmal vorkommen kann. |
| Siehe auch
Assoziation [UML 2.0]
Qualifizierendes Attribut [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:41:25 GMT+1,
[Anmerkungen/Kommentare]
|
| Qualifizierte Assoziation [UML 1.4] (G-404)
|
| Eine qualifizierte Assoziation ist eine Assoziation, bei der die referenzierte Menge der Objekte durch qualifizierende Attribute in Partitionen unterteilt wird, wobei vom Ausgangsobjekt aus betrachtet jede Partition nur einmal vorkommen kann. |
| Siehe auch
Qualifizierendes Attribut [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Qualitätsmanagement [OEP] (G-137)
|
| Qualitätsmanagement (QM) umfasst Managementaufgaben mit dem Ziel der Optimierung von Arbeitsabläufen oder von Geschäftsprozessen unter der Berücksichtigung vor allem qualitativer Aspekte. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Qualitätssicherung [OEP] (G-338)
|
| Maßnahmen, die zur Erlangung, Steigerung oder Kontrolle von Qualität beitragen. Dazu gehören planerische Maßnahmen, konstruktive Maßnahmen (Werkzeuge, Richtlinien, Konventionen etc.), analytische Maßnahmen (Test, Validierung, Verifizierung). |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Rahmenwerk [OO allg.] (G-144)
|
| Ein Rahmenwerk ist eine Menge kooperierender Klassen, die unter Vorgabe eines Ablaufes ("Don´t call the framework, the framework calls you") eine generische Lösung für eine Reihe ähnlicher Aufgabenstellungen bereitstellen. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Rahmenwerk [UML 2.0] (G-939)
|
| Ein Rahmenwerk ist eine Menge kooperierender Klassen, die unter Vorgabe eines Ablaufes (Don´t call the framework, the framework calls you) eine generische Lösung für eine Reihe ähnlicher Aufgabenstellungen bereitstellen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:42:35 GMT+1,
[Anmerkungen/Kommentare]
|
| Rational Unified Process (RUP) [OO allg.] (G-340)
|
| Ein objektorientiertes, UML-basiertes Vorgehensmodell, siehe [Kruchten98]. Kommerzielles Produkt der Fa. Rational Software. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Realisierung [UML 2.0] (G-940)
|
| Eine Realisierung ist eine Beziehung zwischen einem Element, das eine Anforderung beschreibt, und einem Element, das diese Anforderungen umsetzt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:43:28 GMT+1,
[Anmerkungen/Kommentare]
|
| Redundanz [OO allg.] (G-789)
|
| Lat. überreichlich, überflüssig. Bezeichnet gewöhnlich Dinge, die ohne Verlust entfallen können. Als redundanzfrei wird etwas bezeichnet, wenn jeder Sachverhalt (z.B. eine Anwendungsfallbeschreibung) nur genau einmal (im gesamten Anwendungsfallmodell) vorhanden ist. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09 08:07:20 GMT+2,
[Anmerkungen/Kommentare]
|
| Refaktorisierung [EmOO] (G-341)
|
| Umstrukturierung eines Systems zugunsten besserer Wart- oder Erweiterbarkeit ohne Änderung der Funktionalität. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Referentielle Integrität [UML 2.0] (G-941)
|
| Regel, die die Integrität von Objektbeziehungen beschreibt, vor allem für den Fall, daß eines der beteiligten Objekte oder die Objektverbindung selbst gelöscht werden sollen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:43:53 GMT+1,
[Anmerkungen/Kommentare]
|
| Referentielle Integrität [OO allg.] (G-146)
|
| Regel, die die Integrität von Objektbeziehungen beschreibt, vor allem für den Fall, daß eines der beteiligten Objekte oder die Objektverbindung selbst gelöscht werden sollen. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Regressionstest [EmOO] (G-343)
|
| Hiermit wird die Wiederholung früherer Tests bezeichnet. Er dient dazu, nachzuweisen, daß bereits zu einem früheren Zeitpunkt korrekt vorhandene Systemfunktionalität immer noch vorhanden ist, auch wenn zwischenzeitlich neue Funktionalität hinzugekommen ist. |
| Siehe auch
Test [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| rekursiv [OO allg.] (G-790)
|
| Selbstbezüglich, zurückgehend bis zu einem bekannten Punkt. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09 08:08:20 GMT+2,
[Anmerkungen/Kommentare]
|
| Remote Interface [Komponenten] (G-606)
|
| Dieses Interface enthält alle Methoden die von einer Enterpise JavaBean für Clients
zur Verfügung gestellt werden (Geschäftsmethoden). Diese Methoden sind per
RMI in einem verteilten Umfeld ansprechbar. |
| Siehe auch
RMI [Komponenten]
Enterprise Java Beans [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:22:41 GMT+1,
[Anmerkungen/Kommentare]
|
| Repository [OEP] (G-148)
|
| Zentrale Informationsablage. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Review [OEP] (G-347)
|
| Ein Review ist eine Sitzung zur kritischen Begutachtung des aktuellen Projektstands auf Basis repräsentativer (Teil-)Ergebnisse mit dem Ziel, den Status zu ermitteln und mögliche Beiträge zur weiteren Problemlösung aufzunehmen. |
| Siehe auch
Audit [OEP]
Inspektion [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Richtlinie [OEP] (G-348)
|
| Eine Richtlinie ist die Vorgabe eines Handlungsmusters, das befolgt, oder einer Qualität, die eingehalten werden sollte. Sie dient dazu, unabhängig voneinander entstehende Artefakt mit einheitlichen, ähnlichen oder vergleichbaren Eigenschaften oder Qualitäten herzustellen. |
| Siehe auch
Norm [OEP]
Artefakt [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Risiko [GPM] (G-791)
|
| Ein Risiko ist ein möglicher Verlust. Ein Risiko kann ausgedrückt werden durch die Wahrscheinlichkeit seines Auftretens und einer Schadenhöhe im Eintrittfall. Ein Risiko ist eine negative Chance. |
| Siehe auch
Chance [GPM]
|
| Letzte Änderung von cj am 2003/04/09 08:09:03 GMT+2,
[Anmerkungen/Kommentare]
|
| RMI [Komponenten] (G-630)
|
| Remote Method Invocation. RMI definiert ein Protokoll für Methodenaufrufe in anderen
Java virtual machines, die ggf. sogar auf anderen Rechnern laufen. |
| Siehe auch
|
| Letzte Änderung von gl am 2001/03/05 10:35:04 GMT+1,
[Anmerkungen/Kommentare]
|
| ROCE [GPM] (G-792)
|
| Gesamtkapitalrentabilität (Return on Capital Employed) |
| Siehe auch
ROI [GPM]
|
| Letzte Änderung von cj am 2003/04/09 08:09:48 GMT+2,
[Anmerkungen/Kommentare]
|
| ROI [GPM] (G-793)
|
| Abkürzung für Return on Investment. Der Return on Investment ist das, was aus dem Investment "zurückkehren" soll. Er drückt somit das Gewinnziel aus. Der Gewinn wird auf das investierte, betriebsnotwendige Vermögen bezogen. |
| Siehe auch
ROCE [GPM]
|
| Letzte Änderung von cj am 2003/04/09 08:10:43 GMT+2,
[Anmerkungen/Kommentare]
|
| Rolle [OEP] (G-407)
Alias für
Akteur [OEP]
|
| Eine Rolle ist ein abstrakter Platzhalter für jemanden, der an der Durchführung einer Aktivität mitwirkt, wobei ausgedrückt wird, in welcher Rolle er dabei mitwirkt. Der Begriff Rolle hat sich innerhalb von Vorgehensmodellen etabliert, während im Rahmen der Anwendungsfallanalyse eher von Akteuren die Rede ist. |
| Siehe auch
Aktivität [OEP]
Akteur [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Sammlung [OO allg.] (G-488)
|
| Sammlungen sind Objekte, die eine Menge anderer Objekte referenzieren und die Operationen bereitstellen, um auf diese Objekte zuzugreifen. |
| Siehe auch
Objekt [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Sammlung [UML 2.0] (G-942)
|
| Sammlungen sind Objekte, die eine Menge anderer Objekte referenzieren und die Operationen bereitstellen, um auf diese Objekte zuzugreifen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:45:10 GMT+1,
[Anmerkungen/Kommentare]
|
| Schätzung [EmOO] (G-392)
|
| Eine Schätzung ist eine Vorhersage, deren Eintrittswahrscheinlichkeit gleichermaßen über und unter dem tatsächlichen Ergebnis liegt. Man kann die Größe eines Produktes schätzen oder mit einer Projektschätzung den erforderlichen Aufwand zur Herstellung des Produktes. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Schnittstelle [OO allg.] (G-154)
|
| Schnittstellen beschreiben einen ausgewählten Teil des extern sichtbaren Verhaltens von Modellelementen (hauptsächlich von Klassen und Komponenten), d.h. eine Menge von Signaturen. |
| Siehe auch
Schnittstellenklassen [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Schnittstelle [UML 2.0] (G-943)
|
| Schnittstellen beschreiben mit einer Menge von Signaturen einen ausgewählten Teil des extern sichtbaren Verhaltens von Modellelementen (hauptsächlich von Klassen und Komponenten). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:46:08 GMT+1,
[Anmerkungen/Kommentare]
|
| Schnittstellenklassen [UML 1.4] (G-155)
|
| Schnittstellenklassen sind abstrakte Klassen (genauer: Typen), die ausschließlich abstrakte Operationen definieren. Schnittstellenklassen sind Klassen, die mit dem Stereotyp «interface» gekennzeichnet sind. Sie sind Spezifikationen des extern sichtbaren Verhaltens von Klassen und beinhalten eine Menge von Signatur für Operationen, die Klassen, die diese Schnittstelle bereitstellen wollen, implementieren müssen. |
| Siehe auch
Klasse [OO allg.]
Stereotyp [UML 1.4]
Operation [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Schnittstellenvererbung [UML 2.0] (G-944)
|
| Innerhalb einer Spezialisierungsbeziehung wird lediglich eine Schnittstelle vererbt. |
| Siehe auch
Schnittstelle [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:46:56 GMT+1,
[Anmerkungen/Kommentare]
|
| Sekundärer Anwendungsfall [OEP] (G-579)
|
In Abgrenzung zu normalen (primären) Anwendungsfällen sind mit sekundären Anwendungsfällen solche gemeint, die erst durch funktionale Zerlegung von Anwendungsfällen entstehen, d.h. durch die Anwendung von Generalisierungs-, Include- und Extend-Beziehungen.
Beispielsweise können mit Hilfe der Include-Beziehungen redundante Beschreibungen in Anwendungsfällen herausgelöst werden. Die so entstehenden Anwendungsfälle werden als sekundäre, mittelbare oder abgeleitete Anwendungsfälle bezeichnet. |
| Siehe auch
Anwendungsfall [UML 1.4]
Primärer Anwendungsfall [OEP]
Anwendungsfallmodell [UML 1.4]
|
| Letzte Änderung von boe am 1999/12/27 22:20:27 GMT+1,
[Anmerkungen/Kommentare]
|
| Sekundärer Anwendungsfall [UML 2.0] (G-945)
|
| Ein sekundärer Anwendungsfall ist ein Anwendungsfall, der einen unvollständigen Teilablauf beschreibt, der in gleichartiger Weise Teil meh-rerer Anwendungsfälle ist und deren Vollständigkeits- und Abgrenzungskriterien ggf. nicht erfüllt sind. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:47:36 GMT+1,
[Anmerkungen/Kommentare]
|
| Selbstdelegation [UML 2.0] (G-946)
|
| Zur Ausführung einer Operation wird eine Teilaufgabe an eine andere Operation der selben Klasse delegiert (d.h. ein Objekt sendet sich selbst eine Nachricht). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:48:40 GMT+1,
[Anmerkungen/Kommentare]
|
| self [OO allg.] (G-532)
|
| Self (Smalltalk) und this (Java, C++) sind vordefinierte Programmiersprachen-Schlüsslwörter. Mit self bzw. this kann ein Objekt sich selbst eine Nachricht senden, d. h. es ruft eine seiner eigenen Methoden auf. Nachrichten, die eine Objekt sich auf diesen Weg selbst sendet, werden genauso behandelt, wie solche von außen kommenden. |
| Siehe auch
Objekt [OO allg.]
Nachricht [OO allg.]
Methode [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Sequenzdiagramm [UML 2.0] (G-947)
|
| Eine Sequenz zeigt eine Reihe von Nachrichten, die eine ausgewählte Menge von Beteiligten (Objekten und Akteuren) in einer zeitlich begrenzten Situation austauscht, wobei der zeitliche Ablauf betont wird. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:50:42 GMT+1,
[Anmerkungen/Kommentare]
|
| Sequenzielles Vorgehen [OEP] (G-158)
|
| Vorgehensweise, bei der einzelne Aktivitäten nacheinander und nicht gleichzeitig bzw. nebeneinander durchgeführt werden. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Session Bean [Komponenten] (G-608)
|
| Session Beans sind eine von zwei möglichen Bean Arten der Enterprise JavaBean 1.x Spezifikation.
Session Beans beinhalten die geschäftliche Logik (die Anwendungsfälle) einer Anwendung. |
| Siehe auch
Enterprise Java Beans [Komponenten]
|
| Letzte Änderung von gl am 2001/03/05 10:23:25 GMT+1,
[Anmerkungen/Kommentare]
|
| Session-Bean [OO allg.] (G-590)
|
| Komponententyp der Komponentenarchitektur Enterprise JavaBeans. Session-Beans sind Geschäftsobjekte, die Abläufe oder Arbeitsflüsse (Workflows) repräsentieren. |
| Siehe auch
Entity-Bean [OO allg.]
|
| Letzte Änderung von boe am 2000/01/15 16:27:59 GMT+1,
[Anmerkungen/Kommentare]
|
| SEU [OO allg.] (G-160)
|
| Software-Entwicklungsumgebung |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Sichtbarkeitskennzeichen [UML 2.0] (G-949)
|
| schränken die Zugreifbarkeit von Attributen und Operationen ein (private, protected, public etc.). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:52:48 GMT+1,
[Anmerkungen/Kommentare]
|
| Signal [UML 2.0] (G-950)
|
| Ein empfangenes Signal ist die Benachrichtigung über ein zu beach-tendes Vorkommnis. Ein gesendetes Signal ist ein Vorkommnis über das benachrichtigt wird. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:53:41 GMT+1,
[Anmerkungen/Kommentare]
|
| Signatur [OO allg.] (G-161)
|
| Die Signatur einer Operation setzt sich zusammen aus dem Namen der Operation, ihrer Parameterliste und der Angabe eines evtl. Rückgabetyps. |
| Siehe auch
Operation [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Signatur [UML 2.0] (G-951)
|
| Die Signatur einer Operation setzt sich zusammen aus dem Namen der Operation, ihrer Parameterliste und der Angabe eines evtl. Rückgabetyps. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:54:11 GMT+1,
[Anmerkungen/Kommentare]
|
| Software-Element [EmOO] (G-357)
|
| Ein Software-Element ist die kleinste unteilbar zu behandelnde und eindeutig zu identifizierende Einheit, die einem Änderungs- und Freigabeverfahren unterworfen werden kann. |
| Siehe auch
Konfigurationsmanagement [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Softwareentwicklungsplan [OEP] (G-358)
|
| Zusammenfassung aller zur Projekt- und Iterationsplanung notwendigen Unterlagen und Ergebnisse. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Software-Entwicklungsumgebung (SEU) [OO allg.] (G-163)
|
| Eine (meistens integrierte) Umgebung, die eine Reihe von Werkzeugen enthält, die im Rahmen der Softwareentwicklung notwendig oder hilfreich sind, beispielsweise Editor, Compiler, Debugger, Inspektoren etc. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Spezialisierung [OO allg.] (G-166)
|
| Eine Generalisierung (bzw. Spezialisierung) ist eine taxonomische Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere weitere Eigenschaften hinzufügt, die Semantik erweitert und sich kompatibel zum allgemeinen verhält. Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Modellsemantik unter einem diskriminierenden Aspekt. |
| Siehe auch
Generalisierung [OO allg.]
Diskriminator [UML 1.4]
Vererbung [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Spezialisierung [OO allg.] (G-795)
|
| Eine Generalisierung (bzw. Spezialisierung) ist eine taxonomische Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere weitere Eigenschaften hinzufügt, die Semantik erweitert und sich kompatibel zum allgemeinen verhält. Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Modellsemantik unter einem diskriminierenden Aspekt. |
| Siehe auch
Generalisierung [OO allg.]
|
| Letzte Änderung von cj am 2003/04/09 08:12:10 GMT+2,
[Anmerkungen/Kommentare]
|
| Spezialisierung, Generalisierung [UML 2.0] (G-948)
|
| Eine Generalisierung (bzw. Spezia-lisierung) ist eine taxonomische Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere weitere Eigenschaften hinzufügt, die Semantik erweitert und sich kompatibel zum allgemeinen verhält. Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Modellsemantik unter einem diskriminierenden Aspekt (Diskriminator). |
| Siehe auch
Vererbung [UML 2.0]
Diskriminator [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:51:32 GMT+1,
[Anmerkungen/Kommentare]
|
| Stakeholder [GPM] (G-632)
|
| Person, die in irgendeiner Form ‚teil hat’ bzw. betroffen ist (engl. Teilhaber). Mögliche deutsche Bezeichnungen: Interessenshalter, Anforderungsbeitragender oder Projektbetroffener. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09,
[Anmerkungen/Kommentare]
|
| Standart-Implementierung [UML 2.0] (G-952)
|
| Konkrete Implementierung einer eigentlich abstrakten Operation, um für Subklassen ein Standardverhalten bereitzustellen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:54:54 GMT+1,
[Anmerkungen/Kommentare]
|
| Statistische Klassifikation [UML 2.0] (G-953)
|
| Ein Objekt ist und bleibt Instanz genau einer Klassen, d.h. es kann seine Klassenzugehörigkeit während seiner Lebenszeit nicht ändern. Vgl. Dynamische Klassifikation. |
| Siehe auch
Dynamische Klassifikation [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:55:52 GMT+1,
[Anmerkungen/Kommentare]
|
| Stereotyp [UML 2.0] (G-954)
|
| Das Konzept der Stereotypen ist ein Erweiterungsmechanismus in der UML, mit dem neue eigene Modellierungselemente auf der Basis bestehender definiert werden können. Dieser Definitionsvorgang wird auch stereotipisieren genannt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:57:15 GMT+1,
[Anmerkungen/Kommentare]
|
| Stereotyp [UML 1.4] (G-169)
Alias für
stereotype [UML 1.4]
|
| Stereotypen dienen zur (werkzeug-, projekt-, unternehmens- oder methodenspezifischen) Erweiterung vorhandener Modellelemente der UML, d.h. ihres Metamodells. Entsprechend der mit der Erweiterung definierten Semantik wird das Modellierungselement, auf das es angewendet wird, direkt semantisch beeinflußt. In der Praxis geben Stereotypen häufig mögliche Verwendungszusammenhängen einer Klasse, einer Beziehung oder eines Paketes an. Andere erweiternde Mechanismen in der UML sind Eigenschaftswert und Zusicherung. (Duden: das Stereotyp) |
| Siehe auch
Metamodell [OO allg.]
Zusicherung [UML 1.4]
Eigenschaftswert [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Strategisch, Strategisches Ziel [GPM] (G-797)
|
| Eine Strategie ist ein Vorgehensplan, der dazu dient, ein Ziel zu erreichen, indem man diejenigen Faktoren, die in die eigene Aktion hineinspielen könnten, von vornherein einzukalkulieren versucht. Bezieht sich meist auf einen längeren Zeitraum. Ein strategisches Ziel zielt gewöhnlich auf das Erreichen einer zukünftig besseren Ausgangsposition ab. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09 08:15:36 GMT+2,
[Anmerkungen/Kommentare]
|
| Subsystem [UML 2.0] (G-955)
|
| Ein Subsystem ist eine spezielle Komponente, deren Zweck die Rep-räsentation einer architektonischen Einheit darstellt. |
| Siehe auch
Komponente [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 15:58:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Subsystem [UML 1.4] (G-535)
|
| Ein Subsystem ist eine spezielle Form von Paket, daß gewöhnlich eine größere Zahl von Modellelementen enthält und der fachlichen Systempartitionierung dient. |
| Siehe auch
Paket [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Synergie [GPM] (G-798)
|
| Synergie ist der Effekt, dass bei optimaler Kombination von Einzelelementen die sich ergebende Gesamtheit mehr ist als die Summer der Einzelteile. Abgegriffenes Modewort. Insbesondere in der Strategischen Planung ist die Diskussion von Synergien durch die optimale Kombination von Geschäftsfeldern von Bedeutung. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09 08:16:28 GMT+2,
[Anmerkungen/Kommentare]
|
| System [Qualitätssicherung] (G-649)
|
| 1) Kombination von zusammenwirkenden Komponenten, z.B.: ein Computersystem aus Hard- und Software, ein Windowssystem als PC mit MS Windows-Betriebssystem oder ein DTP-System als PC mit Desktop Publishing Software
2) Kurzform für Computersystem
3) Kurzform für Betriebssystem
4) Organisation oder Methodik, z.B. das binäre Zahlensystem |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/10 13:37:25 GMT+2,
[Anmerkungen/Kommentare]
|
| System Bauhaus [EmOO] (G-365)
|
| Das System Bauhaus ist ein Netzwerk international bekannter und im deutschsprachigen Raum tätiger unabhängiger Fachleute für objektorientierte Systementwicklung. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Systemanwendungsfall [UML 2.0] (G-956)
|
| Ein Systemanwendungsfall ist ein Anwendungsfall, der speziell das für außen stehende Akteure (Benutzer oder Nachbarsysteme) wahrnehmbare Verhalten eines (Hard-/Software-) Systems beschreibt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:58:30 GMT+1,
[Anmerkungen/Kommentare]
|
| Systemarchitektur [OO allg.] (G-173)
|
| Architektur für die IT-Infrastruktur. Beschreibt Zusammenhänge zwsichen Hardware, Betriebssystemen, Datenbanken, Middleware u.a. |
| Siehe auch
Architektur [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Systemkontextdiagramm [UML 2.0] (G-957)
|
| Ein Systemkontextdiagramm ist ein Komponentendiagramm, das alle Akteure dieses Systems zeigt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 15:59:30 GMT+1,
[Anmerkungen/Kommentare]
|
| Szenario [GPM] (G-174)
|
| Das Szenario beschreibt einen möglichen konkreten Ablauf von etwas. In der Praxis werden Szenarien durchgespielt, um aus der hypothetischen Aufeinanderfolge von Ereignissen Erkenntnisse über kausale Zusammenhänge zu gewinnen. Ein Szenario ist eine konkrete mögliche Ausprägung eines Anwendungsfalles. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09,
[Anmerkungen/Kommentare]
|
| Szenario [UML 2.0] (G-958)
|
| Ein Szenario beschreibt einen möglichen konkreten Ablauf von etwas. In der Praxis werden Szenarien durchgespielt, um aus der hypothetischen Aufeinanderfolge von Ereignissen Erkenntnisse über kausale Zusammenhänge zu gewinnen. Ein Senario ist eine konkrete mögliche Ausprägung eines Anwendungsfalles. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:00:05 GMT+1,
[Anmerkungen/Kommentare]
|
| Test [OEP] (G-368)
|
| Testen ist eine Tätigkeit mit der Absicht, Fehler zu finden. Ein Test kann die Existenz eines Fehlers beweisen. Die Abwesenheit von Fehlern ist nicht beweisbar. |
| Siehe auch
Fehler [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Timebox [OEP] (G-807)
Alias für
Iteration [OEP]
|
| Eine Timebox definiert einen unverrückbaren Zeitrahmen, in dem eine Menge von Ergebnissen in vorgegebener Detaillierung und Vollständigkeit vorliegen soll. Liegen die Ergebnisse nicht wie geplant vor, werden die offenen Teile in eine nachfolgende Timebox verschoben. Hierzu werden zum geplanten Endtermin die tatsächlich erreichten Ergebnisse bestimmt. Eine Timebox ist ein Hilfsmittel zur Planung und Überwachung eines Entwicklungsprozesses. |
| Siehe auch
Timeboxing [OEP]
|
| Letzte Änderung von boe am 2003/04/10 14:22:20 GMT+2,
[Anmerkungen/Kommentare]
|
| Timeboxing [OEP] (G-595)
|
| Timeboxing ist ein Verfahren, bei dem für eine oder mehrere Aktivitäten ein fester Zeitrahmen festgelegt wird. Der Endtermin ist dabei wichtiger als die Vollständigkeit des Ergebnisses. |
| Siehe auch
Timepacing [OEP]
|
| Letzte Änderung von boe am 2000/01/18 19:17:03 GMT+1,
[Anmerkungen/Kommentare]
|
| Timepacing [OEP] (G-594)
|
| Timepacing ist ein Prinzip, bei dem regelmäßig, d.h. in einem vorgegebenen Rhythmus Ergebnisse oder Arbeitsfortschritte erzielt werden sollen. Der Rhythmus wird durch eine Folge von Timeboxen o.ä. vorgegeben. |
| Siehe auch
Timeboxing [OEP]
|
| Letzte Änderung von boe am 2000/01/18 19:16:24 GMT+1,
[Anmerkungen/Kommentare]
|
| Transaktion [OO allg.] (G-614)
|
| Eine Transaktion ist ein Vorgang, der entweder vollständig oder gar nicht vollzogen werden kann. Wenn der Vorgang mittendrin aufhört oder abgebrochen wird, ist dies im Ergebnis so, als hätte der Vorgang nie stattgefunden, der Zustand ist derselbe wie vorher. Eventuelle Zwischenergebnisse gehen im Falle eines vorzeitigen Abbruches verloren. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09,
[Anmerkungen/Kommentare]
|
| Typ [UML 2.0] (G-961)
|
| Definition einer Menge von Operationen und Attributen. Andere Elemente sind typkonform, wenn sie über die durch den Typen definierten Eigenschaften verfügen. Wird in der Praxis häufig gleichgesetzt mit der Beschreibung von Schnittstellen. |
| Siehe auch
Schnittstelle [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 16:02:40 GMT+1,
[Anmerkungen/Kommentare]
|
| UML [UML 1.4] (G-799)
|
| UML ist die Abkürzung für Unified Modeling Language. Die UML ist eine von der Object Management Group (OMG) standardisierte Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die objektorientierte Softwareentwicklung. |
| Siehe auch
Unified Modeling Language [UML 1.4]
|
| Letzte Änderung von cj am 2003/04/09 08:19:05 GMT+2,
[Anmerkungen/Kommentare]
|
| Unterklasse [OO allg.] (G-181)
|
| Eine Unterklasse ist die Spezialisierung einer Oberklasse und erbt alle Eigenschaften der Oberklasse. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Unterklasse [UML 2.0] (G-962)
|
| Eine Unterklasse ist die Spezialisierung einer Oberklasse und erbt alle Eigenschaften der Oberklasse. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:03:36 GMT+1,
[Anmerkungen/Kommentare]
|
| Untermengenzusicherung [UML 2.0] (G-963)
|
| Eine Zusicherung/Abhängigkeit zwischen zwei Assoziationen. Die Elemente (Objektverbindungen) der einen Assoziationen müssen Teil der Elemente der anderen Assoziation sein. |
| Siehe auch
Zusicherung [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 16:17:08 GMT+1,
[Anmerkungen/Kommentare]
|
| Unterstützender Geschäftsanwendungsfall [GPM] (G-801)
|
| Ein unterstützender Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf der für den Unternehmenszweck und die Gewinnerzielungsabsicht keinen oder nur indirekt einen Wert darstellt. Im Kontrast hierzu sind die Kern-Geschäftsanwendungsfälle zu sehen. In einem Handelsunternehmen ist die Finanzbuchhaltung oder der Wareneinkauf gewöhnlich ein unterstützender Geschäftsanwendungsfall, während beispielsweise der Verkauf von Waren hier ein Kern-Geschäftsanwendungsfall wäre. |
| Siehe auch
Geschäftsanwendungsfall [GPM]
Kern-Geschäftsanwendungsfall [GPM]
|
| Letzte Änderung von cj am 2003/04/09 08:22:00 GMT+2,
[Anmerkungen/Kommentare]
|
| Verantwortlichkeit [UML 2.0] (G-964)
|
| Verantwortlichkeit beschreibt, für welche fachlichen Aufgaben eine Klasse verantwortlich ist. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:17:58 GMT+1,
[Anmerkungen/Kommentare]
|
| Vererbung [OO allg.] (G-185)
|
| Vererbung ist ein Programmiersprachenkonzept für die Umsetzung einer Relation zwischen einer Ober- und einer Unterklasse, wodurch Unterklassen die Eigenschaften ihrer Oberklassen mitbenutzen können. Vererbung implementiert normalerweise Generalisierungs- und Spezialisierungsbeziehungen. Alternativen sind Delegation, Aggregation, generisches Design, generische Programmierung. |
| Siehe auch
Spezialisierung [OO allg.]
Generalisierung [OO allg.]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Verfeinerungsbeziehung [UML 2.0] (G-966)
|
| Verfeinerungsbeziehungen sind Beziehungen zwischen gleichartigen Elementen unterschiedlichen Detaillierungs- bzw. Spezifikationsgrades. Verfeinerungsbeziehungen sind Stereotypisierungen von Abhängigkeitsbeziehungen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:19:43 GMT+1,
[Anmerkungen/Kommentare]
|
| Verifizierung [OO allg.] (G-376)
|
| Überprüfung, ob ein Ergebnis bzw. Produkt richtig ist, d. h. gegebene Anforderungen erfüllt. |
| Siehe auch
Validierung [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Verteilungsdiagramm [UML 2.0] (G-967)
|
| Verteilungsdiagramme zeigen, welche Software (Komponenten, Objekte) auf welcher Hardware (Knoten) laufen, d.h. wie diese konfiguriert sind und welche Kommunikationsbeziehungen dort bestehen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:20:36 GMT+1,
[Anmerkungen/Kommentare]
|
| V-Modell [OO allg.] (G-379)
|
| Vorgehensmodell. Meistens wird damit das erstmalig 1992 in Form des "Softwareentwicklungsstandard der Bundeswehr" veröffentlichte Vorgehensmodell bezeichnet. |
| Siehe auch
Vorgehensmodell [OEP]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Vorbedingung [UML 2.0] (G-968)
|
| Eine Vorbedingung beschreibt einen Zustand, der vor dem Ablauf einer Tätigkeit, Aktivität, Operation o.ä. gegeben sein muss. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:21:31 GMT+1,
[Anmerkungen/Kommentare]
|
| Vorbedingung [OO allg.] (G-194)
|
| Eine Vorbedingung beschreibt einen Zustand, der vor dem Ablauf einer Operation o.ä. gegeben sein muß. |
| Siehe auch
Zusicherung [UML 1.4]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Vorbedingungen [OO allg.] (G-802)
|
| Eine Vorbedingung beschreibt einen Zustand, der vor dem Ablauf einer Tätigkeit, Aktivität, Operation o.ä. gegeben sein muss. |
| Siehe auch
Nachbedingung [OO allg.]
|
| Letzte Änderung von cj am 2003/04/09 08:25:34 GMT+2,
[Anmerkungen/Kommentare]
|
| Vorgehensmodell [OEP] (G-380)
|
| Modellhafte und häufig formale Beschreibung, wie in Projekten vorgegangen werden soll. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Wartung [EmOO] (G-381)
|
| Wartung ist derjenige Teil des Software-Lebenszyklus, der nach dem Ende der Garantiezeit liegt. Hierunter werden auch Tätigkeiten verstanden, die eine bestehende Anwendung verbessern, optimieren, reparieren oder überprüfen mit dem Ziel, die Anwendung weiterhin bzw. besser nutzen zu können. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Widget [EmOO] (G-382)
|
| Ein Widget ist ein vorgefertigtes Oberflächenelement in den Programmierumgebungen für moderne grafische Benutzungsoberflächen. Der Programmierer benutzt es wie ein Bauteil, entweder deklarativ in einem Kompositionseditor oder durch prozeduralen Aufruf. |
| Siehe auch
Widgetpunkte [EmOO]
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Wiki-Wiki [OO allg.] (G-803)
|
| Ein Wiki ist eine von Ward Cunningham initiierte Open-Source-Technologie zum kooperativen Erstellen von Internet- und Intranet-Seiten, d.h. jeder Benutzer darf jederzeit alles lesen, ändern und neue Seiten hinzufügen. Die Benutzung ist extrem einfach. Wiki-Wiki kommt aus dem Hawaianischen und heißt schnell. Einfach ausprobieren unter http://c2.com/cgi/wiki?WikiWiki. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09 08:26:31 GMT+2,
[Anmerkungen/Kommentare]
|
| Workflow [GPM] (G-199)
|
| Ein Workflow ist die computergestützte Automatisierung und Unterstützung eines Geschäftsprozesses oder eines Teils davon. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09,
[Anmerkungen/Kommentare]
|
| Workflow [UML 2.0] (G-969)
|
| Ein Workflow ist die computergestützte Automatisierung und Unterstützung eines Geschäftsprozesses oder eines Teils davon. |
| Siehe auch
Geschäftsprozess [UML 2.0]
|
| Letzte Änderung von ch am 2003/11/12 16:22:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Workflow-Engine [UML 2.0] (G-970)
|
| Die Workflow-Engine ist eine Software, die Workflows steuert. Sie erzeugt, aktiviert, suspendiert und terminiert Workflow-Instanzen (d.h. die computergestützte Manifestation eines Geschäftsvorfalles). |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:26:06 GMT+1,
[Anmerkungen/Kommentare]
|
| Workflow-Instanz [UML 2.0] (G-971)
|
| Eine Workflow-Instanz ist die computergestützte Manifestation eines Geschäftsvorfalles; sie wird durch eine Workflow-Engine gesteuert. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:26:55 GMT+1,
[Anmerkungen/Kommentare]
|
| XA [Komponenten] (G-615)
|
| Um verteilte Transaktionen auf verschiedenen Datenbanken umsetzten zu können
werden spezielle Datenbank-Treiber benötigt. Diese müssen dem XA Protokoll entsprechen. |
| Siehe auch
Transaktion [OO allg.]
|
| Letzte Änderung von gl am 2001/03/05 10:27:25 GMT+1,
[Anmerkungen/Kommentare]
|
| Zeitdiagramm [UML 2.0] (G-972)
|
| Ein Zeitdiagramm beschreibt die zeitlichen Bedingungen von Zu-standswechseln mehrerer beteiligter Objekte. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:27:42 GMT+1,
[Anmerkungen/Kommentare]
|
| Zusicherung [UML 2.0] (G-973)
|
| Eine Zusicherung ist ein Ausdruck, der die möglichen Inhalte, Zustände oder die Semantik eines Modellelementes einschränkt und der stets erfüllt sein muss. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:28:24 GMT+1,
[Anmerkungen/Kommentare]
|
| Zustand [UML 2.0] (G-974)
|
| Ein Zustand ist ein Ausdruck, der die möglichen Inhalte, Zustände o-der die Semantik eines Modellelementeseinschränkt und der stets erfüllt sein muss. Bei dem Ausdruck kann es sich um einen Stereotyp oder einen Eigenschaftswert handeln, um eine freie Formulierung oder ei-nen OCL-Ausdruck. Zusicherung in einer Form reiner boolescher Ausdrücke werden auch Assertions genannt. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:29:00 GMT+1,
[Anmerkungen/Kommentare]
|
| Zustand [UML 1.4] (G-201)
Alias für
state [UML 1.4]
|
| Ein Zustand ist eine benannte Abstraktion (Zusammenfassung) der möglichen Attributwerte eines Objektes. Ein Zustand gehört zu genau einer Klasse und stellt eine Abstraktion bzw. Zusammenfassung einer Menge von möglichen Attributwerten dar, welche die Objekte dieser Klasse einnehmen können. In der UML ist ein Zustand eine Situation im Leben eines Objektes, während der eine bestimmte Bedingung erfüllt ist, Aktivitäten ausgeführt werden oder auf ein Ereignis gewartet wird. |
| Siehe auch
|
| Letzte Änderung von cj am 2003/04/09,
[Anmerkungen/Kommentare]
|
| Zustandsdiagramm [UML 2.0] (G-975)
|
| Ein Zustandsmodell wird dargestellt durch Zustandsdiagramme. Ein Zustandsmodell zeigt eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann, und gibt an, aufgrund welcher Stimuli Zustandsänderungen stattfinden. Ein Zustandsmodell beschreibt eine hypothetische Maschine (endlicher Automat), die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet. Sie besteht aus einer endlichen, nicht leeren Menge von Zuständen, einer endlichen, nicht leeren Menge von Eingabesymbolen (Ereignissen), Funktionen, die den Übergang von einem Zustand in den nächsten beschreiben, einem Anfangszustand und einer Menge von Endzuständen. |
| Siehe auch
|
| Letzte Änderung von ch am 2003/11/12 16:29:44 GMT+1,
[Anmerkungen/Kommentare]
|
| Zustandsdiagramm [UML 1.4] (G-202)
Alias für
state diagram [UML 1.4]
|
Ein Zustandsdiagramm zeigt eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann und aufgrund welcher Stimuli Zustandsänderungen stattfinden. Ein Zustandsdiagramm beschreibt eine hypothetische Maschine (Endlicher Automat), die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet. Sie besteht aus:
- einer endlichen, nicht-leeren Menge von Zuständen
- einer endlichen, nicht-leeren Menge von Eingabesymbolen (Ereignissen)
- Funktionen, die den Übergang von einem Zustand in den nächsten beschreiben
- einen Anfangszustand
- einer Menge von Endzuständen
|
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Änderungsmanagement (Organisationseinheit) [OEP] (G-220)
|
| Entscheidungs- und Steuerungsgremium für das Änderungsmanagement. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Änderungsmanagement (Tätigkeit) [OEP] (G-219)
|
| Management zur Aufnahme, Verfolgung und Durchführung von Änderungen, Erweiterungen und Fehlerbeseitigung. |
| Siehe auch
|
| Letzte Änderung von boe am 1999/01/01,
[Anmerkungen/Kommentare]
|
| Äquivalenzklassen [Qualitätssicherung] (G-637)
|
| Mathematische Definition einander äquivalenter Tests aus einer gemeinsamen Testklasse. Auf Basis der informellen Spezifikation können Äquivalenzklassen erstellt werden, die zur Findung sinnvoller, vom Umfang her minimaler §Testdaten für einen Testfall dienen. Ziel ist es, durch speziell ausgewählte Testdaten eine ganze Klasse von Testdaten abzudecken und so die Anzahl der Testfälle und Testdaten zu minimieren. |
| Siehe auch
|
| Letzte Änderung von uvi am 2001/05/07 14:35:23 GMT+2,
[Anmerkungen/Kommentare]
|
OEP - Object Engineering Process, v3.0, 06.11.2006 11:03:56, Copyright © 2006 by oose Innovative Informatik GmbH