Standardy w zakresie systemów rozproszonych i baz danych

1. Standardy w zakresie systemów rozproszonych i baz danych Wykład 13: Wizualne programowanie w VIDE Piotr Habela Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. Możliwości programowania wizyjnego • Jakkolwiek próby stworzenia interfejsu do programowania wizyjnego są podejmowane od dawna, znajduje się ono raczej na uboczu głównego nurtu języków programowania. • Podzielone są poglądy co do tego, czy wizyjna forma programu przynosi właściwe efekty • Dla szybkości programowania • Dla zrozumiałości kodu (łatwiejszego jego odczytania) • Dla pielęgnacyjności (szybszej możliwości zmiany kodu) • Budowa języka programowania opartego na UML w sposób naturalny każe rozważyć ten styl programowania • UML jest oparty na rodzinie wizyjnych diagramów • Wizualną analizę i projektowanie/modelowanie uważa się za bardziej naturalne, wykorzystującą wrodzone własności percepcyjne gatunku ludzkiego • Niektóre diagramy UML mają rzeczywiście charakter programów zapisanych graficznie, więc może wystarczy je po prostu uściślić? • Istnieje jednak spory sceptycyzm dotyczący tego stylu programowania • wielu znanych metodologów nie wierzy w jego skuteczność.

3. Założenie VIDE w zakresie programowania wizyjnego • Początkowe założenia były bardzo optymistyczne – autor projektu (Grzegorz Fałda) wierzył, ze ten styl zrewolucjonizuje tworzenie oprogramowania biznesowego • Przyjęto twarde założenie, że każda forma tekstowa będzie miała swój odpowiednik wizyjny, i odwrotnie • Koncepcja ta (tzw. PEC – pre-existing concept) była oparta na języku Smalltalk, którego zdania były zapisywane w postaci zagnieżdżonych prostokątów oraz innych symboli graficznych • Koncepcja została zrealizowana w postaci prototypu • Ta koncepcja napotkała na dość zdecydowany opór ze strony innych uczestników projektu (szczególnie SAP i Bournemouth Univ.) • Argumentowano, ze dla cokolwiek bardziej złożonych programów ich zapis wizyjny jest nieczytelny, stwarzający wrażenie chaosu • Był to krytyczny moment projektu, gdyż początkowe najbardziej istotne założenie nie mogło być zrealizowane • W tej sytuacji podjęta została decyzja o rezygnacji z PEC na rzecz innych koncepcji • Zrezygnowano przy tym z założenia o 1:1 odwzorowaniu formy tekstowej w wizyjną, i odwrotnie

4. Formy programowania wizyjnego w VIDE • Diagram klas UML jako sposób deklarowania obiektowych struktur danych. • Zrealizowany w wielu narzędziach CASE • VIDE zaadoptowało dwa z nich (Topcased, Softeam Objecteering) • Diagramy stanów (w formie zbliżonej do diagramów aktywności) • zrealizowane przez SAP • Wizualny Edytor Wyrażeń • Zrealizowany przez PJWSTK • koncepcja bazuje na graficznym języku Query-By-Example zaproponowanym przez IBM w latach 1970-tych i następnie rozwiniętym w wielu systemach (np. Microsoft Access) • Wizualizacja języka OCL • Każda forma wizyjna ma swój odpowiednik tekstowy i kompiluje się do formy tekstowej • Jest to istotne z punktu widzenia metamodelu – w ten sposób nie ma potrzeby tworzenia go dla form wizyjnych

5. Przykład diagramu klas tworzonego w Topcased • VIDE wprowadza pewne ograniczenia w stosunku do UML – nie wszystkie jego konstrukcje są wspierane • Ograniczenia są podyktowane trudnościami z doborem konstrukcji programistycznych obsługujących pewne struktury danych • Np. asocjacje n-arne, n>2 • Ograniczenia te są nieistotne w 99% przypadków

6. Edytor Wizualny • Edycję w edytorze wizualnym wywołujemy w sposób analogiczny, jak dla edytora tekstowego, czyli wybierając z menu kontekstowego operacji pokazanej w modelu otwartym w Repository Browser opcję „Open Visual Editor”.

7. Tworzenie metod (1) • Dla nowo utworzonej metody, zobaczymy w edytorze następującą zawartość: • Należy, pod inicjacją zmiennej self, dodać SequenceNode. Będzie ona odpowiednikiem nawiasów klamrowych wyznaczających w edytorze tekstowym zewnętrzne granice ciała operacji: • Następne czynności realizujemy wybierając odpowiednie konstrukcje z przybornika edytora wizualnego po prawej stronie i wskazując kliknięciem ich lokalizację w diagramie metody. Wszystkie wstawiane przez nas elementy powinny się znaleźć w ww. SequenceNode.

