Standardy w zakresie systemów rozproszonych i baz danych

P.Habela, K.Subieta. SSR, Wykład 13, Folia 1 czerwiec 2009

Standardy w zakresie systemów rozproszonych i baz danych

Piotr HabelaKazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 13:Wizualne programowanie w VIDE


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ść.


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


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


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


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”.


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.


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.


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).


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.


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>.


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.


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.


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ę.


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.


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>.


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.


Przykład programu wizyjnego w VIDE

accountX.balance>= transfer

accountX:

balance -= transfer

accountY:

balance += transfer

any accountX

accountX: Account

number = x

any accountX

accountY: Account

number = y

Aktualizacja konta: transfer pieniędzy z konta x na konto y.

Selekcja konta x

Selekcja konta y

warunek: stan konta x jest większy lub równy transferowi

Zmniejszenie konta x

Zwiększenie konta y


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.


Wizyjne zapytania

1. Podaj nazwiska pracowników pracujących w dziale, którego szefem jest Bert:

Schemat:

Emp ->select(worksIn.boss.name = "Bert").name

name = "Bert"

: Empd : Dept

boss

worksIn

e: Emp

select e collect name

name

e : Emp

2. Zwróć nazwisko szefa pracownika Poe.

Emp -> any (name = "Poe").worksIn.boss.name

e : Emp d: Dept

any e collect name

name

: Emp

name

e: Emp

=“Poe“

worksIn boss


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) ->foreach salary += 100;

foreach workerEmp

select b

name = "Smith"

b : EmpbossDept

collect workerEmp

d: Dept workerEmp : Empemploys

select workerEmp

name

workerEmp : Emp

salary<2000

name

workerEmp : Emp

salary += 100


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.


VEB diagram w edytorze


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.



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



• Podaj użytkowników, którzy sprzedają wyłącznie pozycje z kategorii „książki”

Standardy w zakresie systemów rozproszonych i baz danych

Documents

Transcript of Standardy w zakresie systemów rozproszonych i baz danych