kierujemy niniejsze
Podczas spotkania przedstawimy trzy sporych rozmiarow projekty badawcze:
Wszystkie projekty rzucaja wyzwanie trudnosciom teoretycznym, zlozonosci projektow i
naszej ogolnej niemoznosci. Nie mamy zamiaru niczego ukrywac, chcemy te wyzwania
omowic i przedyskutowac. Wiemy, ze ich pokonanie jest mozliwe.
Projekty te sa ze soba scisle powiazane: w projekcie CASE NT chcemy wykorzystac
Loglan jako narzedzie pracy i jako zrodlo doswiadczen, w projekcie Loglan'96
chcielibysmy by system CASE NT stanowil uzupelnienie systemu kompilator+interpreter.
Mamy nadzieje, ze nie. Kazdy z proponowanych projektow moze przyciagnac wielu wspolpracownikow z Polski i z zewnatrz. Dla kazdego znajdzie sie praca odpowiednia do jego kwalifikacji i zamilowan. Nasze zaproszenie jest zaadresowane do pracownikow naukowych, ambitnych studentow, placowek badawczych i firm software'owych.
Zacznijmy od cytatu "apetyt rosnie w miare jedzenia". W naszym przypadku oznacza to, ze poczatkowa specyfikacja projektu (projektow) bedzie ulegac zmianom, rozszerzeniom.
Tu jest wiele do zrobienia:
Loglan'96 | |
---|---|
Przedyskutowac i zatwierdzic raport jezyka | uwaga.1sza wersja powinna byc gotowa szybko. Spodziewamy sie ze trzeba bedzie ja poprawic gdy beda pierwsze wyniki dot. implementacji |
Stworzyc opis jezyka | Chcielibysmy by byl to opis formalny, aksjomatyczny, wykorzystujacy aparature logiki algorytmicznej. Ale wymagac to bedzie rozwiazania nowych problemow. W szczegolnosci dotyczacych dziedziczenia klas. |
Stworzyc opis L-maszyny virtualnej czyli interpretera | Istnieje cenne opracowanie A. Kreczmara. Do niego trzeba by dodac: procesy i obiekty trwale (persistent object). |
Podac specyfikacje i zaimplementowac kompilator Loglanu'96 w Loglanie | Proponujemy by zastosowac metode zstepujacej rekursji. Zastanowic sie czy przy okazji nie da sie stworzyc modulu alternatywnego dla yacca i bisona. Mialoby to polegac na automatycznym tworzeniu klas i innych modulow (pierwszej czesci) kompilatora na podstawie gramatyki jezyka zapisanej w notacji EBNF. |
Zbadac i zaproponowac nowa koncepcje biblioteki modulow predefiniowanych | Kazdy program jest domyslnie prefiksowany klasa BIBLIOTEKA pref BIBLIOTEKA programjego nazwa; ... end; Dzieki temu moze dziedziczyc inne moduly zawarte w BIBLIOTECE. Ale tylko te z pierwszego poziomu zagniezdzenia. Krotko mowiac, uwazamy ze nalezy pojecie biblioteki zorganizowac wokol pojec modul i klasa. |
Zaimplementowac rozpraszanie procesow w sieci heterogenicznej. | Obecnie potrafimy rozpraszac procesy w sieci maszyn Unixowych. Najblizsze zadania polegaja na przeniesieniu obecnych rozwiazan na siec zawierajaca maszyny DOS i Windows, a takze na Novella i inne platformy. |
Biblioteki uslug sieciowych dla programowania w Loglanie. | Rozszerzyc zbior klas predefiniowanych o klase NETLIB umozliwiajaca korzystanie z protokolow sieciowych roznych warstw np. TCP/IP, FTP, HTTP, ... |
"Stary" Loglan | |
Uporzadkowac dokumentacje | Np. wydac nowa wersje raportu jezyka. To juz jest zaawansowane. |
Ulepszyc srodowisko Loglanu | Np. poprawic edytor Lotek, lub napisac nowy Rozwazyc ponowne wprowadzenie debuggera Teresy Przytyckiej. Ujednolicic biblioteke graficzna: w tej chwili biblioteki dla DOSa i Xwindows bardzo sie roznia. Mozna napisac w Loglanie jedna wspolna "czapke". |
Uporzadkowac aplikacje i ich opisy |
|
Nowe aplikacje | |
CASE NT | zob. ponizej |
browser typu HotJava | to moze byc i ciekawe i pozyteczne |
Obiektowa baza danych | Tu jest sporo wynikow zespolu L. Banachowskiego trzeba to wykorzystac |
Nowa klasa simulation | Jak powinna wygladac symulacja przeprowadzana na maszynie wieloprocesorowej? Nie wiemy, ale podejrzewamy ze powinien powstac nowy uniwersalny modul. Jego specyfikacja nie jest dla nas ozywista. Symulacja wieloprocesorowa powinna byc bardziej wydajna za wzgledu na przyspieszenie ale moze tez wnosic i inne aporty. |
Obecne systemy CASE sa drogie i nie dostarczaja zadnych narzedzi wpomagajacych analize poprawnosci
powstajacego oprogramowania wzgledem jego specyfikacji. Gorzej, bo nie dostarczane sa narzedzia wspomagajace tworzenie specyfikacji ani tym bardziej ich analizy. Dzis czesto przez specyfikacje rozumie sie liste metod (operacji) czyli funkcji i procedur wraz z wyliczeniem typow argumentow i wynikow. To jest uproszczenie idace zbyt daleko. Mozna dolaczyc postulaty dotyczace tych procedur. Zapisane w jezyku etnicznym nie nadaja sie one do dalszego formalnego przetwarzania.
My mozemy sie wesprzec na naszych wlasnych wynikach dotyczacych specyfikacji. Nasza metoda specyfikacji zostala sprawdzona w kilku eksperymentach i cieszy sie nastepujacymi (meta)wlasnosciami:
Formalnym narzedziem powstajacego systemu CASE bedzie logika algorytmiczna. Rachunek ten w swiecie programowania ma do spelnienia role porownywalna z rola rachunku rozniczkowego i calkowego w tradycyjnej inzynierii mechanicznej czy elektrycznej.
Naszym zdaniem nowy system powinien przewyzszac dotychczas znane systemy i dostarczac narzedzi wspomagajacych dowodzenie wlasnosci programow z aksjomatow specyfikacji.
Zadania jakie sobie stawiamy to miedzy innymi opis abstrakcyjnego typu danych: SRODOWISKO DOWODOW FORMALNYCH Logiki Algorytmicznej i jego obiektowa realizacja. Nalezy wiec opisac typy danych np. formula, wezel drzewa dowodu, drzewo dowodu, etc.i operacje na nich. Zaprogramowac klasy i metody odpowiadajace opisanym typom i operacjom. Zaprogramowac przyjazne srodowisko asystujace dowodzeniu wlasnosci programow.
wyznaczanie prawdopodobienstw zachowan algorytmow probabilistycznych dzialajacych na zbiorach skonczonych, | opracowanie oprogramowania (w Loglanie) umozliwiajacego wyznaczanie prawdopodobienstw zachowan algorytmow probabilistycznych (niezaleznie od symulacji ich dzialania) |
zastosowanie algorytmow do zagadnien analizy informacji niepewnej (porownanie z metoda zbiorow przyblizonych - Z.Pawlak, A.Skowron), | w procesie analizy algorytmow probabilistycznych nasza uwaga skupiona jest wylacznie na stanach koncowych, np. proces wypracowania przyblizonych regul decyzyjnych (analogicznie: zasad wnioskowania statystycznego) dokonuje sie przy pomocy pewnego algorytmu probabilistycznego; poszczegolnym regulom odpowiadaja pewne stany koncowe, |
badanie zwiazkow miedzy algorytmami probabilistycznymi, interpretowanymi w dziedzinach skonczonych, ze skonczenie stanowymi lancuchami Markowa: | nawet w przypadku bardzo prostych iteracyjnych
algorytmow probabilistycznych, interpretowanych
w skonczonym zbiorze, odpowiadajacy lancuch Markowa
nie musi byc ergodyczny, potrafimy juz wyznaczac prawdopodobienstwa przejsc wylacznie do stanow koncowych, nawet w przypadku lancuchow nieergodycznych. |
Mamy nadzieje, ze nasza propozycja nie jest Ci obojetna.