Entwurfsvarianten in der Software-Konstruktion

Transkript

1 Fachhochschule Köln Cologne University of Applied Sciences Forschungsschwerpunkt Software-Qualität Am Sandberg 1 D Gummersbach Telefon+49(0) oder -107 (Sek.) Telefax +49(0) fsq@gm.fh-koeln.de Entwurfsvarianten in der Software-Konstruktion Von den Bedingungen der en Uwe Poborski uwe.poborski@fh-koeln.de FSQ-Bericht Nr Januar 2007

2 Bedingungen beschreiben exakt en einer Schnittstelle durch Aussagen über die System- Zustände vor bzw. nach der Operation. Unterschieden werden dementsprechend Vorbedingungen und Nachbedingungen. Es gibt mehrerlei Aspekte, unter denen die en und deren Bedingungen zu betrachten sind: * die Metapher eines Vertrages, wobei die Vorbedingungen die Voraussetzungen, unter denen die Leistungen erbracht werden, und die Nachbedingungen die Leistungen, für die der verantwortlich zeichnet, beschreiben * als deklarative Beschreibungen der Systemzustände vor bzw. nach Ausführung des s, das heißt es werden Aussagen über die Ausprägungen von Merkmalen involvierter Dinge gemacht * die Interpretation 1 der Vorbedingungen obliegt dem Aufrufer des s * die Interpretation der Vorbedingungen obliegt der Implementierung des s * die Nachbedingungen bedürfen keiner Interpretation; es gibt keinen Misserfolg bzw. die Handlung kann nicht scheitern * die Nachbedingungen müssen interpretiert werden; bei Falsifizierung gilt die Handlung als gescheitert * die Interpretation der Bedingungen erfolgt ausschließlich mit Hilfe der zur Verfügung stehenden en Dabei stehen die genannten Betrachtungsweisen nicht im Gegensatz zueinander, sondern lassen sich in geeigneter Weise kombinieren. 1 Mit Interpretation ist die Auswertung bzw. Berechnung des Wahrheitwerts der Aussagen gemeint 2/11

3 Untersuchungsgegenstand der Beispiele sei hierbei ein System, das zwei Personen ermöglicht Schach zu spielen, wobei die Regelkonformität der Züge überwacht werde. Kontext Schach, Handlung Ziehen. Handlungsschemata des Beispiels Schach Handlungsschema weiße Dame zieht auf Feld involvierte Dinge betroffene weiße Dame benötigte weißer König alle weißen Figuren auf dem Brett alle schwarzen Figuren auf dem Brett Feld, auf dem die weiße Dame steht Zielfeld, auf das die weiße Dame gestellt werden soll Vorbedingungen weiße Figuren am Zug weißer König nach dem Zug nicht im Schach Zielfeld ist frei Zielfeld gehört zur Gangart Weg zwischen aktueller Position und Zielfeld ist frei Nachbedingungen weiße Dame steht auf Zielfeld schwarze Figuren sind am Zug 3/11

4 Handlungsschema steht weißer König im Schach involvierte Dinge betroffene benötigte Vorbedingungen --- Nachbedingungen weißer König alle weißen Figuren auf dem Brett alle schwarzen Figuren auf dem Brett Feld, auf dem der weiße König steht ja, wenn es eine schwarze Figur gibt, zu deren Gangart die aktuelle Position des weißen König, gehört und der Weg von aktueller Position der schwarzen Figur zu aktueller Position des weißen König frei ist, respektive die schwarze Figur ein Springer ist nein, sonst 4/11

5 Für die Handlungsschemata weiße Dame zieht auf Feld ergeben sich zur Spezifikation der Vorund Nachbedingungen nachfolgend genannte en. Im Vorgriff auf anderweitig zu begründende Entwurfsentscheidungen und, um das Beispiel klein zu halten, sind diese rundimentären 2 Schnittstellen zugeordnet. 1. (Figur). zieht(zielfeld). wegzufeld(feld) : {Feld}. amzug() : bool. aktuelleposition() : Feld. figurengleicherfarbe() : {Figur}. figurenandererfarbe() : {Figur}. königgleicherfarbe() : König. königandererfarbe() : König 2. König : Figur Schnittstellen-Vererbung. imschach() : bool 3. Feld. frei() : bool 2 Für Schachexperten sei hier der Hinweis gegeben, dass einige Details in diesem Beispiel weggelassen wurden, was nicht mit Abstraktion zu verwechseln ist! 5/11

