Propozycja Dynamicznych Ról i Programowania Przez Kontrakt dla

Transkrypt

Wstęp
Programowanie Przez Kontrakt
Dynamiczne Role
Uwagi końcowe
Propozycja Dynamicznych Ról
i Programowania Przez Kontrakt dla języka Java
Aleksander Kosicki
Politechnika Warszawska
wydział Matematyki i Nauk Informacyjnych
10 maja 2009
Aleksander Kosicki
Prezentacja pracy dyplomowej
Wstęp
Dynamiczne Role
Uwagi końcowe
Przedmiot prezentacji
Krótka charakterystyka pracy
Zakres Pracy
Motywacja
Prezentacja w luźny sposób przedstawia kontekst i problematykę
pracy magisterskiej pt. “Propozycja Dynamicznych Ról i
Programowania Przez Kontrakt dla języka Java”.
Praca powstała na wydziale Matematyki i Nauk
Informacyjnych Politechniki Warszawskiej, pod kierunkiem dr
inż. Krzysztofa Kaczmarskiego.
Udana obrona miała miejsce 24 lutego 2009.
Praca zdobyła II nagrodę w XXVI edycji Ogólnopolskiego
Konkursu PTI na najlepsze prace magisterskie z informatyki.
Treść pracy można znaleźć w Internecie.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Zakres Pracy
Motywacja
Celem niniejszej pracy jest propozycja oraz
implementacja pewnych dwóch koncepcji z zakresu
języków programowania.
Pierwsza z koncepcji związana jest z “Programowaniem Przez
Kontrakt”, druga z “Dynamicznymi Rolami”.
Obie z koncepcji zostały osadzone w istniejącym języku
programowania, tj. w Javie.
Charakter pracy jest eksperymentalny.
Podejście autora do omawianych w pracy zagadnień
ewoluowało w czasie.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Zakres Pracy
Motywacja
Zakres Pracy
Z perspektywy wytworzonych artefaktów, pracę można podzielić na
następujące części:
Część teoretyczno-opisowa, tj.:
rozważania ogólne
propozycje konkretnych rozwiązań
Część praktyczną, tj.:
dostarczenie implementacji† dla danej propozycji
przygotowanie środowiska programistycznego
† W wypadku pierwszej z koncepcji, implementacja dostarczona jest w
postaci translatora, w wypadku drugiej — jako biblioteka.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Zakres Pracy
Motywacja
Motywacja
Główną motywacją dla poruszenia niniejszych zagadnień były
dla autora własne doświadczenia praktyczne.
Propozycje autora nie zwiększają możliwość obliczeniowych
Javy, pozwalają natomiast na uzyskanie większej zwięzłości,
czytelności i, przede wszystkim, umożliwiają dalszy “rozdział
funkcjonalności” (Separation of Concerns).
Cechą wspólną obu propozycji jest, w pewnym sensie,
formalizacja cyklu życia obiektów.
Mimo, że propozycje owe zostały przedstawione na tle Javy,
dotyczą one w ogólności języków obiektowych.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Jakość oprogramowania
Klasa jako automat skończony
Propozycja autora
Implementacja
Część I
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
“Jakość oprogramowania” - termin używany na określenie
bardzo szerokiego zagadnienia.
“Jakość oprogramowania” nigdy nie jest wystarczająca.
Braki w jakości często wychodzą na jaw, gdy oprogramowanie
funkcjonuje już w środowisku produkcyjnym (patche,
poprawki, service packi).
Jednym z najistotniejszych aspektów “Jakość
Oprogramowania” jest zgodność wykonania programu z
pewnymi oczekiwaniami, np. z wymaganiami funkcjonalnymi.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Prosty przykład
Hello World — wersja popularna. Sprawdzona i działająca.
hello1.c
#i n c l u d e < s t d i o . h>
i n t main ( i n t a r g c , char ∗ a r g v [ ] ) {
p r i n t f ( ” H e l l o World ” ) ;
return 0;
}
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Prosty przykład c.d.
Hello World — wersja mniej typowa, oparta na problemie Collatza.
hello2.c
#i n c l u d e < s t d i o . h>
i n t main ( i n t a r g c , char ∗ a r g v [ ] ) {
unsigned v e r y l o n g i n t s e e d ;
s c a n f ( ”%d” , &s e e d ) ;
w h i l e ( s e e d != 1 )
s e e d = s e e d & 1 ? 3∗ s e e d + 1 : s e e d / 2 ;
p r i n t f ( ” H e l l o World ” ) ;
return 0;
}
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Dwa problemy
Problem 1:
Czy program hello2.c faktycznie będzie zawsze
wypisywał powitanie? Analiza statyczne tego
programu nie może być, przynajmniej na dzień
dzisiejszy, przeprowadzona w sposób automatyczny,
wymaga natomiast zastosowania zaawansowanego
aparatu matematycznego i wiąże się z rozwiązaniem
tzw. Problemu Collatza.
Problem 2:
Skąd w ogóle wiadomo jakie jest zadanie programu
hello2.c?
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Dwa problemy c.d.
Dyskusja 1:
Być może Problem Collatza jest rozstrzygalny (czego
nie udowodniono). Jeśli tak, prędzej czy później,
zostanie on rozwiązany i tym samym będzie wiadomo
czy program hello2.c działa prawidłowo. W
przeciwnym wypadku...
Dyskusja 2:
Nie wiadomo. Wymagania funkcjonalne programu nie
zostały nigdzie zapisane. Jedyne co można
powiedzieć, to że “zadaniem programu jest
imperatywne wykonanie instrukcji zapisanych w
kodzie źródłowym”.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Dwa problemy c.d.
Rozwiązanie 1:
Analiza statyczna niestety nie zawsze jest możliwa.
Pewnym obejściem tego problemu jest po prostu
przeprowadzanie odpowiedniej ilości różnego rodzaju
testów.
Rozwiązanie 2:
Zapisywanie wymagań funkcjonalnych — szczególnie
w wypadku języków imperatywnych, gdzie kod
programu stwierdza “jak” ale już nie “co”. Najlepiej
w sposób formalny, tak aby możliwa była ich
automatyczna weryfikacja podczas testów.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Wprowadzenie
Formalna specyfikacja wymagań dostępna jest w różnych w
stopniu, w różnych klasach języków.
Np. wypadku języków opisu sprzętu (Hardware Description
Languages) istnieją towarzyszące im języki weryfikacji sprzętu
(Hardware Verification Languages), często o znacznie
bogatszej od swoich odpowiedników składni (Verilog i
SystemVerilog). Na ogół języki te mogą występować razem w
obrębie tych samych jednostek kompilacji. Języki HVL mają
silne podstawy matematyczne (logiki temporalne).
W wypadku języków programowania, specyfikacja wymagań
występuje na ogół w formie elementów “Programowania Przez
Kontrakt”, a często w ogóle nie jest przez dany język
wspierana.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Wprowadzenie
Programowanie Przez Kontrakt — termin ukuty przez Bertranda
Meyera w trakcie prac nad językiem Eiffel.
Przykład specyfikacji kontraktu w języku D
double d i v i d e ( d i v i d e n t a , d i v i s o r b )
i n { a s s e r t b != 0 ; } body {
return d i v i d e n t / d i v i s o r ;
};
Typowe elementy kontraktów:
• warunki wstępne
• warunki końcowe
• niezmienniki
• efekty uboczne
• błędy
• asercje
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
W Javie występują już pewne elementy kontraktów, jak np.
asercje. Niestety język ten nie oferuje, i nie będzie w
przewidywalnej przyszłości oferował, pełnej funkcjonalności
PPK.
Autor postanowił temu zaradzić i wzbogacić ten lubiany przez
niego język o brakującą funkcjonalność PPK, dodając przy
tym pewien unikalny element — automaty skończone:
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Spostrzeżenie: niektóre klasy w językach programowania mogą
realizować schemat działania automatu skończonego. Za przykład
może tu posłużyć stworzona swego czasu przez autora klasa
monitorująca połączenia centralki telefonicznej:
Fakt ten można wykorzystać przy kontroli kontraktów.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Propozycja autora
Propozycja PPK dla Javy - przykład definicji automatu.
p u b l i c c l a s s AutomatonDemo {
automaton {
i n i t i a l S0 : S1 ;
a c c e p t i n g S1 ;
}
public void callMeOnce ( ) {
t r a n s i e n t : S1 ;
}
p u b l i c boolean w a s A l r e a d y C a l l e d ( ) {
r e t u r n t r a n s i e n t ? S1 ;
}
}
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Implementacja
Zaproponowane przez autora mechanizmy PPK zostały
osadzone w składni Javy za pomocą dodatkowych reguł
gramatycznych.
Gramatyka została zmodyfikowana w taki sposób aby
powstały język był nadklasą Javy, przy zachowaniu tej samej
semantyki odziedziczonych konstrukcji.
Implementacja propozycji dostarczona jest w postaci
translatora produkującego na wyjściu programy napisane w
Javie. Translator został wygenerowany przy pomocy narzędzia
ANTLR.
Translator potrafi dodatkowo wykrywać błędy semantyczne,
występujące w składni kontraktów.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
Przykład schematu translacji
Fragment kodu przed translacją:
example.javab
p r o t e c t e d i n t method ( ) out ( r e t u r n ∗ r e t u r n >= 0 ) {
return 12;
}
I po translacji (na kolejnym slajdzie):
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Propozycja autora
Implementacja
example.java
p r o t e c t e d i n t method ( ) {
a s s e r t ( ( Example . t h i s . a u t o m a t o n E x a m p l e ==
Example . A u t o m a t o n E n u m e r a t i o n E x a m p l e . S3 ) )
? true : true ;
int out return
= 0;
try {
= 12;
return o u t r e t u r n
} finally {
final int out return2 = out return ;
assert out return2
∗ out return2
>= 0 ;
a s s e r t ( ( Example . t h i s . a u t o m a t o n E x a m p l e ==
Example . A u t o m a t o n E n u m e r a t i o n E x a m p l e . S3 ) )
? true : true ;
}
}
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wprowadzenie
Dynamiczne Role
Propozycja autora
Implementacja
Część II
Dynamiczne Role
(W tej chwili powinna mijać 40 minuta prezentacji...)
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wprowadzenie
Dynamiczne Role
Propozycja autora
Implementacja
Dynamiczna funkcjonalność
Przykład 1 — cykl rozwojowy motyla.
Przejście ze stadium gąsienicy do stadium imago nosi
wymowną nazwę “zupełnego przeobrażenia”; Mimo że dany
motyl potrafi w trakcie swojego życia zmienić zupełnie postać,
cały czas pozostaje tym samym, w sensie identyfikacji,
osobnikiem.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wprowadzenie
Dynamiczne Role
Propozycja autora
Implementacja
Dynamiczna funkcjonalność c.d.
Przykład 2 — system świadczący usługi.
Niech dany będzie pewien system. W systemie tym istnieją
byty abstrakcyjnych usługobiorców, na rzecz których
świadczone są usługi. Konkretna usługa wymaga konkretnego
typu usługobiorcy. Abstrakcyjny usługobiorca może być
klientem różnych usług, tj. mogą być z nim związane różne
instancje konkretnego usługobiorcy.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wprowadzenie
Dynamiczne Role
Propozycja autora
Implementacja
Dynamiczna funkcjonalność c.d.
Problem — jak zamodelować komponent usługobiorcy?
jako pojedynczą klasę?
jako szereg klas związanych ze sobą pewnym wzorcem
(Composite, Decorator)?
w ogóle nie wyodrębniać komponentu?
Wady poszczególnych rozwiązań...
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wprowadzenie
Dynamiczne Role
Propozycja autora
Implementacja
Dynamiczne Role - definicja
Dynamiczne role są pewną koncepcją z pogranicza
kontroli typów w językach programowania. Pojęcie to
oznacza swego rodzaju mechanizm, który pozwala na
dynamiczne przypisywanie danemu obiektowi wielu
różnego rodzaju typów (i związanych z nimi wartości)
jednocześnie. Obiekt ów nosi miano aktora, a jego
reprezentacje, w postaci wartości o określonych typach,
nazywane są rolami
Można powiedzieć, że głównym celem użycia dynamicznych ról jest
modelowanie bytów o dynamicznie zmieniającym się interfejsie:
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wprowadzenie
Dynamiczne Role
Propozycja autora
Implementacja
Propozycja autora
Funkcję ról pewnego aktora pełnią obiekty zwyczajnych klas
języka Java, tzw. POJO.
Funkcja aktora jest pełniona przez specjalną klasę Actor.
Współdziałanie ról w obrębie danego aktora polega na
synchronizacji odpowiednich pól.
Actor amphibian = ActorFactory . c r e a t e A c t o r ( ) ;
Ship s h i p = amphibian . playRole ( Ship . c l a s s ) ;
s h i p . f l e e t ( 10 ) ;
Car c a r = a m p h i b i a n . p l a y R o l e ( Car . c l a s s ) ;
c a r . move ( −15 ) ;
a s s e r t s h i p . g e t P o s i t i o n ( ) == −5;
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wprowadzenie
Dynamiczne Role
Propozycja autora
Implementacja
Implementacja
Zaproponowany przez autora mechanizm Dynamicznych Ról
został dostarczony w formie biblioteki.
Składnia języka nie została zmieniona, jednakże jego
semantyka w pewnym sensie tak.
Biblioteka, w celu uzyskania żądanego działania, podczas
ładowania klas ról tworzy odpowiadające im klasy agentów
(proxy).
“Pod maską” używana jest biblioteka Javassist, dzięki której
nie było potrzeby bezpośredniej manipulacji bytecodem.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Wybrana bibliografia
Koniec
A.V. Aho, R. Sethi, and J.D. Ullman. Kompilatory: reguły,
metody i narzędzia. Wydawnictwa Naukowo-Techniczne,
Warszawa, 2002.
J.E. Hopcroft, R. Motwani, and J.D. Ullman Introduction to
Automata Theory, Languages, and Computation. Addison
Wesley, 2006.
J. Gosling, B. Joy, G. Steele, and G. Bracha. Java (TM)
Language Specification. Addison Wesley Professional, 2005.
T. Parr. The Definitive ANTLR Reference: Building
Domain-specific Languages. Pragmatic Bookshelf, 2007.
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Koniec
Pytania
Pytania?
Aleksander Kosicki
Wstęp
Dynamiczne Role
Uwagi końcowe
Koniec
Podziękowania
Dziękuję za uwagę
Aleksander Kosicki

Propozycja Dynamicznych Ról i Programowania Przez Kontrakt dla

Transkrypt

Podobne dokumenty

Załącznik 2 do zarządzenia nr 16 Rektora Uniwersytetu Śląskiego w

zajęcia fakultatywne bródnowskiego uniwersytetu dzieci

ZAŁ4.Oświadczenie autora o przekazaniu

Wniosek o powołanie komisji egzaminacyjnej do przeprowadzenia

Ocena pracy dyplomowej

Plan pracy dyplomowej studentom prawa może

Kontrakty zawierane z uczniami w szkole funkcjonują od wielu już

Programista tokarki-frezarki - Praca

Technologie internetowe i mobilne

Opinia promotora w sprawie dopuszczenia pracy