pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 1
w
w
Koncepcja użycia języka XVCL
do zapisu ewolucji diagramów UML
reprezentujących struktury baz danych
da
.b
w
Streszczenie. Zaproponowano metodę zapisu ewolucji diagramów UML, reprezentujących struktury baz danych, za pomocą języka XVCL – bazującego
na XML języka zapisu wariantów. Diagramy UML zapisano w XMI i zapis
ten opatrzono metainformacją w XVCL, opisującą ewolucję. Szczególną
uwagę zwrócono na możliwość zapisu projektów mających wiele wariantów
rozwijanych równolegle, a różniących się nieznacznie. Zaproponowano też
wykorzystanie typowych narzędzi projektowych (Rational Rose) do wspomagania zarządzania wariantami.
1 Wprowadzenie
pl
s.
Projektowanie i utrzymanie systemów informacyjnych z bazami danych wymaga z reguły
wielokrotnego modyfikowania struktur danych, często trwającego przez cały wieloletni
okres życia systemu. Niejednokrotnie także istnieje potrzeba wytworzenia kilku równolegle
żyjących wariantów, różniących się tylko stosunkowo nielicznymi szczegółami. Zarządzanie wieloma wersjami i wariantami schematów danych jest zwykle zadaniem niełatwym
i wymagającym formalizacji; próbę takiej właśnie formalizacji zaprezentowano poniżej.
1.1 Motywacja – ewolucja struktur danych zapisanych w UML
Obecnie jednym z popularnych sposobów zapisu schematów baz danych są diagramy klas
UML, reprezentujące (np. z użyciem stereotypów):
− w projektowaniu konceptualnym (terminologia wg [1]) – encje i związki, jak w [2];
− w projektowaniu logicznym – tabele, jak w UML Data Profile [3], [4].
Potrzebne są więc sposoby, by w sposób formalny zapisywać ewolucję tak zapisanych
schematów danych: ich kolejne wersje i równolegle istniejące warianty.
Ponieważ diagramy UML mają powszechnie akceptowaną reprezentację tekstową –
format XMI (XML Metadata Interchange [5]), do zapisu ewolucji schematów można użyć
narzędzi przeznaczonych do zarządzania wariantami dokumentów tekstowych. Takim właAdam Bębenek, 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 2006
A. Bębenek, T. Traczyk
śnie narzędziem jest język XVCL. Zastosowanie XVCL do zapisu wariantów diagramów
przypadków użycia i czynności zaprezentowano w [6]; niniejsza praca stanowi propozycję
adaptacji tego podejścia do zapisu ewolucji diagramów klas reprezentujących struktury baz
danych. W dalszym tekście skupiono się na diagramach UML reprezentujących związki encji (jak w [2]), ale to samo podejście może być do diagramów reprezentujących tabele (jak w [3], [4]).
w
1.2 Język XVCL
da
.b
w
w
Język XVCL (XML-based Variant Configuration Language) [7], [8] jest dialektem XML
służącym do zapisu wariantów programów lub innych dokumentów tekstowych, bazującym
na idei tzw. ram Bassetta [9].
Zapis mającego wiele wariantów dokumentu składa się ze zbioru ramek (x-frames), zawierających fragmenty dokumentu opatrzone znakowaniem XVCL, opisującym zmienność.
W ramkach można umieszczać odwołania do innych ramek (instrukcje <adapt>), zatem
ramki tworzą graf skierowany (x-framework), zbliżony zwykle budową do drzewa (ale ze
„zrostami” – poszczególne ramki mogą mieć więcej niż jedną ramkę nadrzędną). Ramki
niższych poziomów (adaptowane) zawierają zapisy bardziej generyczne, zaś ramki wyższych poziomów (adaptujące) określają sposób adaptacji swych ramek podrzędnych do bardziej specyficznych warunków. W ramce adaptowanej można określić fragmenty (<break>), które w czasie jej przetwarzania mogą być uzupełnione lub zastąpione przez fragmenty zdefiniowane za pomocą instrukcji <insert> w ramce nadrzędnej (adaptującej).
Procesor XVCL [10], przetwarzający tak zdefiniowaną strukturę, przetwarza ramki rekurencyjnie, poczynając od ramki najwyższego poziomu, tzw. ramki specyfikacyjnej. W miejsce każdej napotkanej instrukcji <adapt> podstawia zaadaptowaną zawartość ramki podrzędnej i w ten sposób scala zawartość całej struktury ramek w jeden dokument wynikowy.
W XVCL można także używać zmiennych: instrukcje <set> i <set-multi> sterują podstawianiem zmiennych jedno- i wielowartościowych. W tekście adaptowanego dokumentu
można odwoływać się do tych zmiennych i do wyrażeń na nich opartych; zmienne mogą
także sterować działaniem instrukcji XVCL, np. przetwarzaniem warunkowym (instrukcja
<select>) lub iteracjami sterowanymi zmienną wielowartościową (instrukcja <while>). Co
ciekawe, w XVCL wartość zmiennej podstawiona w ramce nadrzędnej ma priorytet nad
podstawieniami w ramkach podrzędnych, by możliwe było zmienianie (adaptacja) lokalnych podstawień wartości domyślnych przez ramki nadrzędne (adaptujące).
pl
s.
2 Zapis wariantów i wersji diagramów UML za pomocą XVCL
2.1 Reprezentacja diagramów UML
Aby móc wykorzystać język XVCL do zapisu procesu ewolucji, należy przekształcić diagramy UML do postaci tekstowej. Większość narzędzi projektowych umożliwia eksport
diagramów UML do plików w formacie XMI i ten format wykorzystano jako postać źródłową, której warianty mogą być zapisane za pomocą XVCL. Aby umożliwić procesorowi
odróżnienie komend języka XVCL (który, podobnie jak XMI, jest dialektem XML) od
zwykłego tekstu XMI opisującego obiekty UML, zastosowano przestrzeń nazw (namespace) i każdą komendę języka XVCL poprzedzono prefiksem xvcl (procesor XVCL należy
uruchamiać z opcją –N). W wyniku działania procesora XVCL powstaje plik XMI, będący
14
Koncepcja użycia języka XVCL do zapisu ewolucji diagramów UML
odwzorowaniem wynikowego wariantu, który może być zaimportowany przez narzędzie
projektowe i wyświetlony w postaci graficznej.
2.2 Zapis wyboru wariantu z rodziny systemów
w
Rodziną systemów nazywany będzie zbiór systemów, które wywodzą się ze wspólnego
źródła i mają część wspólną oraz części różniące się. Istnieje wówczas rdzeń zbioru diagramów UML, odpowiadający wspólnej części systemów rodziny, który jest włączany do
wszystkich diagramów opisujących członków rodziny. Za pomocą XVCL należy opisać te
części diagramów, którymi systemy rodziny się różnią. Specyfikacji wariantów dokonuje
się, w zależności od sytuacji, wykorzystując tylko jedną z wielu opcji albo superpozycję
(połączenie) kilku opcji. Jeśli diagramy końcowe różnią się całymi klasami lub zbiorami
klas, to można stworzyć oddzielne ramki XVCL (pliki) i sterować ich załączaniem poprzez
ustawianie zmiennych w ramce specyfikacyjnej.
Dla przykładu zapis kilku opcji może wyglądać następująco:
w
w
da
.b
<xvcl:while using-items-in="PrzelewBankowy">
<xvcl:select option="PrzelewBankowy">
<xvcl:option value="Internet">
<xvcl:adapt x-frame="Internet.xvcl" />
</xvcl:option>
<xvcl:option value="Telefon">
<xvcl:adapt x-frame="Telefon.xvcl" />
</xvcl:option>
<xvcl:option value="OddzialBanku">
<xvcl:adapt x-frame="OddzialBanku.xvcl" />
</xvcl:option>
</xvcl:select>
</xvcl:while>
W ramce specyfikacyjnej nadawane są, w zależności od potrzeb, wartości zmiennej sterującej wyborem opcji, np. zapis równoczesnego wyboru kilku z opcji może wyglądać tak:
<xvcl:set-multi var="PrzelewBankowy" value="Internet, OddzialBanku" />
Wynikowy diagram będzie w tym przypadku superpozycją diagramów odpowiadających
wybranym opcjom.
pl
s.
2.3 Zapis wariantów atrybutów i związków
Różnice o większej szczegółowości, dotyczące zmian atrybutów i związków, można zapisać wykorzystując polecenia XVCL:
− <break> – obejmujące miejsce wprowadzenia zmian w ramce opisującej klasę,
− <insert> – umieszczone w ramce specyfikacyjnej, określające specyficzny dla danej
opcji kod XMI.
Kod dodany do ramki specyfikacyjnej może zatem wyglądać tak:
<xvcl:adapt x-frame="Klasa.xvcl">
<xvcl:insert break="nowe_atrybuty">
… 
</xvcl:insert>
<xvcl:insert break="istniejacy_atrybut">
… 
</xvcl:insert>
</xvcl:adapt />
15
2.4 Zapis ewolucji systemu w czasie
w
Przez ewolucję systemu w czasie rozumie się tu ciąg kolejnych wersji systemu, powstających w czasie jego rozwoju i wprowadzających kolejne modyfikacje do struktur danych.
Wersje oznaczono kolejnymi wartościami atrybutu versions. Informację o pochodzeniu
kolejnej wersji umieszczono na początku ramki specyfikacyjnej; użyto sposobu zapisu,
który umożliwia wywodzenie kolejnej wersji niekoniecznie z wersji bezpośrednio poprzedniej.
Zapis <xvcl:set-multi var="versions" value="1,2,3"/> oznacza, że wersja nr 3 korzysta ze zmian, które były wprowadzane we wszystkich poprzednich wersjach. Natomiast
użycie: <xvcl:set-multi var="versions" value="1,3"/> oznacza, że wersja nr 3 korzysta tylko ze zmian, które były wprowadzone w wersji nr 1, a zmiany z wersji nr 2 są pomijane. Zmianami w kodzie XMI steruje się przez ustawianie – za pomocą komendy option
– wartości odpowiednich zmiennych, jak w przykładzie poniżej.
w
/>
/>
/>
da
.b
w
<xvcl:set-multi var="versions" value="1,3" />
<xvcl:while using-items-in="versions">
<xvcl:select option="versions">
<xvcl:option value="1">
<xvcl:set var="zmienna1" value="11"
</xvcl:option>
</xvcl:option>
</xvcl:option>
</xvcl:select>
</xvcl:while>
/>
/>
Następnie, w zależności od stanu tak ustawionych zmiennych, procesor XVCL dołącza
całe pliki XMI ze specyfikacjami diagramów lub modyfikuje ich fragmenty.
pl
s.
<xvcl:select option="zmienna1">
<xvcl:adapt x-frame="diagram1.xvcl">
<xvcl:ifdef var=”zmienna2”>
<xvcl:select option="zmienna2">
<xvcl:insert break="zmiana21">
… 
</xvcl:insert>
</xvcl:option>
<xvcl:insert break="zmiana22">
… 
</xvcl:insert>
</xvcl:option>
</xvcl:select>
</xvcl:ifdef>
</xvcl:adapt>
</xvcl:option>
… <!—analogiczny kod XVCL opisujący przypadek 12 -->
</xvcl:option>
</xvcl:select>
16
3 Zastosowanie Rational Rose do zarządzania ewolucją diagramów
3.1 Wykorzystanie diagramu przypadków użycia do zarządzania wariantami
w
Konieczność kodowania wariantów w języku XVCL może być uciążliwa dla użytkownika.
Dlatego opracowano sposób wykorzystania popularnego narzędzia projektowego Rational
Rose, ułatwiający zarządzanie wariantami. Użyto odpowiednio przystosowanego widoku
przypadków użycia (wybrano ten rodzaj diagramu ze względu na możliwość powiązania
każdego węzła diagramu ze specyficznym diagramem klas). Posługując się diagramem
przypadków użycia wzbogaconym o pewne stereotypy, można budować diagramy wariantów – schematy przedstawiające zależności między wariantami (patrz rys. 1). Każdy przypadek użycia reprezentuje wariant, do którego przypisany jest oddzielny diagram klas.
Użytkownik może zarządzać wariantami posługując się językiem graficznym, bez wgłębiania się w zawiłości składni języków XVCL i XMI. Odpowiednie oprogramowanie umożliwi automatyczne budowanie ramek XVCL w zależności od struktury diagramu.
da
.b
w
w
pl
s.
Rys. 1. Przykładowy diagram wariantów rodziny systemów
3.2 Wykorzystanie zaawansowanych możliwości programu Rational Rose
Do zbudowania rozszerzeń ułatwiających zarządzanie wariantami używane są zaawansowane możliwości Rational Rose: interfejs programistyczny REI oraz język RSL.
Rose Extensibility Interface (REI) [11] jest zbiorem pakietów klas, które stanowią interfejs programistyczny, pozwalający kontrolować całą funkcjonalność programu Rational
Rose. Dzięki niemu z diagramów przypadków użycia i diagramów klas mogą być pobrane
szczegółowe informacje, służące do zapisu wyeksportowanego kodu XMI w postaci
XVCL.
17
w
Rational Rose Language (RSL) jest językiem skryptowym, służącym do komunikacji
z REI. Skrypty pisane w nim służą do oprogramowania kolejnych etapów działania systemu
zarządzania ewolucją:
− uzupełnienia tekstowej reprezentacji diagramu brakującymi szczegółowymi informacjami (np. powiązaniami między diagramami) w postaci kodu XMI,
− przedstawienia struktury diagramu wariantów w postaci kodu XVCL,
− inicjalizacji zmiennych w ramce specyfikacyjnej, zgodnej z wyborem wariantów,
dokonanym przez użytkownika na diagramie (np. przez zaznaczenie myszką),
− uruchomienia procesora XVCL [10], który tworzy plik XMI gotowy do importu.
Samo przetwarzanie diagramów na postać XMI i ponownie na postać graficzną jest wykonywane za pomocą standardowych narzędzi wbudowanych w Rational Rose:
− UML 1.3 Export przekształca diagram UML w plik w formacie XMI; stworzony plik
jest wykorzystywany jako wersja startowa dla dalszego przekształcania przez skrypty
napisane w RSL i REI;
− UML 1.3 Import wczytuje wygenerowany przez procesor XVCL plik XMI, dzięki
czemu wynikowy diagram może być przedstawiony w postaci graficznej.
w
w
3.3 Przykład zarządzania wariantami rodziny systemów
da
.b
Załóżmy, że naszym zadaniem jest zaprojektowanie rodziny diagramów związków encji
(w notacji UML), z których w przyszłości może powstać:
− system ewidencji książek i ich autorów, np. księgarnia internetowa,
− system ewidencji książek, czasopism, filmów, płyt z muzyką oraz ich twórców,
np. sklep internetowy,
− biblioteka wypożyczająca tylko książki,
− biblioteka wypożyczająca książki, czasopisma, prace magisterskie, dokumenty
w formie elektronicznej.
Dla każdego z tych systemów trzeba stworzyć osobne, ale bardzo podobne diagramy
klas. Jeśli więc potrzebna będzie jakaś nowa wspólna funkcjonalność, trzeba będzie modyfikować kilka diagramów. Lepszym rozwiązaniem jest wyodrębnienie za pomocą XVCL
funkcjonalności, które są wspólne oraz takich, które są specyficzne, a następnie automatyczne tworzenie diagramów systemów rodziny. Posługując się widokiem przypadków
użycia zbudowano diagram wariantów przykładowej rodziny systemów (rys. 1).
Na diagramie przy niektórych wymaganiach występuje krotność:
− 1 – oznacza, że wymaganie jest obowiązkowe,
− 0..1 – oznacza, że wymaganie jest nieobowiązkowe.
Do reprezentacji różnego typu powiązań użyto dwóch stereotypów:
− <<one-of-many>> – tylko jedno z wielu wymagań może zostać wybrane,
− <<any-of-many>> – można wybrać kilka z wielu wymagań.
Stosując się do tych zasad można zauważyć, że końcowy system musi zajmować się jednym z dwóch zasobów: Tylko książki albo Książki, czasopisma, kasety video
itp. Ponadto system może obsługiwać wypożyczanie swoich zasobów.
Diagram przypisany do węzła Rdzeń systemu zawiera wszystkie te informacje, które
występują u każdego członka rodziny systemów (rys. 2). W tym przykładzie są to informacje na temat autorów, ponieważ można tam zawrzeć zarówno dane o twórcach książek, jak
i reżyserach filmów. Diagram przypisany do węzła opcjonalnego Umożliwienie wypożyczeń zawiera wszystkie informacje, które są potrzebne by gromadzić dane na temat tego,
kto i co wypożyczył. Węzeł obowiązkowy Jakie zasoby posiada?
pl
s.
18
nie zawiera żadnego diagramu i służy jedynie do logicznego przedstawienia podziału systemów na dwa rodzaje: zajmujących się tylko książkami albo mających w swym zakresie
większą różnorodność zasobów. Na diagramie przypisanym do węzła Książki, czasopisma, kasety video itp. przedstawiono możliwość wprowadzania do bazy informacji
zarówno o książkach, jak i o innych zasobach. Między innymi wprowadzono tutaj atrybut
typ_zasobu, który ok.reśla z czym mamy do czynienia. Natomiast diagram przyporządkowany do węzła Tylko książki umożliwia gromadzenie danych jedynie o książkach.
w
da
.b
w
w
pl
s.
Rys. 2. Podgląd diagramów związków encji przypisanych do kolejnych wariantów
W trakcie tworzenia diagramu końcowego łączone są ze sobą diagramy z różnych węzłów. Asocjacje są tworzone dzięki zdefiniowanym powiązaniom między klasami; definicje
powiązań umieszcza się we właściwościach podrzędnych węzłów, w pokazanej poniżej
formie (oznaczenie nazwaDiagramu.nazwaKlasy).
19
w
Tylko ksiazki:
A:class=”ksiazki.ksiazka”, name=”napisana przez”, multiplicity=”1”,
B:class=”rdzen.autorstwo”, name=”napisalo”, multiplicity=”1..*”;
Książki, czasopisma, kasety video, itp.:
A:class=”zasoby.zasob”, name=”stworzony przez”, multiplicity=”1”,
B:class=”rdzen.autorstwo”, name=”stworzylo”, multiplicity=”1..*”;
Umożliwienie wypożyczeń:
A:class=”ksiazki.wydanie_ksiazki”, name=”posiada”, multiplicity=”1”,
B:class=”wypozyczenia.egzemplarz”, name=”nalezy do”, multiplicity=”0..*”;
A:class=”zasoby.wydanie_zasobu”, name=”posiada”, multiplicity=”1”;
B:class=”wypozyczenia.egzemplarz”, name=”nalezy do”, multiplicity=”0..*”;
w
Użytkownik, w celu stworzenia diagramu obrazującego bibliotekę wypożyczającą tylko
książki, wybiera na diagramie wariantów węzły: Rdzeń systemu, Jakie zasoby
posiada?, Tylko książki oraz Umożliwienie wypożyczeń. W ramce specyfikacyjnej
zostaną wówczas ustawione odpowiednie wartości zmiennych, które sterują wykonaniem
właściwych fragmentów kodu i utworzeniem wynikowego diagramu (rys. 3).
w
<set var="Jakie zasoby posiada?" value=”ksiazki" />
<set var="Umozliwienie wypozyczen" value=”wypozyczenia" />
<xvcl:adapt x-frame="rdzen.xvcl" />
da
.b