6 Schnittstellen des Beispiels weiße Dame zieht auf Feld Schnittstelle Figur wegzufeld(zielfeld) : Set(Feld) -- liefert die Menge der Felder, die auf dem Weg zum zielfeld überschritten werden gehoertzurgangart(feld) : bool -- prüft, ob Feld je nach Figuren(Gang)art erreichbar ist zieht(zielfeld) precondition self.amzug() = true and zielfeld.frei() = true and self.gehoertzurgangart(feld) and self.wegzufeld(zielfeld)->forall(f f.frei() = true) and -- Problematisch(1): if self.aktuelleposition() = zielfeld then!königgleicherfarbe().imschach() -- bezieht sich auf Zustand durch Leistung des s postcondition self.aktuelleposition() = zielfeld and self.amzug() = false and -- Problematisch(2):!königGleicherFarbe().imSchach() -- gehört nicht zur Leistung des s postcondition -- alternativ zur Vorherigen if!königgleicherfarbe().imschach() then self.aktuelleposition() = zielfeld and self.amzug() = false else -- Problematisch(3): self.aktuelleposition() = self.aktuelleposition()@pre and self.amzug() = true -- im Falle des Scheiterns muss Aktion rückgängig gemacht werden weitere en wie oben 6/11

7 Um die Probleme, die in den Ausdrücken der Vor- bzw. Nachbedingungen auftreten zu erkennen, muss der König:imSchach() näher expliziert werden. Der einfache Fall einer zirkulären Abhängigkeit von Bedingungen ist, wenn die Nachbedingung die Vorbedingung eines s darstellt: zirkulärabhängig() precondition involviertesding.merkmalsausprägung() = WertNach postcondition involviertesding.merkmalsausprägung() = WertNach Die zirkuläre Abhängigkeit stellt im Entwurf ein geringeres Problem dar als bei der Umsetzung, zumal sich das Ergebnis des s durch Angabe geeigneter weiterer en oder durch Rückgriff auf Meta-Informationen berechnen lässt. In der Implementierung eines solchen s müssen die weiteren Unterstützung-en versteckt werden und die Systemzustände durch diese vorweg hergestellt und anschließend wieder zurück genommen werden, da Meta-Informationen dem System nicht zur Verfügung stehen. Noch interessanter, weil schwieriger zu entdecken, in diesem Zusammenhang zu betrachten ist der Fall, wenn zwei oder mehr en sich wechselseitig bedingen, wie er im oben genannten Beispiel weiße Dame zieht auftritt. 7/11

