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 szczegóły.

– 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 • 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 (InterruptedException e) {}; } elements[++top] = element; if (top==0) notifyAll();

// signal if was empty

} public synchronized Object pop() { while (top==-1) { try { wait(); } catch (InterruptedException e) {}; } Object return_val = elements[top--]; if (top==under_max_top) notifyAll();

// signal if was full

return 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 wszystkie aspekty złożony, ponieważ muszą być brane pod uwagę jednocześnie.

2.

3.

Implementacja jest trudna do zrozumienia.

Kod programu jest często nadmiarowy 4.

5.

Wprowadzanie zmian wymaga mentalnej dekompozycji, modyfikacji i ponownego zespolenia.

Możliwość występowania tzw. anomalii dziedziczenia (ang. Inheritance anomalies) w tworzenie językach wspierających programowanie współbieżne czy 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

interakcja pomiędzy obiektami

zabezpieczenia QoS rozproszenie

zarządzanie buforami

replikacja optymalizacje

ograniczenia czasu rzeczywistego

monitoring

trwałość

transakcje Aspekty specyficzne dla aplikacji (np. optymalizacja)

obsługa wyjątków i błędów

debugowanie

Historia zmian

wizualizacje 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 (InterruptedException e) {}; } elements[++top] = element; if (top==0) notifyAll();

// signal if was empty

} public synchronized Object pop() { while (top==-1) { try { wait(); } catch (InterruptedException e) {}; } 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”

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)

„Tangled” code Moduły funkcjonalne Separacja aspektów Moduły funkcjonalne Aspekty Aspekty 18

Moduły funkcjonalne

Wiązanie aspektów (1)

Statyczne włączanie aspektów Aspekty Join Points Aspect Weaver Kompilator 19

Moduły funkcjonalne

Wiązanie aspektów (2)

Dynamiczne włączanie aspektów Aspekty Kompilator Kompilator Program Join Points 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.setFoo()” 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 M1, które odbywają się z wnętrza metody M2.

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 wyjściowych metody, etc.

21

Aspect Oriented Programming

Principle of separation of concerns

Advance Separation of Concerns Dynamic Roles Hyperspaces Composition Filters Adaptive Programming Subject Oriented 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 STUDENT PODATNIK PACJENT WŁAŚCICIEL PSA CZŁONEK KLUBU 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 Predicate Object

http://www.w3.org/TR/1999/PR-rdf-schema-19990303#Book Owner “John Wayne” 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

->

ilość miejsca na nogi

->

domena

->

Samochód osobowy Minivan 26

Właściwości dynamicznych ról (pod kątem separacji aspektów) - przykłady

RDF Zasoby Właściwości Obiekty 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

Nazwisko Nowak RokUr 1951

pracuje_w

PROFESOR

Zarobek 1500

Staż Pracy

5

stanowisko

KSIĘGOWY Zarobek

1000

Staż Pracy

1

WYKŁADOWCA

Zarobek 1500

Staż Pracy

2

stanowisko stanowisko

INSTYTUT

Nazwa IChR

pracuje_w

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 wizualizacje

KONTO Nr … Właściciel … ZABEZPIECZENIA event

…

condition … Action …

Dostęp do obiektu Dostęp do roli (aspektu) 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