CI9x - AE2
ACHTUNG: Diese Inhalte werden ab sofort nicht weiter gepflegt. Ab sofort befinden sich sämtliche Inhalte zu diesem Kurs in Logineo, der offiziellen Lernplattform des Berufskolleg Technik Remscheid.
Einfach auf das Logo klicken und Ihr werdet zu der Login Seite geführt.
oder alternativ hier klicken:
externer Link: [Logineo: offizielles Lernmanagement System des BTR]
hier findet ihr die gesammelten Aufgaben der letzten Corona-Wochen (neueste oben, älteste unten)
in blau das Veröffentlichkeitsdatum
in grün das Abgabedatum
veröffentlicht am 02.12.2020
In der heutigen Teamleiter Sitzung haben wir den Fortschritt der einzelnen Teams besprochen. Ebenfalls haben wir ein Inhaltsverzeichnis der Dokumentation besprochen, welches die wesentlichen Themen abdeckt:
- Deckblatt
- Inhaltsverzeichnis
- Erwartung der einzelnen Mitglieder
- Projektbeschreibung
- Projektplanung
- Projektverlauf (mit Schwierigkeiten und Lösungsvorschlägen)
- Beschreibung der einzelnen Rollen
- Use Case Analyse (UCD + UCT)
- Bedienungshinweise Client
- Bedienungshinweise Server
- Beschreibung des Protokolls (inkl. Visualisierung exemplarischen Datenaustausches)
- Fazit der einzelnen Mitglieder (Conclusion in englischer Sprache)
veröffentlicht am 18.11.2020
In der heutigen Teamleiter Sitzung wurden die notwendigen zeitlichen Termine besprochen und der Aufbau einer Dokumentation erläutert. Die besprochenen Dokumente findet Ihr hier:
Download: [Wochenjournal Vorlage]
Download: [Tätigkeitsnachweis für Gruppenmitglieder]
Download: [Präsentation Inhalte einer wissenschaftlichen Arbeit]
wichtig: für dieses Projekt muss kein Literaturverzeichnis, Abbildungsverzeichnis, etc. erstellt werden.
Download: [Gliederungsvorschlag einer Dokumentation]
Abgabetermin: 25.11.2020
Aufgabe CI91/CI92 - Teamleiter only:
Erstellt einen Projektplan für das Projekt "Dont Worry" und bringt diesen in ausgedruckter Form zur nächsten Teamleitersitzung mit.
veröffentlicht am 11.11.2020
Als krönenden Abschluss dieses Faches gibt es ein umfangreiches Projekt.
Dieses Projekt besteht in der Implementierung einer Client-Server Anwendung, die ein "Mensch-Ärgere-Dich-nicht" Spiel als Netwerkanwendung realisiert.
Mit dabei sind die Fächer Deutsch/Kommunikation und Englisch.
Abgabetermin: 18.12.2020
Aufgabe CI91/CI92:
Implementiert das Buzzerspiel so, dass es mit dem vorgegebenen Protokoll funktioniert. Ihr benötigt dazu zwei Server-Instanzen der Klasse clsTCPWrapper in der Server-Anwendung.
Download: [Aufgabenstellung des Projektes]
Download: [notwendiges / hilfreiches Material für diese Aufgabe]
veröffentlicht am 09.11.2020
Für das Buzzer Spiel gibt es jetzt eine vollständige Lösung. Damit Ihr einen Ansatz habt für eigene Entwicklungen, stelle ich die Lösung hier zur VErfügung:
Download: [Lösung für Buzzerspiel]
Die Lösung verwendet eine Zählvariable, die hochgezählt wird, wenn sich jemand auf dem Server verbunden hat.
In der Informatik nennt man so etwas eine Semaphore.
Bedeutung einer Semaphore
Eine Semaphore ist eine Datenstruktur (im einfachsten Fall eine Zählvariable), die hoch-/runter gezählt wird um eine begrenzte Anzahl einer Resource zu verwalten.
Beispiel
Einfaches Beispiel: Unser BuzzerServer kann zwei Verbindungen zu zwei Clients aufbauen. Danach ist er "voll". Eine Zählvariable zeigt jetzt an, wieviele "Verbindungen" der Server noch annehmen kann.
Das Programm kann sich sonst nämlich nicht merken, wieviele Clients sich noch verbinden können.
Davon abgrenzen muss man ein Mutex.
Bedeutung eines Mutex
Mutex ist die Abkürzung von Mutual Exclusion. Also gegenseitiger Ausschluss. Das ist dann wichtig, wenn zwei verschiedene Teilnehmer (bspw. Clients) nicht gleichzeitig agieren dürfen.
Beispiel
Bei unserem TicTacToe darf ja immer nur ein Spieler dran sein. Das heißt der andere Spieler darf keine Knöpfe drücken. Weil auf dem virtuellen Spielbrett ja immer nur einer aktiv sein kann.
Dazu verwendet man ein "Mutex", das kann beispielsweise eine bestimmte "Zeichenfolge" sein, die an einen Client übermittelt wird. Dann weiß dieser, dass er jetzt dran ist. Wenn er fertig ist, schickt er diese "Zeichenfolge" an den nächsten weiter.
Port Brokering
Wie funktioniert es eigentlich, dass sich mehrere Clients auf einen Server verbinden können?
Zunächst einmal benötige ich für jeden Client einen freien Port und einen laufenden Server.
Aus Client Sicht gibt es jetzt ein Problem, er muss nämlich wissen, welcher Port gerade frei ist. Das ist aber für einen Client ziemlich blöd, denn er müsste dann ja alle Ports ausprobieren. Welche Ports nämlich schon belegt sind, dass kann der Client ja vorher gar nicht wissen.
Dazu setzt man sogenanntes Port Brokering ein. Das bedeutet, dass es einen Anmeldeport gibt, auf dem sich ein Client zunächst verbindet. Dort bekommt er dann eine bestimmte Portnummer zugewiesen und er baut die "Anmeldeverbindung" dann ab und wechselt auf einen anderen Port. Das heute besprochene Protokoll sieht so aus:
Download: [Protokoll für Port Brokering]
veröffentlicht am 04.11.2020
Ziel der heutigen Stunde war das Implementieren eines Buzzer Programms, nachdem das Protokoll vorliegt.
Ein Buzzer Spiel besteht aus 2 Clients und einem Server. Der Server verwaltet die beiden Buzzer und schaltet das Spiel frei. Wenn einer der beiden klickt, dann wird der Gegner abgeschaltet. So etwas benötigt man beispielsweise bei Gewinnspielen, oder Shows, damit man weiß, welches Team zuerst gedrückt hat.
Das verwendete Protokoll findet Ihr hier:
Download: [Protokoll für Buzzer Spiel]
und das zugehörige Framework, in das das ganze implementiert werden soll, gibt es auch zum Download:
Download: [FrameWork für VB.net für Buzzerspiel]
Abgabetermin: 11.11.2020
Aufgabe CI91/CI92:
Implementiert das Buzzerspiel so, dass es mit dem vorgegebenen Protokoll funktioniert. Ihr benötigt dazu zwei Server-Instanzen der Klasse clsTCPWrapper in der Server-Anwendung.
veröffentlicht am 28.10.2020
Ein Protokoll zu beschreiben besteht formal zunächst aus der textuellen Beschreibung des Ablaufs und einer Tabelle der zugehörigen syntaktischen Befehle und deren Semantik.
Meistens reicht das aber nicht aus, um den Ablauf sich gut vorstellen zu können. Daher bietet es sich an, eine Visualisierung zu verwenden, die die hin- und herlaufenden Nachrichten darstellt.
Das folgende Arbeitsblatt stellt diesen Ablauf dar
[Download - Arbeitsblatt zur Visualierung von Protokollen]
veröffentlicht am 22.10.2020
Wie bereits angekündigt, stelle ich Euch hier eine funktionsfähige Version zur Verfügung. Dann könnt Ihr mal schauen, ob diese Version mit Eurem Client oder Server funktioniert. Oder Ihr könnt einfach nachschauen, wie diese Lösung implementiert worden ist.
[Download - TicTacToe Musterlösung]
veröffentlicht am 30.09.2020
Vor der Klassenarbeit haben wir uns mit der Protokoll-Entwicklung beschäftigt. Die Klasse CI92 ist etwas weiter (aufgrund einer Menge Vertretungsunterricht) und hat schon ein funktionsfähiges TicTacToe Spiel programmiert.
Leider hinkt die Formalisierung und die Entwicklung des zugehörigen Protokolls enorm hinterher. Daher ist die Aufgabe diesmal etwas getrennt. Die CI91 soll nämlich von den Ergebnissen der CI92 profitieren können.
Abgabetermin: 05.10.20 bzw. 07.10.2020
Aufgabe CI91:
Damit wir in der nächsten Stunde direkt mit der Implementierung eines vorhandenen Protokolls für TicTacToe anfangen können, sollt Ihr bitte bis kommenden Mittwoch ein Interface für einen TicTacToe Server und einen TicTacToe Client erstellen.
Ihr braucht noch keinen Code reinschreiben, sondern nur die Buttons und notwendigen Textfelder für die Bedienung der Software erstellen. (Achtet auf die korrekte Benennung der Steuerelemente). Ihr könnt Euch auch ruhig grafisch austoben, so dass das Interface nachher auch schön aussieht.
Aufgabe CI92:
Ich gehe mal davon aus, dass S.W. bereits sein TicTacToe Spiel den anderen zur Verfügung gestellt hat / das Funktionsprinzip erklärt hat. Daher ist die Aufgabe bis Montag eine schriftliche Aufstellung der über das Netz gesendeten Befehle mit zugehöriger Semantik zu erstellen.
Dann können wir am Montag das TicTacToe Protokoll abschliessen.
Abgabetermin: 14.09.2020
Heute ist das Thema das Verständnis für State Machines gewesen. Eine State-Machine ist eigentlich nur ein Modell einer Maschine, die sich in verschiedenen Zuständen befinden kann. Im Unterricht haben wir das folgende Infoblatt besprochen:
[Infoblatt mit dem Beispiel eines Drehkreuzes als State-Machine]
Man kann sich eine State-Machine aber auch per Video erklören lassen:
externer Link: [Youtube - What is a state machine]
externer Link: [studyflix: Erklärung in Textform und mit Videos]
Wenn man das ganze überträgt auf unseren Server, dann erhält man folgende Diagramme:
[Infoblatt State Machines des Clients und des Servers]
Aufgabe:
Erarbeitet Euch die State Machine des Servers und versucht einen Server zu implementieren. Achtet dabei darauf, dass Ihr einen zusätzlichen Timer zur Überprüfung des "IsPending" zustandes braucht.
Abgabetermin: 01.09.2020
Während des Unterrichts haben wir erfolgreich einen Client implementiert. Als nächsten Schritt müssen Daten empfangen werden.
Aufgabe:
Implementiert und verbessert Euren Client zu einem guten "Chat-Client". Dazu müssen die notwendigen Eingabefelder vorhanden sein. Natürlich dürft Ihr Euer Interface auch schön "designen".
Zusätzlich soll ein Timer eingebaut werden, der in einem regelmäßigen Intervall überprüft ob Daten vorhanden sind und diese ggfs mit Hilfe von getData wieder abholt.
BTR-LMS
Die Login-Daten erhalten Ihr von euren Fachlehrern (m/w/d)
(auf das Logo klicken)
BTR-Website
Die offizielle Website des Berufskolleg Technik Remscheid findet Ihr / Sie unter:
Aurochs DMS
Ein Dokumentenmanagement speziell für Lehrer*innen findet man hier: