Praktikum OOAD - fbi.h-da.de · PDF filePraktikum OOAD SS2015 Prof. Dr. Wolfgang Weber Michael...

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




− 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




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




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




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




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




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

https://www.fbi.h-da.de/fileadmin/personal/m.schreeck/documents/MagicDraw-Anleitung.pdf

https://www.fbi.h-da.de/fileadmin/personal/m.schreeck/documents/MagicDraw-Anleitung.pdf

http://www.omg.org/




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




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




Seite 10




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




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




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




+

Seite 14




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





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




„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




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




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




Sequenzdiagramme in der Vorlesung noch nicht behandelt haben, überlegen

Sie sich bitte welche Funktionen vom Programm aufgerufen werden müssen um

Seite 20




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




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




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




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




Ü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




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





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




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




Sequenzdiagramm dem Code entspricht, kann die Abnahme durch den

Praktikumsbetreuer erfolgen.

Seite 29

Praktikum OOAD - fbi.h-da.de · PDF filePraktikum OOAD SS2015 Prof. Dr. Wolfgang Weber Michael...

Documents

Transcript of Praktikum OOAD - fbi.h-da.de · PDF filePraktikum OOAD SS2015 Prof. Dr. Wolfgang Weber Michael...