Klassenschema - Versionsgeschichte

Kowa am 16. Oktober 2019 um 09:26 Uhr

2019-10-16T09:26:41Z

Kowa am 3. August 2019 um 12:25 Uhr

2019-08-03T12:25:13Z

← Nächstältere Version		Version vom 3. August 2019, 12:25 Uhr
Zeile 311:		Zeile 311:

	<noinclude>[[Kategorie:Objektorientierte Programmierung]]		<noinclude>[[Kategorie:Objektorientierte Programmierung]]
	[[Kategorie:Glossar~~]][[Kategorie:Programmierung~~]]		[[Kategorie:Glossar]]
	[[en:Class schema]]		[[en:Class schema]]
	[[Kategorie:Kapitel:Multimedia-Programmierung]]		[[Kategorie:Kapitel:Multimedia-Programmierung]]
	</noinclude>		</noinclude>

Kowa am 3. August 2019 um 12:24 Uhr

2019-08-03T12:24:39Z

← Nächstältere Version		Version vom 3. August 2019, 12:24 Uhr
Zeile 3:		Zeile 3:
	\|extent = 4		\|extent = 4
	\|numberOfReferences = 1		\|numberOfReferences = 1
	\|qualityOfReferences = 3		\|qualityOfReferences = 4
	\|conformance = 5		\|conformance = 5
	}}		}}

Kowa am 3. August 2019 um 12:24 Uhr

2019-08-03T12:24:01Z

← Nächstältere Version		Version vom 3. August 2019, 12:24 Uhr
Zeile 1:		Zeile 1:
			{{Qualität
			\|correctness = 3
			\|extent = 4
			\|numberOfReferences = 1
			\|qualityOfReferences = 3
			\|conformance = 5
			}}

	==Informelle Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==		==Informelle Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==
	[[Datei:UMLClassDetail.jpg\|miniatur\|550px\|UML-Klassendiagramm: Zwei Klassen und ein Klassen-Template deren Klassenschemata aus zahlreichen Integritätsbedingungen bestehen]]		[[Datei:UMLClassDetail.jpg\|miniatur\|550px\|UML-Klassendiagramm: Zwei Klassen und ein Klassen-Template deren Klassenschemata aus zahlreichen Integritätsbedingungen bestehen]]

Kowa am 22. September 2014 um 08:16 Uhr

2014-09-22T08:16:26Z

← Nächstältere Version		Version vom 22. September 2014, 08:16 Uhr
Zeile 1:		Zeile 1:
	==Informelle Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==		==Informelle Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==
	[[Datei:UMLClassDetail.jpg\|miniatur~~\|links~~\|550px\|UML-Klassendiagramm: Zwei Klassen und ein Klassen-Template deren Klassenschemata aus zahlreichen Integritätsbedingungen bestehen]]		[[Datei:UMLClassDetail.jpg\|miniatur\|550px\|UML-Klassendiagramm: Zwei Klassen und ein Klassen-Template deren Klassenschemata aus zahlreichen Integritätsbedingungen bestehen]]
	Ein [[Klassenschema]] (oder eine '''Klassenspezifikation''') definiert die [[Softwareschnittstelle]], die alle Objekte der zugehörigen [[Klasse (OOP)\|Klasse]] mindestens unterstützen müssen.		Ein [[Klassenschema]] (oder eine '''Klassenspezifikation''') definiert die [[Softwareschnittstelle]], die alle Objekte der zugehörigen [[Klasse (OOP)\|Klasse]] mindestens unterstützen müssen.

Zeile 153:		Zeile 153:
	Beispielsweise muss bei der Division		Beispielsweise muss bei der Division

	<~~code~~>operator/ (dividend: double, divisor: double\{0}): double</~~code~~>		<source lang="actionscript3">operator/ (dividend: double, divisor: double\{0}): double</source>

	i. Allg. zur Laufzeit überprüft werden, ob die Bedingung <code>divisor!=0</code> erfüllt ist.		i. Allg. zur Laufzeit überprüft werden, ob die Bedingung <code>divisor!=0</code> erfüllt ist.

Kowa: /* Anmerkung */

2014-09-22T08:14:06Z

Anmerkung