8. Tworzenie metod (2) • Edytor intensywnie wspiera podpowiedzi kontekstowe – pojawiają się one na liście pod polem, do którego wpisujemy nazwę: • Nazwy należy jednak wprowadzić z klawiatury • Konstrukcje języka wizualnego – aktywności, akcje oraz deklaracja zmiennej – są, w zależności od ich charakteru, parametryzowane wyrażeniami OCL, nazwami klasy /atrybutu / operacji / zmiennej, lub liczbami.

9. Edytor Wizualny – Sequence Node • Stanowi kontener na instrukcje; odpowiada w języku tekstowym klamerkom { } ; zapewnia uporządkowanie tych instrukcji w zadanej kolejności wykonania • Element ten automatycznie się powiększy, dopasowując swój rozmiar do wstawianych weń elementów. • Zwykle tworzenia Sequence Node będziemy potrzebować tylko dla ciała całej metody – w pozostałych przypadkach odpowiedni kontener zostanie już dla nas automatycznie utworzony (np. wewnątrz instrukcji iterującej czy warunkowej).

10. Edytor Wizualny – Conditional Node • Parametryzowana wyrażeniem OCL (w polu <Condition>) – powinno ono zwracać wartość typu Boolean. • Poza tym zawiera gotowy Sequence Node, przeznaczony do wstawienia instrukcji, które zostaną wykonane, jeśli warunek zostanie spełniony. • Nie mamy obsługi bloku „else”. Wobec czego, jeśli jest potrzebny, trzeba stworzyć drugi Conditional Node z zanegowanym warunkiem.

11. Edytor Wizualny – Expansion Region • Instrukcja jest parametryzowana wyrażeniem OCL (w polu <Collection>) • Powinno zwracać pojedynczy obiekt, albo kolekcję wartości do przetworzenia. • Drugim z parametrów (domyślnie „i”) jest nazwa iteratora – możemy ją zmienić w zależności od potrzeb. • Poza tym zawieraj gotowy Sequence Node, przeznaczony do wstawienia instrukcji, które zostaną wykonane kolejno dla każdego z elementów zwróconych przez wyrażenie w polu <Collection>.

12. Edytor Wizualny – Call Operation Action • Instrukcja jest parametryzowana wyrażeniem OCL (w polu <Target>) – powinno ono zwracać pojedynczy obiekt. • Drugim z parametrów jest <Operation> - tu musi pojawić się nazwa operacji. • Typ wyrażenia <Target> jest badany i nazwy dostępnych operacji podawane są w podpowiedziach.

13. Edytor Wizualny – Create Object Action • Instrukcja jest parametryzowana nazwą klasy tworzonego obiektu (w polu <Classifier>) – są dostępne podpowiedzi. • Drugim z parametrów jest variable – pozwala programiście wybrać nazwę dla automatycznie utworzonej zmiennej, poprzez którą będzie można dostać się do nowo utworzonego obiektu. • Jak widać, nie mamy tu do dyspozycji środków dla bezpośredniego inicjowania atrybutów i powiązań nowotworzonego obiektu. • Trzeba je aktualizować za pomocą zestawu konstrukcji Add Structural Feature Value Action (zob. dalej), umieszczonego po akcji utworzenia obiektu.

14. Edytor Wizualny – Reply Action • Parametryzowana wyrażeniem OCL (w polu <Return Value>) – jego typ rezultatu powinien być zgodny z sygnaturą operacji, dla której budujemy metodę.

15. Edytor Wizualny – Add Structural Feature Value Action • Parametryzowana wyrażeniem OCL (w polu <Object>) • Powinno ono zwracać pojedynczy obiekt, nazwą atrybutu albo końca asocjacji – w polu <Feature> (są dostępne podpowiedzi, jeśli wcześniej wypełnimy <Object) i wartością podstawianą – wyrażenie OCL w polu <Feature Value>. • Jeśli zatem chcemy zainicjować atrybuty / powiązania nowo utworzonego obiektu – dla każdego z atrybutów i powiązań tworzymy taką akcję i w jej polu <Object> - podajemy nazwę zmiennej powołanej dla nowoutworzonego w Create Object Action obiektu. • Jeśli chcemy zastąpić dotychczasową zawartość modyfikowanej własności – należy w okienku Properties zmienić wartość flagi Is Replace All na true.

