Logic-Data-View-Controller-Service-Paradigma - Versionsgeschichte

Kowa am 22. September 2017 um 14:49 Uhr

2017-09-22T14:49:45Z

Kowa am 16. November 2016 um 09:38 Uhr

2016-11-16T09:38:22Z

Änderungen zeigen

Kowa am 5. März 2014 um 16:45 Uhr

2014-03-05T16:45:59Z

← Nächstältere Version		Version vom 5. März 2014, 16:45 Uhr
Zeile 1:		Zeile 1:
	{{MVC:Menü}}		{{MVC:Menü}}
	=Definition ([[Kowarschick (MMProg)]])=		=Definition ([[Kowarschick (MMProg)]])=
	[[~~Medium~~:LDVC-Module 01.png\|gerahmt\|rechts\|LDVC-Module]]		[[Datei:LDVC-Module 01.png\|gerahmt\|rechts\|LDVC-Module]]
	[[~~Medium~~:LDVCS-Module 01.png\|gerahmt\|rechts\|LDVCS-Module]]		[[Datei:LDVCS-Module 01.png\|gerahmt\|rechts\|LDVCS-Module]]

	Als [[Logic-Data-View-Controller-Service-Paradigma]]		Als [[Logic-Data-View-Controller-Service-Paradigma]]
Zeile 78:		Zeile 78:

	<gallery perrow="2" widths="301px" heights="410px" class="floatright">		<gallery perrow="2" widths="301px" heights="410px" class="floatright">
	~~Medium~~:VCLSD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLSD-Schichtenarchitektur		Datei:VCLSD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLSD-Schichtenarchitektur
	~~Medium~~:VCLD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLD-Schichtenarchitektur		Datei:VCLD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLD-Schichtenarchitektur
	</gallery>		</gallery>

Zeile 141:		Zeile 141:

	= Der VCLSD-Prozess =		= Der VCLSD-Prozess =
	[[~~Medium~~:VCLD-Prozess 01.png\|gerahmt\|\|rechts\|Der VCLD-Prozess]]		[[Datei:VCLD-Prozess 01.png\|gerahmt\|\|rechts\|Der VCLD-Prozess]]
	[[~~Medium~~:VCLSD-Prozess 01.png\|gerahmt\|\|rechts\|Der VCLSD-Prozess]]		[[Datei:VCLSD-Prozess 01.png\|gerahmt\|\|rechts\|Der VCLSD-Prozess]]

	== Beispiel Jump 'n' Run==		== Beispiel Jump 'n' Run==
Zeile 191:		Zeile 191:
	Der umgekehrte Weg sollte allerdings vermieden werden, damit die innere Komponente problemlos in andere Umgebungen integriert werden können.		Der umgekehrte Weg sollte allerdings vermieden werden, damit die innere Komponente problemlos in andere Umgebungen integriert werden können.

	[[~~Medium~~:VCLSD-Prozess 02.png\|gerahmt\|links\|Der VCLSD-Prozess mit Trennung in eine äußere und eine innere Komponente]]		[[Datei:VCLSD-Prozess 02.png\|gerahmt\|links\|Der VCLSD-Prozess mit Trennung in eine äußere und eine innere Komponente]]

	==Beispiel „Spiel mit Highscore-Verwaltung“==		==Beispiel „Spiel mit Highscore-Verwaltung“==

Kowa am 2. Juni 2013 um 14:00 Uhr

2013-06-02T14:00:44Z

← Nächstältere Version		Version vom 2. Juni 2013, 14:00 Uhr
Zeile 1:		Zeile 1:
	{{MVC:Menü}}		{{MVC:Menü}}
	=Definition ~~nach~~ [[Kowarschick (MMProg)]])=		=Definition ([[Kowarschick (MMProg)]])=
	[[Medium:LDVC-Module 01.png\|gerahmt\|rechts\|LDVC-Module]]		[[Medium:LDVC-Module 01.png\|gerahmt\|rechts\|LDVC-Module]]
	[[Medium:LDVCS-Module 01.png\|gerahmt\|rechts\|LDVCS-Module]]		[[Medium:LDVCS-Module 01.png\|gerahmt\|rechts\|LDVCS-Module]]

Kowa: /* LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg)) */

2011-12-13T16:38:21Z

LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg))

← Nächstältere Version		Version vom 13. Dezember 2011, 16:38 Uhr
Zeile 78:		Zeile 78:

	<gallery perrow="2" widths="301px" heights="410px" class="floatright">		<gallery perrow="2" widths="301px" heights="410px" class="floatright">
	Medium:VCLSD-Schichtenarchitektur 01.png \| Besipiel für eine VCLSD-Schichtenarchitektur		Medium:VCLSD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLSD-Schichtenarchitektur
	Medium:VCLD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLD-Schichtenarchitektur		Medium:VCLD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLD-Schichtenarchitektur
	</gallery>		</gallery>

