Slajdy

Aleksandar Milicevic, Derek Rayside, Kuat Yessenov,
Daniel Jackso
Computer Science and Artificial Intelligence
Laboratory
Massachusetts Institute of Technology
{aleks, drayside, kuat, dnj}@csail.mit.edu
http://people.csail.mit.edu/aleks/squander/doc/mil
icevic-icse11-squander.pdf
 Framework dający ujednolicone środowisko wykonywalne dla kodu imperatywnego
oraz deklaratywnego w kontekście jednego programu.
 http://people.csail.mit.edu/aleks/squander/





KodKod to wydajny system rozwiązywania zależności w logice pierwszego rzędu.
Używany do sprawdzania kodu, generowania test case’ów oraz np. w UML
Silnik SAT (http://www.sat4j.org/ )
http://alloy.mit.edu/kodkod/
Autorka: Emina Torlak
 Sat4J - Biblioteka do rozwiązywania
oraz optymalizacji problemów
opartych o logikę bool
 http://www.sat4j.org/
 Język formalny podobny do Alloy
(http://alloy.mit.edu/alloy/)
 Wspiera logikę pierwszego rzędu z
standardowymi dla javy
wyrażeniami
 Wykorzystywany do opisywania
złożonych relacji pomiędzy
obiektami w programie




Z obiektów do relacji
Cześć KodKod
Przywrócenie sterty
Przykłady implementacji
algorytmów
 Przykład praktycznego systemu
 Bierze formułę relacyjną do
rozwiązania, wraz z zbiorem relacji
„z granicami” oraz skończony zbiór
atomów.
 Tłumaczy formułę na problem
rozwiązywalny w logice Bool’a,
przekazuje do SAT.
 Kiedy rozwiązanie zostanie
znalezione tłumaczy je z powrotem
na relacje
 Relacje nie są typowane
 Dla każdej relacji potrzebne jest
zdefiniowanie dwóch granic
„dolnej” oraz „górnej”
 Dolna granica określa krotki jakie
relacja musi mieć
 Górna granica krotki które relacja
może mieć
 Rozmiar granic wpływa na czas
rozwiązywania zadania
 mniej krotek=> mniej
przeszukiwania => szubciej wynik
 Specyfikacje JFSL zamieszczane są
w adnotacjach
 @Invariant, @Requires, @Ensures,
@Modifies, @specField
 @SpecField("x: one int | x = this.y this.z")
 Specyfikacje pól są dziedziczone,
mogą być nadpisywane
 @Modifies("f [s][u]")
 f (obowiązkowe) nazwa pola które
Squander może modyfikować
 s „selektor” wybiera instancje
obiektów które mogą modyfikować
pole f, domyślnie wszystkie
 u – górna granica – określa jakie
części pola f mogą być
modyfikowane.
 Ważna adnotacja, ogranicza
przestrzeń przeszukiwana
1.
2.
3.
4.
Parsowanie relacji zapisanych w
adnotacjach, wraz z definicjami
metod, klas
Konstruowanie relacji na
podstawie wartości pól w
stanie przed i stanie po
Przekształcanie relacji do
formuły dla KodKod
Jeśli rozwiązanie zostanie
zwrócone, przywrócenie sterty
programy
 Szukanie osiągalnej części sterty
 Następnie przechodzi obiekty
metoda Breadth-first – najpierw
korzenie potem dzieci pierwszego
rzędu, potem drugiego..
 Serializacja obiektów
 Squander posiada zestaw serializatorów
 Domyślny zwraca wartości pól obiektu
 Serializowanie obiektów abstrakcyjnych
 Generyków nie było od początku
 Typ parametru typów
generycznych jest znany tylko
podczas kompilacji
 Po co znać typ podczas runtime’u
 Nie trzeba bezpośrednio rzutować
 Optymalizacja
 System refleksji Javy, dostarcza
statyczne metody sprawdzania
typów pod wykonywania
programu.
 Podczas przeszukiwania sterty
kiedy natrafimy na nowa klasę
Sprawdzane są adnotacje
@Invariant, oraz @SpecField
poprzez refleksje.
 Adnotacje mogą znaleźć się w
osobnym pliku
 Musi być w classpath
 Nazwa taka sama jak klasy
 Następnie sprawdzane są
dostępność oraz typy pól
Przykład
transformacji BST
 Transformacji podlegają tylko
obiekty „ważne” oraz osiągalne
poprzez pola obiektów „ważnych”
– Literały
 Najpierw konstruowany jest
wszechświat zawierający każdy
literał oraz każdy int
 Dla każdego literału generowana
jest jedno argumentowa relacja z
niego samego do niego samego
 Dla każdego pola tworzona jest
tworzona relacja z typu
fld.declType->fld.type by trzymać
przypisania wartości pól do obiektu
 Dla pol z adnotacja @modifies
 Generowanie relacji pre
 Generowanie relacji post
 Dla reszty pól generowana jest
relacja odzwierciadlająca jej stan
na stercie
Definiowanie
Relacji oraz
granic Schemat
 W zależności od wyników szukania
rozwiązania przed KodKod
 Brak wyniku – generowany jest wyjątek
który łatwo można przechwycić
 Znaleziono kilka wyników zwracane jest
jedno wybierane niedetermistycznie
 Podczas transformacji Squander
zapisuje mapowania z Obiektów na
KodKod atomy, oraz z pól na
relacje.
 KodKod zwraca wartości relacji
oraz w postaci zbiorów
kartezjańskich atomów.
Przywrócenie sterty jest zatem
zwykłym modyfikowaniem
obiektów oraz ich pól
wykorzystującym wcześniej
utworzone mapowanie
 Kodkod dla relacji r, kargumentowej alokuje pamięć
rozmiaru n^k gdzie n to liczba
atomów we wszechświecie
 Relacja trzymana jest w
jednowymiarowej tablicy int’ów,
więc ograniczenie jest do
Integer.MAX_VALUE
 Trójargumentowa relacja, wraz z
wszechświatem zawierającym 1291
atomów, przekracza ogranicznie
1291^3 > Integer.MAX_VALUE
 Sposób zapisu relacji stanowi
problem. Wszechświat z 1290
atomami nie trudno wygenerować.
W ostatnim przykładzie będzie on
miał 1900 obiektów.
 Musiała powstać metoda
optymalizacji, aby system miał
jakiekolwiek zastosowanie.
 Funkcja mapująca literały na atomy
nie musi być różnowartościowa.
 Kilka literałów przechodzi na jeden
atom
 Plik .jfspec
 Własny serializer, implementacja
interface’u IObjSer
Generyki
 Jeśli problem można rozwiązac w
czasie wielomianowym, squander
jest sporowolniejszy
 Dla problemów trudnych squander
dzięki wydajności SAT może okazać
się szybszy, bądź porównywalny
 Problem łatwiej wyrazić w sposób
deklaratywny -> Squander
wygrywa.
Ścieżka
Hamiltona
Problem
rozmieszczenia
n hetmanów
Przykład
Praktyczny