<xvcl:select option="Jakie zasoby posiada?">
<xvcl:option value="ksiazki"> 
<xvcl:adapt x-frame="ksiazki.xvcl">
<xvcl:insert break="ksiazki_rdzen">
… <!—- kod XMI związku między książkami a rdzeniem-->
</xvcl:insert>
</xvcl:adapt>
</xvcl:option>
<xvcl:option value="zasoby"> 
<xvcl:adapt x-frame="zasoby.xvcl">
<xvcl:insert break="zasoby_rdzen">
… <!—- kod XMI związku między zasobami a rdzeniem-->
</xvcl:insert>
</xvcl:adapt>
</xvcl:option>
</xvcl:select>
pl
s.
<xvcl:ifdef var=”Umozliwienie wypozyczen”>

<xvcl:adapt x-frame="wypozyczenia.xvcl">
<xvcl:select option="Jakie zasoby posiada?">
<xvcl:option value="ksiazki"> <!—-to będzie wykonane-->
<xvcl:insert break="wypozyczenia_ksiazki">
…<!—-kod XMI związku z książkami-->
</xvcl:insert>
</xvcl:option>
<xvcl:option value="zasoby"><!—-to nie będzie wykonane-->
<xvcl:insert break="wypozyczenia_zasoby">
…<!—-kod XMI związku z zasobami-->
</xvcl:insert>
</xvcl:option>
</xvcl:select>
</xvcl:adapt>
</xvcl:ifdef>
20
w
w
w
Rys. 3. Wygenerowany diagram związków encji, przedstawiający bibliotekę wypożyczającą tylko książki
da
.b
4 Podsumowanie
4.1 Stan prac i dalsze zadania
4.2 Potencjalne zastosowania
pl
s.
Opracowano koncepcję użycia języka XVCL do zapisu ewolucji diagramów UML, reprezentujących struktury baz danych. Obecnie trwają prace nad oprogramowaniem rozszerzającym pakiet Rational Rose o możliwość zarządzania wariantami diagramów.
Dalsze prace polegać będą z jednej strony na rozwijaniu koncepcji; opracowania wymaga np. sposób graficznej reprezentacji ewolucji systemów w czasie. Z drugiej strony planuje się przeprowadzenie testów opracowanego sposobu zapisu i narzędzi na rzeczywistym
przypadku: diagramach związków encji opisujących strukturę bazy danych konstrukcji
detektora cząstek (Detector Construction Database [12]) – „żyjącego” projektu, mającego
trzy równolegle utrzymywane warianty i wiele kolejnych wersji, rozwijanych na przestrzeni
kilku lat.
Zaprezentowany w tym rozdziale sposób zapisu ewolucji diagramów UML może znaleźć
zastosowanie przede wszystkim do zarządzania projektami systemów, które rozwijane są
przez dłuższy czas i istnieją w więcej niż jednym wariancie jednocześnie. Jest to sytuacja
stosunkowo często występująca w przypadku systemów informacyjnych z bazami danych,
dla których typowa jest wieloletnia eksploatacja powiązana z nieustannymi modyfikacjami
schematu danych; stosunkowo często występuje też konieczność równoczesnego utrzymywania kilku wariantów schematów, np. dla różnych docelowych platform DBMS. Dlatego
w prowadzonych pracach skoncentrowano się na diagramach UML, reprezentujących
struktury baz danych.
21
Można mieć nadzieję, że zaproponowane podejście umożliwi sformalizowany zapis
ewolucji wersji i wariantów schematów struktur danych, co mogłoby ułatwić zarządzanie
projektami i utrzymywanie długookresowo eksploatowanych systemów informacyjnych.
Literatura
w
1.
2.
Conolly T., Begg C.: Systemy baz danych. RM 2004.
Gornik D.: Entity relationship modeling with UML. Rational Software – IBM 2003,
3.
Gornik D.: UML Data Modeling Profile. Rational Software Corporation 2002,
4.
Gornik D.: Relational modeling with UML. Rational Software – IBM 2003,
5.
XML Metadata Interchange (XMI). Object Management Group (OMG) 2001,
http://www.ibm.com/developerworks/rational/library/319.html
http://www.jeckle.de/files/RationalUML-RDB-Profile.pdf
w
http://www.ibm.com/developerworks/rational/library/322.html
http://www.omg.org/technology/documents/formal/xmi.htm
6.
da
.b
w
Jarzabek S., Zhang H.: XML-based Method and Tool for Handling Variant Requirements in
Domain Models. Proceedings of 5-th International Symposium on Requirements Engineering,
RE’01. Toronto, Canada 2001.
7. 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. Toronto, Canada
2001.
8. 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. ACM Press 2002.
9. 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.
10. XML-based Variant Configuration Language – Download Site,
http://sourceforge.net/project/showfiles.php?group_id=58966
11. Using the Rose Extensibility Interface. Rational Software Corporation 2001,
http://www.cs.rhul.ac.uk/CompSci/Computers/rational/pdf/rose_REI_guide/Rose_REI_guide.pdf
12. Traczyk T.: Rozproszona heterogeniczna baza danych wspierająca budowę wielkiego eksperymentu fizyki wysokich energii. W ramach pracy zbiorowej pod redakcją S. Kozielskiego i in.:
Bazy danych. Modele, technologie, narzędzia. Wydawnictwa Komunikacji i Łączności 2005.
pl
s.
22

pobierz plik referatu

Transkrypt

Podobne dokumenty

projektowanie obiektowe i modelowanie z użyciem uml

Podstawy UML

Zmiana opcji formularza wyboru rodzaju lekcji

dr inż. Ryszard Myhan Nazwa przedmiotu: Techniki programowania

Stanisław Bajor

Modelowanie w języku UML (kod: UML1)

Laboratorium 3 Diagramy klas — Różnice między kompozycją a

Technologie internetowe

Książki dla studentów kierunku „geodezja i kartografia”

OCUP-F/TOPDS Warsztat przygotowujący do egzaminu OMG UML