Rozdział monografii: `Bazy Danych: Rozwój metod i technologii
Transkrypt
Rozdział monografii: `Bazy Danych: Rozwój metod i technologii
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 Rozdział 10 w Zarządzanie wersjami warstwy ORM sterowane atrybutami w da .b w Streszczenie. Warstwa ORM (Object Relational Mapping), dość powszechnie spotykana we współczesnych systemach informacyjnych, jest zależna od wielu czynników, które ulegają zmianom, m.in. od zmiennej struktury danych relacyjnych, typu i wersji DBMS, czy typu i wersji samego narzędzia użytego do zbudowania ORM. Czynniki te ewoluują w sposób w dużej mierze niezależny, ale zmiany każdego z nich mogą wymuszać modyfikowanie warstwy ORM. W pracy przedstawiono propozycję zastosowania wersjowania sterowanego atrybutami, w którym uwzględnia się niezależność wielu czynników wpływających na ewolucję systemu, biorąc pod uwagę także pewne ograniczenia owej niezależności. Opis wersji, skonstruowany z atrybutów, służy następnie do sterowania generacją wersji ORM na podstawie repozytorium zbudowanego z użyciem języka XVCL – opartego na idei programowania generatywnego języka opisu wariantów oprogramowania. 1 Wprowadzenie pl s. Współczesne systemy informacyjne często programowane są w obiektowych językach programowania (np. Java, C++, C#, Delphi), tymczasem dane z reguły składowane są w relacyjnych bazach danych. Jedną w często stosowanych metod połączenia tych dwóch „światów” jest użycie warstwy tzw. odwzorowania obiektowo-relacyjnego – ORM (ObjectRelational Mapping). Do tworzenia takiej warstwy służą specjalne, dość popularne narzędzia (np. Hibernate czy TopLink), a jej istnienie przewidziane jest w wiodących architekturach systemów informacyjnych (np. JPA w JEE). Warstwa ORM stanowi interfejs między różnymi częściami systemu i musi być nich dostosowana; zmiany funkcjonalne i technologiczne, zarówno po stronie bazy danych jak i aplikacji, wpływać mogą na ORM. Zmienność warstwy ORM zależy zatem od wielu niezależnych czynników. Praca opisana tutaj ma pokazać przydatność modelu wersjowania sterowanego atrybutami [2], w połączeniu z technikami programowania generatywnego i językiem XVCL [5], do zarządzania zmiennością warstwy ORM. Zarządzanie wersjami powinno, zgodnie z [9], umożliwiać tworzenie pierwszej i kolejnych wersji, identyfikację, wybór i ekstrakcję werAndrzej Grudzień, Tomasz Traczyk Politechnika Warszawska, Instytut Automatyki i Informatyki Stosowanej, ul. Nowowiejska 15/19, 00665 Warszawa, Polska email: [email protected], [email protected] (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 A. Grudzień, T. Traczyk w sji. W tej pracy skupiono się na sposobie zapisu wersji oraz wyborze właściwej wersji i jej ekstrakcji. Praca ta jest częścią większego zamierzenia [10]: zbadania możliwości użycia programowania generatywnego i języka XVCL jako środka do zarządzania zmianami całości projektów – wszystkich ich części i warstw, poczynając od modeli konceptualnych, a na dokumentacji gotowego systemu kończąc – w systemach informacyjnych mających wiele równoczesnych wariantów i zbudowanych z użyciem współczesnych technologii wykorzystujących bazy danych oraz nowoczesne środowiska budowania aplikacji. 1.2 Podstawowe założenia 1.3 Podobne prace da .b w w System informacyjny, którego częścią jest ORM, podlega ciągłej zmienności, wymuszanej zmianami wymagań funkcjonalnych i pozafunkcjonalnych, pojawianiem się nowych wersji oprogramowania itp. Zmienność nie polega jednak tylko na ukazywaniu się kolejnych wydań; istnieć mogą także równoległe warianty, np. związane z wykorzystaniem różnych systemów zarządzania bazami danych czy narzędzi ORM, a także przeznaczeniem dla różnych klientów, których wymagania mogą się nieznacznie różnić. Założono, że cały opis systemu, w tym warstwy ORM, będzie zawarty w XML-owym repozytorium [10], w którym wersje artefaktów będą opisane za pomocą języka XVCL [14]. Struktury danych, kod aplikacji, modele analityczne oraz dokumentacja systemu są traktowane jako równorzędne artefakty, których zmienność powinna być zarządzana w ten sam sposób. Zastosowany sposób zapisu oraz zarządzania wersjami muszą być więc dość ogólne, a nie wyspecjalizowane pod kątem specyficznej części projektu czy rodzaju kodu. Założono także, że struktura repozytorium musi być na tyle klarowna, by było możliwe zarządzanie nim bez użycia specjalnych narzędzi („ręczne”) oraz by na podstawie przeglądu plików repozytorium można było łatwo odczytać, jak przebiegała ewolucja systemu. pl s. Koncepcję zastosowania modelu wersjowania opartego na atrybutach do zarządzania komponentami będącymi podstawą systemów biznesowych można znaleźć w [2], [3]. Prace te przestawiają ogólne podejście, w którym komponenty są opisywane poprzez zbiory interfejsów dostarczanych i wymaganych. Model wersjowania użyty w tej pracy został wybrany jako baza dla prezentowanego w tym opracowaniu. Jeszcze szerszy przykład zastosowania modelu wersjowania opartego na atrybutach można znaleźć w języku PCL (Proteus Configuration Language) [11]. Tam jest on składową metody opisu elementów systemu, rozpoczynając na elementach sprzętowych, a na dokumentacji kończąc. Samo wykorzystanie modelu opartego na atrybutach jest nieco prostsze, gdyż dopuszczalne wartości atrybutów są definiowane jako zbiory a nie taksonomie. Niniejsza praca różni się od wymienionych w dwóch istotnych kwestiach. Po pierwsze, zajmuje się zagadnieniem o znacznie mniejszym zakresie, co pozwala na wprowadzenie ograniczeń w modelu wersjowania, zmniejszając jego złożoność. Po drugie i ważniejsze, przytoczone prace zajmują się ewolucją obiektów jako kompletnych artefaktów, natomiast proponowane tu podejście, dzięki wykorzystaniu techniki generatywnej, pozwala odnotowywać zmiany składowych i cech obiektów, zapisanych w nieredundantny sposób. 128 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 Sterowane atrybutami zarządzanie wersjami warstwy ORM 2 Wersjowanie sterowane atrybutami w Wersjowanie sterowane atrybutami [2], jest spotykane dość często. Przykład jego zastosowania znajdziemy chociażby w narzędziu CVS [1], gdzie stosowane jest – w postaci znaczników (tags) – do zarządzania konfiguracjami obiektów. W tym modelu wersjowania każda wersja obiektów jest opisana za pomocą zbioru par (atrybut, wartość). Atrybuty mogą reprezentować cechę wersji obiektu (np. język narodowy) lub relację z innym obiektem należącym do systemu lub zewnętrznym (np. system operacyjny). W ramach tego modelu można wyróżnić dwa podejścia. Pierwsze z nich, stosujące atrybuty o charakterze opisowym (np. opis zmiany czy nazwisko wprowadzającego ją), nie wymaga szczególnego komentarza. Przykład wykorzystania można znaleźć w [7]. Drugie podejście, stosujące atrybuty taksonomiczne, stanowi postawę opisanego tu rozwiązania. Atrybuty taksonomiczne posiadają taksonomie określające dopuszczalne wartości oraz opisujące relacje między nimi. Istnieją różne sposoby wyrażenia taksonomii (np. kostka, drzewo, czy proponowany w [2] zbiór częściowo uporządkowany). Oprócz taksonomii podstawowej, która obejmuje wszystkie dopuszczalne wartości jednego atrybutu, atrybuty mogą posiadać taksonomie pomocnicze, które nie zawierają wszystkich wartości atrybutu, ale mogą obejmować wartości innych atrybutów. Umożliwia to zapis wiedzy o dodatkowych relacjach, a także narzucenie ograniczeń. Na rys. 1 przedstawiono przykład dwóch atrybutów taksonomicznych, które mogą być użyte do opisu obiektów warstwy ORM. Ich zbiory wartości dopuszczalnych są wyznaczone poprzez taksonomie główne (1 i 2), zaś taksonomia pomocnicza (3) modeluje ograniczenie „jeżeli wariant jest przeznaczony dla klienta akceptującego tylko Oracle, to może mieć tylko cechy przewidziane dla narzędzi dobrze współpracujących z Oracle”. da .b w w pl s. Rys. 1. Przykładowe atrybuty i taksonomie 2.1 Wybór modelu wersjowania do zarządzania ewolucją ORM Szukając właściwego modelu wersjowania dla problemu ORM, oprócz modelu opartego na atrybutach rozważano zarówno tradycyjne modele sekwencyjny i równoległy, jak i modele zaawansowane, takie jak model zorientowany na zmiany [8], czy model oparty na środowisku zmian [12]. 129 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 A. Grudzień, T. Traczyk w Model sekwencyjny staje się niepraktyczny już w przypadku, gdy konieczne jest jednoczesne utrzymywanie wersji już dostarczonej klientowi oraz rozwijanie kolejnego wydania. Także w przypadku, gdy produkt jest dostarczany w więcej niż jednym wariancie równocześnie, ten model zawodzi. Model równoległy, popularny w powszechnie przyjętych rozwiązaniach (CVS, Subversion), także nie jest wystarczający. Ze względu na działanie warstwy ORM na styku dwóch elementów systemu: schematu zrealizowanego w relacyjnej bazie danych i obiektowego programu, w zarządzaniu ewolucją trzeba uwzględnić wiele czynników, podczas gdy model równoległy umożliwia modelowanie tylko jednej relacji (zwykle „pochodzi od”). Dobrym przykładem jest tu chociażby przypadek, gdy system jest utrzymywany jednocześnie dla różnych systemów zarządzania bazami danych i dwóch klientów o nieco odmiennych wymaganiach co do struktur danych. W modelu równoległym należałoby utworzyć oddzielną równoległą ścieżkę dla każdej z 4 kombinacji oraz wybrać arbitralnie jedną z nich jako „pień”. Ewentualna zmiana, np. związana z wykorzystaniem możliwości nowej wersji jednej z baz, musi być wprowadzona w dwóch miejscach. Gdy uwzględnimy dodatkowe czynniki, takie jak różne narzędzia ORM, problem staje się dotkliwy. Co gorsza, dla niektórych zmian może okazać się niemożliwe ustalenie po fakcie, który z czynników spowodował powstanie nowej wersji. W modelu opartym na atrybutach każdy czynnik może być modelowany osobno jako atrybut lub kombinacja kilku atrybutów. Jednocześnie opis pojedynczej wersji czy wariantu w postaci zbioru par atrybut-wartość jest zrozumiały i wygodny dla użytkownika. Model bazujący na atrybutach umożliwia także wygodne wyszukiwanie wersji właściwej w danej sytuacji przez odpowiednie wykorzystanie taksonomii przypisanych atrybutom, z jednoczesnym zachowaniem zdefiniowanych ograniczeń. Bardziej zaawansowane modele cechują się większą złożonością i trudnością opanowania, co jest sprzeczne z jednym z podstawowych założeń przedsięwzięcia, to jest by istniała możliwość zrozumienia wszystkich zapisów w repozytorium i – w razie potrzeby – wprowadzania modyfikacji bez użycia specjalnych narzędzi. Główne przyczyny wyboru modelu opartego na atrybutach to zatem: łatwość modelowania różnych czynników mogących wymuszać zmiany systemu, duża ilość informacji semantycznej, możliwa do zapisania w wartościach atrybutów, rozwinięte możliwości wyszukania właściwej wersji oraz możliwy do opanowania poziom komplikacji. da .b w w pl s. 2.2 Dostosowanie modelu wersjowania do zarządzania wersjami ORM Dla określenia powiązań między wartościami atrybutu wybrano zbiory częściowo uporządkowane, co wynikło z obserwacji, że w przypadku ORM niektóre atrybuty będą odpowiadać wersjowaniu równoległemu użytych produktów, na przykład narzędzia ORM. Prostszy model drzewa nie zapewnia odwzorowania dla częstej operacji łączenia (merge), którą można znaleźć na przykład w przypadku gdy wydawana jest nowa wersja narzędzia ORM zawierająca cechy dwóch poprzednich wersji, a użytkownik posiada już wcześniej opracowane warianty współpracujące z owymi wersjami. Podstawę opisywanego sposobu zarządzania wersjami stanowią atrybuty taksonomiczne. Każdy z nich posiada jedną taksonomię główną, oraz może posiadać pewną liczbę taksonomii pomocniczych, przy czym taksonomie pomocnicze stanowią tylko ograniczenia, to jest nie biorą udziału w wyszukiwaniu wersji, a jedynie ograniczają zbiór wynikowy. Taksonomia pomocnicza może zawierać wartości wielu różnych atrybutów, przez co można wyrażać zależności między nimi, np. relację współpracy wariantu jednego obiektu z określonym 130 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 Sterowane atrybutami zarządzanie wersjami warstwy ORM w zbiorem wariantów innego. Decyzja o ograniczeniu roli taksonomii pomocniczych tylko do definiowania ograniczeń jest podyktowana chęcią utrzymania względnej prostoty modelu i zapewnienia łatwego do interpretacji sposobu definiowania ograniczeń. Użycie atrybutów o charakterze opisowym jest także dopuszczalne, przy czym w wyszukiwaniu wersji może występować albo odwołanie do konkretnej wartości, albo deklaracja, że dany atrybut nie jest istotny. Nie jest dopuszczalne umieszczanie odwołań do wartości takich atrybutów w taksonomiach pomocniczych atrybutów taksonomicznych. Założenie to ma na celu utrzymanie wyłącznie opisowego charakteru tej grupy atrybutów. Atrybuty podzielono na trzy kategorie: systemowe, wbudowane oraz użytkownika. Atrybuty systemowe i wbudowane muszą być użyte dla każdego projektu. Różnica polega na sposobie ustalania wartości tych atrybutów. Dla atrybutów wbudowanych decyzję o wartościach i powiązaniach między nimi podejmuje użytkownik, natomiast dla systemowych istnieją określone ścisłe reguły, zarówno dla wartości, jak i powiązań między nimi. Atrybuty użytkownika mogą są tworzone osobno dla poszczególnych projektów i użytkownik nie jest ograniczony w ich tworzeniu. Proponowane atrybuty systemowe to: − czas dodania – atrybut taksonomiczny, w którym wartościami są stemple czasowe utworzenia wersji/wariantu obiektu, a taksonomia ma postać szeregowej listy uporządkowanej według rosnącej wartości; − identyfikator wprowadzającego zmianę – atrybut którego wartościami są identyfikatory użytkowników systemu, a taksonomia grupuje je według ról; − typ i wersja DBMS. da .b w w 3 Realizacja zarządzania wersjami ORM pl s. Warto zauważyć, że dwa pierwsze atrybuty systemowe nie mają ścisłego związku z problematyką ORM, a raczej stanowią odpowiednik rozwiązań typowo spotykanych w narzędziach do zarządzania wersjami. Kolejny służy natomiast do integracji z częścią repozytorium opisującą schemat bazy danych1. Atrybutem wbudowanym jest typ i wersja narzędzia ORM. Przykłady atrybutów użytkownika to zaś np. docelowe środowisko wdrożenia wariantu/wersji. Podział na kategorie ma znaczenie przy ustalaniu taksonomii pomocniczych dla atrybutów. Po pierwsze tworzenie tych taksonomii przez użytkownika jest dozwolone tylko dla atrybutów wbudowanych i użytkownika. Po drugie, dla zachowania prostej struktury zależności, zabronione jest korzystanie z wartości atrybutów użytkownika w taksonomiach pomocniczych atrybutów wbudowanych. Jako że atrybuty systemowe mają swoje odrębne reguły, nie ma potrzeby podawania dla nich dodatkowych ograniczeń. Aby zrealizować zarządzanie ewolucją ORM, oprócz modelu wersjowania określić trzeba także sposób zapisu informacji o odwzorowaniu między strukturami relacyjnymi a obiektowymi, mechanizm wyszukiwania wersji oraz sposób tworzenia artefaktów dla narzędzia ORM. Implementację przedstawionego pomysłu oparto na języku XVCL, wspieranym przez pomocnicze zastosowanie języka XQuery. 1 Wersję schematu bazy danych określają zarówno atrybuty systemowe (np. typ i wersja DBMS), jak i użytkownika (związane np. z wersją wymagań, użytkownikiem itp.). 131 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 A. Grudzień, T. Traczyk w XVCL [14] to język i metodologia programowania generatywnego [5]. Podstawowym elementem tego języka są tzw. x-ramki zapisane w XML. Na x-ramkach wykonuje się operację adaptacji, która powoduje wygenerowanie wynikowego dokumentu, np. programu. Xramki tworzą hierarchię, w której ramki wyższego poziomu wywołują (adaptują) ramki niższego poziomu, sterując adaptacją m.in. za pomocą przekazywanych zmiennych. Ramka specyfikacyjna jest to ramka najwyższego poziomu, od której rozpoczyna się przetwarzanie. Stosowany w ramkach znacznik <select> umożliwia wybór fragmentów ramki przeznaczonych do przetwarzania na podstawie wartości zmiennej określonej przez atrybut option. Przetwarzane są wszystkie elementy <option>, których atrybut value ma wartość równą wartości podanej zmiennej. Deklaracja zmiennej, z jednoczesnym nadaniem wartości, wykonywana jest przy użyciu znacznika <set>. Zmienna jest widoczna w ramce, w której została zadeklarowana, oraz w ramkach przez nią adaptowanych. XQuery [13] jest deklaratywnym językiem zapytań, przeznaczonym do operowania na dokumentach XML. W projekcie język ten jest wykorzystywany do nawigacji po taksonomiach i stworzenia x-ramki specyfikacyjnej na podstawie konfiguracji. Użycie XVCL do tego celu jest znacząco utrudnione, gdyż XVCL jest skonstruowany z myślą o generacji nowych obiektów, a nie o przeglądaniu i modyfikowaniu istniejących, w szczególności brak w nim możliwości łatwego przetwarzania grafów. w w da .b 3.1 Zapis wersji encji i związków Podlegającymi wersjowaniu obiektami opisującymi strukturę danych są encje, odpowiadających klasom w odwzorowaniu, oraz związki. Każdy z obiektów jest zapisany w odrębnej x-ramce. Szkielet każdej x-ramki opisu stanowią znaczniki <select>, jak poniżej: pl s. <select option="selectingVariable"> <option value="?@Operating-system=OS;DB-type=Oracle?"> <set var="?@objectId?:Present" value="true"/> <!-- zmienne opisujące cechy --> </option> <option value="?@Operating-system=WinXP;DB-type=Postgres?"> <set var="?@objectId?:Present" value="false"/> <!-- zmienne opisujące cechy --> </option> <!-- inne elementy option, z innymi zmiennymi w atrybucie value --> </select> Wartość zmiennej selectingVariable w trakcie interpretacji jest zawsze ustawiana na true. Dla zmiennych sterujących, występujących w atrybutach value elementów <option>, jest określony schemat tworzenia nazw, które stanowią serializację zbioru par atrybut-wartość opisujących wersje i warianty: każda wartość poprzedzana jest nazwą jej atrybutu i znakiem równości, wartości poszczególnych atrybutów są oddzielone średnikami, a kolejność występowania jest alfabetyczna. Wartości tych zmiennych są definiowane w ramce specyfikacyjnej. W zależności od tego, czy zostanie im nadana wartość true, czy inna, po przetworzeniu tej klauzuli zmienne opisujące obiekt będą miały wartość taką jak w pierwszym lub w drugim elemencie <option> (gdy więcej niż jedna z ze zmiennych sterujących będzie miała wartość true, wartości zmiennych będą wyznaczone przez ostatni „pasujący” element <option>). Nie prowadzi to do komplikacji jeśli przestrzega się zasady, według której przy dodawaniu nowej wersji odpowiadający jej element <option> dopisuje się po już istniejących oraz stosuje się zasady modyfikacji taksonomii opisane dalej. Opis encji składa się z jednego elementu <select>, opisującego cechy encji jako całości, takie jak nazwa czy główna tabela odpowiadająca jej w bazie, oraz po jednym elemencie 132 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 Sterowane atrybutami zarządzanie wersjami warstwy ORM w <select> na każdy atrybut (odpowiadający kolumnie tabeli relacyjnej). Jeżeli kolumna w tabeli relacyjnej jest kluczem obcym, to nie jest reprezentowana w obiekcie encji, gdyż jej istnienie wynika z opisu związku. Opis związku składa się zawsze z trzech elementów <select>. Pierwszy, tak jak w przypadku encji, zawiera ogólne cechy (nazwa, typ), a dwa pozostałe – wskazanie encji stanowiących końce związku oraz dodatkowe cechy, takie jak nawigowalność. Cechy obiektów i ich składowych zostały wybrane w taki sposób, by zapewnić kompatybilność z Java Persistence API, jako najnowszym standardem w dziedzinie ORM dla języka Java. w 3.2 Zapis konfiguracji da .b w Konfiguracja systemu zapisywana jest jako x-ramka, w której użytkownik musi zdefiniować następujące trzy elementy: zbiór par atrybut-wartość wybierający wersje obiektów z repozytorium, nazwę generatora (opisanego dalej) oraz nazwę zbioru strojącego [4], zawierającego techniczne parametry ORM. Dwa ostanie elementy są związane z zastosowaniem metodyki generatywnej i nie mają znaczenia z punktu widzenia problemu wersjowania, natomiast według wymienionego jako pierwszy zbioru wartości atrybutów wyznaczane są zmienne sterujące. Istotne jest założenie, że niezależnie od rozbudowy taksonomii atrybutów, raz określona konfiguracja musi zawsze powodować wygenerowanie tych samych artefaktów. Wspomniany wyżej generator [4] jest to zbiór x-ramek opisujących meta-ORM, tj. zawierających definicje generycznych metakomponentów, które zostają dopasowane do konkretnej sytuacji w procesie adaptacji x-ramek, sterowanym przez konfigurację. Generator ten jest używany przetworzenia zbioru zmiennych, powstającego w rezultacie opisanej wyżej interpretacji ramek obiektów, na finalny kod warstwy ORM. 3.3 Zapis taksonomii Taksonomie atrybutów zapisywane są w plikach XML o strukturze przedstawionej poniżej: pl s. <taxonomies> <!-- taksonomia główna --> <taxonomy for-attribute="nazwa_atrybutu" name="nazwa_taksonomii"> <element name="wartosc_atrybutu"> <belongs-to distance="0" name="wartosc_atrybutu"/> <belongs-to distance="1" name="inna_wartosc_atrybutu"/> </element> <!-- pozostałe wartości atrybutu --> </taxonomy> <!-- taksonomia pomocnicza --> <taxonomy name="nazwa_taksonomii"> <element name="wartosc_atrybutu" for-attribute="nazwa_atrybutu"> <belongs-to distance="0" name="wartosc_atrybutu" for-attribute="nazwa_atrybutu"/> <belongs-to distance="1" name="inna_wartosc_atrybutu" for-attribute="inna_nazwa_atrybutu"/> </element> <!-- pozostałe wartości atrybutu --> </taxonomy> </taxonomies> Jak widać, dla każdej wartości atrybutu podawane są wszystkie wartości będące dla niej przodkiem w grafie taksonomii. 133 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 A. Grudzień, T. Traczyk Konstrukcja tego zapisu ma przede wszystkim na celu wygodne i efektywne przetwarzanie z pomocą XQuery, stąd między innymi wymienianie wszystkich przodków elementu, upraszczające znacząco proces wyznaczania wartości zmiennych sterujących. Nowe wartości atrybutu do taksonomii można dodawać tylko jako liście grafu. Gdyby dopuścić możliwość wstawiania nowych wartości pomiędzy istniejące, to byłaby możliwa sytuacja, w której to samo wyszukiwanie wersji, wykonane przed i po modyfikacji taksonomii dałoby różne wyniki. w 3.4 Wyznaczanie elementów konfiguracji da .b w w W celu wyszukania należących do konfiguracji wersji elementów wykonuje się zapytanie, podające uporządkowany zbiór par atrybut-wartość. Odpowiedni skrypt w języku XQuery wyznacza wartości zmiennych sterujących występujących w x-ramkach, zgodnie z następującymi regułami. 1) Tworzony jest zbiór wszystkich nazw zmiennych sterujących występujących w ramkach repozytorium. 2) Każda z tych nazw jest rozbijana na uporządkowany zbiór par atrybut-wartość. 3) Dla każdego zbioru sprawdzane jest, czy spełnia on warunki zapytania, tj. a) dla każdego atrybutu opisowego zachodzi równość wartości lub w zapytaniu dla danego atrybutu użyto wartości uniwersalnej; b) wartości atrybutów taksonomicznych są równe tym z zapytania lub też są ich przodkami (nie jest to równoważne wcześniejszej wersji, ale daje bardziej racjonalne wyniki w przypadku, gdy wersja dziedziczy cechy po wersjach mających wspólnego przodka). 4) Dla każdego zbioru, który przeszedł poprzednie kroki, sprawdzane jest dla każdego atrybutu taksonomicznego, czy jego wartość występuje w jednej z taksonomii pomocniczych. Jeżeli tak, to dla każdego z każdego z pozostałych atrybutów taksonomicznych sprawdzane jest czy jego wartość jest w relacji wyznaczonej przez taksonomię pomocniczą. Jeżeli dla dowolnego atrybutu wynik będzie negatywny, to sprawdzany zbiór wartości atrybutów jest odrzucany, czyli odpowiadająca mu zmienna sterująca będzie miała wartość false. 3.5 Dalsze przetwarzanie pl s. Rezultat jest formowany w x-ramkę specyfikacyjną, która przyjmuje postać szeregu elementów set, nadających wyznaczone wartości zmiennym sterującym, oraz pojedynczego elementu powodującego adaptację ramki zbiorczej repozytorium (zawierającej odwołania do pozostałych ramek). Rezultatem opisanej powyżej procedury jest stworzenie reprezentacji obiektów warstwy ORM w przestrzeni zmiennych XVCL. Aby utworzyć artefakty dla konkretnego narzędzia, należy zaadaptować ramkę główną odpowiedniego generatora (patrz wyżej). Dla potrzeb przeglądu wersji i wariantów zawartych w repozytorium, a spełniających warunki zapytania, dostarczony może być specjalny generator, tworzący raport o wybranych obiektach. 134 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 Sterowane atrybutami zarządzanie wersjami warstwy ORM 3.6 Pozostałe funkcje zarządzania wersjami w Utworzenie pierwszej wersji systemu jest wspomagane przez narzędzie oparte na XQuery, tworzące ramki obiektów na podstawie schematu bazy danych zapisanego we wspomnianym wcześniej, specjalizowanym dialekcie. Identyfikacja kolejnych wersji i równoległych wariantów bazuje na zmiennych sterujących – każda unikalna wartość wyznacza jedną wersję lub wariant. Klasyfikacja na wersje i warianty jest możliwa na podstawie atrybutów – przykładowo zmienne różniące się jedynie wartością atrybutu czasu wstawienia wyznaczają kolejne wersje, a np. różniące się wartością atrybutu „środowisko wdrożenia” stanowią równoległe warianty. Tworzenie wersji warstwy ORM polega na ustaleniu wartości atrybutów, jakie mają opisywać nową wersję, a następnie ręcznym wprowadzenie do zmiennych modelu zgrupowanych w podelementach <option> różnic opisanych przez wartość zmiennej sterującej, wyznaczoną przez nowe wartości atrybutów. Wybór wersji przechowywanych obiektów możliwy jest tylko w ramach ekstrakcji konfiguracji, którą to procedurę opisano wcześniej. Nie przewiduje się operacji na pojedynczych obiektach, ponieważ obiekty warstwy ORM przedstawiają wartość tylko jako całość, a próby „ręcznego” składania warstwy z arbitralnie wybranych wersji doprowadzą do problemów ze wzajemną zgodnością elementów oraz zgodnością ze schematem bazy danych. da .b w w 4 Podsumowanie pl s. Podstawową korzyścią, jaka ma być osiągnięta poprzez zastosowanie proponowanego rozwiązania, jest możliwość śledzenia zmian obiektów i ich składowych nie jako zmian w tekstowym zapisie pewnego artefaktu, ale jako zmian konkretnych, nazwanych cech, których przyczyny są łatwo odczytywane z wartości atrybutów użytych do opisu. Dodatkową zaletą, która musi zaistnieć by było możliwe powyższe, jest opisywanie obiektów odwzorowania w klarowny i ustrukturalizowany sposób. Pozytywną cechą, otrzymywaną niejako przy okazji realizacji powyższych celów, jest redukcja rozmiaru zarządzanego kodu, w sytuacji gdy system utrzymywany jest w wielu wariantach. Prace nad zarządzaniem wersjami ORM są dość zaawansowane, ale oczywiście nie wszystkie problemy rozwiązano. Dalsze prace powinny obejmować m.in.: − rozwinięcie modelu opisu odwzorowań, tak by można w nim wyrazić wszystkie użyteczne koncepcje ORM (pola wyliczane, funkcje składowane), nie zaś tylko encje z atrybutami i związki między encjami; − sposób prezentowania użytkownikowi opisu wersji spełniających podane kryteria, przed przekazaniem ich do generatora; − możliwości kilkustopniowej eksploracji repozytorium (poziom obiektów – poziom wersji/wariantów obiektu równolegle z definicjami składników obiektu – poziom cech składników); − lepszą integrację wersjowania ORM z zarządzaniem wersjami schematu bazy danych (por. [6]). Opracowana metoda zarządzania wersjami wydaje się dawać duże możliwości, w szczególności pozwala definiować i generować zarówno kolejne wydania jak i równoległe warianty ORM. Analiza zawartości repozytorium pozwala w każdej chwili prześledzić ewolucję projektu, możliwe jest też zawsze wygenerowanie każdej wersji. 135 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008 Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008 A. Grudzień, T. Traczyk w Sugerowany sposób zapisu jest klarowny, choć trochę przytłaczający (ilościowo) przy dłuższej historii zmian; stąd potrzeba prac nad łatwiejszą eksploracją repozytorium. Możliwości modelu wersjowania opartego na atrybutach są bardzo duże. W zastosowaniu do warstwy ORM można pozwolić sobie na wprowadzanie – dla uproszczenia – dość silnych ograniczeń funkcji taksonomii pomocniczych, a model pozostaje użyteczny i dostatecznie „pojemny”. Pokazane tu rozwiązanie jest samo w sobie ciekawe, ale działając w separacji byłoby mało użyteczne. Właściwy poziom użyteczności osiągnięty może być dopiero we współpracy z kompatybilnymi rozwiązaniami do zarządzania ewolucją schematu bazy danych i obiektów warstwy wyższej (biznesowej). w Literatura 1. 3. 4. 6. 7. 8. 9. 10. 12. 13. 14. pl s. 11. da .b 5. w 2. CVS – concurrent versions system v1.11.21. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs.html Gergic J.: Towards a versioning model for component-based software assembly. In Proceedings: ICSM 2003, Amsterdam, The Netherlands, 22-26 September 2003. Gergic J.: A Versioning Model for SOFA/DCUP Architecture. Praca magisterska, 1999. Grudzień A., Traczyk T., Jarzabek S.: Application of Generative Programming to Evolution of Object-Relational Mapping Layer. Proceedings of the 2nd AIS SISGSAND Symposium on Systems Analysis And Design, ss. 64-71. Gdańsk, czerwiec 2007. Jarzabek S., Basset P., Zhang H. and Zhang W.: XVCL: XML-based Variant Configuration Language. Proc. Int. Conf. on Software Engineering, ICSE’03, pp. 810-811, Portland, May 2003. Kowalski J., Traczyk T.: Zastosowanie języka XVCL do zarządzania ewolucją schematu relacyjnej bazy danych. Bazy danych. Nowe technologie, t. 1, ss. 35-44. WKiŁ, Warszawa 2007. Morzy T., Eder J., Koncilia C.: The COMET metamodel for temporal data warehouses. In 14th Int. Conf. on Advanced Information Systems Engineering (CAISE’02), Toronto, Canada, 2002. Munch B. P.: Versioning in a Software Engineering Database - the Change Oriented Way. PhD thesis, The Norwegian Institute of Technology, 1995. Tichy W.F.: RCS – A System for Version Control. Software – Practice & Experience 17, 7, July 1985, pp. 637-654. Traczyk T.: Zarządzanie ewolucją systemu informacyjnego za pomocą programowania generatywnego i języka XVCL. TPD 2005 I Krajowa Konferencja Naukowa Technologie Przetwarzania Danych, ss. 378-389. Poznań, wrzesień 2007. Tryggeseth E., Conradi R., Gulla B.: Software Configuration Management in PROTEUS Proceedings of the 4th International Workshop on Software Configuration Management, 1993. Wilkes W. Klahold P. Schlageter G.: A general model for version management in databases. In: Wesley W. Chu, Georges Gardarin, Setsuo Ohsuga,and Yahiko Kambayashi, editors, VLDB’86 Twelfth International Conference on Very Large Data Bases, August 25-28, 1986, Kyoto, Japan, Proceedings, pages 319–327. Morgan Kaufmann, 1986. W3C XML Query (XQuery). http://www.w3.org/XML/Query/ XVCL Web Site. http://xvcl.comp.nus.edu.sg/ 136 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008