pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Nowe Technologie', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2007
Rozdział 3
w
Zastosowanie języka XVCL do zarządzania ewolucją
schematu relacyjnej bazy danych
w
da
.b
w
Streszczenie. Opisana tu praca stanowi część projektu zbadania przydatności
języka XVCL – bazującego na XML języka zapisu wariantów – do zarządzania ewolucją systemów informacyjnych z bazami danych. Zaproponowano
metodę użycia XVCL do zapisu ewolucji schematów relacyjnych baz danych, przedstawionych w postaci skryptów SQL DDL. Ponieważ jedną
z form ewolucji może być tworzenie wariantów przeznaczonych na różne
platformy DBMS, wprowadzono niezależny od platformy i jej dialektu SQL
zapis struktur baz danych, w postaci specjalnie zaprojektowanego dialektu
XML. Stworzono także prototypowe narzędzia wspomagające proces zarządzania ewolucją schematów.
1 Wprowadzenie
pl
s.
Współczesne systemy informacyjne z bazami danych zwykle użytkowane są przez wiele
lat, w warunkach stałej silnej zmienności wymagań i otoczenia. W czasie życia systemu
ewoluują procesy biznesowe wspierane przez system, zmieniają się zwyczaje i przepisy;
zmienia się także „zaplecze” informatyczne: sprzęt i oprogramowanie, standardy i upodobania. System, by zachować przydatność, musi zmieniać się wraz z otoczeniem, konieczna
jest więc jego stała ewolucja. Niejednokrotnie system musi też jednocześnie istnieć w kilku
wariantach, np. przeznaczonych na wiele platform sprzętowo-programowych lub dla wielu
użytkowników, różniących się nieco wymaganiami.
Aby system mógł być dostosowywany do zmian wymagań i otoczenia, bez nadmiernego
ryzyka i przy rozsądnych kosztach, niezbędne jest zapanowanie nad jego zmiennością; potrzebne są więc narzędzia i metody pozwalające opanować proces ewolucji systemu.
Niniejszy rozdział opisuje część większego zamierzenia, którego celem jest zbadanie
przydatności języka XVCL do opisu procesu ewolucji systemu informacyjnego z bazą danych i do zarządzania tą ewolucją. Zamierzenie to zawiera kilka wątków:
− próby zastosowania XVCL do zarządzania ewolucją modeli wyrażonych w UML,
wstępne koncepcje opublikowano w [2];
− zastosowanie XVCL do zarządzania ewolucją schematów relacyjnych baz danych
[6], co stanowi temat niniejszego opracowania;
Jan Maria Kowalski, Tomasz Traczyk
Politechnika Warszawska, Instytut Automatyki i Informatyki Stosowanej, ul. Nowowiejska 15/19,
00-665 Warszawa, Polska
email: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2007
J. M. Kowalski, T. Traczyk
− użycie XVCL do koordynacji ewolucji schematu danych i warstw oprogramowania
budowanego zgodnie z wzorcem MVC (Model-View-Controller); rozpoczęte prace
dotyczą ewolucji warstwy Model, w szczególności tzw. odwzorowania relacyjno-obiektowego.
1.1 Zapis ewolucji schematów baz danych
w
da
.b
w
w
Wraz ze zmianami systemu informacyjnego musi ewoluować struktura jego danych, w systemach z bazami danych następuje więc ewolucja schematów danych. By zapanować nad tą
zmiennością, potrzebne są metody formalnego zapisu ewolucji schematów danych: ich kolejno tworzone wydania i równolegle współistniejące warianty. Taki zapis powinien umożliwiać:
− śledzenie ewolucji schematu, związanej np. z ewolucją wymagań;
− zapis równolegle istniejących wariantów schematu, uzależnionych np. od typu i wersji systemu zarządzania bazą danych;
− ponowne wykorzystanie w przyszłych wersjach wcześniej zaimplementowanych
właściwości systemu;
− możliwość tworzenia nowej wersji na podstawie więcej niż jednej z wersji poprzednio istniejących.
− dokumentowanie (opis przyczyn i charakteru) wprowadzanych zmian.
Ponadto istotna jest możliwość współpracy z różnymi narzędziami zarządzania wersjami/zmianami oraz koordynacji zmian w różnych warstwach systemu (np. zmiany w modelu
danych mogą spowodować konieczność zmian w warstwie odwzorowania relacyjno-obiektowego, logiki biznesowej czy interfejsu użytkownika).
By zapis taki ułatwiał zarządzanie zmiennością systemu, powinien m.in. pozwalać ustalić kto, kiedy i dlaczego dokonywał zmian w systemie. Na podstawie zapisu zmian powinno być możliwe wypracowanie zarówno bezpiecznego przejścia do następnej wersji, jak
i przywrócenia poprzedniej wersji systemu, z zachowaniem integralności danych (por. [4]).
Przyjęty model wersjowania musi być stosunkowo bogaty, w praktyce bowiem kolejne
wydania (wersje wynikające z rozwoju systemu w czasie) oraz równolegle istniejące warianty systemu tworzą graf, w którym może dochodzić zarówno do „rozejścia się” gałęzi,
jak i do ponownego ich łączenia – jak na rys. 1.
pl
s.
Rys. 1. Ewolucja systemu: wydania (revisions) i warianty (variants)
Jako podstawę opisu ewolucji schematu przyjęto zapis poszczególnych jego wersji
w postaci kodu SQL DDL (Data Definition Language). Skrypty SQL DDL są bowiem powszechnie używane do tworzenia schematów; a jeśli nawet skrypty tworzące daną wersję
36
Zastosowanie języka XVCL do zarządzania ewolucją schematu relacyjnej bazy danych
nie są dostępne, to kod jest stosunkowo łatwy do uzyskania wprost z DBMS (np. za pomocą pakietu DBMS_METADATA w Oracle) lub przy użyciu popularnych narzędzi (np. TOAD).
1.2 Język XVCL
w
W większości istniejących systemów SCM (Software Configuration Management) zarządzanie wersjami polega na odpowiednim przechowywaniu i udostępnianiu kolejnych wersji
całych komponentów systemu (np. plików źródłowych oprogramowania, skryptów DDL
itp.). Przy takim sposobie zapisu zmian nie można niestety uniknąć niektórych ważnych
problemów, szczególnie szybko rosnącej liczby bardzo podobnych do siebie wersji komponentów [8].
Zamiast przechowywać kolejne wersje komponentów można przechowywać informację
o tym, jak poszczególne wersje uzyskać na podstawie komponentów generycznych i opisujących zmienność metakomponentów. To podejście do problemu wersjowania znane jest jako wzorzec zestaw zmian (change set) [3]. Utworzenie nowej wersji systemu polega tu na
specyfikacji generycznych komponentów wchodzących w jego skład oraz zestawu zmian,
które mają zostać wprowadzone w nowej wersji. Do takiego zarządzania wersjami może
służyć język XVCL.
Język XVCL (XML-based Variant Configuration Language, patrz [5], [9], [10], [11])
jest dialektem XML, służącym do zapisu wariantów; może on być użyty w każdej dziedzinie, w której podlegające zmienności komponenty da się przedstawić za pomocą kolekcji
dokumentów tekstowych.
Zapis w XVCL składa się ze zbioru ramek (x-frames), odpowiadających tzw. ramom
Bassetta [1], w których fragmenty tekstowego opisu komponentu opatrzone są znakowaniem XVCL, opisującym zmienność. W ramkach można umieszczać odwołania do innych
ramek, tworząc graf skierowany. Ramki niższych poziomów są to tzw. ramki adaptowane,
które zawierają zapisy generyczne, dostosowywane do specyficznych okoliczności dopiero
w procesie przetwarzania XVCL. Ramki wyższych poziomów – tzw. ramki adaptujące –
służą do określenia sposobu adaptacji ramek podrzędnych. Odpowiednio oznakowane fragmenty zawartości ramki adaptowanej w czasie jej przetwarzania mogą być warunkowo włączane lub wyłączane albo uzupełnione lub zastąpione przez fragmenty zdefiniowane
w ramce adaptującej. Procesor XVCL [12] przetwarza ramki rekurencyjnie, od najwyższego poziomu. W miejsce każdego odwołania do ramki podrzędnej podstawiana jest zaadaptowana zawartość tej ramki i w ten sposób z grafu ramek buduje się wynik adaptacji.
da
.b
w
w
pl
s.
2 Niezależny od DBMS zapis schematów danych
Jak wspomniano wyżej, przyjęto tu, że struktury danych opisane są w języku SQL DDL.
Jednak bezpośrednie użycie kodu DDL do stworzenia opisu wersji i wariantów nie wydaje
się rozwiązaniem właściwym. Dialekty tego języka, właściwe dla poszczególnych DBMS,
a nawet ich wersji, różnią się bowiem bardzo znacznie, i różnice te nie są tylko syntaktyczne, lecz głównie odzwierciedlają zróżnicowanie możliwości poszczególnych baz danych.
Składnia SQL DDL nie jest też zbyt łatwa do przetwarzania.
Jednym z częstszych problemów, jakie napotykamy przy zarządzaniu ewolucją schematów, jest współistnienie wariantów przeznaczonych dla różnych DBMS. By zarządzanie
takimi wariantami było łatwe, a w szczególności by można było w sposób prosty i czytelny
zapisywać i analizować wspólne cechy schematów i różnice między nimi, warto opracować
37
w
ujednolicony zapis, bazujący na SQL DDL, ale wyróżniający cechy wspólne dla różnych
DBMS. Notacja taka powinna umożliwić jednolity zapis i łatwe porównywanie tych cech
schematu, które są wspólne dla różnych DBMS, np. tabel i kolumn, indeksów, więzów
integralności, uprawnień; ale jednocześnie powinna zachować konstrukcje specyficzne dla
danego DBMS, np. klauzule sterujące partycjonowaniem i alokacją przestrzeni dyskowych,
kod źródłowy procedur i funkcji składowanych w języku właściwym dla danego DBMS,
struktury relacyjno-obiektowe itp.
Zaproponowano zatem taki właśnie zapis, zamieniając kod DDL w specjalnie zaprojektowany dialekt XML, w którym:
− zapisywana jest jedna konkretna wersja schematu,
− zawarte są informacje o tej wersji: numer, autor, data utworzenia, komentarz; i o docelowej platformie: producent i wersja DBMS;
− obiekty schematu i ich cechy, które są wspólne dla różnych DBMS, np. tabele, kolumny, widoki, indeksy, więzy integralności, uprawnienia, nagłówki podprogramów
składowanych i wyzwalaczy zapisuje się w specjalnych elementach o czytelnych
znacznikach, np. <table>, <view>, <column> itd.;
− konstrukcje charakterystyczne dla konkretnego DBMS zapisywane są w niezmienionej postaci w elemencie <clause>; znaczenie zawartego w nim fragmentu DDL nie
jest dalej analizowane.
W celu uzyskania takiego zapisu schematu, kod skryptów SQL DDL jest przetwarzany
przez parser dostosowany do dialektu DDL właściwego dla danego DBMS.
Dzięki temu zapisowi dalsze przetwarzanie jest prostsze, łatwiejsze jest również zobrazowanie schematu: można łatwo w przejrzystej formie zaprezentować użytkownikowi
obiekty w nim zawarte (np. tabele z kolumnami), a nie tylko klauzule SQL DDL. Przede
wszystkim zaś możliwe jest sprawne porównywanie różnych wydań i wariantów schematu
bazy danych oraz generowanie dokumentów różnicowych, ewolucję schematu bazy danych
można tu bowiem śledzić przez stosunkowo proste porównywanie dokumentów XML. Na
podstawie dokumentu różnicowego i znajomości odpowiednich reguł dla danego DBMS
można wygenerować różnicowe skrypty SQL DDL realizujące zmianę.
da
.b
w
w
3 Zapis ewolucji schematu danych za pomocą XVCL
pl
s.
3.1 Prosty model wersji
Prostym koncepcyjnie modelem ewolucji schematu jest drzewo wydań, w którym węzły reprezentują ewolucję schematu w czasie; w każdym węźle natomiast zapisana jest dodatkową informacja o równoległych wariantach, np. dla różnych platform. Węzeł w takim drzewie odpowiada ramce XVCL, a zależności między węzłami są realizowane za pomocą instrukcji <adapt>. Zmiany w obiektach schematu bazy danych (np. zmiana typu kolumny)
czy pojawienie się nowych elementów (np. nowych klauzul) realizowane są za pomocą
instrukcji <break> i <insert>.
Poniższy zapis reprezentuje pierwszą wersję pewnego prostego schematu.

