Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Praktikum OOAD I) Ziel des Praktikums Im Rahmen des OOAD-Praktikums sollen Sie verschiedene Aufgaben, die im
Zusammenhang mit der UML-Modellierung stehen, lösen. Als Anwendungsszenario
dient die Entwicklung eines einfachen Lottospiels. Der fachliche Inhalt der
einzelnen Sitzungen baut aufeinander auf, so dass Sie immer auf demselben
Problembereich arbeiten werden. Im Laufe des Praktikums entstehen so ein UML-
Modell und zugehöriger Code.
Das Praktikum findet im CASE-Labor D14/211 statt. Dort stehen Ihnen Linux-
Maschinen zur Verfügung, auf welchen das CASE-Tool MagicDraw installiert ist. Es
wird die UML in der Version 2 verwendet.
Weitere nützliche Informationen finden Sie auf der Labor-Homepage unter
https://www.fbi.h-da.de/labore/case/laborausstattung/magicdraw.html.
II) Gliederung des Praktikums Das Praktikum ist in 3 Aufgaben gegliedert. Für die ersten 2 Aufgaben sind 2
Termine, für die 3. Aufgabe 1 Termin eingeplant. Spätestens zwischen dem 1. und 2.
Termin einer Aufgabe sollten Sie die Aufgabe so weit vorbereitet haben, dass die
Abnahme am Ende des 2. Termins möglich ist. Es verwendet als Beispiel die
Spezifikation und Realisierung eines Lottospiels.
Nachfolgend sind die Themenschwerpunkte pro Praktikumsaufgabe aufgelistet:
− Einführung in MagicDraw(CASE-Werkzeug) mit einem Beispiel-Use-Case-
Diagramm und einem Beispiel-Klassendiagramm
− Analysemodell, Design-Modell (Use-Case- ,Klassen- und Sequenzdiagramm),
Generierung der Coderahmen, Implementierung und Test des Lotto-Systems
Seite 1
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
− Reverse-Engineering und Nachdokumentation mit Anpassung der Sequenz-
und Klassendiagramme.
III) Testat und Regeln Je nach Größe der Praktikumsgruppe wird entweder alleine (falls genügend
Arbeitsplätze vorhanden) oder in 2-er Teams gearbeitet. 3-er-Teams sind nicht
zugelassen. Die 2-er Teams bleiben das ganze Praktikum über gleich.
Die erfolgreiche Bearbeitung der Aufgaben zur Erstellung des UML-Modells sowie
die lauffähige C++-Implementierung ist Voraussetzung für das Testat von OOAD
und somit zur Zulassung zur schriftlichen Prüfung am Ende des Semesters.
Bitte beachten Sie die veröffentlichten Praktikumstermine und Ihr x/y-Raster. Es
besteht Anwesenheitspflicht. Unentschuldigtes Fehlen führt zum Nichtbestehen des
Praktikums!
Zu Beginn jeder Aufgabe wird der Vorbereitungsteil bei jedem Teilnehmer
überprüft. Bei der Vorbereitung geht es weniger um eine perfekte Lösung sondern
darum, dass Sie sich intensiv mit dem Thema beschäftigt haben. Nur dann können
Sie im Praktikum entsprechende Fragen stellen und erzielen den optimalen
Vorbereitungseffekt für die Klausur am Ende des Semesters.
Die ideale Vorbereitung besteht darin, dass Sie die Aufgabe zuerst alleine angehen
(wie in einer Klausur) und dann mit Ihrem Praktikumspartner ein gemeinsames
Ergebnis erarbeiten. Dabei fallen Ihnen sicher einige Unklarheiten auf, die Sie im
Praktikumstermin klären können (d.h. vor der Klausur).
Fehlt die Vorbereitung, erhalten beide Teammitglieder eine gelbe Karte. Nach 2
gelben Karten gilt das Praktikum als nicht bestanden!
Nach jeder Praktikumsaufgabe (am Ende des 2., 4. und 5. Praktikumstermins) wird
das Erreichen der Ziele von den Betreuern festgehalten und die jeweilige Übung
abgenommen. Sofern Sie aufgrund von Mängeln die Übung nicht abgenommen
Seite 2
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
bekommen, besteht die Möglichkeit, dies bis zum nächsten Praktikumstermin
nachzuholen. Die Abnahme erfolgt dann direkt zu Beginn des nächsten Praktikums.
Sofern auch die Nachbesserung nicht zur Abnahme führt, gilt das Praktikum
insgesamt für das Team(!) als nicht bestanden, also kein Testat!
Es sind auch Diskussionsrunden geplant, in denen eine Gruppe Ihre Lösung den
anderen Gruppen vorstellt. Anschließend werden andere Gruppen
Alternativlösungen zu einigen Punkten der vorgestellten Lösung einbringen, die
dann in der Runde diskutiert werden können.
Achtung:
Sie verwenden im Praktikum Ihren persönlichen Filespace auf Userv. Falls Sie dies
noch nicht getan haben, müssen Sie im OBS unter „Passwort ändern“ ein Passwort
für diesen Account eintragen. Tauschen Sie die erarbeiteten Daten am Ende des
Praktikums mit Ihrem Partner aus, damit z.B. im Krankheitsfall weiter gearbeitet
werden kann.
IV) Praktikumsdurchführung Das CASE-Labor verfügt über verschiedene Softwareprodukte um die Entwicklung
von Software zu professionalisieren und zu vereinfachen.
Eine kurze Einführung in das Betriebssystem befindet sich unter http://www.fbi.h-
da.de/
labore/case/laborausstattung unter der Rubrik „Einführung in die Hard- und
Software“.
Tätigkeiten beim 1. Einloggen im CASE-Labor:
Einloggen mit dem UServ-Account:
Seite 3
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Username: i konkateniert mit <h_da-account>
Beispiel: Hans Müller hat sthamuel als h_da-Account.
Dann ist der UServ-Account isthamuel
Passwort: Ihr persönliches Labor-Passwort aus OBS
Initialisierung der Praktikumsumgebung Öffnen Sie eine Konsole. Dazu klicken Sie unten links auf das KDE-Symbol und
wählen
Sie Konsole (Terminal).
In der Konsole geben Sie einen Befehl ein, der die Praktikumsumgebung für Ihren
Zug herstellt z.B. /soft/ini2B. Den genauen Namen erfragen Sie bitte bei Ihrem
Betreuer.
Tätigkeiten beim ersten und späteren Einloggen im CASE-Labor: Nach dem Einloggen mit Ihrem Usernamen und Passwort (s. o.).
sollten Sie, falls noch nicht geschehen, zum Classic Menü switchen (unten links,
rechte Maustaste auf „K“-Button). Dann auf K-Button, development/magic draw Dadurch startet die Magic-Draw-Anwendungsoberfläche
Öffnen Sie das durch das „ini2B-Programm“ erstellte Projekt durch Open Project,
Magic Draw Projekte (auf Symbol drücken), OOAD.mdzip. Dann: Rechte Maustaste
auf Data - Neues Package Mensa anlegen (nicht neues Projekt!). Dann am besten
Unter-Pakete für Analyse / Use-Case etc. anlegen.
V) Am Ende des Praktikums Beide Personen einer Arbeitsgruppe müssen Zugriff auf die Modelldaten haben
(falls ein Arbeitsgruppenmitglied krank ist). Sie sollten deshalb das Projekt am Ende
Seite 4
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
der Übung austauschen d.h. z.B. auf den Userv-Arbeitsbereich des anderen
kopieren.
Das können Sie mit dem folgenden Befehl in einer Konsole tun (Der Doppelpunkt
am Ende des Befehls ist wichtig!)
scp –r <<Mein_Ordner_oder_Datei>> <<istUser>>@userv-shell.fbi.h-da.de:
VI) Fachliches Szenario
Als durchgängiges Beispiel für das OOAD-Praktikum wird ein einfaches Lottospiel
verwendet. Zunächst werden die fachlichen Anforderungen beschrieben. Da es sich
um ein recht kleines und konkretes Szenario handelt, wird auf eine gesonderte
Geschäftsprozessanalyse verzichtet. Auch die Beschreibung der Benutzerinteraktion
mit dem System (z.B. als Use Cases) wird in der ersten Übung vernachlässigt.
Stattdessen soll direkt aus den vorgegebenen Anforderungen ein Design entwickelt
werden. Im weiteren Verlauf des Praktikums wird das Design bis zur
Implementierung verfeinert.
Fachliche Anforderungen „Lotto“ Entwickeln Sie eine Software für eine Teilnahme an einer Lottoziehung:
− Es nehmen mehrere Spieler teil. Zu Beginn gibt jeder Spieler einen Tipp ab, d.
h. er gibt folgende Daten ein:
− seine Adresse
− 6 Zahlen zwischen 1 und 49
− Nach „Abgabe“ des Lotto-Tipps werden 6 Zahlen gezogen.
− Nach der Ziehung werden die Ergebnisse bekannt gegeben.
Als Ausgabe erzeugen Sie folgendes Menü:
=== Lotto Menü === 1 Tippzettel ausfüllen 2 Glückszahlen ziehen 3 Ergebnis bekannt geben 0 BEENDEN Auswahl(0-3): _
Seite 5
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Erklärung der einzelnen Menüpunkte:
Tippzettel ausfüllen: Die Spieler werden nacheinander dazu aufgefordert,
ihre Adresse und 6 Zahlen zwischen 1 und 49 einzugeben. Eine Zahl kann pro
Spieler nur einmal gesetzt werden.
Glückszahlen ziehen: Es werden 6 verschiedene Zufallszahlen zwischen 1
und 49 erzeugt und auf dem Bildschirm ausgegeben.
Ergebnis bekannt geben: Die gezogenen Zahlen und die Tipps aller Spieler
werden ausgegeben. Bei jedem Spieler wird ausgegeben wie viele Zahlen
richtig getippt wurden.
Der Benutzerdialog der Anwendung der obigen Aufgaben ist robust zu gestalten,
d.h. keine Eingabe darf zu Programmabbrüchen, Endlosschleifenschleifen oder
sonstigen unerwünschten Effekten führen. Dabei ist insbesondere auf die genaue
Abfolge zu beachten: Es darf erst zur Ziehung der Zahlen bzw. zur
Ergebnisermittlung kommen, wenn die Spieler getippt haben.
Weitere fachliche Anforderungen finden Sie bei den einzelnen Praktikumsaufgaben.
Seite 6
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
1. Praktikumsaufgabe
Ziele des 1. Praktikums Zuerst sollen Sie sich mit der grundlegenden Bedienung des CASE-Tools
MagicDraw vertraut machen. Hierfür wurde eine Anleitung geschrieben, die auf die
Bedürfnisse des Praktikums abgestimmt ist und Ihnen einen Überblick über Magic
Draw gibt. Die Anleitung finden Sie hier:
https://www.fbi.h-da.de/fileadmin/personal/m.schreeck/documents/MagicDraw-
Anleitung.pdf
Weitere genauere Anleitung zu speziellen Diagrammen oder Vorgehensweisen
finden Sie auf der Seite des Case-Labors.
Anschließend wenden Sie das Erlernte an und erstellen dabei ein Klassenmodell für
unsere Praktikumsanwendung „Lottospiel“.
Vorbereitung des 1. Praktikumstermins ( jeder Teilnehmer einzeln!) - Lesen Sie die Anleitung für MagicDraw.
Schlagen Sie in einem Buch zur UML, in Wikipedia oder auch unter www.omg.org
folgende Begriffe nach und schreiben Sie deren Bedeutung möglichst mit einem
Beispiel auf (handschriftlich, pro Person ca. 1 Seite):
Use-Case (=Anwendungsfall)
Use-Case-Diagramm
Klasse
Attribut
Methode (einer Klasse)
Klassendiagramm
Assoziation
Aggregation
Seite 7
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Generalisierung / Vererbung
Des Weiteren sollten Sie sich bereits mit der Hochschulanleitung für MagicDraw
beschäftigt haben.
Hinweis Nutzen Sie diesen Termin, um sich mit dem mächtigen Programm vertraut zu
machen und dadurch später Fehler zu vermeiden. Beachten Sie, dass beide
Praktikumspartner mit der Praktikumsumgebung und insbesondere auch mit
MagicDraw vertraut sein müssen.
Aufgabe Teil I: Spielmodell 1.1) CASE-Tools sind nicht immer intuitiv zu bedienen. Um Fehler im
eigentlichen Projekt zu vermeiden, sollen Sie in diesem Teil des Praktikums die
Zeit nutzen, sich mit dem Programm vertraut zu machen. Daher ist es wichtig,
dass sie eigenständig herum experimentieren und die einzelnen Funktionen
ausprobieren. Bei Fragen und Problemen wenden Sie sich bitte an Ihren
Betreuer.
1.2) Erstellen Sie ein neues Projekt Mensa. Kreieren Sie anschließend ein
Use-Case-Diagramm und ein Klassendiagramm und geben Sie die unten
aufgeführten Diagramme ein. (Teilweise werden die Stereotypen (z. B.
<<constructor>>) oder Kommentare (z. B. {getter …}) in der jetzigen
Version/Voreinstellung von Magic Draw anders oder gar nicht angezeigt.)
Nutzen Sie bei der Erstellung der Diagramme die auf der FBI-Seite unter
Labore/CASE-Labor/Laborausstattung/magicDraw hinterlegten Anleitungen, in der
alles hinreichend erklärt sein sollte (Punkte Einführung Magic Draw,
Klassendiagramm). Bei Fragen und Problemen können Sie sich selbstverständlich
Seite 8
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
immer an Ihren Betreuer wenden.
1.3) Wichtiger Lerneffekt ist hierbei auch, dass die Existenz der Klassen nicht
mit dem Vorhandensein im Klassendiagramm zusammenhängen. Entfernen Sie
daher die Klasse Geldeinzug aus dem Diagramm und fügen Sie sie erneut hinzu
(rüberziehen). Was passiert? Hierbei sollten auch die Funktionen zur
automatischen Anzeige der Assoziationen verwendet werden (display path).
Beachte: Entferne-Taste: Entfernen aus Diagramm, STRG+D: Löschen aus Projekt
Wenn Sie (bzw. bei 2-er Gruppen BEIDE) nun mit der Praktikumsumgebung und
insbesondere auch mit dem CASE-Werkzeug MagicDraw vertraut sind, zeigen Sie
Ihr Diagramm bitte dem Betreuer, dann können Sie den 2. Teil der Aufgabe
angehen.
Seite 9
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Seite 10
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Aufgabe Teil II: Modellierung nach Vorgabe
Eine erste Analyse der fachlichen Anforderungen wurde bereits durchgeführt und
hat die ersten Klassen ergeben. Das Klassendiagramm ist noch nicht vollständig! In
der nächsten Praktikumsaufgabe soll das Diagramm erweitert werden.
1.1) Erzeugen Sie ein Klassendiagramm mit dem
Namen „Lotto Deluxe“.
1.2) Fügen Sie folgende Klassen und die zugehörige Dokumentation ein
und ordnen die Klassen wie in der Abbildung an.
Klasse Dokumentation
Lotto Dies ist die zentrale Steuerung des Lottospiels inklusive GUI. Sie
erzeugt die erforderlichen Klassen und verwaltet die
teilnehmenden Lottospieler (Tippzettel).
Tippzettel Ein Tippzettel beinhaltet die Zahlen von 1 bis 49. Davon können
6 Zahlen ausgewählt werden. Außerdem „kennt“ ein Tippzettel
seinen Besitzer. Realisieren Sie die Zahlen über ein Array von
bool-Variablen, wobei die Arraykomponente (z. B. zahl[7]) ==
true, wenn diese Zahl (z. B. 7) getippt ist.
Adresse Diese Klasse verwaltet die Adressdaten zu einem Tippzettel
1.3) Nun erweitern Sie die Klassen mit folgenden Klassenattributen:
Seite 11
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Klasse Attribut Sichtbarkeit
Lotto
Tippzettel bool getippteZahl[50]; privat
Adresse string name;
string strasse;
string ort;
privat
privat
privat
1.4) Im nächsten Schritt erweitern Sie das Modell um folgende
Assoziationen (inkl. Multiplizitäten, Navigationsrichtungen).
MagicDraw legt für die Aggregation zwischen Lotto und Tippzettel, eine Variable
wie Lotto oder ein Feld wie Tippzettel[1..*] an. Im C++Programm benötigen wir
später eine Datenstruktur mit einem oder einer variablen Anzahl von Pointer-
Variablen. Dazu müssen Sie zu dem Attribut unter Spezifikation bei einem einzelnen
Pointer den Type Modifier auf $* setzen bzw. bei einer Menge (Vector) of Pointers
im Container std::vector<$*> setzen. (siehe Magic-Draw Beschreibung
Klassendiagramme).
Klasse 1 Beziehungsart Klasse 2
Lotto gerichtete Aggregation →
(1,*)
Tippzettel
Tippzettel gerichtete Komposition →
(1,1)
Adresse
Seite 12
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
1.5) Erweitern Sie die Klassen um (public-)Methoden. Beachten Sie dabei, dass
Standardmethoden wie Konstruktoren, Destruktoren, Getter oder Setter auch als
solche vom System angelegt werden sollen (siehe Magic-Draw/Klassendiagramm-
Beschreibung):
Klasse Methode
Lotto Lotto();
virtual ~Lotto(void);
virtual void LottoGUI();
virtual void setzen();
virtual void ziehen();
virtual void ErgebnisAusgeben();
Tippzettel Tippzettel();
virtual void ausfuellen();
virtual string getAdresse();
Adresse Kostruktor und alle Setter und Getter
Überlegen Sie anhand der fachlichen Beschreibung auf Seite 5, was diese
Methoden tun sollen und beschreiben Sie dies innerhalb der Spezifikation.
Ihr Diagramm sollte nun ungefähr so aussehen:
Seite 13
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
+
Seite 14
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
1.6) Überprüfen Sie das Modell auf falsch gelöschte Klassen und
Assoziationen. Dazu kontrollieren Sie die Objekte im Objektbaum.
1.7) Wenn Sie das vorläufige Design-Modell vollständig erstellt und
geprüft haben, kann die Abnahme durch den Praktikumsbetreuer
erfolgen.
Vergessen Sie nicht, die Ergebnisse mit Ihrem Praktikumspartner
auszutauschen.
Außerdem sollten Sie sich darüber verständigen wie Sie die Vorbereitung
für die nächste Übung angehen. Wegen des Umfangs der nächsten
Aufgabe sollten Sie schon vor Beginn des nächsten Praktikumstermins an
der Arbeit für die nächste Aufgabe beginnen.
Seite 15
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
2. Praktikumsaufgabe
Ziel
In der ersten Praktikumsaufgabe haben Sie ein UML-Modell für ein Lottospiel
begonnen. Dieses Modell soll jetzt so erweitert werden, dass es die gesamte
Aufgabenstellung abdeckt und daraus Coderahmen erzeugt werden können.
Vorbereitung
Die Vorbereitung wird pro Person durchgeführt und überprüft! Alle erzeugten
Dokumentationen (Anwendungsfall, Modelländerungen und
Ablaufbeschreibung) sind handschriftlich anzufertigen. Die Vorbereitung
besteht aus 3 Teilen (a bis c). Lesen Sie den Abschnitt Fachliches Szenario auf Seite 5 noch einmal genau
durch.
a) Entwerfen Sie das Anwendungsfalldiagramm mit mehreren
Anwendungsfällen für das komplette Lottospiel. Die Anwendungsfälle sollen alle
möglichen Durchläufe durch Ihr System abdecken. Schreiben Sie die
Anwendungsfälle auf (in Magic Draw im Fenster links unten unter
Dokumentation oder Spezifikation und links Dokumentation/Hyperlinks).
Verwenden Sie das Muster aus der Vorlesung (Use Case Name: …., Primary
Actor: …, evtl. auch mit zusätzlichen Eintrag Vorbedingung). In der
Ablaufbeschreibung gehen Sie bitte auf die einzelnen Aktionen ein.
Analysieren Sie die Anwendungsfälle und überlegen Sie, welche Systemteile
noch fehlen und wie Sie diese in Ihrem Entwurf umsetzen wollen.
Als Leitlinie bei der Bestimmung der Klassen können Sie das Entwurfsprinzip
Seite 16
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
„Trennung von Zuständigkeiten“ verwenden:
Unterteile das System so in Teile, dass jeder Teil genau eine Aufgabe hat!
− Diese Aufgabe wird auch nur von diesem Teil erledigt
− Die Abgrenzung gegenüber anderen Teilen ist klar erkennbar
− Die Aufgabe ist genau und prägnant definiert und spiegelt sich
im Namen des Teils wider
− Trenne Teile an denen sich (voraussichtlich) keine Änderungen
ergeben, von Teilen an denen sich wahrscheinlich Änderungen
ergeben!
Vorteil von getrennten Zuständigkeiten:
Ein Systemteil, der nur eine Zuständigkeit hat, ändert sich nur, wenn
an dieser einen Zuständigkeit eine Änderung nötig wird! Das
verbessert die Wartbarkeit.
b) Überlegen Sie sich, welche Analyseklassen es gibt und welche Attribute
diese Analyseklassen haben. Danach leiten Sie daraus die Desingklassen ab
und definieren dazu Methoden, evtl. zusätzliche Attribute und
Assoziationen (Erweiterung / Änderung des bereits von Ihnen erstellten
Klassendiagramms.)
Beschreiben Sie für Elemente, die nicht selbsterklärend sind, was seine
Aufgabe ist (wieder unter dem Reiter Dokumentation im Fenster unten
links). Z. B. was sich hinter der Klasse Lotte verbirgt, wie die getippten
Zahlen abgespeichert sind oder wie der Abgleich zwischen getippten Zahlen
und gezogenen Glückszahlen durchgeführt ist.
Achten Sie darauf, dass die Spezifikation einer Klasse eine klare Aufgabe
beschreibt. Ist dies nicht der Fall, sollten Sie noch einmal über die „Trennung
von Zuständigkeiten“ nachdenken.
Seite 17
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
c) Zur Überprüfung „spielen“ Sie mit Ihren Klassen und Methoden die
Szenarios aus den Anwendungsfällen durch. Hierbei geht es darum zu
überprüfen, ob alle nötigen Klassen und Methoden vorhanden sind und ob stets
die notwendige Information übergeben und zurückgegeben wird. Schreiben Sie
auf, wie Sie mit Objekten Ihrer Klassen und Aufruf von Methoden den
Anwendungsfall durchführen und dokumentieren Sie die Aufrufe. Dies
können Sie entweder mit Sequenzdiagrammen tun oder, falls
Sequenzdiagramme noch nicht in der Vorlesung behandelt wurden, auch in
Textform. (Dann müssen Sie die Erstellung der Sequenzdiagramme später
nachholen.) Wichtig ist, dass aus Ihrer Darstellung genau hervorgeht, welche
Methoden von wem wann mit welchen Argumenten aufgerufen werden, was
der Zweck der Methoden ist und welche Ergebnisse zurückgeliefert werden.
Verdeutlichen Sie sich außerdem in Ihrem Ablauf, welcher Schritt des jeweiligen
Anwendungsfalles durchgeführt wird.
Hinweis: Arbeiten Sie sorgfältig und durchdenken alles genau, denken Sie auch
an „Nebensächlichkeiten“ wie bspw. das Anlegen von Objekten. Jeder Fehler
oder jede Ungenauigkeit erschwert Ihnen später die Programmierung.
Aufgabe
In diesem Praktikum sollen Sie ein einfaches Lottospiel in der Analyse- und
Designsicht vollständig modellieren und dazu Coderahmen generieren.
Grundlage ist das zuvor entwickelte Teilmodell.
Dazu erfassen Sie die Anwendungsfälle und verfeinern und ergänzen das
bestehende Modell Klassendiagramm um neue Klassen (Tipp: Es sollten insgesamt 4
bis 5 Klassen entstehen.), Methoden, Attribute und Assoziationen. Auch Fehler sind
Seite 18
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
zu korrigieren. (z. B. falsche Art von Parametern, sind wirklich alle benötigten
Attribute aufgeführt, sind alle Operationen notwendig?) Anschließend werden
Coderahmen für die Implementierung erzeugt.
2.1) Loggen Sie sich ein und öffnen Sie das Projekt. Sie sehen Ihre Klassen vom
letzten Praktikumstermin und das Klassendiagramm.
2.2) Erfassen Sie das Anwendungsfalldiagramm mit mehreren
Anwendungsfällen für das komplette Lottospiel im Tool. Die Anwendungsfälle
sollen alle möglichen Durchläufe durch Ihr System abdecken. Geben Sie die
Beschreibung der Anwendungsfälle gemäß Cockburn ein.
2.3) Öffnen Sie das Design-Klassendiagramm „Lotto Deluxe“ und ergänzen
Sie das Diagramm um die Ergebnisse aus Ihrer Vorbereitung1. Tragen Sie zu
jedem neuen Modellierungselement die Dokumentation ein, die Sie sich als
Vorbereitung überlegt haben. Zeigen Sie in den Klassen die Assoziationsenden
als Attribute an (Siehe Beschreibung „Konfiguration“ im Internet, Anzeige der
Assoziationsenden). Geben Sie den Attributen zu Assoziationsenden über
Spezifikation noch Namen. Bei Kompositionen liegt das/die in Beziehung
stehende(n) Objekt(e) direkt in der Klasse, zu der es(sie) gehört/gehören, bei
Assoziationen und Aggregationen zeigt der Pointer oder Vector of Pointer auf
das/die Objekt(e) in der anderen Klasse.
2.4) Um sich über die Struktur Ihres Programms im Klaren sein, stellen Sie
parallel zur Erstellung des Design-Klassendiagramms, die Funktionen und die
Funktionsaufrufe mit Hilfe eines Sequenzdiagramms graphisch dar. Falls Sie
1 Denken Sie unbedingt daran Standardmethoden wie Konstruktoren, Destruktoren, Getter- und Settermethoden und
Standardattribute (Implementierung der Assoziationen) auch so anzulegen, wie Sie es in der 1. Übung gelernt haben.
Seite 19
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Sequenzdiagramme in der Vorlesung noch nicht behandelt haben, überlegen
Sie sich bitte welche Funktionen vom Programm aufgerufen werden müssen um
Seite 20
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
die gestellte Aufgabe zu erledigen.
(Siehe Punkt c dieser Aufgabe.)
◦ Der Anfang des Programms ist durch obiges Sequenzdiagramm dargestellt
(dieses Sequenzdiagramm müssen Sie nicht im System erfassen!):
Bitte zeichnen Sie die Sequenzdiagramme zu den Combined Fragments
SDsetzen, SDziehen und SDergebnisAusgeben. Bitte tragen Sie alle
Konstruktoraufrufe, Funktionsaufrufe, Destruktoraufrufe, Returns und die
Kommunikation zwischen Aktor und Objekten in die Diagramme ein. Für
Schleifen, Verzweigungen und Untersequenzdiagrammen sind
„Combined Fragments“ zu verwenden. Hier noch der Anfang des
Sequenzdiagramms SDsetzen:
Prüfen Sie nach der Erstellung der Sequenzdiagramme, ob
Seite 21
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Sequenzdiagramme und Klassendiagramm zueinander konstistent sind
(sind alle in den Klassendiagrammen definierten Funktionen in den
Sequenzdiagrammen vorhanden? …)
2. 5) Erstellen Sie nun das Code-Engineering-Set und konfigurieren Sie es so,
dass alle benötigten Klassen erzeugt werden. (Siehe hierzu Forward/Revers
Engineering im Internet)
Achtung! Bevor Sie ab hier weitermachen, sollten Sie Ihr Modell mit Ihrem
Betreuer diskutiert haben.
2.6) Generieren Sie nun den Code. 2.7) Nun schauen wir uns den Code an, den MagicDraw erzeugt hat.
Öffnen Sie eine Konsole und wechseln Sie mit „cd <Verzeichnis>“ in das
Verzeichnis in dem Ihr Code erzeugt wurde. Den Inhalt des Verzeichnisses
können Sie mit „ls“ auflisten. Eine Autovervollständigung von Pfaden und
Dateinamen können Sie mit Tab auslösen.
2.8) Öffnen Sie die Dateien Lotto.h und Lotto.cpp in einem Editor (geben Sie z.B.
„kate Lotto.cpp “ ein). Sie sehen in der cpp-Datei,
dass MagicDraw automatisch einen Header erzeugt und inkludiert hat
dass die Methoden mit der Dokumentation als Kommentar angelegt wurden
dass Set- bzw. Get-Methoden in einer einfachen Form bereits implementiert
sind2
In der h-Datei
2 Allerdings nur, wenn Sie die Methoden als Standardmethoden angelegt haben.
Seite 22
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
einen Header
eine #ifndef-Klammerung, die Fehler vermeidet, die auftreten, wenn eine
Datei mehrfach inkludiert wird
die Klasse „Lotto“ mit ihren Attributen und Methoden
einem Header zu der Klasse in dem der Text aus Ihrer Dokumentation als
Kommentar eingetragen ist
2.9) Passen Sie den Code so an, dass er kompiliert werden kann. Zuerst
kompilieren Sie die Dateien durch den Befehl g++ -c *.cpp (oder einzelne
Klassen/Dateien mit g++ -c <Klassenname>.cpp)
Es erscheinen viele Fehlermeldungen vom Compiler. Der Grund ist, dass die
erzeugten Klassen den Datentyp string oder auch vector enthält – diese
aber nicht definiert sind.
Öffnen Sie die betroffenen Header-Dateien in einem Editor und fügen Sie folgende
Zeilen in den freien Bereich nach dem #ifndef-Block ein: #include <string> #include <iostream> #include <vector> using namespace std; Nun sollte der Code recht schnell ohne Fehler kompilieren.
2.10) Damit eine echte Anwendung entsteht, wird nun noch eine main()
Funktion gebraucht, welche die Klassen erzeugt.
Geben Sie den Befehl g++ *.cpp ein. Damit werden die Dateien kompiliert und
anschließend gelinkt. Sie erhalten eine (recht unverständliche) Fehlermeldung
vom Linker, die besagt, dass die main()-Funktion fehlt.
Öffnen Sie im Editor eine neue Datei und legen Sie folgende main-Funktion an.
Dann speichern Sie die Datei als main.cpp ab. Nun sollte der Befehl g++ *.cpp
Seite 23
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
ohne Fehlermeldung durchlaufen. Lassen Sie die Main-Funktion unverändert.
Neuer Code gehört in die passende Klasse und nicht in die Main-Funktion.
Sie können das erzeugte Programm starten, indem Sie in der Konsole (im
entsprechenden Verzeichnis) den Programmnamen des lauffähigen Programms
aufrufen (falls Sie beim Kompilieren keinen Namen für die Ausgabe angegeben
haben, heißt die Datei a.out).
Zum Ausführen müssen Sie dann „./a.out“ eingeben.
Allerdings tut das Programm noch nichts, weil die Methoden noch nicht
implementiert sind.
Sie können das Programm über Konsolenbefehle übersetzen, binden und laufen
lassen (siehe unten) oder die NetBeans IDE verwenden, die Sie spätestens im
nächsten Semester verwenden sollten, um bequem mit dem Testtool C++Unit
arbeiten zu können.
Übersicht Compilerbefehle:
◦ g++ --help zeigt alle Optionen an. Hier einige Beispiele:
◦ g++ *.cpp Übersetzt alle cpp-Dateien im aktuellen Verzeichnis und
linkt das Ergebnis zu einer ausführbaren Datei zusammen. Die Datei heißt
unter Unix a.out und unter Windows a.exe
◦ g++ -o <Name für das ausführbare Programm> *.cpp
// main.cpp #include "Lotto.h" int main(){ Lotto myLotto(); myLotto.LottoGUI(); }
Seite 24
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Übersetzt alle cpp-Dateien im aktuellen Verzeichnis und linkt das Ergebnis
zu einer ausführbaren Datei mit dem angegebenen Namen zusammen
◦ g++ -c <Klassenname.cpp>
Übersetzt eine einzelne cpp-Dateien und erzeugt eine Objektdatei (.o)
(-c heißt: Nur kompilieren ohne zu linken.)
◦ g++ -o <Name für das ausführbare Programm> *.o Nach dem
Erzeugen der Objektdateien können Sie die Anwendung so (ohne
erneutes Compilieren) zusammenlinken
◦ ./a.out bzw. ./<Name für das ausführbare Programm>
Starten des erzeugten ausführbaren Programms
2.11) Wenn der Code erfolgreich kompiliert, kann die Abnahme durch den
Praktikumsbetreuer erfolgen.
2.12) Sie sollten nun mit der Implementierung beginnen und zu Hause fertig
stellen. Bis zum Beginn des nächsten Praktikumstermins muss die
Implementierung komplett abgeschlossen sein.
◦ Der Code wird im nächsten Praktikum in Ihr Modell importiert. Dabei kann
allerdings einiges schief gehen. Deshalb sollten Sie diesen Schritt nur unter
Aufsicht durchführen.
◦ Hinweis:
Eine Zufallszahl erhält man durch die Systemfunktion rand():
#include <iostream>
using namespace std;
#include <cstdlib> /*unter Window -- #include <stdlib.h> unter Unix*/
#include <time.h> /*nur unter Windows -- unter Unix nicht benötigt
int main () {
Seite 25
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
srand (time(NULL)); /* initialize random seed: */
/* generate secret number [1-9] */
cout << rand()%9+1 << endl;
return 0;
}
◦ Neue Methoden oder Attribute fügen Sie bitte an der üblichen Stelle ein.
◦ Verwenden Sie Klassenkonstanten statt „Magic Numbers“ oder #define’s.
Dazu können Sie im Header einer Klasse eine Konstante mit Wert definieren:
z.B. private: static const int NUMBERS_TO_DRAW = 6;
2.13) Tauschen Sie die Ergebnisse (Modell und Code) mit Ihrem
Praktikumspartner aus! Außerdem sollten Sie sich darüber verständigen wie
Sie die Vorbereitung für die nächste Übung angehen. Es steht evtl. noch
einige Implementierungsarbeit bis zum Beginn des nächsten (und letzten)
Praktikums an.
Seite 26
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
3. Praktikumsaufgabe
Ziel
Im dritten Praktikum geht es um die Abnahme des Lottospielssystems in C++.
Vorbereitung
Schlagen Sie folgende Begriffe nach und schreiben Sie deren Bedeutung
handschriftlich auf:
Forward-Engineering
Reverse-Engineering
Roundtrip-Engineering
Sie haben den Code für das Lottospiel vollständig implementiert .
Aufgabe
Nachdem Sie die Software implementiert haben, soll die Konsistenz zwischen
Modell und Code wiederhergestellt werden. Sie sollen die Vor- und Nachteile
eines Modells im Allgemeinen und auch Ihres Modells im Speziellen verstehen.
3.1) Kompilieren Sie Ihre Software auf dem Zielsystem und rufen Sie
anschließend Ihren Betreuer zur Überprüfung der Funktionalität.
Sie dürfen erst mit den folgenden Schritten weitermachen, wenn Ihr Code
abgenommen wurde!
3.2) Machen Sie eine Sicherungskopie von Ihrem Code und dem Modell.
3.3) Starten Sie das MagicDraw-Projekt und öffnen Sie das Klassendiagramm.
3.4) Damit die Änderungen, die Sie im Quellcode vorgenommen haben, im
Seite 27
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
MagicDraw-Modell verfügbar werden, müssen diese in das Modell reimportiert
werden. Sie müssen dafür ein Reverse-Engineering durchführen.
3.5) Wenn Sie im Code weitere Methoden und Attribute hinzugefügt haben,
erscheinen diese auch im Modell. Prüfen Sie daher ob alle Ihre Änderungen im
Modell auftauchen. Neue Klasse müssen dabei beim Reverse-Engineering
hinzugefügt werden, wenn sie in neuen Dateien implementiert wurden.
3.6) Vergleichen Sie das neue Modell mit Ihrem ursprünglichen. Was hat sich
geändert? Erkennen Sie, wie sich Ihre Änderungen im Code nun im Modell
wiederfinden?
3.7) Prüfen Sie, ob es in Ihrem Entwurf Methoden gibt, welche die Sichtbarkeit
"public" haben, obwohl das nicht nötig ist. Ändern Sie die Sichtbarkeit unter den
Eigenschaften der Methoden im Modell auf "private".
3.8) Falls Sie nicht sehr sorgsam gearbeitet haben, enthält Ihr Programm
wahrscheinlich ein „Memory Leak“ , weil Sie Speicher dynamisch reservieren,
aber nicht mehr freigeben. Prüfen Sie, wo Sie den „new“-Operator ohne
entsprechendes „delete“ verwenden und fügen Sie die fehlenden Methoden in
ihrem Modell ein (z.B. als Destruktor). Dann erzeugen Sie mit einem Forward-
Engineering den erweiterten Coderahmen und füllen die Methode mit Inhalt.
3.9) Vergleichen Sie das Sequenzdiagramm mit Ihrem geschriebenen
Programm. Korrigieren Sie das Sequenzdiagramm, so dass es der neuesten
Version Ihres Programms entspricht.
3.10) Wenn der Code fehlerfrei kompiliert und läuft und das Klassen- und
Seite 28
Praktikum OOAD SS2015
Prof. Dr. Wolfgang Weber
Michael Guist Version 8
Sequenzdiagramm dem Code entspricht, kann die Abnahme durch den
Praktikumsbetreuer erfolgen.
Seite 29