Klausur 2010, Aufgabe 3.c)

Moderator: Automated Software Engineering

tgp
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 268
Registriert: 15. Nov 2006 21:41

Klausur 2010, Aufgabe 3.c)

Beitrag von tgp » 28. Feb 2012 13:27

Ich bin mir bei der Aufgabe ziemlich sicher, möchte meine Lösung aber zur Sicherheit trotzdem mal vorstellen:

Der Zustandsautomat sieht so aus:

Bild

(evtl. könnte man noch hasNext einbeziehen: Kante von one_next nach start, self-loop bei start)

Wenn Quick Check keine shadows entfernen können soll, muss das Programm mindestens einen next- und einen hasNext-Aufruf enthalten. Die Orphan-Shadow-Analyse müsste nun aber kontext-sensitiv sein, um eine ungefährliche hasNext-next-Aufrufreihenfolge zu erkennen.

Mr.B
Mausschubser
Mausschubser
Beiträge: 65
Registriert: 13. Dez 2009 17:04

Re: Klausur 2010, Aufgabe 3.c)

Beitrag von Mr.B » 28. Feb 2012 17:27

Könnte der Quick Check nicht schon keinen Shadow entfernen, wenn nur ein "next"-Aufruf im Program vorkommt?
Has-next ist doch irrelevant um den finalen Zustand zu erreichen!?

viele Grüße
Mr. B

Benutzeravatar
ericbodden
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 243
Registriert: 5. Apr 2010 19:06

Re: Klausur 2010, Aufgabe 3.c)

Beitrag von ericbodden » 28. Feb 2012 17:50

Hallo.

Das "next next" pattern ist leider eines, auf dem der Quick Check nicht sehr effektiv ist. Er kann nur Shadows entfernen, wenn ein Programm keine next-shadows enthält sondern nur hasNext-Shadows.

Falls ein Programm nur einen einzigen next-Shadow enthält, dann kann man den trotzdem nicht deaktivieren; er könnte ja in einer Schleife liegen.
-- Eric

Mr.B
Mausschubser
Mausschubser
Beiträge: 65
Registriert: 13. Dez 2009 17:04

Re: Klausur 2010, Aufgabe 3.c)

Beitrag von Mr.B » 28. Feb 2012 18:50

Falls ein Programm nur einen einzigen next-Shadow enthält, dann kann man den trotzdem nicht deaktivieren; er könnte ja in einer Schleife liegen.
Das habe ich gemeint 8)

Wie wäre denn die Antwort auf dei Klausurfrage zu 3. c)?
Es ist mir klar, dass OSA nicht ausschließen kann, dass ein next in den Endzustand fürt, allerdings ist mir nicht ganz klar warum bzw. wie man es begründen sollte. :roll:

So wie ich das verstanden habe, überprüft OSA ohnehin das selbe wie der Quick Check. Also ob ein Shadow vokommt, der den Automaten in den Endzustand bringen würde. Allerdings mit Beachtung, dass ein shadow auf unterschiedlichen Objekten arbeiten könnte.

Hat man jetzt ein Programm, indem der "next"-Shadow vorkommt, ist es eigentlich egal ob sich dieser nun auf ein oder mehrere Objekte bezieht, da man in keinem fall sagen kann ob next in den Endzustand fürt oder nicht.

tgp
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 268
Registriert: 15. Nov 2006 21:41

Re: Klausur 2010, Aufgabe 3.c)

Beitrag von tgp » 28. Feb 2012 20:13

ericbodden hat geschrieben:Falls ein Programm nur einen einzigen next-Shadow enthält, dann kann man den trotzdem nicht deaktivieren; er könnte ja in einer Schleife liegen.
Ah ja stimmt, dann ist der "shadow-Counter" != 0.
Mr.B hat geschrieben:So wie ich das verstanden habe, überprüft OSA ohnehin das selbe wie der Quick Check. Also ob ein Shadow vokommt, der den Automaten in den Endzustand bringen würde. Allerdings mit Beachtung, dass ein shadow auf unterschiedlichen Objekten arbeiten könnte.

Hat man jetzt ein Programm, indem der "next"-Shadow vorkommt, ist es eigentlich egal ob sich dieser nun auf ein oder mehrere Objekte bezieht, da man in keinem fall sagen kann ob next in den Endzustand fürt oder nicht.
So hab ichs auch verstanden, solange in einem (wohl recht konstruierten^^) Programm nur ein zum Automaten passendes Objekt gibt, kann OSA nicht mehr als QC.

Antworten

Zurück zu „Automated Software Engineering“