Kowa: /* LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg)) */

2011-12-13T16:35:10Z

LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg))

← Nächstältere Version		Version vom 13. Dezember 2011, 16:35 Uhr
Zeile 78:		Zeile 78:

	<gallery perrow="2" widths="301px" heights="410px" class="floatright">		<gallery perrow="2" widths="301px" heights="410px" class="floatright">
	Medium:VCLSD-Schichtenarchitektur 01.png \| Besipiel für eine VCLSD-Schichtenarchitektur \|		Medium:VCLSD-Schichtenarchitektur 01.png \| Besipiel für eine VCLSD-Schichtenarchitektur
	Medium:VCLD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLD-Schichtenarchitektur		Medium:VCLD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLD-Schichtenarchitektur
	</gallery>		</gallery>

Kowa: /* LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg)) */

2011-12-13T16:34:37Z

LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg))

← Nächstältere Version		Version vom 13. Dezember 2011, 16:34 Uhr
Zeile 78:		Zeile 78:

	<gallery perrow="2" widths="301px" heights="410px" class="floatright">		<gallery perrow="2" widths="301px" heights="410px" class="floatright">
	Medium:VCLSD-Schichtenarchitektur 01.png \| Besipiel für eine VCLSD-Schichtenarchitektur \|\|		Medium:VCLSD-Schichtenarchitektur 01.png \| Besipiel für eine VCLSD-Schichtenarchitektur \|
	Medium:VCLD-Schichtenarchitektur 01.png \| Besipiel für eine VCLD-Schichtenarchitektur		Medium:VCLD-Schichtenarchitektur 01 301px.png \| Besipiel für eine VCLD-Schichtenarchitektur
	</gallery>		</gallery>

Kowa: /* Der VCLSD-Prozess */

2011-12-02T16:29:00Z

Der VCLSD-Prozess

← Nächstältere Version		Version vom 2. Dezember 2011, 16:29 Uhr
Zeile 141:		Zeile 141:

	= Der VCLSD-Prozess =		= Der VCLSD-Prozess =
			[[Medium:VCLD-Prozess 01.png\|gerahmt\|\|rechts\|Der VCLD-Prozess]]
	[[Medium:VCLSD-Prozess 01.png\|gerahmt\|\|rechts\|Der VCLSD-Prozess]]		[[Medium:VCLSD-Prozess 01.png\|gerahmt\|\|rechts\|Der VCLSD-Prozess]]

Kowa: /* LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg)) */

2011-12-02T16:28:35Z

LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg))

← Nächstältere Version		Version vom 2. Dezember 2011, 16:28 Uhr
Zeile 78:		Zeile 78:

	<gallery perrow="2" widths="301px" heights="410px" class="floatright">		<gallery perrow="2" widths="301px" heights="410px" class="floatright">
	Medium:VCLSD-Schichtenarchitektur 01.png \| Besipiel für eine VCLSD-Schichtenarchitektur		Medium:VCLSD-Schichtenarchitektur 01.png \| Besipiel für eine VCLSD-Schichtenarchitektur \|\|
			Medium:VCLD-Schichtenarchitektur 01.png \| Besipiel für eine VCLD-Schichtenarchitektur
	</gallery>		</gallery>

Kowa: /* Definition nach Kowarschick (MMProg)) */

2011-12-02T16:26:51Z

Definition nach Kowarschick (MMProg))

← Nächstältere Version		Version vom 2. Dezember 2011, 16:26 Uhr
Zeile 1:		Zeile 1:
	{{MVC:Menü}}		{{MVC:Menü}}
	=Definition nach [[Kowarschick (MMProg)]])=		=Definition nach [[Kowarschick (MMProg)]])=
			[[Medium:LDVC-Module 01.png\|gerahmt\|rechts\|LDVC-Module]]
	[[Medium:LDVCS-Module 01.png\|gerahmt\|rechts\|LDVCS-Module]]		[[Medium:LDVCS-Module 01.png\|gerahmt\|rechts\|LDVCS-Module]]
	~~[[Medium:LDVC-Module 01.png\|gerahmt\|rechts\|LDVC-Module]]~~

	Als [[Logic-Data-View-Controller-Service-Paradigma]]		Als [[Logic-Data-View-Controller-Service-Paradigma]]

