Programowanie zorientowane aspektowo a Model obiektowy z rolami

Programowanie zorientowane aspektowo a Model obiektowy z rolami Radosław Adamus

Zagadnienia • Złożoność • Dekompozycja i metody dekompozycji • Aspekty • Narzędzia zaawansowanej separacji aspektów • Model obiektowy z rolami i separacja aspektów 2

Wymagania, z którymi muszą zmierzyć się projektanci systemów • Stworzenie systemu zgodnego z wymaganiami w określonym czasie i budżecie • Stworzenie systemu, którego ewolucja nie doprowadza wprowadzających zmiany do załamania nerwowego • Stworzenie systemu, który wykorzystuje i tworzy elementy ponownego użycia Złożoność oprogramowania wykorzystywanego w praktyce powoduje, że powyższe wymagania są trudne do spełnienia szczególnie, że spełnienie jednego może wykluczać spełnienie innego. 3

Narzędzia wspierające twórców w walce ze złożonością • Dekompozycja – fundamentalna zasada inżynierii (nie tylko) oprogramowania postulująca rozdzielenie problemu na „niezależne” podproblemy, łatwe do wytworzenia, zarządzania, możliwe do ponownego wykorzystania. • Abstrakcja – zasada zwracająca uwagę na ograniczone możliwości człowieka w kontrolowaniu i panowaniu nad złożonością. Najlepiej jest myśleć jednocześnie o wybranej części problemu bez wnikania od razu w szczegóły. • Sprzyjanie naturalnym ludzkim właściwościom pojmowania rzeczywistości na poziomie modelowania oraz implementacji. 4

Divide et impera • Podążając za starożytną regułą w inżynierii oprogramowania jedną z podstawowych zasad jest zasada separacji niezależnych kwestii tworzonego oprogramowania tak, aby umożliwić twórcy zajmowanie się tylko jednym zagadnieniem na raz. • Reguła ta znana jest pod nazwą „principle of separation of concerns” (Dijkstra 1976) Jakie zagadnienia powinny być odseparowywane? Jaki mechanizm dekompozycji wykorzystać? W jaki sposób dokonać optymalnej dekompozycji? W jaki sposób wyrażać zdekomponowane elementy? 5

Zalety optymalnej dekompozycji Ø Ułatwienie ewolucji ØWprowadzania nieinwazyjnych zmian i udoskonaleń oprogramowania Ø Ułatwienie zrozumienia implementacji Ø Zwiększenie możliwości ponownego użycia Ø Uproszczenie procesu integracji komponentów. 6

Dekompozycja pod lupą – metody dekompozycji • Dekompozycja strukturalna – modelowanie funkcji systemu operujących na danych – struktury danych, funkcje. • Dekompozycja zorientowania obiektowo – dekompozycja problemu zgodna z naturalnym sposobem postrzegania przez człowieka opisywanej rzeczywistości - obiekty, komunikaty, dziedziczenie, polimorfizm. Czy to jest optymalna dekompozycja? 7