16. Edytor Wizualny – Remove Structural Feature Value Action i Clear Structural Feature Action • Parametryzowana wyrażeniem OCL (w polu <Object>) • Powinno ono zwracać pojedynczy obiekt, • Drugi parametr jest nazwą atrybutu albo końca asocjacji – w polu <Feature> • są dostępne podpowiedzi, jeśli wcześniej wypełnimy <Object> • W przypadku pierwszej z ww. akcji, wartość, która ma być usunięta, jest określona wyrażeniem OCL w polu <Feature Value>.

17. Edytor Wizualny – Variable • Deklaracja zmiennej lokalnej. • Parametryzowana nazwą deklarowanej zmiennej (w polu <Variable Name>), oraz nazwą typu zmiennej – w polu <Type> (są dostępne podpowiedzi) i licznością zmiennej. • Jeśli powołujemy zmienną typu prostego, może on nie pojawić się na liście dostępnych opcji dla <Type>. • W takim wypadku należy sięgnąć do widoku Properties elementu Variable i wybrać odpowiedni typ. • Add Variable Value Action, Remove Variable Value Action, Clear Variable Action - Akcje te skonstruowano dla zmiennych lokalnych w sposób w pełni analogiczny z odpowiednimi akcjami dla właściwość (Structural Feature) obiektów.

18. Przykład programu wizyjnego w VIDE accountX.balance>= transfer any accountX accountX: Account number = x accountX: balance -= transfer any accountX accountY: accountY: Account balance += transfer number = y Aktualizacja konta: transfer pieniędzy z konta x na konto y. warunek: stan konta x jest większy lub równy transferowi Zmniejszenie konta x Selekcja konta x Zwiększenie konta y Selekcja konta y

19. Przykład wizualizacji ciała metody • Przykład ilustruje, że wizualizacja nie usuwa złożoności, wręcz odwrotnie. • W wersji wizualnej tak czy inaczej jest mnóstwo kodu tekstowego.

20. Wizyjne zapytania Schemat: 1. Podaj nazwiska pracowników pracujących w dziale, którego szefem jest Bert: Emp ->select(worksIn.boss.name = "Bert").name 2. Zwróć nazwisko szefa pracownika Poe. Emp -> any (name = "Poe").worksIn.boss.name

21. Wizyjne zapytania w konstrukcji imperatywnej Schemat: Podnieś o 100 zarobek pracowników pracujących w dziale kierowanym przez Smith’a i zarabiających mniej niż 2000. (Dept ->select (boss.name = "Smith"). employs -> select (salary < 2000)-> foreachsalary += 100;

22. Wizualny Edytor Wyrażeń - idea • Oparty na idei QBE • W QBE wyświetlamy relacyjna tabelę lub kilka tabel, w których wypełniamy pewne pola stałymi (ew. z operatorami), zaś pewne pola zmiennymi (examples). • Stałe służą do selekcji odpowiednich krotek, zmienne służą do tworzenia złączeń (joins). • Pewne pola są zaznaczane jako wynik (output). • Ta idea została obudowana ogromną liczbą opcji, które w dużym stopniu przyczyniły się do jej porażki w głównym nurcie • Powstało wiele uproszczonych wersji, np. Forms lub wersja MS Access • Dokładnie ta sama idea jest zaimplementowana w VIDE jako VEB (Visual Expression Builder). • Oczywiście, zamiast tabel mamy klasy (ściślej: kolekcje obiektów), a zamiast zmiennych mamy asocjacje. • Liczba opcji została silnie ograniczona • Nie mamy ambicji, aby narzędzie było algorytmicznie kompletne • Raczej chodzi o te opcje, które są łatwe i naturalne dla użytkowników • Inna nazwa narzędzia: Object Query by Example, OQBE.

23. VEB diagram w edytorze

24. Przykład zapytania w VEB • Dwie klasy, Auction i Bid • Nazwa przedmiotu aukcji ‘Vide Cookbook’ • Asocjacja bid do oferty (bid) • Oferty są porządkowane wg daty i ceny. • Wynikiem (output) sa oferty.

25. Przykład zapytania w VEB

26. Przykład zapytania w VEB • Podaj użytkowników, którzy złożyli ofertę na pozycje sprzedawane przez użytkowników z niższa ranga (rating)

27. Przykład zapytania w VEB • Podaj użytkowników, którzy sprzedają wyłącznie pozycje z kategorii „książki”