← Nächstältere Version		Version vom 22. September 2017, 14:49 Uhr
Zeile 21:		Zeile 21:
	(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/data\|LDVCS data module]])		(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/data\|LDVCS data module]])
	einer [[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]]		einer [[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]]
	dient zur Speicherung bestimmter Daten, ~~d.h.~~ zur Speicherung von Teilen des aktuellen Zustands der Anwendung.		dient zur Speicherung bestimmter Daten, {{dh}} zur Speicherung von Teilen des aktuellen Zustands der Anwendung.

	Ein LDVCS-Datenmodul kann weitere Aufgaben übernehmen:		Ein LDVCS-Datenmodul kann weitere Aufgaben übernehmen:
Zeile 44:		Zeile 44:
	(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/controller\|LDVCS controllers]]) dienen zur Steuerung einer		(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/controller\|LDVCS controllers]]) dienen zur Steuerung einer
	[[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]].		[[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]].
	Dazu nimmt ein Controller Eingaben aus verschiedensten Quellen entgegen (~~z.B.~~ Sensor-Daten oder Daten, die ein Benutzer über eine beliebige Benutzer-Schnittstelle wie eine Tastatur oder eine Maus eingibt) und leitet diese bereinigt und normalisiert an geeignete [[Logic-Data-View-Controller-Service-Paradigma/Logic\|Logikmodule]] weiter.		Dazu nimmt ein Controller Eingaben aus verschiedensten Quellen entgegen ({{zB}} Sensor-Daten oder Daten, die ein Benutzer über eine beliebige Benutzer-Schnittstelle wie eine Tastatur oder eine Maus eingibt) und leitet diese bereinigt und normalisiert an geeignete [[Logic-Data-View-Controller-Service-Paradigma/Logic\|Logikmodule]] weiter.

	Ein LDVCS-Controller sollte keine weiteren Aufgaben übernehmen.		Ein LDVCS-Controller sollte keine weiteren Aufgaben übernehmen.
Zeile 53:		Zeile 53:
	Anwendungslogik einer [[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]].		Anwendungslogik einer [[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]].

	Ein Logikmodul reagiert auf Ereignisse, wie ~~z.B.~~ Benutzereingaben, Timer Events oder Ähnliches,		Ein Logikmodul reagiert auf Ereignisse, wie {{zB}} Benutzereingaben, Timer Events oder Ähnliches,
	indem es Daten in Datenmodulen entweder indirekt mit Hilfe von		indem es Daten in Datenmodulen entweder indirekt mit Hilfe von
	[[Logic-Data-View-Controller-Service-Paradigma/Service\|Servicemodulen]] oder direkt manipuliert.		[[Logic-Data-View-Controller-Service-Paradigma/Service\|Servicemodulen]] oder direkt manipuliert.

	Die Aktionen, die ein Logikmodul ausführt, hängen ~~i. Allg.~~ vom aktuellen [[Zustand]] der Anwendung ab.		Die Aktionen, die ein Logikmodul ausführt, hängen {{iAllg}} vom aktuellen [[Zustand]] der Anwendung ab.
	Dieser Zustand kann entweder in Datenmodulen gespeichert werden (so dass auch andere Module darauf zugreifen können)		Dieser Zustand kann entweder in Datenmodulen gespeichert werden (so dass auch andere Module darauf zugreifen können)
	oder im Logikmodul selbst (so dass ein Zugriff durch andere Module nicht möglich ist).		oder im Logikmodul selbst (so dass ein Zugriff durch andere Module nicht möglich ist).
Zeile 67:		Zeile 67:
	(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/service\|service]])		(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/service\|service]])
	dient einer [[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]] zur Kommunikation		dient einer [[Logic-Data-View-Controller-Service-Paradigma\|LDVCS]]-[[Anwendung]] zur Kommunikation
	mit der Außenwelt, ~~d.h.~~ mit Dienste-Anbietern wie [[Web-Server]]n, [[Datenbanksystem]]en oder auch [[Dateisystem]]en.		mit der Außenwelt, {{dh}} mit Dienste-Anbietern wie [[Web-Server]]n, [[Datenbanksystem]]en oder auch [[Dateisystem]]en.
	Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus [[Logic-Data-View-Controller-Service/Data\|Datenmodulen]] auslesen und in externe		Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus [[Logic-Data-View-Controller-Service/Data\|Datenmodulen]] auslesen und in externe
	[[Repository\|Repositories]] schreiben, als auch Daten aus externen Repositories lesen und in Datenmodule einfügen.		[[Repository\|Repositories]] schreiben, als auch Daten aus externen Repositories lesen und in Datenmodule einfügen.
