zalozenia-projektu-t..

TEMIDA to projekt badawczo-rozwojowy w zakresie inżynierii oprogramowania,
którego głównym celem jest budowa narzędzi architektonicznych automatyzujących
metody inspekcji artefaktów projektowych takich jak kod i model projektowy.
MOTIVATION STORY:
Załóżmy sporej wielkości przedsięwzięcie informatyczne z jawnie zdefiniowaną rolą
architekta oprogramowania (czy też project leadera), którego zadaniem jest szczęśliwe
zakończenie projektu w wyznaczonych ramach czasowo-osobowo-finansowych. W
ramach powyższego zadania można zidentyfikować dwie istotne czynności architekta:
1. zbudowanie szkieletu systemu (kernela) rozwiązującego wszystkie problemy
technologiczne, minimalizującego ryzyko porażki technicznej projektu oraz
umożliwiającego przyszłą rozbudowę systemu,
2. dopilnowanie, żeby pozostali członkowie zespołu uzupełniając szkielet o niezbędną
funkcjonalność nie zepsuli tego, co zostało stworzone w punkcie 1.
Dla zaspokojenia punktów 1 i 2 architekt czyni szereg założeń i wprowadza wiele
ograniczeń, które zapisuje w formie wytycznych architektonicznych (guidelines) i
przekazuje pozostałym uczestnikom projektu (projektantom i programistom
poszczególnych modułów systemu). Przykładem wytycznych architektonicznych jest np.
zakaz bezpośredniego dziedziczenia po pewnej klasie kernela, nakaz wywołania funkcji
X przed każdym wywołaniem funkcji Y, obowiązek obsługi błędu A w określonych
sytuacjach, stosowanie wzorca projektowego D przy realizacji zagadnienia typu S itp.
Przy każdej zmianie kernela (dyktowanej zazwyczaj kwestiami wydajnościowymi lub
rozwojowymi oprogramowania) architekt stara się poruszać w wyznaczonych przez siebie
granicach. Zakłada przy tym, że programiści pisząc dotychczasowy kod zachowali
zgodność z wytycznymi architektonicznymi. Niestety założenie to w porażającej ilości
przypadków okazuje się błędne a system nawet po drobnej zmianie architektonicznej nie
daje się zbildować (skąd to znamy?). Zaczyna się żmudna praca całego zespołu
polegająca na poszukiwaniu buga w kodzie....
O ile inaczej toczyłaby się opisana wyżej historyjka gdyby architektowi, projektantom i
programistom dostarczyć narzędzie weryfikujące zgodność kodu/projektu z wytycznymi
architektonicznymi. A o ile piękniejszy byłby świat, gdyby wykryte błędy automatycznie
niwelować! WARTO wspomnieć że nie znalazłam (na razie) narzędzia realizującego
podobną funkcjonalność.
ZAŁOŻENIA TEMIDY:
1. Architekt jest leniuchem (inaczej nie byłby architektem) dlatego nie skorzysta z
narzędzia, które wymaga od dodatkowego nakładu pracy ponad to co zwykł robić
(czyli picia piwa, kawy i popalania papieroów). Z tych względów należy
maksymalnie wykorzystać wszystkie dostępne środki minimalizując równocześnie
wszelką dodatkową aktywność architekta. Krytyczną kwestią w tym miejscu staje
się forma zapisu wytycznych architektonicznych, które zazwyczaj (jeśli w ogóle)
stanowią dokument tekstowy w ojczystym języku architekta.
2. Programiści i projektanci są przyzwyczajeni do narzędzi z którymi obcują na co
dzień i niechętnie będą używać innych narzędzi na boku tylko dlatego, że
architektowi się tak podoba. Stąd narzędzie weryfikujące (oraz refaktoryzujące)
powinno być zintegrowane z popularnymi środowiskami programistycznymi i
projektowymi. TEMIDA może więc stanowić plug-in (add-ins) do wybranych
środowisk programistycznych i projektowych.
ROZPASANA WIZJA TEMIDY
Najodważniejsza wizja otrzymana w pewnym zwidzie zakłada, że TEMIDA sama
domyśla się co architekt chce powiedzieć po czym sama (nieprzymuszona) sprawdza czy
programiści realizują wytyczne architekta. W przypadku wykrycia błędu automatycznie
dostosowuje kod do wytycznych i obcina premię programisty przenosząc ją na konto
architekta. Ponieważ sztuczna inteligencja nie dorosła do podanej wizji i póki co nie ma
co marzyć o AI_Kappo, dlatego należy ograniczyć zakres TEMIDY do tego co
(przynajmniej w teorii) wydaje się technologicznie osiągalne. Poniżej zobrazowany
całokształt pomysłu:
dane wejsciowe: dokument
architektoniczny (guideli ne)
dane wyjsciowe: szablon wytycznych
dane wejsciowe: szablon wytycznych; wybrane
elementy model u
dane wyjsciowe: instancj e wytycznych
NL PARSER
GENERAT OR INST ANCJI
WYT YCZNYCH
dane wejsciowe: model UML
dane wyjsciowe: wybrane
elementy modelu (l ista?)
PREZENTACJA
dane wejsciowe: instancje
wytycznych
dane wyjsciowe: wyni k anali zy
XMI
PARSER
ANALIZATOR
MODELU
ANALIZATOR
KODU
MODEL UML 1.4
dane wejsciowe: pli k XMI
dane wyjksciowe: model
UML
REFAKT OR
MODELU
WYNIK ANALIZY
REFAKTOR
KODU
dane wejsciowe: wynik anali zy
dane wyjsciowe: nowa instancja
model u UML
dane wejsciowe: wynik
anal izy
dane wyjsciowe: null
KOD
WYSWIETLACZ
BLEDOW
dane wejsciowe: wyni k anali zy
dane wyjsciowe: nowa
instancj a kodu
INNA BARDZIEJ PRZYZIEMNA KONCEPCJA
Zgoda – przesadziłam – analizator semantyczny języka naturalnego też nie jest rzeczą
trywialną. Poniżej to, co w pewnej dalekiej ale dającej się przewidzieć przyszłości można
spróbować zrobić z TEMIDĄ:
dane wejsciowe: bezp. od programisty
/projektanta
dane wyjsciowe: szablon wytycznych
dane wejsciowe: szablon wytycznych; wybrane
elementy modelu
dane wyjsciowe: instancje wytycznych
MODELER
WY TY CZNYCH
GENERATOR INSTANCJI
WYTYCZNYCH
dane wejsciowe: model UML
dane wyjsciowe: wybrane
elementy modelu (lista?)
PREZENTACJA
dane wejsciowe: instancje
wytycznych
dane wyjsciowe: wynik analizy
XMI
PARSER
ANALIZATOR
MODELU
ANALIZATOR
KODU
MODEL UML
dane wejsciowe: plik XMI
dane wyjksciowe: model
UML
REFAKTOR
MODELU
REFAKTOR
KODU
WYNIK ANALIZY
dane wejsciowe: wynik analizy
dane wyjsciowe: nowa instancja
modelu UML
dane wejsciowe: wynik
analizy
dane wyjsciowe: null
KOD
WYSWIETLACZ
BLEDOW
dane wejsciowe: wynik analizy
dane wyjsciowe: nowa
instancja kodu
TO CO ZROBIMY
Ponieważ nie da się wszystkiego zbudować od razu (ale to odkrywcze) to proponuję kilka
iteracji, w których małymi kroczkami przy niewielkiej liczbie strat osobowych w zespole
można spróbować zaimplementować TEMIDĘ:
dane wejsciowe: instancje
wytycznych, kod
dane wyjsciowe: wynik analizy
dane wejsciowe: wynik
analizy
dane wyjsciowe: null
ANALIZATOR
KODU
KOD
WYSWIETLACZ
BLEDOW
WYNIK ANALIZY
ITERACJA „0”: TEMIDA jako add-ins do .NET’a
Analizator kodu dla jednego języka programowania (? C# ?) lub wszystkich języków
programowania dostępnych na platformie .NET (wykorzystanie CLR – pomysł Dominika
Chrzanowskiego). Konkretne (zinstancjonowane) wytyczne architektoniczne podajemy
do TEMIDY ręcznie w stosownym formacie.
dane wejsciowe: bezp. od programisty
/projekta...
dane wejsciowe: szablon wytycznych; wybrane
elementy mod...
MODELER
WYT YCZNYCH
GENERATOR INSTANCJI
WYT YCZNYCH
dane wejsciowe: model UML
dane wyjsci owe: wybrane
elementy model u (l ista?)
PREZENTACJA
dane wejsciowe: instancje
wytycznych, kod
dane wyjsci owe: wyni k analizy
XMI
PARSER
ANALIZATOR
KODU
MODEL UML 1.4
dane wejsciowe: pli k XM I
dane wyjksciowe: m odel
UML
WYNIK ANALIZY
dane wejsciowe: wyni k
analizy
dane wyjsciowe: null
WYSWIET LACZ
BLEDOW
KOD
ITERACJA 1: Szablonowanie wytycznych architektonicznych
Implementujemy modeler wytycznych, moduł parsowania dokumentów XMI i moduł
prezentacji diagramów UML (POWIĄZANIE Z PROJEKTEM CHORS) oraz generator
instancji wytycznych. Warto nadmienić, że swego czasu popełniłam parser XMI dla UML
1.4 (niestety lub stety w C#.NET).
ITERACJA 2: Refaktoryzator kodu
//to do
ITERACJA 3: Refaktoryzator modelu
//to do
ITERACJA 4: Meta-wizja meta-TEMIDY
//przenosimy analizator na meta-poziom umożliwiając zunifikowaną weryfikację kodu
napisanego w dowolnym języku programowania. Budujemy plug-in do Eclipse celem
sprawdzenia proof-of-concept (POWIĄZANIE Z PROJEKTEM META_META).
JAK SIĘ POŁĄCZYĆ Z CHORSEM?
Programista wykorzystując TEMIDĘ potrzebuje na początek wygenerować instancje
wytycznych architektonicznych na podstawie szablonu wytycznych. W tym celu musi w
modelu UML wskazać pewne elementy, które zastąpią zmienną z szablonu. Póki co nie
mamy implementacji modułów dla parsowania i prezentacji modeli UML 2.0. O czym
jednak warto pamiętać – mamy parser XMI dla UML 1.4 z brakującą warstwą prezentacji
i wizualizacji diagramów.
Z kolei CHORS to projekt narzędzia modelowania (ala Rational Rose dla Linux), który
ma pracować na UML 2.0. CHORS nie został jeszcze zaimplementowany ale został
całkiem przyjemnie zamodelowany. Warto zewrzeć więc szeregi i spróbować znaleźć
sposób na wspólną implementację meta-modelu UML 2.0, parsera XMI 2.0 oraz warstwy
prezentacji diagramów UML.
PROBLEM 1: nasz model UML 1.4 i parser XMI są napisane w C#.NET; piszemy add-in
do Visual Studio .NET;
PROBLEM 2: podobno Mono (.NET pod Linux) nie jest jeszcze dopracowany, więc
prawdopodobnie koledzy z CHORS nie będą skłonni pisać w C#(dajcie znać, gdyby się
coś zmieniło);
PROBLEM 3: UML 2.0 prawdopodobnie nie jest ostatnim zdaniem, jakie OMG ma
zamiar wypowiedzieć w zakresie modelowania systemów informatycznych;
PROBLEM 4: z dużym prawdopodobieństwem można powiedzieć, że nie da się
bezboleśnie wykorzystywać otrzymanych z zewnątrz struktur C++’owych (ich
wykorzystanie wymagałoby zaimplementowania w ramach TEMIDY całego metamodelu UML czyli masło maślane);
Dwa rozwiązania ad hoc (autorstwa Krzysia Śmiechowicza):
//Krzysztof, daj znać, gdyby coś było nie tak zamodelowane.
GUI
KOMUNIKACJA
dane wejsciowe:
diagram
eleme...
PREZENTACJA
dane wejsciowe: model UML
dane wyjsciowe: graf
diagramu UML 1.4
MODEL
INT EGRAT OR
MODEL UML 2.0
XMI
PARSER
dane wejsciowe: plik XMI dla UML
2.0
dane wyjksciowe: model UML 2.0
MODEL UML 1.4
XMI
PARSER
dane wejsciowe: plik XMI dla UML
1.4
dane wyjksciowe: model UML 1.4
XMI
WRIT ER
dane wejksciowe: model UML
1.4
dane wyjsciowe: plik XM I dla
UML 1.4
GUI
dane wejsciowe: model UM L
dane wyjsciowe: graf
diagramu UML 2.0
KOMUNIKA
CJA
PREZENT ACJ
A
MODEL UML 2.0
XMI
PARSER
dane wej sciowe: plik XMI
dla UML 2.0
dane wyjksciowe: mod...
dane wej sciowe:
diagram
eleme...
PREZENT ACJ
A
dane wej sciowe: model UM L
dane wyjsciowe: graf
diagramu UML 1.4
MODEL UML
XMI
PARSER
dane wejsciowe: plik XMI
dla UML 1.4
dane wyjksciowe: mod...
XMI
WRIT ER
dane wejksciowe: model
UML 1.4
dane wyjsciowe: plik X...