8 Schnittstellen des Beispiels weiße Dame zieht auf Feld Schnittstelle König imschach() : bool -- überprüft, ob durch die aktuelle Konstellation der Figuren -- der König im nächsten Halbzug der anderen Farbe geschlagen werden kann -- bzw. das Feld auf dem der König steht von einer anders farbigen Figur bedroht ist precondition -- postcondition result = self.figurenandererfarbe()->exists(figur figur.gehoertzurgangart(self.aktuelleposition()) and figur.wegzufeld(self.aktuelleposition())->forall(f f.istfrei() ) -- Problematisch Schnittstelle Feld istfrei() : bool precondition -- postcondition result =!exists(figur self = figur.aktuelleposition()) -- Problematisch: hier schließt der Kreis Die Problematik lässt sich über den Zustandsraum der beteiligten Komponenten deutlicher aufzeigen. Ziel des Systems ist es, die Benutzerhandlungen zu unterstützen, indem sichergestellt wird, dass die Konstellation der Figuren vor jedem Zug konsistent zu den Schachregeln ist. Das bedeutet, es kann zu jeder Zeit bestimmt werden, ob es einen weiteren Zug bei einer bestimmten, gültigen Stellung gibt oder die Partie beendet ist. Der zieht(zielfeld) und damit letztlich der frei() setzt voraus, dass die aktuelleposition() einer Figur für die Überprüfung einer Schachstellung des Königs unabhängig von den sonst zu beachtenden Regeln manipuliert wird 8/11

9 und das System somit in einen inkonsistenten Zustand gebracht werden könnte. Im Weiteren ist die Fragestellung zu erörtern, ob eine bestimmte Anordnung der eingangs benannten Aspekte von Vor- und Nachbedingungen Abhilfe schaffen kann und, ob die Problematik überhaupt die Entscheidungen betrifft, die im Entwurf getroffen werden müssen. Die spezifizierten en des Systementwurfs mit ihren Vor- und Nachbedingungen entsprechen einer algebraischen Spezifikation eines Abstrakten Datentyps. Es gilt also, alle Funktionen des Systems mit entsprechenden en nach außen sichtbar zu machen und gleichzeitig nach innen als Realisierungsvorgabe fest zu halten. Wenn man nun einige der oben erwähnten Aspekte der Vor- und Nachbedingungen als maximale Autonomie des s kombiniert: * die Interpretation der Vorbedingungen obliegt der Implementierung des s * die Nachbedingungen beschreiben die Leistungen, für die der verantwortlich zeichnet * die Nachbedingungen bedürfen keiner Interpretation; es gibt keinen Misserfolg bzw. die Handlung kann nicht scheitern und die Sichtbarkeit nach außen in den Vordergrund stellt, löst sich die Problematik, zumindest im Entwurf, auf. In Bezug auf die Realisierung kann auf geeignete Design Pattern 3 verwiesen werden, die genau zur Beantwortung solcher Fragestellungen gesammelt und kategorisiert wurden. Will man hingegen eine Vorgabe für die Realisierung herstellen, die auf Vollständigkeit der Axiome des Abstrakten Datentyps bedacht ist, und zudem die eingangs aufgeführten Aspekte der Vorund Nachbedingungen als minimale Komplexität des s kombiniert: * die Interpretation der Vorbedingungen obliegt dem Benutzer des s * die Nachbedingungen müssen interpretiert werden; bei Falsifizierung gilt die Handlung als gescheitert * die Interpretation der Bedingungen erfolgt ausschließlich mit Hilfe der zur Verfügung stehenden en ist es unumgänglich, das Geheimnisprinzip, genauer gesagt die Datenkapselung in Komponenten, auf zu weichen um, wenn auch nur kurz, oder zwischenzeitlich, den Zustandsraum, der durch deren Datenbereich repräsentiert wird, zu manipulieren. 3 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster, Addison-Wesley, /11

10 Daraus folgt, dass zwischen Vollständigkeit und Datenkapselung ein Kompromiss gefunden werden muss, da beide Forderungen nicht gleichzeitig zu erfüllen sind. Für das Beispiel weisse Dame zieht auf Feld ergibt sich, mit einer Kombination der Aspekte der Vor- und Nachbedingungen zu rationale Abwägung von Autonomie und Komplexität eines s, der zieht(zielfeld) wie folgt: Schnittstelle Figur zieht(zielfeld) precondition -- der Benutzer des s könnte diesen Teil der Bedingungen prüfen self.amzug() = true and zielfeld.frei() = true and self.gehoertzurgangart(feld) and self.wegzufeld(zielfeld)->forall(f f.frei() = true) postcondition -- der Benutzer des s muss mit dem eventuellen Scheitern umgehen if!königgleicherfarbe().imschach() then self.aktuelleposition() = zielfeld and self.amzug() = false else -- im Falle des Scheiterns muss Aktion rückgängig gemacht werden self.aktuelleposition() = self.aktuelleposition()@pre and self.amzug() = true weitere en wie oben 10/11

11 Als Empfehlung leitet sich daher die Kombination der Aspekte der Vor- und Nachbedingungen zu rationale Abwägung von Autonomie und Komplexität eines s : * die Metapher eines Vertrages, wobei die Vorbedingungen die Voraussetzungen, unter denen die Leistungen erbracht werden, und die Nachbedingungen die Leistungen und eventuellen Misserfolg, für die der verantwortlich zeichnet, beschreiben * die Interpretation der Vorbedingungen obliegt der Implementierung des s * im Fall der Falzifizierung einer Vorbedingung wird der nicht ausgeführt * die Nachbedingungen bedürfen keiner Interpretation; die Handlung kann scheitern und der der Fall des Misserfolges ist zu behandeln * die Interpretation der Bedingungen erfolgt überwiegend mit Hilfe der zur Verfügung stehenden en und der Verzicht auf Vollständigkeit zugunsten des Geheimnisprinzips ab. Die Lösung der aufgezeigten Problematik an zirkulären Abhängigkeiten obliegt damit der Realisierung. Da es eine Vielzahl möglicher Realisierungen gibt und die technische Umsetzung im Entwurf gar keine Rolle spielen soll, ist die Implementierung der adäquate Platz für kreative Ansätze und den eventuellen Einsatz an Mustern. 11/11