Zeile 88:		Zeile 88:

	Die unterste Ebene ist Data. Das zugehörige Modul weiß nichts von den über ihr liegenden Module und kann mit diesen nur mit		Die unterste Ebene ist Data. Das zugehörige Modul weiß nichts von den über ihr liegenden Module und kann mit diesen nur mit
	indirekt – ~~z.B.~~ durch Antworten auf [[Nachricht]]en oder mit Hilfe des [[Observer-Pattern]]s – kommunizieren.		indirekt – {{zB}} durch Antworten auf [[Nachricht]]en oder mit Hilfe des [[Observer-Pattern]]s – kommunizieren.

	Ein Servicemodul kennt nur die darunterliegende Datenmodule und kann nur auf diese zugreifen		Ein Servicemodul kennt nur die darunterliegende Datenmodule und kann nur auf diese zugreifen
	(sowie ~~i. Allg.~~ auf externe Datenquellen, sofern es nicht nur Filterfunktionen wahrnimmt).		(sowie {{iAllg}} auf externe Datenquellen, sofern es nicht nur Filterfunktionen wahrnimmt).

	Ein Logikmodul kann entweder direkt auf ein Datenmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel		Ein Logikmodul kann entweder direkt auf ein Datenmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel
Zeile 100:		Zeile 100:
	Direkte Zugriffe auf Service- und Datenmodule wären zwar möglich, sind aber nicht vorgesehen.		Direkte Zugriffe auf Service- und Datenmodule wären zwar möglich, sind aber nicht vorgesehen.

	Eine View kommuniziert ~~i. Allg.~~ direkt nur mit Controller-Modulen, um diesen Benutzeraktionen, die über die View erfolgen, mitzuteilen.		Eine View kommuniziert {{iAllg}} direkt nur mit Controller-Modulen, um diesen Benutzeraktionen, die über die View erfolgen, mitzuteilen.
	Ein direkter Zugriff auf ein Datenmodul ist nur dann notwendig, wenn die Nachrichten, die von den Datenmodulen verschickt werden,		Ein direkter Zugriff auf ein Datenmodul ist nur dann notwendig, wenn die Nachrichten, die von den Datenmodulen verschickt werden,
	nicht alle relevanten Informationen enthalten. Zugriffe auf andere Module sind nicht vorgesehen.		nicht alle relevanten Informationen enthalten. Zugriffe auf andere Module sind nicht vorgesehen.
Zeile 107:		Zeile 107:

	====LDVCS-Multicast-Paradigma====		====LDVCS-Multicast-Paradigma====
	Ein LDVCS-Paradigma wird LDVCS-Multicast-Paradigma genannt, wenn alle Module nur indirekt, ~~d.h.~~ mit Hilfe		Ein LDVCS-Paradigma wird LDVCS-Multicast-Paradigma genannt, wenn alle Module nur indirekt, {{dh}} mit Hilfe
	von [[Multicast-Nachricht]]en kommunizieren.		von [[Multicast-Nachricht]]en kommunizieren.

Zeile 153:		Zeile 153:
	zur Manipulation der Spielfigur an die Logik-Komponente ('''Logic''') weitergeleitet.		zur Manipulation der Spielfigur an die Logik-Komponente ('''Logic''') weitergeleitet.

	Man beachte, dass die Logik-Komponente ~~i. Allg.~~ aktiv sein kann: Sie kann die Daten selbstständig, ~~d.h.~~ auch ohne Manipulation durch den		Man beachte, dass die Logik-Komponente {{iAllg}} aktiv sein kann: Sie kann die Daten selbstständig, {{dh}} auch ohne Manipulation durch den
	Controller verändern. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, direkt von der Logik-Komponente gesteuert.		Controller verändern. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, direkt von der Logik-Komponente gesteuert.

	Mit Hilfe einer Service-Komponente ('''Service''') kann das Spiel zu einem Multiuser-Spiel erweitert werden.		Mit Hilfe einer Service-Komponente ('''Service''') kann das Spiel zu einem Multiuser-Spiel erweitert werden.
	Die Service-Komponente hat dann zwei Aufgaben:		Die Service-Komponente hat dann zwei Aufgaben:
	# Die Position des Avatars (~~d.h.~~ der eigenen Spielfigur) an einen zentralen Server zu übertragen.		# Die Position des Avatars ({{dh}} der eigenen Spielfigur) an einen zentralen Server zu übertragen.
	# Die Position anderer Spielfiguren und möglicher Gegner vom zentralen Server zu holen und in die eigene Datenkomponente zu schreiben.		# Die Position anderer Spielfiguren und möglicher Gegner vom zentralen Server zu holen und in die eigene Datenkomponente zu schreiben.