← Nächstältere Version		Version vom 22. September 2014, 08:14 Uhr
Zeile 146:		Zeile 146:
	<math>f(a,b)\,</math> einen Fehler.		<math>f(a,b)\,</math> einen Fehler.

	Ob man die Datentypen einer Signatur eher als Vor- und Nachbedingung oder als ~~Invariante~~ auffasst, ist Geschmackssache.		Ob man die Datentypen einer Signatur eher als Vor- und Nachbedingung oder als Invarianten auffasst, ist Geschmackssache.
	Wichtig ist, wie man sicherstellt, dass alle Integritätsverletzungen erkannt werden, um geeignete Gegenmaßnahmen zu		Wichtig ist, wie man sicherstellt, dass alle Integritätsverletzungen erkannt werden, um geeignete Gegenmaßnahmen zu
	ergreifen zu können. In einer Programmiersprache mit [[Starke Typisierung\|starker Typisierung]] erkennt ein Compiler		ergreifen zu können. In einer Programmiersprache mit [[Starke Typisierung\|starker Typisierung]] erkennt ein Compiler

Kowa: /* Anmerkung */

2014-09-22T08:13:28Z

Anmerkung

← Nächstältere Version		Version vom 22. September 2014, 08:13 Uhr
Zeile 131:		Zeile 131:

	Aus [[Imperative Programmierung\|prozeduraler]] Sicht steht <math>A \times B</math> für folgende ''Vorbedingung'':		Aus [[Imperative Programmierung\|prozeduraler]] Sicht steht <math>A \times B</math> für folgende ''Vorbedingung'':
	Vor Aufruf der Funktion/Methode <math>f\,</math> müssen je ein [[Objekt (OOP)\|Objekt]]/[[Wert]] vom Typ <math>A\,</math> und vom Typ <math>B\,</math> auf den [[Programmstack]]		Vor Aufruf der Funktion/Methode <math>f\,</math> müssen je ein [[Objekt (OOP)\|Objekt]]/[[Wert]] vom Typ <math>A\,</math> und vom Typ <math>B\,</math> der Funktion als aktuelle [[Argument]]e übergeben werden
	gelegt werden. Und <math>C\,</math> steht für folgende ''Nachbedingung'':		(z.B. indem diese Objekte in richtiger Reihenfolge auf den [[Programmstack]] gelegt werden). Und <math>C\,</math> steht für folgende ''Nachbedingung'':
	Nachdem die Funktion/Methode <math>f\,</math> bearbeitet wurde, ~~findet sich~~ ein Objekt/Wert vom Typ <math>C\,</math> auf ~~dem~~ Programmstack.		Nachdem die Funktion/Methode <math>f\,</math> bearbeitet wurde, liefert sie ein Objekt/Wert vom Typ <math>C\,</math> als Ergebnis (z.B., indem sie die Argumente vom Programmstack löscht und ein passendes
			Ergebnisobjekt auf den Programmstack ablegt).

	Aus [[Funktionale Programmierung\|funktionaler Sicht]] steht die obige Signatur für folgende ''Invariante'':<br />		Aus [[Funktionale Programmierung\|funktionaler Sicht]] steht die obige Signatur für folgende ''Invariante'':<br />

Kowa: /* Anmerkung */

2014-09-22T08:10:26Z

Anmerkung

← Nächstältere Version		Version vom 22. September 2014, 08:10 Uhr
Zeile 141:		Zeile 141:

	Man kann diese Invariante noch um eine zweite Invariante ergänzen:		Man kann diese Invariante noch um eine zweite Invariante ergänzen:
	<div class="formula">$\forall a, b: a \not\in A \vee b\not\in B \Rightarrow f(a,b)$ throws error}</div>		<div class="formula">$\forall a, b: a \not\in A \vee b\not\in B \Rightarrow f(a,b)$ throws error</div>
	Das heißt, wenn entweder <math>a\,</math> kein Element von <math>A\,</math> ist oder <math>b\,</math> kein Element von <math>B\,</math>, dann meldet		Das heißt, wenn entweder <math>a\,</math> kein Element von <math>A\,</math> ist oder <math>b\,</math> kein Element von <math>B\,</math>, dann meldet
	<math>f(a,b)\,</math> einen Fehler.		<math>f(a,b)\,</math> einen Fehler.

Kowa: /* Anmerkung */

2014-09-22T08:09:18Z

Anmerkung