<xvcl:x-frame name="ksiegarnia-1.0.xvcl">
<xvcl:set value="'1.0'" var="revision.number"/>
<xvcl:adapt x-frame="template.xvcl">
<xvcl:insert break="schema.content">
<tables>
38
w
<table name="autorzy">
<columns>
<column name="id" required="true" size="32" type="NUMBER"/>
<column name="nazwisko" required="true" size="64" type="VARCHAR2"/>

<xvcl:break name="table.autorzy.column.imie">
<column name="imie" required="false" size="16" type="VARCHAR2"/>
</xvcl:break>
</columns>

<xvcl:break name="table.autorzy.clauses"/>
</table>

<xvcl:break name="table.ksiazki"/>
</tables>
</xvcl:insert>
</xvcl:adapt>
</xvcl:x-frame>
w
da
.b
w
Ta ramka adaptuje plik template.xvcl, który zawiera szablon wynikowego kodu XML
(np. prolog, element główny i epilog); do szablonu tego wstawiany jest wynik przetwarzania. Instrukcja <break> umożliwia zdefiniowanie takich fragmentów, które procesor XVCL
może w procesie adaptacji uzupełnić lub zastąpić przez fragmenty zdefiniowane za pomocą
instrukcji <insert> w ramce adaptującej (nadrzędnej).
Ramka reprezentująca późniejszą wersję adaptuje ramkę wersji wcześniejszej:
pl
s.

