1 Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme Softwarepraktikum WS...

1

Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme

SoftwarepraktikumWS 2007/08

Vorlesung 01 – 24.10.07

Prof. Dr. Reinhard v. HanxledenAG Echtzeitsysteme/Eingebettete Systeme

Institut für InformatikChristian-Albrechts-Universität zu Kiel

2


Vorlesung 01

• Einführung, Logistik• CVS• Rosenkönig - Spielregeln• Gruppeneinteilung

3


Personen

Vorlesung:• Prof. Dr. Reinhard von Hanxleden

[email protected]

Assistenten:• Dipl. Inf. Claus Traulsen (ctr@...)• Dipl. Inf. Kristine Haase (haase@mip...)

Wissenschaftliche Hilfskraft:• Oliver Fleischmann (ofl@...)

4


Allgemeines

• Ziel des Praktikums ist der Gewinn praktischer Erfahrungen in der Durchführung eines größeren, zusammenhängenden SW-Projektes

• Die Bearbeitung erfolgt in Gruppen von jeweils (möglichst) vier Personen

• Jede Gruppe wird einem Betreuer/einer Betreuerin zugeordnet

• Die Vorlesung liefert unterstützendes Wissen für die Durchführung des Praktikums

• Weiterführende Grundlagen zum SW-Engineering allgemein: Informatik III

5


Aufgabenstellung

• Projektinhalt: Erstellung einer Client-Server-Applikation in Java, die das Spiel “Rosenkönig” funktionalisiert– Server koordiniert Spielzüge, hält Daten bereit,

synchronisiert Kommunikation– Einzelne Spieler sind Clients

• Evolution der Funktionalität:1. Bedienung über Kommandozeile

2. Bedienung per GUI (Java Swing)

3. Automatischer Spieler

4. Abschluss: Wettkampf der Spieler untereinander

6


Ablaufplanung I

Das Praktikum ist in 5 Meilensteine gegliedert

1. UML Klassendiagramm für den prinzipiellen Aufbau und UML Sequenzdiagramme für die Kommunikation(3 Wochen, bis 12.-16.11.07)

2. Implementierung des Servers sowie der GUI mit menschlichem Spieler(4 Wochen, bis 10.-14.12.07)

3. Implementierung des Spielers(3 Wochen, bis 14.-18.1.08)

4. Implementierung des Spieler für einen fremden Server(2 Wochen, bis 28.1.-1.2.08)

5. Ausarbeitung und Abschlusspräsentation(2 Wochen, bis 11.2-15.2.08)

7


Ablaufplanung II

• Zu jedem Meilenstein ein Aufgabenzettel• Nach jedem Meilenstein:

– Vorstellung der Ergebnisse• Einzelne Gruppen + Betreuer

• Individuelle Termine

– Zusammenfassung der Ergebnisse durch die Betreuer• Alle gemeinsam

• Mittwöchlicher Vorlesungstermin

• Nach dem 2. und dem 5. Meilenstein– Benotete Präsentation

• Jeweils ca. drei Gruppen gemeinsam + mind. 2 Betreuer

• Individuelle Termine

8


Bewertung

• Scheine sind benotet• Kriterien:

– Präsentationen (nach 2. und 5. Meilenstein)– Qualität von Code und Dokumentation

9


Vorlesung etc.

Vorlesung:• Mittwochs, 14:15 – 15:45

Betreute Rechnerzeiten:• Mittwochs, 16:00 – 18:00, GAP

Durchsprache mit Betreuer:• 45 min/Woche, Termin nach Vereinbarung

10


Homepage

• http://www.informatik.uni-kiel.de/rtsys/teaching/ws07-08/swprak/

• Diese Folien• Aufgabenstellungen etc.• Weiterführende Links

11


Studierendendatenbank

• Anmeldung zu diesem Praktikum• http://www.informatik.uni-kiel.de/ifi/studium-

lehre/studidb/• Siehe Link auf Homepage

12


Die Mailingliste

• [email protected]• Wird in erster Linie zur Informationsweiterleitung

seitens Dozent/Assistent genutzt• Anmeldung über https://lists.informatik.uni-

kiel.de/mailman/listinfo/p-software• Sie sollten sich hier mit ihrem

@informatik.uni-kiel.de account anmelden• Falls Sie nicht wissen, wie Sie Mails von diesem

Account lesen/weiterleiten, siehe http://www.informatik.uni-kiel.de/rbg/mail/mailweiterleitung

13


Das Forum

• http://www.infmath.de/• Wird durch Fachschaft verwaltet• Dient primär dem Informationsaustausch unter

Praktikumsteilnehmern• Gutes Posting:

– Ich habe Problem xyz mit Eclipse – weiß jemand eine Lösung?

• Weniger gutes Posting:– Der Source code für den nächsten Meilenstein ist ...