← Nächstältere Version		Version vom 22. September 2014, 08:09 Uhr
Zeile 136:		Zeile 136:

	Aus [[Funktionale Programmierung\|funktionaler Sicht]] steht die obige Signatur für folgende ''Invariante'':<br />		Aus [[Funktionale Programmierung\|funktionaler Sicht]] steht die obige Signatur für folgende ''Invariante'':<br />
	<~~math~~>\forall a \in A, b\in B: f(a,b) \in C~~</math>~~ oder auch ~~<math>~~\forall a, b: a \in A \wedge b\in B \Rightarrow f(a,b) \in C</~~math><br /~~>		<div class="formula">$\forall a \in A, b\in B: f(a,b) \in C$ oder auch $\forall a, b: a \in A \wedge b\in B \Rightarrow f(a,b) \in C$</div>
	Das heißt, <math>f\,</math> erfüllt folgende Bedingung '''dauerhaft''': Wenn <math>a\,</math> ein Element von <math>A\,</math> ist und <math>b\,</math> ein Element von <math>B\,</math>, dann ist		Das heißt, <math>f\,</math> erfüllt folgende Bedingung '''dauerhaft''': Wenn <math>a\,</math> ein Element von <math>A\,</math> ist und <math>b\,</math> ein Element von <math>B\,</math>, dann ist
	<math>f(a,b)\,</math> ein Element von <math>C\,</math>.		<math>f(a,b)\,</math> ein Element von <math>C\,</math>.

	Man kann diese Invariante noch um eine zweite Invariante ergänzen:		Man kann diese Invariante noch um eine zweite Invariante ergänzen:
	<~~math~~>\forall a, b: a \not\in A \vee b\not\in B \Rightarrow f(a,b) ~~{\rm\~~ throws\ error}</~~math><br /~~>		<div class="formula">$\forall a, b: a \not\in A \vee b\not\in B \Rightarrow f(a,b)$ throws error}</div>
	Das heißt, wenn entweder <math>a\,</math> kein Element von <math>A\,</math> ist oder <math>b\,</math> kein Element von <math>B\,</math>, dann meldet		Das heißt, wenn entweder <math>a\,</math> kein Element von <math>A\,</math> ist oder <math>b\,</math> kein Element von <math>B\,</math>, dann meldet
	<math>f(a,b)\,</math> einen Fehler.		<math>f(a,b)\,</math> einen Fehler.

Kowa: /* Siehe auch */

2014-09-22T08:05:35Z

Siehe auch

← Nächstältere Version		Version vom 22. September 2014, 08:05 Uhr
Zeile 299:		Zeile 299:

	==Siehe auch==		==Siehe auch==
	*{{SieheAuch\|Kowarschick (2002a)}}		#{{SieheAuch\|Kowarschick (2002a)}}

	<noinclude>[[Kategorie:Objektorientierte Programmierung]]		<noinclude>[[Kategorie:Objektorientierte Programmierung]]

← Nächstältere Version		Version vom 16. Oktober 2019, 09:26 Uhr
Zeile 8:		Zeile 8:

	==Informelle Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==		==Informelle Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==
	[[Datei:UMLClassDetail.jpg\|miniatur\|550px\|UML-Klassendiagramm: Zwei Klassen und ein ~~Klassen-Template~~ deren Klassenschemata aus zahlreichen Integritätsbedingungen bestehen]]		[[Datei:UMLClassDetail.jpg\|miniatur\|550px\|UML-Klassendiagramm: Zwei Klassen und ein Klassentemplate deren Klassenschemata aus zahlreichen Integritätsbedingungen bestehen]]
	Ein [[Klassenschema]] (oder eine '''Klassenspezifikation''') definiert die [[Softwareschnittstelle]], die alle Objekte der zugehörigen [[Klasse (OOP)\|Klasse]] mindestens unterstützen müssen.		Ein [[Klassenschema]] (oder eine '''Klassenspezifikation''') definiert die [[Softwareschnittstelle]], die alle Objekte der zugehörigen [[Klasse (OOP)\|Klasse]] mindestens unterstützen müssen.

	==Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==		==Definition (von W. Kowarschick)<ref>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</ref>==
	Das zu einer [[Klasse (OOP)\|Klasse]] gehörende [[Klassenschema]] umfasst eine (endliche) Menge von [[Integritätsbedingung]]en, die alle zugehörigen Objekte (d.h. alle in der [[Klassenextension\|Extension]]		Das zu einer [[Klasse (OOP)\|Klasse]] gehörende [[Klassenschema]] umfasst eine (endliche) Menge von [[Integritätsbedingung]]en, die alle zugehörigen Objekte (d.h. alle in der [[Klassenextension\|Extension]]
	der zugehörigen Klasse enthaltenen Elemente) zu jedem Zeitpunkt erfüllen müssen. Das Schema [[deklariert]] insbesondere die [[Methoden]], die für jedes Objekt der Klassenextension jederzeit als [[Schnittstelle\|Kommunikationsschnittstelle]] zur ~~Verfügungstehen~~ müssen.		der zugehörigen Klasse enthaltenen Elemente) zu jedem Zeitpunkt erfüllen müssen. Das Schema [[deklariert]] insbesondere die [[Methoden]], die für jedes Objekt der Klassenextension jederzeit als [[Schnittstelle\|Kommunikationsschnittstelle]] zur Verfügung stehen müssen.

	==Bemerkungen==		==Bemerkungen==