Zeile 173:		Zeile 173:
	Jede der folgenden Änderungen hat lediglich Auswirkungen auf eines der fünf Module:		Jede der folgenden Änderungen hat lediglich Auswirkungen auf eines der fünf Module:

	# Änderung der Darstellung (~~d.h.~~ der View): Die View kann jederzeit durch neue [[Skin]]s aktualisiert werden. Es ist auch möglich, die 2D-Ansicht des Spiels durch eine Pseudo-3D-Ansicht zu ersetzen. Bei einem Multiuser-Spiel hat sowieso jeder Spieler seine eigene Sicht auf die Szenerie.		# Änderung der Darstellung ({{dh}} der View): Die View kann jederzeit durch neue [[Skin]]s aktualisiert werden. Es ist auch möglich, die 2D-Ansicht des Spiels durch eine Pseudo-3D-Ansicht zu ersetzen. Bei einem Multiuser-Spiel hat sowieso jeder Spieler seine eigene Sicht auf die Szenerie.
	# Änderung der Spielsteuerung (~~d.h.~~ des Controllers): Anstelle einer Steuerung der Spielfigur durch die Tastatur kann beispielsweise eine Steuerung der Spielfigur durch eine [[WiiMote]] erfolgen. Hier wäre es auch denkbar, dass der WiiMote-Controller bestimmte Datenänderungen (wie ~~z.B.~~ Kollisionen) per [[Force Feedback]] an den Benutzer zurückmeldet. Dazu muss sich der Controller ebenfalls über Datenänderungen informieren lassen.		# Änderung der Spielsteuerung ({{dh}} des Controllers): Anstelle einer Steuerung der Spielfigur durch die Tastatur kann beispielsweise eine Steuerung der Spielfigur durch eine [[WiiMote]] erfolgen. Hier wäre es auch denkbar, dass der WiiMote-Controller bestimmte Datenänderungen (wie {{zB}} Kollisionen) per [[Force Feedback]] an den Benutzer zurückmeldet. Dazu muss sich der Controller ebenfalls über Datenänderungen informieren lassen.
	# Änderung der Spiellogik (~~d.h.~~ der Logikkomponente): Die KI-Engine zur Steuerung der Gegner kann beispielsweise durch eine bessere Engine ersetzt werden.		# Änderung der Spiellogik ({{dh}} der Logikkomponente): Die KI-Engine zur Steuerung der Gegner kann beispielsweise durch eine bessere Engine ersetzt werden.
	# Änderung der Dateninitialisierung (~~d.h.~~ der Service-Komponente): Wenn die Dateninitialisierung künftig beispielsweise nicht mehr über XML, sondern über SQL erfolgen soll, muss lediglich die entsprechende Service-Komponente ausgetauscht werden.		# Änderung der Dateninitialisierung ({{dh}} der Service-Komponente): Wenn die Dateninitialisierung künftig beispielsweise nicht mehr über XML, sondern über SQL erfolgen soll, muss lediglich die entsprechende Service-Komponente ausgetauscht werden.
	# Änderung des Spielservers (~~d.h.~~ der Service-Komponente): Es ist jederzeit möglich, ein Multi-User-Spiel über einen anderen Server (mit einer anderen Architektur) laufen zu lassen.		# Änderung des Spielservers ({{dh}} der Service-Komponente): Es ist jederzeit möglich, ein Multi-User-Spiel über einen anderen Server (mit einer anderen Architektur) laufen zu lassen.

	Auch die Datenkomponente kann ausgetauscht werden, wenn ~~z.B.~~ andere Datenstrukturen zur Speicherung der Daten eingesetzt werden sollen.		Auch die Datenkomponente kann ausgetauscht werden, wenn {{zB}} andere Datenstrukturen zur Speicherung der Daten eingesetzt werden sollen.
	Es ist darüber hinaus möglich, einer Datenkomponente ~~z.B.~~ mit Hilfe von speziellen Filter-Services Filter vorzuschalten (vgl. [[Aspektorientierte Programmierung]]). Zum Beispiel kann auf diese Weise ein Login-Mechanismus realisiert werden:		Es ist darüber hinaus möglich, einer Datenkomponente {{zB}} mit Hilfe von speziellen Filter-Services Filter vorzuschalten (vgl. [[Aspektorientierte Programmierung]]). Zum Beispiel kann auf diese Weise ein Login-Mechanismus realisiert werden:
	Der Zugriff auf bestimmte Daten wird erst dann erlaubt, wenn ein Login-Vorgang erfolgreich abgeschlossen wurde.		Der Zugriff auf bestimmte Daten wird erst dann erlaubt, wenn ein Login-Vorgang erfolgreich abgeschlossen wurde.