AUTOMATYKA " 2006 " Tom 10 " Zeszyt 3
Paweł Skrzyński*
Język UML 2.0 w modelowaniu relacyjnych baz danych
1. Wprowadzenie
Proces projektowania systemów relacyjnych zwyczajowo przebiega przez trzy etapy:
1) modelowanie konceptualne,
2) modelowanie logiczne,
3) modelowanie fizyczne.
WiększoSć klasycznych metod modelowania dostarcza wsparcia głównie w pierw-
szych dwóch etapach. Model konceptualny stanowi specyfikację modelu logicznego i opi-
suje dziedzinę systemu oraz jego funkcjonalnoSć. Model logiczny, który rozważamy w tym
artykule, jest modelem relacyjnym. Model konceptualny jest zazwyczaj przedstawiany
w postaci diagramu ERD, podczas gdy na model logiczny składają się relacje czyli tabele
systemu relacyjnego. Transformacja pomiędzy tymi dwoma metodami jest dosyć oczywista
i szybka, jednak właSciwie na tym kończy się jakiekolwiek wsparcie dla projektantów.
Z drugiej strony diagram klas UML jest używany właSciwie we wszystkich etapach
pracy nad modelem od fazy analizy, poprzez projektowanie, szczegółowe projektowanie
itd. Oprócz tego istnieje możliwoSć generowania nawet działającego kodu z modelu UML,
a w literaturze można się spotkać z terminem executable UML . Żeby móc utworzyć wy-
konywalny model należy oczywiScie oprócz zamodelowania statycznej perspektywy syste-
mu dostarczyć specyfikacji zachowania. Specyfikacja zachowania może odbywać się po-
przez definiowanie stanów maszyny stanowe lub bez nich poprzez modelowanie ciała
operacji/metody.
W obydwu przypadkach zachowanie można opisywać poprzez:
maszynę stanową na diagramie stanów,
tekstowy opis na diagramie tekstowym,
diagram czynnoSci.
Diagramy czynnoSci pokazują przepływ sterowania od czynnoSci do czynnoSci i są
bardzo przydatne w modelowaniu procesów biznesowych lub modelowaniu ciała metod.
Należą do grupy dynamicznych diagramów UML. Ich zadanie polega na ogół na przedsta-
* Katedra Automatyki, Akademia Górniczo-Hutnicza w Krakowie
559
560 Paweł Skrzyński
wieniu sekwencyjnych (rzadziej współbieżnych) kroków procesu obliczeniowego i to
ich zastosowanie jest najciekawsze z punktu widzenia tego artykułu. Można na nim przed-
stawić również zmiany zachodzące w obiekcie, gdy przechodzi z jednego stanu do drugie-
go [1].
Jak widać, mogą one stanowić doskonałe uzupełnienie diagramu klas diagram klas
okreSla atrybuty klasy/obiektu oraz, poprzez metody, zachowania, jakich możemy oczeki-
wać od obiektów danej klasy, jednak nie mówi nic o sposobie implementacji metod, co
natomiast może być modelowane na diagramach czynnoSci. Metody stanowią specyfikację
usług jakie klasa udostępnia innym klasom, więc w pewnym sensie stanowią definicję pro-
tokołu komunikacji w systemie. Jednak informacja ta jest całkowicie gubiona w prostej
transformacji Encja-Klasa.
Jak wiadomo, w systemach relacyjnych, w języku SQL, możemy implementować nie
tylko statyczną częSć systemu w postaci relacyjnych tabel, ale również operacje, które za-
chodzÄ… na danych. Odbywa siÄ™ to poprzez procedury wbudowane (stored procedures)
i funkcje, które są również przechowywane w bazie danych. Pomimo iż używa się ich od
kilku lat i są bardzo popularne, wydajne oraz pozwalają na lepszą modularyzację systemów,
właSciwie nie ma dla nich żadnego wsparcia na etapie modelowania. Artykuł przedstawia
pewne cechy języka UML, które czynią go przydatnym do modelowania relacyjnych baz
danych nie tylko na etapie konceptualnym i logicznym ale również fizycznym.
Artykuł jest zorganizowany następująco: rozdział 2 przedstawia state of art w łącze-
niu UML z systemami relacyjnymi, rozdział 3 przedstawia możliwoSci użycia diagramów
czynnoSci do modelowania procedur wbudowanych, rozdział 4 prezentuje zastosowania
proponowanego podejScia na przykładzie prostego forum dyskusyjnego. Ostatnia częSć sta-
nowi podsumowanie.
2. State of art
Relacyjny modela danych jest w dalszym ciÄ…gu najpopularniejszym logicznym mode-
lem służącym do reprezentowania rzeczywistoSć a konkretniej jej fragmentów zależ-
nych od dziedziny problemu modelowanego systemu. Pomimo że model jest popularny,
istnieje mnóstwo dostawców systemów relacyjnych, dowiódł swojej przydatnoSci w ty-
siącach aplikacji, to jednak stwarza on pewne problemy. Największy z nich wiąże się
z reprezentowaniem rzeczywistych obiektów w tym formalizmie każdy obiekt, taki jak
samochód, osoba, budynek itp., nie jest przechowywany w jednej relacji, lecz jest rozpro-
szony na kilka lub kilkanaScie relacji, które są ze sobą powiązane. Sytuację tę opisuje rysu-
nek 1.
PodejScie takie jest kłopotliwe, ponieważ ludzki umysł postrzega rzeczywistoSć taką,
jaka jest a nie poprzez pryzmat jej składowych. WiększoSć ludzi mySli o budynku, samo-
chodzie, fabryce jako całoSci, a nie rozważa ich jako połączonych okien, drzwi itd. Kon-
sekwencją tego jest to, że projektant musi na początku dokonać mapowania rzeczywistych
obiektów na zbiór tabel, co może nie tylko sprawić kłopot początkującym projektantom,
lecz co ważniejsze, powodować zaburzenie integralnoSci danych.
Język UML 2.0 w modelowaniu relacyjnych baz danych 561
Rys. 1. Model relacyjny i model obiektowy
Na podobne problemy natrafia się również podczas implementacji. Przez ostatnie lata
głównym paradygmatem był paradygmat obiektowy. Zatem warstwa biznesowa i prezenta-
cji posługują się często paradygmatem obiektowym, natomiast warstwa danych relacyj-
nym. Prowadzi to do pewnych rozbieżnoSci w modelu częSć obiektowa była modelowana
z użyciem UML, natomiast warstwa danych przy użyciu ERD. Często zachodzi potrzeba
prezentacji w warstwie biznesowej danych z relacyjnego modelu potrzebne jest zatem
dostarczenie odpowiedniego mapowania (rys. 2), co powoduje oczywiScie zwiększenie na-
kładu, czasu oraz jest potencjalnym xródłem błędów.
Rys. 2. Mapowanie pomiędzy językiem programowania a systemem relacyjnym
Wprawdzie mapowanie przedstawione na rysunku 2 jest częSciowo robione przez plat-
formy developerskie, jednak nie likwiduje to potrzeby tworzenia dwóch modeli obiekto-
wego dla aplikacji i relacyjnego dla danych. Konsekwencją tego jest to, że w dalszym ciągu
562 Paweł Skrzyński
w warstwie aplikacji jednemu obiektowi odpowiada kilka połączonych tabel z warstwy da-
nych.
CzęSciowym rozwiązaniem takich problemów może być posługiwanie się w warstwie
danych obiektowÄ… bazÄ… danych lub systemami hybrydowymi jednak jak wspomniano, nie
są one tak popularne i efektywne jak systemy relacyjne. Przewaga systemów relacyjnych
jest osiągana dzięki:
silnym fundamentom matematycznym (logika);
językowi SQL, który jest prosty, potężny i bardzo popularny;
OLTP przetwarzaniu transakcji on-line.
Dodatkowo istnieją czynniki ekonomiczne, które sprawiają, że jeszcze przez długie
lata systemy relacyjne będą tworzone. Wszystko to sprawia, że jest silna potrzeba tworzenia
metod pozwalajÄ…cych na generacjÄ™ danych relacyjnych z modelu aplikacyjnego.
Ponieważ UML jest właSciwie przemysłowym standardem, oczywiste zatem jest, że
duża częSć badań powinna koncentrować się na transformacji modelu UML do postaci
systemu relacyjnego. Jednym z najważniejszych diagramów UML jest diagram klas za-
wiera on klasy, dzięki którym póxniej tworzone są obiekty reprezentujące rzeczywistoSć
one z kolei powinny być mapowane do postaci tabel relacyjnych. W związku z tym,
dotychczasowe badania [3, 5] skupiajÄ… siÄ™ na metodach generowania tabel na podstawie
informacji dostarczanych przez klasy. Generalne zasady, jakie wynikają z tych badań, doty-
czÄ…ce transformacji klasy z modelu konceptualnego do tabeli z modelu logicznego sÄ… nastÄ™-
pujÄ…ce:
R1. Każda klasa z modelu konceptualnego jest transformowana do tabeli relacyjnej
o tej samej nazwie.
R2. Atrybut klasy jest transformowany do kolumny tabeli o tej samej nazwie (jeSli jest
możliwe mapowanie od typu atrybutu do typu kolumny).
R3. Tabeli zostaje przypisany klucz główny ze zbioru kluczy kandydujących, które
powinny być brane pod uwagę przy modelowaniu konceptualnym. Klucze niewy-
brane jako klucz główny powinny spełniać więzy SQL: UNIQUE.
R4. Binarna asocjacja typu wiele-do-wielu jest transformowana do relacyjnej tabeli.
Klucz główny tej tabeli składa się z kluczy głównych tabel powstałych z transfor-
macji klas wchodzących w skład asocjacji.
R5. Generalizacja jest reprezentowana jako klucz obcy (który jest równoczeSnie klu-
czem głównym jego wartoSć identyfikuje jednoznacznie rekord w tabeli repre-
zentujÄ…cej nadklasÄ™).
IstniejÄ… jednak jeszcze alternatywne sposoby odwzorowania generalizacji:
R5b. Tworzenie osobnych tabeli dla każdej nadklasy i klasy potomnej.
R5c. Tworzenie osobnej tabeli tylko dla klas potomnych.
R5d. Tworzenie jednej tabeli dla całej hierarchii klas.
Każde z tych podejSć ma pewne wady polegające między innymi na wprowadzaniu
redundantnych danych do tabel.
Język UML 2.0 w modelowaniu relacyjnych baz danych 563
Sposoby generowania tabel relacyjnych z klas modelu obiektowym były już zdefinio-
wane dla UML w wersji 1.x. W kontekScie nowej wersji języka zaproponowane kilka cie-
kawych rozszerzeń przedstawionego sposobu transformacji. Rozszerzenia te wykorzystują
nowe cechy języka takie jak power-types (nie ma jeszcze przyjętego odpowiednika polskie-
go tego pojęcia), nowe specyfikatory końców asocjacji ({set},{bag},{list})) oraz rozszerze-
nie pojęcia generalizacji o jej typy [6]:
{disjoint} dowolny obiekt nadklasy może być instancją co najwyżej jednej pod-
klasy,
{overlapping} dowolny obiekt nadklasy może być instancją dwóch lub więcej podklas,
{complete} każdy obiekt nadklasy musi być instancją przynajmniej jednej podklasy,
{incomplete} dowolny obiekt nadklasy może nie być instancją dowolnej podklasy.
Bazując na tych właSciwoSciach zaproponowane zostały nowe reguły transforma-
cji [3]. Rozważając typ asocjacji {bag}, regułę R4 można zmodyfikować następująco:
S1. Asocjacja binarna wiele-do-wielu jest transformowana do tabeli relacyjnej. Klu-
czem głównym tej tabeli jest sztuczny klucz a kluczami obcymi są klucze główne
tabel reprezentujących klasy z końców asocjacji.
Transformacja generalizacji zależy teraz od modyfikatorów. Najciekawsze są wła-
SciwoSci: {complete}, {incomplete, overlapping}, {incomplete, disjoint}, {com-
plete, overlapping}, {complete, disjoint}, a reguły transformacji dla nich są nastę-
pujÄ…ce:
S2. Nadklasa z jedną podklasą i właSciwoScią {complete} jest reprezentowana przez
jedną tabelę, której kolumny stanowią atrybuty obydwu klas.
S3. Nadklasa z wieloma podklasami i właSciwoScią {incomplete, overlapping} jest
transformowana zgodnie z regułą R5 osobna tabela dla każdej podklasy. Wszyst-
kie te tabele powinny mieć taki sam klucz główny.
S4. Nadklasa z wieloma podklasami i właSciwoScią {incomplete, disjoint}, jak wyżej
z dodatkową właSciwoScią: zbiór wartoSci kluczy głównych tabel dla różnych
podklas musi być rozłączny.
S5. Transformacja nadklasy z wieloma klasami potomnymi i właSciwoScią {complete,
disjoint}zależy od tego czy podklasa jest powiązana z innymi klasami. JeSli nie
jest wtedy stosowana jest reguła S2 z dodatkowym warunkiem: zbiór wartoSci
kluczy głównych reprezentujących różne podklasy musi być rozłączny. W innych
przypadkach stosuje się regułę S4 z dodatkowym warunkiem: każdy wiersz w ta-
beli reprezentujący nadklasę jest referencjonowany dokładnie przez jeden klucz
obcy jednej z tabel reprezentujÄ…cych podklasÄ™ [3].
Jak widać, pewne reguły transformacji zostały zaproponowane już dla UML 1.x (regu-
ły R1 R4), a następnie dodane zostały pewne szczegóły bazujące na nowych cechach UML
2.0 (reguły S1 S5). W rozdziale 3 autor proponuje kolejne reguły bazujące na diagramach
czynnoSci, które biorą pod uwagę dynamiczne aspekty działania systemu.
564 Paweł Skrzyński
3. Modelowanie zachowania
3.1. Symbole na diagramach czynnoSci
Diagramy czynnoSci posiadają symbol decyzyjny, który umożliwia modelowania zło-
żonych algorytmów za ich pomocą. Inne symbole, które pojawiają się na tych diagramach to:
symbol czynnoSci reprezentowany przez prostokÄ…t z zaokrÄ…glonymi rogami;
symbol sygnału kiedy czynnoSć wiąże się z wysłaniem lub odebraniem sygnału, wte-
dy nazywana jest sygnałem (signal);
rozwidlenie i złączenie do modelowania czynnoSci współbieżnych;
aktywnoSć początkowa i końcowa
3.2. Reguły transformacji
Jak wspomniano w rozdziale 2, klasy sÄ… transformowane do relacyjnych tabel nato-
miast atrybuty do kolumn. Jednak klasy zawierają oprócz atrybutów tez metody, dla któ-
rych nie dostarczono żadnej transformacji. Najbardziej intuicyjną transformacją jest trans-
formacja ich do procedur wbudowanych i/lub funkcji, ponieważ zarówno procedury wbu-
dowane, jak i metody służą do wykonywania operacji na danych. Jedynym problemem jest
ich zakres: metody są związane z klasą, natomiast procedury wbudowane z całym syste-
mem, a nie z pojedynczą tabelą. Aby zapobiec zatem konfliktom nazw (metody różnych
klas mogą się nazywać tak samo), autor proponuje prefiksowanie nazwy procedury nazwą
tabeli/klasy. Zatem nowa reguła mogła by wyglądać następująco:
R6. Metody klasy sÄ… transformowane do procedur wbudowanych przy czym nazwa
procedury to nazwa metody poprzedzona nazwÄ… klasy ze znakiem podkreSlenia.
Diagram kIas
sygnatury metod
Diagram czynnoSci Diagram czynnoSci
dIa dIa
metody 1 metody N
Diagram tekstowy Diagram tekstowy Diagram tekstowy Diagram tekstowy
& ... & ...
dIa dIa dIa dIa
CzynnoSci 1 CzynnoSci M CzynnoSci 1 CzynnoSci K
Procedura Procedura
wbudowana wbudowana
dIa metody 1 dIa metody N
Rys. 3. Generowanie kodu SQL z diagramów czynnoSci
Język UML 2.0 w modelowaniu relacyjnych baz danych 565
Aby modelować ciało operacji, można się posłużyć diagramami czynnoSci, na podstawie
których póxniej może zostać wygenerowany kod SQL. Innymi słowy, można wprowadzić
dodatkową warstwę abstrakcji pomiędzy sygnaturę operacji z diagramu klas a wykonywalny
kod aplikacji, który bazuje na diagramach czynnoSci. Dzięki temu model staje się bardziej
czytelny i ułatwione jest przejScie od projektu konceptualnego do fizycznej implementacji.
Autorowi nie są znane żadne nowoczesne narzędzia CASE, które umożliwiałyby ge-
nerowanie kodu proceduralnego w SQL (większoSć narzędzi ma możliwoSć generowania
kodu w popularnych językach programowania takich jak Java czy C++) oczywiScie
transformacja taka jest bardziej złożona od transformacji do języka obiektowego. W związ-
ku z tym można zaproponować ominięcie tego problemu bazujące na diagramach teksto-
wych. Diagram taki może zawierać dowolny tekst, w tym kod SQL i powinien być kojarzo-
ny z każdą czynnoScią na diagramie (rys. 3).
4. Przykład
Omawiana metodologia zostanie zastosowana do prostego systemu forum dyskusyjne-
go dla zarejestrowanych użytkowników. Każdy użytkownik jest opisany poprzez następują-
ce atrybuty: imię, nazwisko, login, hasło. Natomiast każdy post poprzez: tytuł, datę wysła-
nia, autora, zawartoSć oraz informację o tym, na jaki post jest odpowiedzią, jeżeli nie jest
nowym wątkiem (każdy post może mieć wiele odpowiedzi natomiast sam może być oczy-
wiScie odpowiedziÄ… na tylko jeden post macierzysty).
Przykładowy system może zostać zamodelowany na diagramie klas przedstawionym
na rysunku 4.
Author
authorID: Integer
firstName: String
lastName: String
login: String
password: String
addAuthor(id: Integer, aLName : String, aFName : String, aLogin : String, aPassword : String): Boolean
0..* author
PostAuthor
1 post
Post
Post
postID : Integer
postID: Integer
postTitle: String
postParent postChild
postTitle: String
postDate:Time
10..* postDate:Time
Parent
postContent: String
postContent: String
author: Author[1]
author: Author[1]
postParent: Post[1]
postParent: Post[1]
addPost ( id : Integer, authorID : Integer, d : Time, cont : String, tit : String)
getNrOfAncestors ( id : Integer)
Rys. 4. Forum dyskusyjne diagram klas
566 Paweł Skrzyński
Stosując dla tego diagramu omówione reguły transformacji, można wygenerować na-
stępujący kod SQL tworzący schemat bazy danych:
CREATE TABLE Author (
authorID INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
firstName VARCHAR(45),
lastName VARCHAR(45),
login VARCHAR(45),
password VARCHAR(45),
PRIMARY KEY(authorID)
);
CREATE TABLE Post (
postID INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
parentID INTEGER UNSIGNED,
authorID INTEGER UNSIGNED,
postTitle VARCHAR(255),
postContent TEXT,
PRIMARY KEY(postID),
INDEX Post_FKIndex1(authorID),
INDEX Post_FKIndex2(parentID),
FOREIGN KEY(authorID)
REFERENCES Author(authorID)
ON DELETE SET NULL
ON UPDATE SET NULL,
FOREIGN KEY(parentID)
REFERENCES Post(postID)
ON DELETE CASCADE
ON UPDATE CASCADE
);
Transformacja ta jest dosyć prosta i szeroko omawiana w literaturze. Jednak diagram
klas z rysunku 4 niesie ze sobą więcej informacji. definiuje przynajmniej trzy operacje:
dwie proste do dodawania autora i posta oraz jedną bardziej złożoną do pobierania liczby
odpowiedzi na podanego posta. Operacja addAuthor odpowiada za dodanie nowego autora
do systemu i zwraca true w przypadku powodzenia i false w przypadku przeciwnym. Se-
kwencyjne kroki tego procesu można opisać tak:
1. zdefiniuj obsługę jakichkolwiek wyjątków, które mogą wystąpić;
2. wykonaj insert na tabeli relacyjnej;
3. zwróć true, jeSli insert się udał, i false, jeSli nie lub wystąpiły wyjątki.
Przykładowy diagram czynnoSci dla tego procesu przedstawia rysunek 5.
Język UML 2.0 w modelowaniu relacyjnych baz danych 567
Define handler for SQL exception
SQL Insert Author
WystÄ…pienie wyjÄ…tku
Success Failure
Rys. 5. Diagram czynnoSci dla dodania nowego autora
Rysunek ten jest czytelny i łatwy dorozumienia. ChcielibySmy jednak mieć możliwoSć
generowania kodu SQL z tego diagramu. Opisana przez autora metodologia polega na do-
daniu do każdej czynnoSci diagramu tekstowego z kodem SQL. Zatem diagram dla czynno-
Sci Define_handler_for_sql_exception mógłby zawierać taki kod:
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
select «Can not add author;
SET success = false;
END;
Natomiast dla aktywnoSci activity SQL_Insert_Author następujący:
INSERT INTO Author(authorID, firstName, lastName, login, password)
VALUES
(id, fname, lname, login, pass);
568 Paweł Skrzyński
W końcu kod dla aktywnoSci Success :
SET success = true;
select «Author added;
Aby wygenerować z tego diagramu pełny kod procedury powinniSmy przetwarzać
czynnoSci w kolejnoSci, w jakiej pojawiajÄ… siÄ™ na diagramie przetwarzanie takie polega na
konkatenowaniu kodu z kolejnych diagramów tekstowych. Zatem pełen kod procedury (sy-
gnatura jest generowana na podstawie sygnatury metody z diagramu klas dodany zostaje
tylko prefiks z nazwą tabeli) może wyglądać następująco (dialekt DB2):
CREATE PROCEDURE Author_addAuthor (id INT, fname VARCHAR(45),
lname VARCHAR(45), login VARCHAR(45), pass VARCHAR(45), OUT
success Boolean)
BEGIN
#Activity: DECLARE EXIT HANDLER FOR SQLEXCEPTION
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
select «Can not add author;
SET success = false;
END;
#Acitivity END
#Activity: SQL_Insert_Author
INSERT INTO Author(authorID, firstName, lastName, login,
password) VALUES (id, fname, lname, login, pass);
#Acitivity END
#Activity: Success
SET success = true;
select «Author added;
#Acitivity END
END;
Jak widać, dodatkowym wyjSciem, jakie powinno być generowane przez narzędzie
CASE, są komentarze informujące o tym gdzie się zaczyna, a gdzie kończy dana aktyw-
noSć/czynnoSć. Przedstawiona metoda jest elegancka i pozwala szybko zrozumieć kod SQL
reprezentujący nawet bardzo złożone algorytmy. Kolejny przykład reprezentuje właSnie
bardziej złożony algorytm (z rekursją) pobierania liczby odpowiedzi na dany post (rys. 6).
Kod, który może zostać wygenerowany z takiego diagramu (jeżeli zostaną z każdą
czynnoScią skojarzone diagramy czynnoSci) może wyglądać następująco:
CREATE PROCEDURE getNrOfAncestors (Post_ID INT, OUT nr INT)
BEGIN
#Activity: Define_cursor_for_direct_ancestors
DECLARE id, noMoreRows, children INT;
DECLARE cur_1 CURSOR FOR
SELECT postID, parentID FROM Post WHERE parentID=Post_ID;
#Activity END
#Activity: Define_handler_for_not_found
Język UML 2.0 w modelowaniu relacyjnych baz danych 569
DECLARE CONTINUE HANDLER FOR NOT FOUND SET noMoreRows = 1;
#Activity END
#Activity: Open_Cursors
OPEN cur_1;
set nr = 0;
#Activity END
#LOOP
WHILE noMoreRows = 0 DO
#Activity: Get_Next_Child_Post
FETCH cur_1 INTO id;
set nr = nr + 1; #increment for current child
#Activity END
#Activity: Recursively_call_this_method&
call getNrOfAncestors (id, children);
set nr = nr + children; #increment for children of current child
#Activity END
END WHILE;
#LOOP END
#Activity: Return_result
CLOSE cur_1;
#Activity END
END;
Define_cursor_for_direct_ancestor
Define_cursor_for_direct_ancestor
Define_handler_for_not_foun
Define_handler_for_not_foun
d
d
Open_cursors
Open_cursors
[false]
[false]
Cursor_Has_More_Row Return_result
Cursor_Has_More_Row Return_result
[true]
[true]
Get_next_child_post
Get_next_child_post
Recursively_call_this_method_to_increment_return_valu
Recursively_call_this_method_to_increment_return_valu
Rys. 6. Pobieranie liczby odpowiedzi na post diagram czynnoSci
570 Paweł Skrzyński
4.1. Inżynieria wstecz
Jak wspomniano wczeSniej, jeżeli narzędzie CASE generuje odpowiednie komentarze
z informacją o początku i końcu czynnoSci, to umożliwia to inżynierię wstecz.
5. Podsumowanie
W artykule zostało zaprezentowane podejScie integracji języka UML z systemami re-
lacyjnych baz danych. Zaprezentowana metoda pozwala na generowanie kodu SQL z dia-
gramów UML (klas i czynnoSci) definiującego nie tylko schemat bazy danych, ale również
zachowanie systemu: algorytmy i operacje na danych.
Dalsze badania powinny się skupić na:
dodaniu do istniejących wybranych narzędzi CASE funkcjonalnoSci pozwalającej na
generowanie kodu SQL bezpoSrednio z diagramów czynnoSci,
użyciu innych typów diagramów do transformacji np. diagramów stanów wspoma-
gajÄ…cych diagramy czynnoSci przy modelowaniu operacji.
Literatura
[1] Booch G., Rumbaugh J., Jacobson I.: The Unified Modeling Language User Guide. Addison-
Wesley, 1998
[2] Douglass B.P.: Real-Time UML. Developing Efficient Objects for Embedded Systems. Addison-
Wesley, 1998
[3] Hnatkowska B., Huzar Z., Tuzinkiewicz L.: Data Modelling with UML 2.0. IOS Press, 2005
[4] Klimek R., Skrzyński P., Turek M.: UML i Telelogic Tau Generation2. Materiały dydaktyczne
2005
[5] Naiburg E., Maksimchuk R.: UML for Database Design. Addison-Wesley, 2001
[6] OMG: Unified Modeling Language: Superstructure version 2.0. 2004
Wyszukiwarka
Podobne podstrony:
01 Projektowanie relacyjnej bazy danych Czym jest relacyjhelion relacyjne bazy danych2004 11 Porównanie serwerów relacyjnych baz danych Open Source [Bazy Danych]Bazy Danych relacyjne czy obiektowe2009 02 Relacyjna baza danych HSQLDB [Bazy Danych][03] Bazy Danych Relacyjny Model DanychBAZY DANYCH Streszczenie z wykładówStrona polecenia do bazy danychMySQL Mechanizmy wewnętrzne bazy danychBazy danych w CADPostać normalna (bazy danych) – Wikipedia, wolna encyklopediawięcej podobnych podstron