• Hinweis: Sie sollten sich nicht darauf verlassen, dass der Dozent/die Assistenten regelmäßig das Forum lesen. Bei dringenden Fragestellungen senden Sie bitte eine Mail!

14


Versionskontrolle mit CVSConcurrent Versions System

Die nachfolgende Präsentation basiert auf Folienvon Prof. Dr. Thomas Wilke, CAU Kiel

15


CVS

• protokolliert die Entwicklung eines Dateibaums eines Projekts (mehrerer Projekte)

• unterstützt die Zusammenführung von verteilt vorgenommenen Veränderungen

• vieles mehr

16


Grundlegende Idee

• auf einem Server: zentrales Lager (repository) mit allen Versionen

• bei jedem Nutzer: eine Arbeitsversion (working copy) des Dateibaums

• Kommunikation des Nutzers mit dem Server– Auslesen (checkout): aktuelle Version des Dateibaums

aus dem Lager abrufen– Abgleichen (update): aktuelle Version aus dem Lager in

die eigene Arbeitsversion einbringen– Ablegen (commit): eigene Arbeitsversion ins Lager

übertragen– Hinzufügen (add): neue Dateien und Verzeichnisse

anlegen

17


Konflikte

• Normalfall: cvs verschmelzt beim Abgleich die aktuelle Version im Lager mit der Arbeitsversion des Nutzers.

• Problemfall: Es werden miteinander unvereinbare Abschnitte gefunden.– Benachrichtigung des Nutzers– Markierung der problematischen Bereiche– manuelle Nachbehandlung durch den Nutzer nötig

18


Befehle und Umgebungsvariablen

Befehle• cvs checkout [<file>|<directory>]• cvs update [<file>|<directory>]• cvs commit [<file>|<directory>]• cvs add <file>|<directory>

Umgebungsvariablen• CVSROOT: Wurzel des Lagers• CVS_RSH: Programm zur Kommunikation mit dem

Server (Hier: ssh)

19


Erste Schritte

• SSH Schlüssel generieren$ ssh-keygen -t rsa

Und öffentlichen Schlüssel an den Betreuer schicken(Datei id_rsa.pub liegt im Verzeichnis .ssh)

• $ export CVS_RSH =ssh • $ export CVSROOT= \

:ext:[email protected]−kiel.de:/cvs/sopra01(sopra01 durch eigene Gruppennummer ersetzen)

• Neues Modul anlegen (genau einmal)$ cvs import [MODULE-NAME] [vendor−tag][release−tag]z.B.: $ cvs import my-code my-login my-release

• Modul auschecken (jeder in der Gruppe)$ cvs checkout [MODULE-NAME]

20


CVS – Weiterführende Links

• http://kj.uue.org/papers/cvs-handout.pdf(Mini-Tutorial)

• http://refcards.com/docs/forda/cvs/cvs-refcard-a4.pdf(Quick Reference Card)

• http://de.wikipedia.org/wiki/Concurrent_Versions_System

21


RosenkönigVorstellung, Spielregeln

22


Spielaufbau

• Zwei Spieler: Rot und Weiß• 9x9 Felder mit Token für die aktuelle Position

– Beim Start ist der Code in der Mitte

• maximal 5 Machtkarten pro Spieler– Beim Start genau 5 Karten

• Zusätzlich 4 Heldenkarten

• Machtkarten:– Richtung: Norden, Nord-Osten, Osten, …– Länge: 1-3– Kartenstapel enthält jede Kombination

23


Züge

1. Karte nehmen:– Maximal 5 Karten pro Spieler– Nehme oberste Karte vom Stapel und lege sie offen

aus– Wenn der Stapel leer ist: gemischter Ablagestapel wird

der neue Stapel

2. Ziehen:– Bewege Token gemäß einer Karte– Karte wird abgelegt– Das Zielfeld erhält die eigene Farbe– Wenn das Zielfeld bereits vom Gegner besetzt ist:

Spiele eine Heldenkarte um das Feld zu besetzen

3. Aussetzen:– Falls bereits 5 Machtkarten vorhanden sind, von denen

keine gezogen werden kann.

24


Wertung

• Das Spiel ist zu Ende, wenn kein Spieler mehr ziehen kann

oder

es wurden 52 Felder besetzt.• Für jedes zusammenhängende Gebiet quadriere

die Anzahl der enthalten Felder• Verbindungen über Eck zählen nicht• Die Punkte für alle Felder werden aufaddiert.

Gewonnen hat der Spieler mit der höchsten Punktzahl!

25


OrganisatorischesGruppeneinteilung

Date post:	05-Apr-2015
Category:	Documents
Upload:	friede-rampe
View:	110 times
Download:	2 times

1 Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme Softwarepraktikum WS...

Documents