<xvcl:x-frame name="ksiegarnia-1.2.xvcl">
<xvcl:set value="'1.2'" var="revision.number"/>
<xvcl:adapt x-frame="ksiegarnia-1.0.xvcl">

<xvcl:insert break="table.autorzy.column.imie">
<column name="imie" required="true" size="32" type="VARCHAR2"/>
</xvcl:insert>

<xvcl:insert break="table.autorzy.clauses">
<clauses>

<xvcl:select option="revision.database.name">
<xvcl:option value="oracle">
<clause name="tablespace">
<sql>TABLESPACE ksiegarnia</sql>
</clause>
</xvcl:option>
</xvcl:select>
</clauses>
</xvcl:insert>
</xvcl:adapt>
</xvcl:x-frame>
Występująca tu zmienna revision.database.name steruje „rozgałęzieniami”, tworzącymi
równolegle istniejące warianty (w tym wypadku odpowiadające różnym DBMS).
By wygenerować konkretny wariant, należy tę ramkę adaptować za pomocą ramki nadrzędnej (specyfikacyjnej), określającej konkretny DBMS, np. wersję dla bazy PostgresSQL
uzyskamy za pomocą ramki:
<xvcl:x-frame name="postgres-1.2.xvcl" outfile="postgres-1.2.xml">
<xvcl:set value="postgresql" var="revision.database.name"/>
<xvcl:set value="'5.4'" var="revision.database.number"/>
<xvcl:adapt x-frame="ksiegarnia-1.2.xvcl">
<xvcl:insert break="revision.comment">Wersja PostgreSQL</xvcl:insert>
<xvcl:insert break="revision.author">Jan Maria Kowalski</xvcl:insert>
39
<xvcl:insert break="revision.date">2006-03-30T02:53:23</xvcl:insert>
</xvcl:adapt>
</xvcl:x-frame>
W tak wygenerowanej wersji nie będzie klauzuli przeznaczonej dla DBMS Oracle.
3.2 Repozytorium obiektów
w
da
.b
w
w
Zaproponowany wyżej model wersji i sposób zapisu ewolucji schematu bazy danych za pomocą języka XVCL ma jednak ważne ograniczenia, m.in.:
− brak możliwości utworzenia nowej wersji wywodzącej się z więcej niż jednej wersji
poprzedzającej;
− utrudnione śledzenie zmienności obiektów schematu bazy danych (należy analizować ramki XVCL przetworzone przez procesor XVCL);
− konieczność modyfikowania zapisu wcześniejszych wersji – znakowania znacznikiem <break> fragmentów kodu podlegających modyfikacjom oraz miejsc, w których ma się pojawić nowy kod.
Opisane poniżej rozwiązanie – repozytorium obiektów schematu – pozwala uniknąć
dwóch pierwszych ograniczeń. Repozytorium jest współdzielone przez wszystkie wersje
i zawiera w osobnych plikach generyczne zapisy poszczególnych obiektów (tabel, podprogramów itd.) wraz z informacją o ich wydaniach. Każda wersja schematu zawiera bezpośrednie lub pośrednie (przez wersje, z których się wywodzi) odwołania do konkretnych wydań obiektów z repozytorium.
Repozytorium obiektów zawiera więc wiele plików, które są wymienione w ramce bazowej:
pl
s.

