Softwareentwicklung in C++ - ASC

10. Memory – ein kleines Beispiel
Wie versprochen, möchte ich hier nach dem Kennenlernen der notwendigen
Fakten zu Klassen in C ++ das Beispiel des Spiels Memory noch einmal aufgreifen
und vollständig von Anfang an implementieren. Am konkreten Beispiel
ist es einfacher, einmal alle Gedanken zu ordnen, die vielleicht zwischendurch,
bei der Lektüre so einiger technischer Details, durcheinander gekommen sind.
Zu einer sauberen Entwicklung gehört natürlich ein sauberes Konzept. Dieses
wird in der Praxis dadurch erreicht, dass man zuerst alle einzelnen Use-Cases
Stück für Stück ablaufmäßig erfasst und aus diesen die User-Requirements
ableitet. Diese landen dann im URD (=User Requirements Document). Um
nun niemanden zu sehr zu langweilen, erspare ich mir an dieser Stelle die
Abhandlung, wie die Abläufe des Drückens auf eine Taste, des Umdrehens
aller Karten, des Umdrehens einer einzelnen Karte, etc. aus Sicht des Endbenutzers
aussehen. Auch das SRD (=Software Requirements Document) ist an
dieser Stelle nicht besonders spannend. An dieser Stelle bedeutet in diesem
Kontext hier im Buch. Im Rahmen einer Entwicklung (und ich meine jeder
Entwicklung!) sind diese Dokumente sehr wohl spannend, um nicht zu sagen
lebensnotwendig!
Für die Beschreibung hier im Buch wird es beim ADD (=Architectural
Design Document) wichtig. Dieses entsteht als Resultat aus URD und SRD
und das ist auch genau der Punkt, an dem wir hier in die Entwicklung einsteigen.
10.1 Das ADD
Das ADD beschreibt im Prinzip die interne Architektur der zu erstellenden
Software. Der wichtigste Teil der Arbeit bei der Erstellung einer tragfähigen
Softwarearchitektur besteht darin, ein sauberes Modell zu finden, das
modular und damit durchschaubar und beherrschbar ist. Mit durchschaubar
und beherrschbar meine ich hier natürlich auch, dass diese Eigenschaften
nicht nur bis zur ersten Version gegeben sind, sondern, dass sie über alle Stufen
späterer Weiterentwicklung erhalten bleiben. Je nachdem, wie weit man
vorausgedacht hat, sind bei späteren Anpassungen der Software auch Änderungen
an der Architektur notwendig. Die in der Folge sehr kurz dargestellten
Designentscheidungen entsprechen einer von vielen möglichen sauberen