Programowanie zorientowane aspektowo

Prezentacja na temat: "Programowanie zorientowane aspektowo"— Zapis prezentacji:

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

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

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

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

5 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?

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

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

8 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 (InterruptedException e) {}; elements[++top] = element; if (top==0) notifyAll(); // signal if was empty public synchronized Object pop() { while (top==-1) Object return_val = elements[top--]; if (top==under_max_top) notifyAll(); // signal if was full return return_val; private int top; private Object [] elements;

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

10 Modularyzacja obiektowa

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

12 Generowane problemy Proces tworzenia oprogramowania jest trudny i złożony, ponieważ wszystkie aspekty muszą być brane pod uwagę jednocześnie. Implementacja jest trudna do zrozumienia. Kod programu jest często nadmiarowy Wprowadzanie zmian wymaga mentalnej dekompozycji, modyfikacji i ponownego zespolenia. 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.

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

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

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

16 „Tangled code” 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 (InterruptedException e) {}; elements[++top] = element; if (top==0) notifyAll(); // signal if was empty public synchronized Object pop() { while (top==-1) Object return_val = elements[top--]; if (top==under_max_top) notifyAll(); // signal if was full return return_val; private int top; private Object [] elements; „Tangled code”

17 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; { if (full) full=false; if (top==-1) empty=true;

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

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

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

21 Punkty odniesienia (join points)
Join Points – powiązanie pomiędzy aspektami a klasami, umożliwiające odpowiednie połączenie. Typy Join Points: Proste : odniesienie do nazwy klasy, metody, atrybutu. Na przykład: każde odwołanie się do metody „C.setFoo()” powinno być zapisywanie w pliku. Syntaktyczne Kwalifikowane: odniesienie do nazwy wraz z warunkiem. Na przykład zapisywane do pliku mają być tylko te wywołania metody M1, które odbywają się z wnętrza metody M2. 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). Semantyczne Włączenie aspektu w zależności od dynamicznych warunków, grafu -wywołań, wartości parametrów wejściowych i wyjściowych metody, etc. Dynamiczne

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

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

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

25 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

26 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 { Subject Predicate Owner Object “John Wayne” Statement Właściwości: Określanie relacji dziedziczenia pomiędzy klasami opisywanych zasobów (subClassof) oraz terminami opisującymi te zasoby (subPropertyof) (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

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

28 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

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

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

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

32 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

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

34 Dziękuję za uwagę