<xvcl:x-frame name="repository.xvcl">
<xvcl:adapt x-frame ="template.xvcl">
<xvcl:insert break ="schema.content">

<tables>
<xvcl:adapt x-frame="?@root?/repository/tables/autorzy.xvcl"/>
...
</tables>
...
</xvcl:insert>
</xvcl:adapt>
</xvcl:x-frame>
Ta ramka ulega adaptacji w czasie generowania konkretnej wersji. Poszczególne obiekty,
wraz z informacją o ich wydaniach, zapisane są w plikach składowych repozytorium, np.:
<xvcl:x-frame name="autorzy.xvcl">
<xvcl:select option="tables.autorzy">
<xvcl:option value="'1.0'"> 
<table name="autorzy">
<columns>
<column name="autor_id" required="true" type="NUMBER"/>
<column name="nazwisko" required="true" size="63" type="VARCHAR2"/>
<column name="imie" required="true" size="63" type="VARCHAR2"/>
<xvcl:select option ="tables.autorzy.columns.telefon">
<xvcl:option value ="'1.0'"> 
<xvcl:message text="1. wersja kolumny telefon, dane wymagane"/>
<column name="telefon" size="32" type="VARCHAR2" required="true"/>
</xvcl:option>
<xvcl:option value="'1.1'"> 
40
w
<xvcl:message text="Kolumna telefon moze byc pusta"/>
<column name="telefon" size="32" type="VARCHAR2" required="false"/>
</xvcl:option>
<xvcl:otherwise/>
</xvcl:select>
</columns>
</table>
</xvcl:option>
</xvcl:select>
</xvcl:x-frame>
w
Wartość zmiennej tables.autorzy odpowiada tu numerowi wydania tabeli Autorzy,
a zmiennej tables.autorzy.columns.telefon – numerowi wydania kolumny Telefon.
Utworzenie nowej wersji następuje przez wyliczenie wydań obiektów w ramce wyższego poziomu (specyfikującej):
da
.b
w
<xvcl:x-frame name="oracle-1.2.xvcl">