Zeile 36:		Zeile 36:

	Außerdem definiert jede Signatur eine [[Vorbedingung]] (zum Zeitpunkt des Methodenaufrufes müssen die [[Argument]]e den Bedingungen genügen, die		Außerdem definiert jede Signatur eine [[Vorbedingung]] (zum Zeitpunkt des Methodenaufrufes müssen die [[Argument]]e den Bedingungen genügen, die
	in der Signatur an die [[Parameter\|Eingabeparameter]] gestellt werden) und eine [[Nachbedingung]] (die ~~Methodernergebnisse~~ genügen den in der Signatur geforderten Ergebnisdatentypen).		in der Signatur an die [[Parameter\|Eingabeparameter]] gestellt werden) und eine [[Nachbedingung]] (die Ergebnisse von Methodenaufrufen genügen den in der Signatur geforderten Ergebnisdatentypen).

	====Beispiel====		====Beispiel====
Zeile 271:		Zeile 271:

	====Anmerkung====		====Anmerkung====
	Im nebenstehenden ~~Digramm~~ sind zwei Arten von Beziehungen dargestellt. Eine Vererbungsbeziehung besteht nur zwischen Klassen, aber nicht zwischen den zugehörigen		Im nebenstehenden Diagramm sind zwei Arten von Beziehungen dargestellt. Eine Vererbungsbeziehung besteht nur zwischen Klassen, aber nicht zwischen den zugehörigen
	Objekten. Eine Part-of-Beziehung ([[Aggregation (OOP)\|Aggregation]]) oder – allgemeiner – eine [[Assoziation]] besteht dageben zwischen Objekten.		Objekten. Eine Part-of-Beziehung ([[Aggregation (OOP)\|Aggregation]]) oder – allgemeiner – eine [[Assoziation]] besteht dageben zwischen Objekten.
	Wenn eine derartige Beziehung in einem Klassendiagramm		Wenn eine derartige Beziehung in einem Klassendiagramm
	angegeben wird, beschreiben sie (als spezielle Integritätsbedingungen), welche Beziehungen zwischen den zugehörigen Objekten bestehen müssen.		angegeben wird, beschreiben sie (als spezielle Integritätsbedingungen), welche Beziehungen zwischen den zugehörigen Objekten bestehen müssen.

	Die Angabe von Vielfachheiten macht in einem [[Objekt-Diagramm]] keinen Sinn (daher werden insbesondere in einem Klassendiagramm bei einer Vererbungsbeziehung		Die Angabe von Vielfachheiten oder Multiplizitäten macht in einem [[Objekt-Diagramm]] keinen Sinn (daher werden insbesondere in einem Klassendiagramm bei einer Vererbungsbeziehung
	keine Vielfachheiten angegeben; hier werden die beiden beteiligten Klassen als Objekte einer Metaklasse <code>Class</code> aufgefasst).		keine Vielfachheiten angegeben; hier werden die beiden beteiligten Klassen als Objekte einer Metaklasse <code>Class</code> aufgefasst).
	Die Angabe von Vielfachheiten bei einer Assoziation in einen [[Klassendiagramm]] legt fest, ~~vie~~ viele entsprechende Objektbeziehungen in einem zugehörigen ~~Objektdiagram~~		Die Angabe von Vielfachheiten bei einer Assoziation in einen [[Klassendiagramm]] legt fest, wie viele entsprechende Objektbeziehungen in einem zugehörigen Objektdiagramm
	existieren müssen. Eine Vielfachheit ist also ebenfalls eine spezielle Integritätsbedingung.		existieren müssen. Eine Vielfachheit ist also ebenfalls eine spezielle Integritätsbedingung.

Zeile 292:		Zeile 292:
	zusätzlich eine Ladefläche (<code>cargoSpace</code>) enthalten und zum anderen hat jeder Lastwagen (laut obiger Spezifikation!) genau einen Motor:		zusätzlich eine Ladefläche (<code>cargoSpace</code>) enthalten und zum anderen hat jeder Lastwagen (laut obiger Spezifikation!) genau einen Motor:
	Die Vielfachheit des geerbten Beziehungsattributs <code>engine</code> wird eingeschränkt. (Die Tatsache, dass diese Beziehung geerbt wurde,		Die Vielfachheit des geerbten Beziehungsattributs <code>engine</code> wird eingeschränkt. (Die Tatsache, dass diese Beziehung geerbt wurde,
	wir im UML-Diagramm mit einen ~~Schräckstrich~~ <code>/</code> vor dem Rollennamen symbolisiert.)		wir im UML-Diagramm mit einen Schrägstrich <code>/</code> vor dem Rollennamen symbolisiert.)

	====Anmerkung====		====Anmerkung====