Alicja KILIŃSKA-WIŚNIEWSKA Politechnika Koszalińska, Wydział Elektroniki i Informatyki E-mail: alicja.kilinska.wisniewska@gmail.com Metodologie projektowania rozproszonych baz danych w języku UML 2.0 1. Wstęp Obecnie większość instytucji, przedsiębiorstw oraz osób prywatnych korzysta z rozproszonych systemów baz danych. Ich przezroczystość zapewnia, że większość z nas nie ma nawet pojęcia o tym w jak dużym stopniu technologia ta jest rozpowszechniona i wykorzystywana. Zakładając konto na portalu społecznościom rzadko zastanawiamy się nad tym w jaki sposób zamieszczane tam przez nas dane są przechowywane. Przezroczystość rozproszonych systemów bazodanowych sprawa, że wszystko to dzieje się poza naszą świadomością. Nikt z nas nie jest już w stanie sobie nawet wyobrazić jak dzisiaj funkcjonowałyby takie portale gdyby działały na zasadach systemów z lat 90. Wymagania użytkowników w obrębie rosnących ilości danych i czasu dostępu do nich wymuszają na twórcach systemów przygotowywanie nowych rozwiązań. Powstaje wiele nowatorskich technologii proponowanych przez profesjonalne firmy i naukowców z całego świata. Przykładem może być choćby największy i najpopularniejszy ośrodek naukowo - badawczy w Europie CERN (Europejska Organizacja Badań Jądrowych), gdzie od wielu lat trwają prace badawcze nad rozproszonymi bazami danych i ich zastosowaniami w praktyce. Wszechobecny kryzys i popularnie zwany pęd do pieniądza sprawił, iż większość firm tworzących oprogramowanie skupia się na szybkości jego tworzenia i niezawodności, a mniejszy nacisk kładzie na samo zaprojektowanie takiego systemu. W wielu przypadkach skutkuje to późniejszymi problemami z integracją z systemami innych producentów, co oczywiście naraża użytkownika na zbędne koszty. 2. Motywacja W swojej pracy naukowej i również zawodowej nie raz zetknęłam się z niechęcią twórców i administratorów rozproszonych systemów bazodanowych do stosowania jakichkolwiek metodologii projektowania. Skutkowało to w ujęciu długofalowym dużymi problemami z wprowadzaniem zmian w takich systemach i z usuwaniem zaistniałych problemów. Wynika to z faktu, iż samo pojęcie metodologii w odniesieniu do systemów bazodanowych jest traktowane z ogromną niechęcią, jako niepotrzebna i czasochłonna fanaberia. Podczas badań nad szybkością przetwarzania zapytań w ewoluujących silnikach bazodanowych zastanowił mnie fakt, iż brak ogólnych metodologii projektowania systemów bazodanowych, na których prowadziłam badania znacznie spowolnił moją pracę, a w niektórych przypadkach był wręcz ogromną przeszkodą we wprowadzaniu modyfikacji.
92 Alicja Kilińska-Wiśniewska 3. Metodologie projektowania Obecnie nie istnieje ogólnie przyjęty schemat projektowania rozproszonych systemów bazodanowych w ujęciu modelowania dziedziny problemu. Jako wykładnię do poszerzenia tego tematu można przyjąć język UML. Jest on szeroko stosowany w projektowaniu nie tylko systemów informatycznych, ale można nim opisać również zagadnienia o charakterze transportowym, ekspedycyjnym, a nawet i produkcyjnym. Stosowanie pojęcia język jest tutaj dosyć szeroko interpretowane, gdyż sam język UML, jako sam w sobie nie istnieje, jest to zestaw diagramów projektowych. Z całą pewnością można stwierdzić, że jest to swoisty język diagramowy. Metodologia sama w sobie ma za zadanie wspomagać projektowanie w dziedzinie problemu poprzez dostarczanie projektantowi niezbędnych pojęć, modeli, języków i sposobów postępowania. Stosuje się ją powszechnie podczas projektowania fizycznego jak i logicznego stąd można mówić o jej wszechstronności w dziedzinie projektowania. Jednym z charakterystycznych cech metodologii jest fakt, iż składa się z ona z jasno wydzielonych faz, z których każda charakteryzuje się odrębną charakterystyką. Każda z faz posiada wymagania, które muszą być przestrzegane przez użytkownika. Należy jasno sformułować role uczestników modelowanego problemu, scenariusz postępowania, reguły, po których spełnieniu jedna faza zostanie zakończona tak, aby możliwe było przejście do następnej. Muszą również istnieć modele, które powinny być stworzone po przejściu do następnej fazy oraz dokumentacja, która ma być wynikiem przejścia przez wszystkie fazy. Szczególną jednak uwagę należy zwrócić na fakt, iż w metodologii jest przyjęta notacja, której bezwzględnie należy przestrzegać, gdyż wspomaga ona proces myślenia oraz pomaga projektantowi wszystko logicznie poukładać. 4. Opis metodologii Od początku XX wieku metodologie zostały zdominowane poprzez paradygmat projektowania obiektowego i język UML jako fizyczne rozwinięcie. Język UML jest językiem tworzenia wzorów oraz dokumentacji projektowej, jest językiem wizualizacji. Jako sam w sobie zaistniał w 1995 roku i był wynikiem połączenia metodologii G.Boocha, I.Jacobsona i J.Rumbaugha. Od 2003 roku oficjalnie istnieje jego wersja 2.0 i jest ona wspierana i rozwijana przez organizację OMG (Object Management Group). Język UML 2.0 zawiera w swoim standardzie trzynaście diagramów, które służą do opisu i zamodelowania systemu od jest elementów najbardziej szczegółowych do najogólniejszych. Diagramy można podzielić na dwie główne grupy, abstrakcyjne i konkretne. Diagramy abstrakcyjne uogólniają diagramy konkretne pod kątem nazewnictwa. Jako diagramy abstrakcyjne możemy zatem wymieć diagramy dynamiki, interakcji, wdrożeniowe oraz ogólnie diagramy UML, natomiast do diagramów konkretnych należą diagram klas, diagram obiektów, diagram pakietów, diagram struktur, diagram komponentów, diagram przypadków użycia, diagram czynności, diagram maszyny stanowej, diagram sekwencji, diagram komunikacji, diagram harmonogramowania oraz diagram sterowania interakcją. Diagramy stosowane w języku UML można podzielić również pod kątem interakcji na statyczne i dynamiczne, który został przedstawiony na Rys. 1.
Metodologie projektowania rozproszonych baz danych w języku UML 2.0 93 Rys. 1. Podział diagramów w języku UML 2.0 Fig. 1. Breakdown diagrams in UML 2.0 Dziedzina problemu i model problemu badanej rozproszonej bazy danych opisane zostaną na przykładzie diagramu klas, przypadków użycia i sekwencji. Należy więc zadać sobie pytanie, czy lepiej zamodelować już istniejącą bazę danych i na tej podstawie wprowadzać unowocześnienia i poprawki czy zamodelować taką bazę ponownie od podstaw za pomocą metodologii i ją wdrożyć. Który ze sposobów jest mniej pracochłonny i wymaga mniejszych nakładów. Pierwsza myśl, która się nasuwa to fakt iż łatwiej z pewnością będzie opisać coś co już istnieje, niestety należy liczyć się z faktem, że napotkane przeszkody mogą w znacznym stopniu spowolnić prace projektowe jak i je w całości uniemożliwić, co jest argumentem popierającym pracę nad systemem od podstaw. Rys. 2. Rozkład serwerów modelowanego systemu rozproszonego Fig. 2. Distribution of modeled servers distributed system Badana baza znajduje się na pięciu serwerach bazodanowych oddalonych od siebie fizycznie (Rys. 2). Zachowana została w niej przezroczystość, tak więc użytkownik nie zna dokładnie położenia poszczególnych danych.
94 Alicja Kilińska-Wiśniewska 5. Schemat postępowania w projektowaniu systemów rozproszonych Twórca systemu, aby zachować pełną spójność musi pracować zgodnie z ustalonym schematem działania, tak aby system był w pełni spójny i tak aby w każdym momencie możliwe było wprowadzenie poprawek do systemu. Najistotniejszym elementem w sferze projektowej jest ustalenie problemu i jego dziedziny. Jest to nic innego jak określenie wymagań jakie musi spełniać projektowana baza oraz opisanie jej schematu podziału pomiędzy rozproszone jednostki. Na Rys. 3. został przedstawiony ogólny model postępowania jakim powinien kierować się twórca systemu rozproszonego. Projektant w każdym momencie pracy nad projektem może powrócić do dziedziny problemu i zadać sobie nowe pytania lub ponownie przeanalizować problem. W przypadku gdy twórca nie stosuje narzuconej ogólnej metodologii projektowania efektem tego mogą być błędy wykryte już w fazie wdrożenia systemu, które z powodzeniem mogły zostać usunięte podczas określania dziedziny problemu. Rys. 3. Schemat tworzenia systemu rozproszonego Fig. 3. Scheme to create a distributed system
Metodologie projektowania rozproszonych baz danych w języku UML 2.0 95 Model przedstawiony na powyższym może zostać zaimplementowany również podczas tworzenia lokalnego systemu bazodanowego. W przypadku systemu rozproszonego należy skupić się na dziedzinie i modelu problemu, gdyż elementy opracowane na tym etapie trwale i niezmiennie będą wpływały na dalszy proces pracy nad systemem. 6. Dziedzina problemu Dziedzina problemu określa wymagania względem systemu, który ma zostać stworzony. Zostają one ustalone na podstawie: Użytkowników systemu Administratorów systemu Ograniczeń sprzętowych Ograniczeń programistycznych Jest to etap, którego wynikiem powinno być wyobrażenie projektanta zawierające wymagania oraz ograniczenia względem projektowanego systemu. Aby wykonać model problemu projektant musi być do tego gruntownie przygotowany, aczkolwiek model przewiduje późniejszy powrót do dziedziny modelu. Jeżeli zaistnieją fakty wcześniej nieujawnione przez przyszłych użytkowników i administratorów bazy danych lub okaże się, że sprzęt lub programistyczne aspekty nie są w stanie sprostać oczekiwaniom projektanta i przyszłych użytkowników. Jednak to w gestii projektanta zawsze pozostaje ustalenie wszystkich istotnych informacji, tak aby ewentualne powroty do etapu dziedziny problemowej występował jak najrzadziej. W badanej bazie rozproszonej istniejącej na pięciu odrębnych serwerach rozmieszczonych w różnych miastach, dziedzinę problemową można określić przy pomocy tabeli wymagań użytkowników i tabeli ograniczeń systemu. W Tabeli 1 została przedstawiona przykładowa specyfikacja dla trzech typów użytkowników z wymaganiami pod kątem danych, na których mogą operować w systemie. Tab. 1. Wymagania użytkowników i ograniczenia systemu Tab. 1. User requirements and constraints of the system Osoby - użytkownicy Wymagania Dane Administrator Użytkownik uprzywilejowany Zapis Odczyt Modyfikacja Usuwanie Zapis Odczyt Modyfikacja Pełny zestaw tabel Ograniczony zestaw tabel Użytkownik Odczyt Ograniczony zestaw tabel Zazwyczaj projekty wykonywane przez projektantów są o wiele bardziej złożone, mimo tego schemat określenia dziedziny problemu musi być elastyczny i sprawdzać się w przypadku małych jak i dużych systemów bazodanowych. W przypadku ograniczeń sprzętowych projektant musi znać parametry serwerów na których będzie funkcjonował
96 Alicja Kilińska-Wiśniewska rozproszony system bazodanowy. W tym wypadku należy stworzyć tabelę wymagań i ograniczeń sprzętowych, w której to powinien zostać wyszczególniony sprzęt komputerowy z jego konfiguracją oraz wymagania, które ma spełnić sprzęt. Na końcu projektant ocenia czy poszczególne elementy spełnią narzucone wymagania.natomiast ograniczenia programistyczne dotyczą ściśle technologii, w której będzie realizowany system. Oczywistym jest, że niektóre wymagania i oczekiwania przyszłych użytkowników systemu mogą być niemożliwe do zrealizowania w narzuconej technologii, rozwiązaniem może być zaproponowanie innej technologii lub zmodyfikowanie tego elementu w sposób realizowalny. Twórca systemu powinien sobie zdawać sprawę z tego problemu już na samym początku tworzenia bazy danych. Po określeniu wszystkich składowych dziedziny problemowej i stworzeniu zarysu myślowego modelu problemu, możliwe jest przystąpienie do części tworzenia modelu problemu przy pomocy języka modelowania obiektowego. 7. Model problemu Jedną z najistotniejszych faz tworzenia systemów bazodanowych przy pomocy modelowania obiektowego opartego na UML jest zaprojektowanie i przygotowanie samego modelu problemu. Jest to jedyna faza, w której stosuje się język UML i tej części powinien projektant poświęcić najwięcej uwagi, gdyż wszystkie elementy pominięte w tym etapie mogą uwidocznić się w momencie testowania, a nieraz dopiero podczas wdrożenia systemu. Dobrze przygotowany model problemu pozwala się później łatwo i szybko modyfikować. W tym przypadku wskazane jest korzystanie z języka UML. 7.1. Diagram przypadków użycia Aby przedstawić możliwości pracy z system dla użytkownika należy zamodelować problem przy pomocy diagramu przypadków użycia. Użytkownik jest przedstawiany jako aktor, pomiędzy nim, a przypadkami użycia bazy danych zachodzą związki. Wszystkie zależności odbywają się w danej dziedzinie przedmiotowej. Stosując ogólny diagram przypadków użycia można prześledzić jak w najogólniejszej postaci powinno wyglądać przedstawienie modelu problemu projektowanej bazy danych. Na tym etapie widać, że projektant nie uwzględnia rozproszenia systemu, gdyż użytkownik nie będzie tego świadomy podczas korzystania z poszczególnych rozproszonych tabel i danych w nich zawartych.
Metodologie projektowania rozproszonych baz danych w języku UML 2.0 97 Rys. 4. Diagram przypadków użycia dla modelu problemu Fig. 4. Use case diagram for the model problem 7.2. Diagram klas W metodologii funkcjonuje pojęcie obiektu, które jest określeniem pojedynczego bytu. Na niego składają się identyfikator, stany oraz zachowanie. Zachowanie może wpływać na stan obiektu. Zbiór obiektów charakteryzujący się wspólnym zachowaniem funkcjonuje jako klasa. Każdy obiekt, który należy do klasy nazywany jest instancją. Aby zapewnić całkowitą spójność obiekty oraz klasy połączone są pomiędzy sobą wspólnymi zależnościami, które zależą od relacji jakie pomiędzy nimi zachodzą. Możemy wyróżnić trzy typy relacji, jeden do jednego, jeden do wielu i wiele do wielu. Poszczególny typy relacji charakteryzują ile obiektów lub klas jest zależnych od siebie i ma na siebie wpływ. Diagram klas obok diagramu przypadków użycia jest kluczowym i najczęściej stosowanym diagramem w języku UML, opiera się podobnie jak w powszechnie znanych językach programowania na obiektach, które są opisywane przez atrybuty i operacje. Służy on głównie do przedstawienia elementów statycznych i deklaratywnych, które są ściśle związane z modelem problemu oraz związków, które zachodzą pomiędzy poszczególnymi klasami. Jego statyczna budowa stanowi podstawę obiektowej bazy danych. Jego zawartość wpływa znacznie na zawartość innych diagramów w języku UML. Na podstawie przeprowadzonych analiz oraz badań opracowany został ogólny model klas rozproszonej bazy danych. Model przedstawia podstawowy zarys obiektów połączonych wspólnymi relacjami. Może być rozbudowywany o dodatkowe modyfikacje użytkowników lub administratorów. Każdy obiekt określony jest przez atrybuty i operacje. Nadrzędny obiekt administrator może wpływać na pozostałe obiekty. Projektant może odwzorować system w wybranej technologii.
98 Alicja Kilińska-Wiśniewska Rys. 5. Ogólny model klas rozproszonej bazy danych Fig. 5. A general model of distributed database classes Rozproszenie bazy danych zostało ukryte w obiekcie ZestawTabel. Administrator, Użytkownik uprzywilejowany i użytkownik nie są tego świadomi. Aby móc przeanalizować rozproszenie trzeba wgłębić się budowę i zamodelować ten obiekt. Jest to porównywalne do budowy atomu, gdy przyjrzymy mu się z bliska zauważymy, że składa się z jądra i elektronów. Model zachowuje zasadę atomowości. Takie przedstawienie modelu rozproszonej bazy danych pozwala projektantowi spojrzeć na całość modelowanego problemu, jego percepcja nie zostaje rozproszona przez zbytnią ilość zbędnych szczegółów. 7.3. Diagram sekwencji Decyzja o przedstawieniu modelu problemu przy pomocy diagramu sekwencji podyktowana była między innymi faktem iż jest to najczęściej stosowany w praktyce diagram ze wszystkich diagramów interakcji w języku UML. Diagram ten wynika bezpośrednio z diagramu przypadków użycia i można swobodnie określić, że jest on jego częścią funkcjonalną. Wszystkie akcje zostają rozłożone w ramach czasowych przedstawionych przy pomocy pionowych osi czasu. Operacje w diagramie sekwencji przebiegają chronologicznie. W rozproszonym systemie na poziomie podstawowym modelowanie diagramu sekwencji przebiega analogicznie do systemu jednorodnego. Na Rys. 6. został przedstawiony opracowany ogólny schemat bazy danych i udziału użytkowników z różnym poziomem uprawnień. Diagram został zaprojektowany w taki sposób, aby twórca systemu miał możliwość dodania dodatkowych użytkowników z różnym poziomem uprawnień. Diagram może być dowolnie rozbudowywany w tym zakresie. W tym przypadku również została zastosowana zasada atomowości diagramu modelowanego problemu. Tak więc
Metodologie projektowania rozproszonych baz danych w języku UML 2.0 99 aby projektant mógł pracować nad modelem rozproszonego systemu musi zagłębić się w szczegóły wybranej części modelu ogólnego. Rys. 6. Diagram sekwencyjny modelu problemu postać ogólna Fig. 6. Sequence Diagram of model problem general form Dla zobrazowania tego schematu działania wybrany został użytkownik administrator, który wysyła żądanie interakcji z danymi z systemu. Pojęcie interakcji z danymi w tym przypadku służy do ogólnego opisania przypadków użycia tego użytkownika, które zostały przedstawione za pomocą diagramu przypadków użycia. System weryfikuje jakie uprawnienia posiada użytkownik wysyłający żądanie i na tej podstawie opracowuje poziom dostępnych danych. Po poprawnej weryfikacji uruchamia koordynatora, który zarządza rozproszonymi danymi w systemie i jego zadaniem jest rozesłanie zapytania do poszczególnym serwerów i zebranie otrzymanych odpowiedzi. Koordynator prześle otrzymane odpowiedzi jedynie w sytuacji gdy wszystkie serwery odpowiedzą poprawnie na zadane zapytanie. Wyklucza to sytuację awarii jednego lub więcej serwerów i otrzymania w ten sposób uszkodzonych lub niekompletnych danych, co w rezultacie da fałszywy wynik żądanych danych przez użytkownika. Jeżeli wszystko przebiegnie poprawnie użytkownik otrzyma żądane dane. Opisany schemat działania został przedstawiony na Rys.7. Wprowadzanie pojęcia zestawu tabel pozwala oddzielić część rozproszoną diagramu. Diagram staje się bliższy rzeczywistości, gdyż zadaniem projektanta systemu jest ukryć przed użytkownikiem faktyczne rozproszenie danych.
100 Alicja Kilińska-Wiśniewska Rys. 7. Diagram sekwencyjny modelu problemu postać z uwzględnieniem rozproszenia danych Fig. 7. Sequence Diagram model of the problem - including the form of distributed data
Metodologie projektowania rozproszonych baz danych w języku UML 2.0 101 8. Wnioski Opracowane ogólne modele dziedziny problemu i model problemu przy pomocy diagramów języka UML mogą zostać wdrożone podczas tworzenia rozproszonego systemu bazodanowego. Twórca korzystając z ogólnego modelu poprzez modyfikacja w zakresie użytkowników może rozbudowywać dowolnie budowany projekt. System później może zostać odwzorowany w dowolnie wybranej technologii, co może wykluczyć problemy w heterogenicznymi bazami danych. W momencie przejścia na inną technologię projektant przekształca model i przenosi potrzebne dane. Jest to rozwiązanie szybsze i w mniejszym stopniu obarczone problemem zgodności technologii. Literatura 1. G. Booch, J. Rumbaugh, I. Jacobson The Unified Modeling Language User 2. Guide, Addison Wesley, First Edition 1998. 3. G. Booch, J. Rumbaugh, I. Jacobson The UML Reference Manual 2nd Edition, Addison-Wesley, 2004. 4. Muller R.J. Bazy danych. Język UML w modelowaniu danych, Mikom, 2000. 5. Rosenberg D., Scott K. Use Case Driven Object Modeling with UML, Addison- Wesley, 1999. 6. Schmuller J. UML dla każdego, Helion, 2004. 7. Scott K. Fast Track UML 2.0, Apress, 2004. 8. Subieta K. Obiektowość w projektowaniu i bazach danych, Oficyna Wydawnicza, 1998. Streszczenie Artykuł przedstawia metodologię ogólnego opracowywania modeli rozproszonych systemów bazodanowych przy pomocy języka UML 2.0. Opracowanie podstawowego modelu systemu rozproszonego zgodnie z przedstawionym modelem problemu. Opracowywanie modeli w oparciu o skalowanie na zasadzie atomowości. Rozpatrzenie modelu rozproszonego systemu w podziale na ogólny zarys funkcjonalności i dokładne określenie rozproszenia systemu. Methodologies for the disign of distributed data-bases in uml 2.0. Summary This paper presents a general method for developing models of distributed database systems using UML 2.0. Development of the basic model of a distributed system as shown in the model problem. The development of models based on the scaling on the basis of atomicity. Consideration of a distributed system model, divided into an overview of the functionality and the precise dispersion of the system.
102 Alicja Kilińska-Wiśniewska