Tutorial Softwareentwicklung2 - Versionsgeschichte

Openglerf: /* Control-Klassen - Herz des Systems */ hohlen -> holen

2012-03-19T13:19:53Z

‎Control-Klassen - Herz des Systems: hohlen -> holen

Flash: /* Ausblick */

2007-08-23T18:03:06Z

‎Ausblick

Flash: /* Finden von Boundary-Klassen */

2006-07-16T22:53:04Z

‎Finden von Boundary-Klassen

Flash: /* Was macht eine gute Klasse aus? */

2006-07-16T22:50:20Z

‎Was macht eine gute Klasse aus?

Flash: /* Vorwort */

2006-07-16T22:43:41Z

‎Vorwort

Flash: /* Klassen finden */

2006-03-08T13:50:26Z

‎Klassen finden

Flash: Neues Tutorial

2006-03-07T21:13:04Z

Neues Tutorial

Änderungen zeigen

@@ Zeile 173: / Zeile 173: @@
 Control-Klassen speichern keine Daten. Sie leiten Daten von Boundary-Klassen zu Entity-Klassen weiter (und umgekehrt), sie verarbeiten Daten und rufen Funktionen anderer Klassen auf.
-Eine Control-Klasse die mehr tut als steuern ist eine schlechte Control-Klasse. Control-Klassen beauftragen andere Klassen ihnen Infos zu liefern oder Infos zu speichern. Sie hohlen/speichern niemals selbst die Daten!
+Eine Control-Klasse die mehr tut als steuern ist eine schlechte Control-Klasse. Control-Klassen beauftragen andere Klassen ihnen Infos zu liefern oder Infos zu speichern. Sie holen/speichern niemals selbst die Daten!
 Diese Eigenschaften bringen es mit sich, dass Control-Klassen im Gegensatz zu den anderen beiden Klassentypen Anwendungsabhängig sind, und schlecht oder gar nicht wieder verwendet werden können.

← Nächstältere Version		Version vom 23. August 2007, 18:03 Uhr
Zeile 476:		Zeile 476:


−	{{TUTORIAL_NAVIGATION\|[[Tutorial Softwareentwicklung1]]\|-}}	+	{{TUTORIAL_NAVIGATION\|[[Tutorial Softwareentwicklung1]]\|[[Tutorial Softwareentwicklung3]]}}

	[[Kategorie:Tutorial\|Softwareentwicklung2]]		[[Kategorie:Tutorial\|Softwareentwicklung2]]

@@ Zeile 124: / Zeile 124: @@
 ====Finden von Boundary-Klassen====