public class Stack { private int max_top; private int under_max_top; public Stack(int size) { elements = new Object[size]; top = -1; max_top = size-1; under_max_top = max_top-1; } public synchronized void push(Object element) { while (top == max_top) { try { wait(); } catch (Interrupted. Exception e) {}; } elements[++top] = element; if (top==0) notify. All(); // signal if was empty } public synchronized Object pop() { while (top==-1) { try { wait(); } catch (Interrupted. Exception e) {}; } Object return_val = elements[top--]; if (top==under_max_top) notify. All(); // signal if was full return_val; } private int top; private Object [] elements; } 8

Czy obecne metody są lekarstwem na walkę ze złożonością? 9

Modularyzacja obiektowa 10

Wnioski 1. Nie wszystkie kwestie związane z tworzonym systemem da się zdekomponować przy wykorzystaniu istniejących narzędzi dekompozycji 2. Istnieją zagadnienia, które nie pasują do metod dekompozycji udostępnianej przez model obiektowy czy strukturalny. 11

Generowane problemy 1. Proces tworzenia oprogramowania jest trudny i złożony, ponieważ wszystkie aspekty muszą być brane pod uwagę jednocześnie. 2. Implementacja jest trudna do zrozumienia. 3. Kod programu jest często nadmiarowy 4. Wprowadzanie zmian wymaga mentalnej dekompozycji, modyfikacji i ponownego zespolenia. 5. Możliwość występowania tzw. anomalii dziedziczenia (ang. Inheritance anomalies) w językach wspierających programowanie współbieżne czy tworzenie systemów czasu rzeczywistego. 12

Uogólniona procedura (ang. generalized procedure) Obecne metody i notacje koncentrują się na wyszukiwaniu i tworzeniu jednostek odzwierciedlających funkcjonalne zadania tworzonego systemu. Ich struktura wyrażana jest w postaci obiektów, modułów, procedur, itp. , które zostały nazwane uogólnioną procedurą. Jedną z własności złożonych systemów jest to, że pewne kwestie związane z ich tworzeniem przecinają (ang. cross-cut) model stworzony za pomocą uogólnionej procedury. 13

Komponenty i aspekty Własności systemu, które należy zaimplementować, można podzielić na: Komponenty – jeżeli można je zaimplementować wykorzystując Uogólnioną Procedurę (np. . obiekty, metody). Aspekty – jeżeli nie jest możliwe wydzielenie ich przy zastosowaniu Uogólnione Procedury. G. Kiczales Aspekt Jest to zazwyczaj niefunkcjonalne wymaganie względem systemu, którego implementacja powoduje rozsianie dedykowanego kodu w wielu miejscach modelu funkcjonalnego. 14

Aspekty synchronizacja rozproszenie ograniczenia czasu rzeczywistego obsługa wyjątków i błędów interakcja pomiędzy obiektami zarządzanie buforami monitoring debugowanie zabezpieczenia replikacja trwałość Historia zmian Qo. S optymalizacje transakcje wizualizacje Aspekty specyficzne dla aplikacji (np. optymalizacja) 15

public class Stack { private int max_top; private int under_max_top; public Stack(int size) { elements = new Object[size]; top = -1; max_top = size-1; under_max_top = max_top-1; } public synchronized void push(Object element) { while (top == max_top) { try { wait(); } catch (Interrupted. Exception e) {}; } elements[++top] = element; if (top==0) notify. All(); // signal if was empty } public synchronized Object pop() { while (top==-1) { try { wait(); } catch (Interrupted. Exception e) {}; } Object return_val = elements[top--]; if (top==under_max_top) notify. All(); // signal if was full return_val; } private int top; private Object [] elements; } „Tangled code” 16

Programowanie Zorientowane Aspektowo (AOP) Język komponentowy public class Stack { private int s_size; public Stack(int size) { elements = new Object[size]; top = -1; s_size = size; } public void push(Object element) { elements[++top] = element; } public Object pop() { return elements[top--]; } private int top; private Object [] elements; } Język aspektowy coordinator Stack { selfex push, pop; mutex {push, pop}; condition full=false, empty=true; guard push: requires !full; onexit { if (empty) empty=false; if (top==s_size-1) full=true; } guard pop: requires !empty; onexit { if (full) full=false; if (top==-1) empty=true; } } 17

Programowanie Zorientowane Aspektowo (AOP) Separacja aspektów „Tangled” code Moduły funkcjonalne Aspekty 18

Wiązanie aspektów (1) Statyczne włączanie aspektów Moduły funkcjonalne Aspekty Join Points Aspect Weaver Kompilator 19

Wiązanie aspektów (2) Dynamiczne włączanie aspektów Aspekty Moduły funkcjonalne Kompilator Join Points Program Aspect Weaver 20

Punkty odniesienia (join points) Join Points – powiązanie pomiędzy aspektami a klasami, umożliwiające odpowiednie połączenie. Typy Join Points: Syntaktyczne Proste : odniesienie do nazwy klasy, metody, atrybutu. Na przykład: każde odwołanie się do metody „C. set. Foo()” powinno być zapisywanie w pliku. Kwalifikowane: odniesienie do nazwy wraz z warunkiem. Na przykład zapisywane do pliku mają być tylko te wywołania metody M 1, które odbywają się z wnętrza metody M 2. Semantyczne Dynamiczne Włączenie aspektu w zależności od spełnienia danej konstrukcji semantycznej (np. Dla wszystkich metod modyfikujących stan obiektu – niezależnie od typu obiektu). Włączenie aspektu w zależności od dynamicznych warunków, grafu -wywołań, wartości parametrów wejściowych i 21 wyjściowych metody, etc.

Principle of separation of concerns Advance Separation of Concerns Dynamic Roles Aspect Oriented Programming Subject Oriented Programming Composition Filters Hyperspaces Adaptive Programming Variation Oriented Programming Hybrid Approach 22

Wymagania względem mechanizmu zaawansowanej separacji kwestii (aspektów) 1. Udostępnieni mechanizmu kompozycji aspektu i klasy w sposób „nieinwazyjny”. Istniejący kod wykorzystujący daną klasę nie powinien być modyfikowany w celu akceptacji wersji z aspektem. 2. Udostępnienie mechanizmu do reprezentacji ogólnych aspektów, które można specjalizować, w celu wykorzystania w różnych kontekstach. 3. Minimalizacja powiązania pomiędzy aspektami. 4. Udostępnienie mechanizmu definiowania syntaktycznych i semantycznych „punktów odniesienia” (join points). 5. Możliwość określania zależnych od kontekstu „punktów odniesienia” (możliwość „przeskakiwania aspektu” w zależności od kontekstu wywołania). 6. Mechanizm umożliwiający definiowanie różnych interfejsów dla różnych kategorii klientów oraz wymuszać poprawne użycie tych interfejsów. 23

Dynamiczne role OSOBA PRACOWNIK PODATNIK STUDENT WŁAŚCICIEL PSA CZŁONEK KLUBU PACJENT 24

Właściwości dynamicznych ról pod kątem separacji aspektów • Rola może być wstawiona i usunięta z obiektu dynamicznie w czasie wykonania. • Możliwość przeskakiwania roli z jednego obiektu na drugi. • Role przynależne do jednego obiektu mogą mieć atrybuty, metody o takiej samej nazwie, które mogą mieć zupełnie inną semantykę. • Rola posiada swoje własne atrybuty i zachowanie (metody, aktywne reguły) – role aktywne i pasywne 25

Właściwości dynamicznych ról (pod kątem separacji aspektów) - przykłady RDF Opis zasobów na zasadzie: Zasób (resource) -> właściwość (property)-> wartość właściwości Statement { Subject http: //www. w 3. org/TR/1999/PR-rdf-schema-19990303#Book Predicate Owner Object “John Wayne” Właściwości: -Określanie relacji dziedziczenia pomiędzy klasami opisywanych zasobów (sub. Classof) oraz terminami opisującymi te zasoby (sub. Propertyof) (np. . Pojazd -> samochód, biologiczny rodzic -> biologiczny ojciec. ). - Określanie grupy (domeny) zasobów, które mogą być opisane przez dany termin. np. autor -> domena -> książka, autor -> domena -> artykuł, ilość miejsca na nogi -> domena -> Samochód osobowy ilość miejsca na nogi -> domena -> Minivan 26

Właściwości dynamicznych ról (pod kątem separacji aspektów) - przykłady RDF Zasoby Obiekty Właściwości Aspekty (role) 27

Właściwości dynamicznych ról (pod kątem separacji aspektów) - przykłady Dublin Core - podstawowe elementy opisu zasobów WWW: Dotyczące zawartości: • Coverage • Description • Type • Relation • Source • Subject • Title Dotyczące własności: • Contributor • Creator • Publisher • Rights Opisujące właściwości: • Date • Format • Identifier • Language 28

Wizja architektury projektu ICONS Peryferia systemu XML, RDF i inne technologie Web API oparte na obiektowym języku zapytań a la SQL Repozytorium aktywnej obiektowej bazy danych z dynamicznymi rolami obiektów Repozytorium metadanych zintegrowane z zarządzaniem konfiguracją Peryferia systemu Relacyjne bazy danych i inne spadkowe technologie 29

Separacja aspektów przy użyciu dynamicznych ról Modelowanie zmian zachowania obiektu w zależności od perspektywy (perspective dependent behaviour variation) OSOBA Staż Pracy 1 Nazwisko Nowak Zarobek 1000 Rok. Ur 1951 KSIĘGOWY PROFESOR Zarobek 1500 Staż Pracy 5 stanowisko WYKŁADOWCA Zarobek 1500 Staż Pracy 2 stanowisko pracuje_w INSTYTUT Nazwa ICh. R INSTYTUT Nazwa DMCS pracuje_w FUNDACJA Nazwa Serce 30

Separacja aspektów przy użyciu dynamicznych ról Odseparowywanie aspektów przy wykorzystaniu aktywnych ról zabezpieczenia monitoring debugowanie obsługa wyjątków transakcje KONTO Nr … Właściciel … ZABEZPIECZENIA event … condition … Action … Dostęp do roli (aspektu) Dostęp do obiektu wizualizacje 31

Future Work Ø Zdefiniowanie metamodelu umożliwiającego traktowanie roli jako aspektu Ø Dynamiczna typizacja – refleksja Ø Interfejs do aspektu (roli) a interfejs do obiektu Ø Jednoczesne dołączanie aspektu do obiektów różnych typów Ø Stworzenie prototypu bazy danych 32

Ten referat powinien mieć tytuł: Zaawansowana separacja aspektów a model obiektowy z rolami 33

Dziękuję za uwagę 34