<xvcl:set var="revision.number" value="'1.2'"/>
<xvcl:set var="revision.database.name" value="oracle"/>
<xvcl:set var="revision.database.number" value="'8.2'"/>

<xvcl:set value ="'1.1'" var="tables.ksiazki.columns.wydawnictwo"/>
<xvcl:set value ="'1.0'" var="tables.autorzy"/>
<xvcl:select option="revision.number">

<xvcl:option value="'1.2'">
<xvcl:adapt x-frame="repository/repository.xvcl">
<xvcl:insert break="revision.comment">
Dodana nowa tabela Autorzy
</xvcl:insert>
<xvcl:insert break="revision.author">Jan Maria Kowalski</xvcl:insert>
</xvcl:adapt>
</xvcl:option>
</xvcl:select>
</xvcl:x-frame>
pl
s.
Warunek select jest tu użyty, gdyż ramka specyfikująca daną wersję może stać się ramką
adaptowaną w wersji od niej pochodzącej1. Tak też jest w wypadku dziedziczenia zmian od
wielu wersji poprzedzających:
<xvcl:x-frame name="oracle-1.5.xvcl">

<xvcl:set var="revision.number" value="'1.5'"/>
<xvcl:set var="revision.database.name" value="oracle"/>
<xvcl:set var="revision.database.number" value="10g"/>