-Aus jedem Akteur-Szenario-Paar kann eine Boundary-Klasse extrahiert werden. Wir werden später noch zum Thema [[Tutorial_SWE2#Szenarios|Szenarios]] kommen, da man Sie benötigt um Objektinteraktionen zu finden.
+Aus jedem Akteur-Szenario-Paar kann eine Boundary-Klasse extrahiert werden. Wir werden später noch zum Thema [[Tutorial_Softwareentwicklung2#Szenarios|Szenarios]] kommen, da man Sie benötigt um Objektinteraktionen zu finden.
 Die GUIs werden Anfangs nur grob umrissen. Es geht hier noch nicht darum alle Dialogfelder zu bestimmen. Das Design kann durch GUI-Prototypen erarbeitet werden. Es ist aber wichtig, sobald man eine Boundary-Klasse gefunden hat, deren Funktion/Aufgabe zu dokumentieren.
 Da wir wissen, dass die Erarbeitung von Klassen ein iterativer Prozess ist, kann es passieren, dass im weiteren Verlauf Klassen hinzu kommen, oder mehrere Klassen zusammengefasst werden. Deshalb wäre es völlig verfrüht, jetzt schon zuviel Energie in das GUI Design zu stecken.
 ===Entity-Klassen - Datenspeicher===

@@ Zeile 65: / Zeile 65: @@
 . Die goldene Regel des Objekt orientierten Entwurfs ist: '''Eine Klasse hat eine und nur diese eine Aufgabe!'''
-:Nehmen wir einmal wir haben ein Klasse 'Fahrzeug'. Fahrzeuge haben verschiedene Eigenschaften. Unter anderem Gehen sie auch gerne mal kaputt. Deshalb schickt man sie zur Wartung. Was bei der letzten Wartung gemacht wurde, und wann die Wartung war speichert man natürlich in der Klasse Fahrzeug ab, es gehört ja mit dazu. - FALSCH! Die Klasse Fahrzeug enthält all die Dinge die unmittelbar zum Fahrzeug gehören. Die Wartung, wann sie war und was gemacht wurde ist ein eigenes Thema. Es ist "abgrenzbar" und gehört somit in eine eigene Klasse 'Fahrzeugwartung'. Das 'Fahrzeug' selbst besitzt eine Beziehung (was das ist werden wir noch sehen) zur Fahrzeugwartung.
+:Nehmen wir einmal an wir haben ein Klasse 'Fahrzeug'. Fahrzeuge haben verschiedene Eigenschaften. Unter anderem Gehen sie auch gerne mal kaputt. Deshalb schickt man sie zur Wartung. Was bei der letzten Wartung gemacht wurde, und wann die Wartung war speichert man natürlich in der Klasse Fahrzeug ab, es gehört ja mit dazu. - FALSCH! Die Klasse Fahrzeug enthält all die Dinge die unmittelbar zum Fahrzeug gehören. Die Wartung, wann sie war und was gemacht wurde ist ein eigenes Thema. Es ist "abgrenzbar" und gehört somit in eine eigene Klasse 'Fahrzeugwartung'. Das 'Fahrzeug' selbst besitzt eine Beziehung (was das ist werden wir noch sehen) zur Fahrzeugwartung.
@@ Zeile 99: / Zeile 99: @@
 ;Ich kann weder Name noch Definition angeben. :
 -> Wird die Klasse wirklich gebraucht? Wenn ja: Analysiere das Modell genauer um die nötigen Eigenschaften und Aufgaben zu finden.
 ===Das B-C-E Prinzip===

@@ Zeile 4: / Zeile 4: @@
 Hallo und willkommen zum zweiten Teil der Reihe "Grundlagen der Softwareentwicklung". Dieses Tutorial ist das größte und auch wichtigste Tutorial der Reihe. Wir werden uns mit Klassen, Klassendiagrammen, Paketen und Beziehungen zwischen Klassen bzw. Paketen beschäftigen.
-Die meisten von euch werden Klassen "On Demand" gebaut haben. Also immer dann wenn ihr das Gefühl hattet, dass man diese und jene Eigenschaft schön zusammen in eine Klassen stecken könnte. Das Gefühl täuscht. Da wir uns in dieser Tutorialreihe etwas von den Bauchentscheidungen weg, und etwas mehr zu den Kopfentscheidungen hin bewegen wollen, wird ein zentraler Punkt auch sein, was Klassen eigentlich machen dürfen, und was nicht. Wenn ihr eure Projekte einmal unter diesen Gesichtspunkten betrachtet werden ihr mit unter schockiert sein, wie offensichtlich so manche Probleme ihre Anfang nehmen.
+Die meisten von euch werden Klassen "On Demand" gebaut haben. Also immer dann wenn ihr das Gefühl hattet, dass man diese und jene Eigenschaft schön zusammen in eine Klassen stecken könnte. Das Gefühl täuscht. Da wir uns in dieser Tutorialreihe etwas von den Bauchentscheidungen weg, und etwas mehr zu den Kopfentscheidungen hin bewegen wollen, wird ein zentraler Punkt auch sein, was Klassen eigentlich machen dürfen, und was nicht. Wenn ihr eure Projekte einmal unter diesen Gesichtspunkten betrachtet werden ihr mit unter schockiert sein, wie offensichtlich so manche Probleme ihren Anfang nehmen.
 Auch dieser Teil baut auf dem Buch "Visual Modeling with Rational Rose 2000 and UML" (ISBN 0201699613) von Terry Quatrani auf.
 {{Hinweis|Nicht alle beschriebenen Funktionen sind in kostenlosen Tools implementiert. Da auch ich nicht tausende Euros für Projektmanagement Software ausgeben kann, sind einige Bilder in einem Bildbearbeitungsprogramm entstanden. Grundlage für die Bilder waren die Abbildungen im oben genannten Buch.}}
 ==Voraussetzungen==

@@ Zeile 113: / Zeile 113: @@
 ===Boundary-Klassen - Das Tor zur Außenwelt===
-[[Bild:Tutorial_SWE2_BClass.jpg|left|100|framed|UML Symbol für Boundary-Klassen]]
+[[Bild:Tutorial_SWE2_BClass.jpg|left|100|framed|UML Symbol für Boundary- Klassen]]
 Boundary ist englisch und steht für Grenze. Boundary-Klassen grenzen die Software von der Umgebung ab. '''Boundary-Klassen sind das Interface der Software.'''
@@ Zeile 134: / Zeile 134: @@
 ===Entity-Klassen - Datenspeicher===
-[[Bild:Tutorial_SWE2_EClass.jpg|left|framed|UML Symbol für Entity-Klassen]]
+[[Bild:Tutorial_SWE2_EClass.jpg|left|framed|UML Symbol für Entity- Klassen]]
 Entity-Klassen haben nur eine Aufgabe: Sie speichern eine ganz bestimmte Information. Sie verfügen meist über sehr wenige Funktionen neben den "Set"- und "Get"-Funktionen für die gespeicherten Daten. Alle Funktionen die Sie besitzen haben unmittelbar mit den gespeicherten Daten zu tun (das schließt durchaus Datenmanipulation ein). Sobald aber andere Klassen gerufen werden müssen, ist die Funktion mit großer Sicherheit bei der Entity-Klasse falsch postiert.
@@ Zeile 170: / Zeile 170: @@
 ===Control-Klassen - Herz des Systems===
-[[Bild:Tutorial_SWE2_CClass.jpg|left|framed|UML Symbol für Control-Klassen]]
+[[Bild:Tutorial_SWE2_CClass.jpg|left|framed|UML Symbol für Control- Klassen]]
 Control-Klassen sind das Steuerwerk eurer Software. Meistens steuert eine Control-Klasse die Abläufe in einem Use-Case. Hin und wieder können sie auch mehrere steuern. Doch sollte immer darauf geachtet werden, dass die "goldene Regel" (''Jede Klasse hat genau eine Aufgabe'') nicht verletzt wird.
@@ Zeile 204: / Zeile 204: @@
 Denkt daran, dass die neu gefundenen Klassen sofort dokumentiert werden, d.h. ihre Aufgaben die sie haben, bzw. was sie darstellen/speichern kurz aufzuschreiben. Es kommt leider in dieser Phase recht oft vor, dass man den Namen eines Klassenkandidaten sieht, und sich dann fragt, wozu der eigentlich gut ist (weil man mittlerweile bereits neue Klassen gefunden hat, die doch eigentlich das selbe machen). Wenn man dann keine Dokumentation gemacht hat, muss man noch mal prüfen wo die Klasse her kam, und was sie machen soll. Das kostet Zeit, und die ist bekanntlich Geld wert.
 ==Pakete==