<xvcl:adapt x-frame="oracle-1.0.xvcl" samelevel="yes"/>
<xvcl:adapt x-frame="oracle-1.2.xvcl" samelevel="yes"/>
<xvcl:select option="revision.number">
<xvcl:option value="'1.5'">
<xvcl:adapt x-frame="repository/repository.xvcl">
<xvcl:insert break="revision.comment">
Poprawiona wersja dla Oracle 10g
</xvcl:insert>
<xvcl:insert break="revision.author">Tomasz Traczyk</xvcl:insert>
1
Ważny szczegół stanowi tutaj nietypowa cecha XVCL: otóż wartości zmiennych nadane w ramce
nadrzędnej mają pierwszeństwo przez wartościami nadanymi lokalnie (w bieżącej ramce); dzięki
temu ramki nadrzędne mogą adaptować także domyślne wartości zmiennych, nadane w ramkach
podrzędnych.
41
</xvcl:adapt>
</xvcl:option>
</xvcl:select>
</xvcl:x-frame>
Ramki wywołane w części specyfikującej pochodzenie wersji dokonują ustawienia wartości
odpowiednich zmiennych2, a te odpowiednio sterują adaptacją obiektów z repozytorium.
w
3.3 Repozytorium obiektów z zapisem lokalnych zmian
da
.b
w
w
Można połączyć koncepcje powyższych modeli wersjowania, rozszerzając model wersji
z repozytorium obiektów o możliwość zapisu tzw. lokalnych zmian. Koncepcja lokalnych
zmian [4], polega na tym, że każdy programista, który pracuje nad własnym fragmentem
projektu, ma wyłączny lokalny dostęp do swoich obiektów i może swobodnie dokonywać
zmian i testować ich skutki. Wspólnym zbiorem tzw. obiektów bazowych zarządza administrator projektu. Kiedy lokalna praca nad obiektem jest zakończona, programista zgłasza
administratorowi swój fragment kodu źródłowego jako gotowy do wdrożenia (tzw. promocji obiektu) i obiekt bazowy zastępuje się nową wersją.
W opisywanym tu sposobie zapisu wersji lokalne zmiany wprowadzane mogą być za pomocą instrukcji <break> i <insert> do konkretnej wersji schematu. Nie są one zapisywane
do repozytorium obiektów, nie są więc dziedziczone przez inne wersje schematu.
3.4 Prototypowe narzędzia
pl
s.
Stworzono prototypowe narzędzia, umożliwiające wykonywanie operacji potrzebnych do
zarządzania ewolucją schematu danych, zapisaną w sposób zaproponowany powyżej. Program został zbudowany na platformie Eclipse. Zawiera przykładowy parser skryptów DDL
(dla dialektu Oracle) zbudowany na bazie ANTLR3 [7], obiektowy model schematu bazy
danych, serializer zapisujący schemat w postaci opisanego w podrozdziale 2 dialektu XML,
moduł porównywania schematów zapisanych w tej postaci oraz wtyczkę XVCL Workbench4, wspierającą użycie języka XVCL (m.in. edytor kodu źródłowego, procesor XVCL).
Ten prototypowy program zapewnia m.in. konwersję zapisu schematu bazy danych ze
skryptów SQL DDL (dialekt Oracle) do formatu XML oraz porównywanie dwóch wersji
schematu bazy danych i tworzenie dokumentu różnicowego zawierającego zmiany w formacie XML (rys. 2). Prototyp ten ma liczne ograniczenia, np. została zaimplementowana
tylko obsługa jednego dialektu SQL DDL; brak też możliwości konwersji wygenerowanego
w XML opisu schematu z powrotem na DDL, w szczególności nie ma możliwości generowania skryptów różnicowych. Jednak dzięki odpowiednio zaprojektowanej architekturze
programu i wykorzystaniu otwartych rozwiązań, standardów i bibliotek (Java, XML, Eclipse, ANTLR) prototyp ten może być łatwo rozbudowywany.
2
Atrybut samelevel="yes" powoduje określenie tych zmiennych na poziomie bieżącej ramki.
Narzędzie służące do tworzenia kompilatorów oraz translatorów na podstawie opisu gramatyki.
4
Plug-in do środowiska Eclipse wspomagający pracę z XVCL (http://xvcl.comp.nus.edu.sg/update/).
3
42
w
da
.b
w
w
Rys. 2. Prototypowe narzędzie – porównywanie schematów zapisanych w formacie XML
4
Podsumowanie
pl
s.
Zaproponowana tutaj metoda zarządzania wersjami schematu bazy danych z wykorzystaniem języka XVCL dobrze wpisuje się w sprawdzone wzorce stosowane w zarządzaniu
wersjami oprogramowania, przede wszystkim wersjowanie zorientowane na zmiany. Zaproponowano niezależny od platformy format zapisu struktury schematu bazy danych
w postaci dokumentu XML. Format ten umożliwia zapis i efektywne porównywanie obiektów niezależnie od producenta i wersji systemu zarządzania bazą danych, zapewniając zachowanie szczegółów schematu (zaawansowanych cech obiektów, konstrukcji specyficznych dla danego DBMS). Przedstawiono model wersji schematu bazy danych – repozytorium obiektów z możliwością rejestracji lokalnych zmian – do zapisu którego zaproponowano użycie XVCL. Rozwiązanie to spełnia wymagania dotyczące zarządzania ewolucją
schematu oraz dokumentowania historii zmian.
Opisana tu próba formalnego zapisu ewolucji schematu bazy danych za pomocą języka
XVCL jest częścią większego zamierzenia (jak wspomniano w podrozdziale 1), mającego
na celu zbadanie przydatności języka XVCL do zarządzania ewolucją systemu informacyjnego – jego wszystkich warstw na różnych etapach rozwoju. Obecnie zaproponowany model opisu ewolucji schematu danych będzie teraz weryfikowany, w szczególności zbadana
zostanie jego przydatność w kontekście zarządzania zmianami warstwy Model systemu
w architekturze MVC. Przewiduje się też dalsze rozwijanie prototypowych narzędzi wspierających zarządzanie wersjami, np. wzbogacenie programu o parsery dla dalszych dialektów SQL DDL i o generatory skryptów różnicowych.
43
Zaprezentowany sposób zapisu ewolucji schematu może znaleźć zastosowanie przede
wszystkim do zarządzania projektami systemów, które rozwijane są przez długi czas i istnieją w wielu wariantach jednocześnie, w przypadku których typowe systemy SCM nie dają wystarczających możliwości zapanowania nad zmiennością.
Literatura
w
1.
da
.b
w
w
Bassett P.: The Theory and Practice of Adaptive Components. Lecture Notes In Computer Science; Vol. 2177. Proceedings of the Second International Symposium on Generative and Component-Based Software Engineering. Springer-Verlag 2000.
2. Bębenek A., Traczyk T.: Koncepcja użycia języka XVCL do zapisu ewolucji diagramów UML
reprezentujących struktury baz danych. W ramach pracy zbiorowej pod redakcją S. Kozielskiego
i in.: Bazy danych. Struktury, algorytmy, metody, s. 13–22. Wydawnictwa Komunikacji
i Łączności 2006.
3. Conradi R., Westfechtel B.: Version models for software configuration management. ACM
Computing Surveys, 30 (2) pp. 232–282, 1998.
4. Fowler D.: Database change management best practices: Achieving an automated approach and
version control. Bearpark Publishing Ltd., 2004.
5. 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.
6. Kowalski J.M.: Zarządzanie zmianami w schemacie bazy danych zapisanym w SQL DDL. Praca
magisterska, Instytut Automatyki i Informatyki Stosowanej Politechniki Warszawskiej, 2006.
7. Parr T.J., Quong R.W.: ANTLR: A predicated-LL(k) parser generator. Software Practice and
Experience, 25 (7) pp. 789–810, 1995.
8. Seow J., Jarzabek S.: A case study in software evolution with cvs: Problems and alternatives.
School of Computing National University of Singapore, Singapore 2006.
9. Soe M.S., Zhang H., Jarzabek S.: XVCL: A Tutorial. Proceedings of 14-th International Conference on Software Engineering and Knowledge Engineering SEKE’02, Italy, pp. 341–349. ACM
Press 2002.
10. Wong T.W., Jarzabek S., Myat Swe S., Shen R., Zhang H.Y.: XML Implementation of Frame
Processor. Proceedings of ACM Symposium on Software Reusability, SSR’01, pp. 164–172.
Toronto, Canada 2001.
11. XVCL Web Site. http://xvcl.comp.nus.edu.sg/overview_brochure.php
12. XML-based Variant Configuration Language – Download Site
http://sourceforge.net/project/showfiles.php?group_id=58966
pl
s.
44

pobierz plik referatu

Transkrypt

Podobne dokumenty

Co to jest schemat ciała? Po raz pierwszy pojęcia schemat ciała użył

Najnowszą wersję pakietu InsERT GT mona ściągnąć ze strony: ftp

Sztuka jako sposób myślenia - Muzeum Sztuki Nowoczesnej w

Przedmiar robót: Dostawa i montaż stolarki okiennej i drzwiowej w

insert «wkładka, zwykle o charakterze reklamowym

Zarządzanie projektowaniem struktury i schematu organizacji

transformata do insert gt dla banku bgż - Info

e-Archiwizacja w programach InsERT

tekst AS