Alicja KILIŃSKA

Transkrypt

Alicja KILIŃSKA
Alicja KILIŃSKA-WIŚNIEWSKA
Politechnika Koszalińska, Wydział Elektroniki i Informatyki
E-mail: [email protected]
UML i Executable UML
1. Wstęp
Na samym początku należałoby krótko scharakteryzować potrzebę stosowania modelowania przy użyciu języków typu UML podczas tworzenia rozproszonych systemów.
Obecnie rozwijający się rynek korporacji wymusza na deweloperach oraz użytkownikach końcowych korzystanie z różnych systemów klienckich do projektowana i zarządzania bazami danych. Każda korporacja posiada własny zaimplementowany system
oparty zwykle na innym systemie niż inne korporacje. Nie jest to czymś złym dopóki
nie zaistnieje potrzeba komunikacji i przesyłania danych pomiędzy tymi systemami.
Podobna sytuacja może zaistnieć podczas gdy jedne konsorcjum wykupuje drugie konsorcjum i przejmuje jego cały system informatyczny wraz z wdrożonym systemem.
Uzyskamy wtedy sytuację w której główne centrum firmy będzie musiało korzystać
z dwóch odrębnych systemów baz danych, np. Microsoft SQL Server i Oracle Database.
W takim przypadku mamy do czynienia z heterogenicznymi rozproszonymi bazami
danych. Obecnie nie odnaleziono rozwiązania jak w prosty i nie ingerencyjny sposób
łączyć ze sobą dwa lub więcej rozproszone heterogeniczne systemy bazodanowe, aczkolwiek pewne problemy, które mogą wystąpić w przyszłości można już wykluczyć na
etapie samego projektowania systemu dla jednego konsorcjum przy założeniu, że kiedyś
może zaistnieć potrzeba połączenia tego systemu z innym. Stwarza to duże pole manewru i doskonałe możliwości do rozwoju języków modelowania i do badania ich zastosowań podczas modelowania rozproszonych systemów bazodanowych. Artykuł został poświęcony budowie i zastosowaniu języka xUML oraz językowi UML w wersji
2.0, gdyż prace nad starszymi wersjami nie są już wspierane przez konsorcjum OMG.
2. UML wprowadzenie
Język UML powstał w listopadzie 1997 roku w połączeniu prac trzech naukowców
Jamesa Rumbaugha, Grady’go Boocha oraz Ivara Jacobsona. Każdy z nich już wcześniej próbował opracować język graficzny który pozwalałby w prosty i intuicyjny sposób przedstawić programiście wymagania projektowanego systemu, jednak dopiero po
połączeniu ich sił powstał język UML, który do dzisiaj jest standardem i obecnie jest
już w wersji 2.0. Został on oficjalnie uznany poprzez konsorcjum OMG , które podjęło
się prowadzenia jego dalszego rozwoju.
3. Motywacja UML
Język UML został przyjęty entuzjastycznie przez grono projektantów i programistów,
gdyż przedstawia on potrzeby i wymagania w sposób nie związany z żadnym środowi-
56
Alicja Kilińska-Wiśniewska
skiem programistycznym. Projekty są tworzone w sposób graficzny, co pozwala je później przenieść sprawnie na każdą platformę językową. Przede wszystkim jednak istotną
kwestią stało się samo modelowanie przed przystąpieniem do pracy, gdyż programiści
już na starcie pracy byli w stanie wykluczyć większość błędów które mogłyby w późniejszym czasie znacznie spowolnić prace nad projektem.
Każda część przedstawionego problemu w sensie projektowanego systemu lub aplikacji
może zostać rozpatrzona pojedynczo, a następnie złożona w większą całość, projektant
lub programista ma możliwość dopracowywania pojedynczych elementów systemu nad
którym pracuje, aby finalnie móc je połączyć w jeden kompletny system.
4. UML charakterystyka
Projektanci korzystający z języka UML mają w zasięgu szereg modeli, które mogą być
zastosowane, aby przedstawić budowę systemu pod kątem obiektu jak i zamodelować
zachowanie systemu w ramach czasowych. I tak diagramy dla ich lepszego zrozumienia
pod kątem wykorzystania można podzielić na dwie kategorie:
•
•
diagramy struktury, niezależne od czasu,
diagramy dynamiki, istniejące w ramach czasowych.
Poniższy schemat prezentuje podział diagramów języka UML pod kątem wykorzystania
w ramach czasowych.
Rys. 1. Podział diagramów w języku UML 2.0
Fig. 1. Division diagrams in UML 2.0
Najczęściej stosowanymi diagramami są diagram klas oraz diagram przypadków użycia.
Diagram klas jest graficznym przedstawieniem statycznych i deklaratywnych elementów dziedziny przedmiotowej oraz związków pomiędzy nimi, natomiast diagram przypadków użycia jest graficznym przedstawieniem przypadków użycia, aktorów oraz
związków między nimi występujących w danej dziedzinie przedmiotowej.
UML i Executable UML
57
5. xUML wprowadzenie
Język executable UML w skrócie nazywany xUML wywodzi się z języka UML w jego
wersji 1.x. Został stworzony na potrzeby grupy programistów i projektantów MMC
(The Modular MissionComputer), która zajmowała się pracami nad samolotami
F-16 (miała pozwolić na wykonanie wymogów tzw. misji 21-go wieku). Aktualizacje
MMC w połowie zapewniają zwiększoną moc obliczeniową samolotu pod względem
awioniki oraz systemów uzbrojenia. Oryginalnie zespół korzystał podczas pracy nad
aktualizacjami z narzędzi CASEi ręcznym kodowaniem w ADA. Lecz o wiele wydajniejszy okazał się język xUML który wyłonił się podczas prac i dalsza część projektu
była już kontynuowana przy pomocy narzędzia Kennedego Cartera – iUML. Zespół
zyskał możliwość korzystania z języka UML który umożliwiał sprawdzenie zachowania
modeli przed wprowadzeniem ich ręcznego kodowania.
6. Motywacja xUML
Przy pomocy języka xUML możliwe jest programowanie i debugowanie na wyższym
poziomie abstrakcji niż wcześniej. Z utworzonych diagramów można bezpośrednio
wygenerować kod elementu który jest tworzony. Tworzone modele są możliwe do
przetestowania i mogą być kompilowane przy pomocy języka w którym docelowo
mają zostać stworzone. Jedną z najważniejszych cech języka xUML jest fakt, że
znacznie obniża on koszty rozwoju oprogramowania, między innymi dzięki temu iż
jest on crossplatform czyli nie jest on związany ściśle z żadnym językiem programowania, platformą ani technologią. Eliminuje to pracochłonne zadanie opracowywania
przejścia z PIM (Platform-Independent Model) do PSM (Platform-Specific Model).
ExecutableUML umożliwia łatwą wymianę i ponowne stworzenie projektu za pomocą
standardu UML. Jest swoistym uzupełnieniem wieloletniej luki pomiędzy specyfikacją przestrzeni problemu, a samą realizacją problemu za pomocą narzędzi programistycznych. Ponieważ działania są bezpośrednio określone w języku, proces generowania kodu jest o wiele bardziej wydajny i przewidywalny niż byłoby to w przypadku
zwykłego generatora kodu. W przypadku tworzenia dziedziny problemu w systemach
rozproszonych to rozwiązanie jest idealne, gdyż pozwala zaprojektować system,
a następnie odtworzyć jego odwzorowanie z postaci graficznej w dowolnie wybranym
języku programowania. Programista tworząc system jest świadomy faktu, iż jeżeli
zaistnieje potrzeba to z gotowego wdrożonego już systemu z modelu można wygenerować ten sam system w innej technologii, jest to mniej pracochłonne niż tworzenie
systemu od podstaw. W przypadku połączenia systemu heterogonicznego może to być
doskonałym rozwiązaniem o wiele mniej pracochłonnym niż żmudne prace nad opracowaniem schematu działania tych systemów.
7. xUML charakterystyka
ExecutableUML powstał z pierwszej wersji UML z którego zostały usunięte jego słabe
semantyczne części, a dodane elementy definicji akcji semantycznych. UML w wersji
1.x nie jest językiem wykonywalnym ponieważ jest semantycznie niekompletny, dopie-
58
Alicja Kilińska-Wiśniewska
ro wprowadzenie do niego akcji semantycznych na wyższym poziomie abstrakcji uczyniło go wykonywalnym (executable UML).
Rys. 2. Graficzna reprezentacja definicji xUML
Fig. 2. Graphical representation ofthe definitionxUML
xUML jest ściśle zorientowaną obiektowo metodą rozwijania systemu, która oparta jest
na zasadzie budowy precyzyjnych modeli testowo-analitycznych. Wykonywanie określonych testów na stworzonych modelach oraz określenie strategii semantycznej skutkuje wybraniem odpowiedniego modelu do stworzeniasystemu docelowego.
Charakterystyczne dla xUML są kompletne modele analizy, które mogą być testowane
za pomocą symulacji, dzięki którym można przeprowadzać kompletne testy systemu.
Tworzone są w prostej notacji, które może być zrozumiana przez każdego. W xUML
można odnaleźć diagramy języka UML: diagram przypadków użycia, diagram klas,
diagram sekwencji, diagram stanów oraz diagram współpracy. Rysunek 3 przedstawia
model komponentów xUML.
Rys. 3. Model komponentów języka xUML.
Fig. 3. Components model in xUML.
Diagram przypadków użycia opisuje wymagania projektowanego systemu we wstępnej
fazie jego projektowania. Składa się z aktorów, przypadków użycia i relacji zachodzących pomiędzy nimi. Jest częścią statyczną i został wprowadzony do xUML, ponieważ
dokładnie realizuje schematy postępowania dla każdego przewidzianego scenariusza.
Jest istotnym elementem podczas wyznaczania wymagań dla wykonywalnej części
projektowanego systemu.
Do opisu statycznej struktury systemu wykorzystywany jest diagram klas. Składa się on
z obiektów, które opisane są przez swoje atrybuty, operacje i zależności zachodzących
pomiędzy poszczególnymi obiektami. W przypadku xUML wykluczone zostają różnice
pomiędzy związkami asocjacyjnymi, ponieważ model rozpatrywany jest na poziomie
UML i Executable UML
59
dynamicznym. Diagram aktywności jest stosowany do opisania poszczególnych akcji
w modelu xUML. Diagram ten nie opisuje całości zachowań przewidzianych dla systemu, lecz tylko wybrane jego części. Diagramy te mogą dostarczyć projektantowi wielu
użytecznych informacji takich jak przepływ pracy.
Kolejnym elementem xUML jest diagram stanów przejściowych, który opisuje aspekty
zachowania obiektów należących do tej samej klasy. Składają się z pseudostanów, stanów i przejść, które opisują cykl życia poszczególnych obiektów. Ponadto zawierają
akcje, które mogą być w kilku stanach: wejście w pewien stan, wyjście z pewnego stanu, przejście pomiędzy poszczególnymi stanami oraz kontynuację akcji w pewnym
stałym stanie.
Rys. 4. Wykonywalny i możliwy do przetłumaczenia model rozwoju UML.
Fig. 4. Translatable and executableUMLmodeldevelopment
Projektowanie systemu w xUML odbywa się w trzech etapach: modelowanie systemu,
zamodelowanie domeny, weryfikacja i uruchomienie modelu. W pierwszym etapie
należy przede wszystkim zdefiniować dziedzinę problemu i określić ją przy pomocy
diagramu przypadków użycia. Aczkolwiek projektant ma zawsze możliwość powrotu do
tego etapu i wprowadzenie niezbędnych poprawek. W drugim etapie projektowana jest
domena, na którą składają się klasy określające tą domenę. Dla każdej klasy projektowany jest następnie diagram stanów. Projektowanie samego modelu domeny odbywa
się w sposób iteracyjny, jest to podyktowane tym iż niektóre wymagania dla już wcześniej zaprojekowanych klas otrzymuje się po zaprojektowaniu klas następnych. W trzecim i zarazem ostatnim etapie następuje weryfikacja i wykonanie. Weryfikacja modelu
odbywa się w podziale na dwa aspekty, statyczny oraz dynamiczny. Statyczna analizuje
poprawność składni modelu, dynamiczna natomiast obiekty i relacje zawarte w nim.
Jest to najważniejszy etap, który również jest powtarzany w sposób iteracyjny aby wykluczyć wszystkie błędy. Następnie diagramy xUML są przekształcane w kod źródłowy
za pomocą translatora.
8. Wnioski
Metodologia UML może być z powodzeniem zastosowana podczas projektowania heterogenicznych rozproszonych systemów bazodanowych. Projektant otrzymuje możliwość przetestowania stworzonego systemu bazodanowego, który może być później
odwzorowywany w dowolnie wybranej technologii.
Alicja Kilińska-Wiśniewska
60
Wprowadzenie projektowania w metodologii xUML daje projektantowi systemów jeszcze większe możliwości, gdyż uniezależnia go od przekazywania modelu do programisty. xUML daje możliwość przekształcenia zaprojektowanego modelu bezpośrednio do kodu źródłowego i do prowadzenia na nim testów, których wynikiem będzie
w pełni sprawny system bazodanowy.
xUML jest obiecującą metodologią, która doskonale odwzorowuje abstrakcyjność projektowanego systemu.
Literatura
1.
2.
3.
4.
5.
6.
Kennedy C.: Supporting Model Driven Architecture with eXecutable UML, 2002, Kennedy Carter Limited.
Kennedy C.: Configurable Code Generation in MDA using iCCG, 2002, Kennedy
Carter Limited.
Booch G., Rumbaugh J., Jacobson I.: The Unified Modeling Language User Guide,
Addison Wesley, First Edition Oct 20, 1998.
Mellor S. J.: Executable UML A foundation for Model Driven Architecture, 2002
OMG. Action Semantics for the UML. OMG, 2000.
www.knowgravity.com/eng/value/cassandra.htm
Streszczenie
Artykuł ma na celu przedstawienie aspektów modelowania rozproszonego środowiska
bazodanowego w ujęciu heterogenicznym przy zastosowaniu języka UML (Unified Modeling Language) i jego potomka xUML (Executable UML). W zależności od wybranego
podejścia przedstawienie jego implementacji do modelu rozproszonego. W artykule zostanie przedstawione wprowadzenie do języka UML oraz xUML historia języków oraz ich
specyfikacja. ExecutableUML jest podstawowym kryterium w modelowaniu MDA (Model DrivenArchitekture) Jest to nowe podejście do tworzenia specyfikacji i aplikacji na
podstawie modelu niezależnie od platformy na której ten system ma funkcjonować.
UML and Executable UML
Summary
Article is to present aspects of modeling a distributed database environment in terms of
heterogeneous using UML (Unified Modeling Language)and its descendant xUML (Executable UML). Depending on the approach to present its implementation into a distributed model. The article will be provided an introduction to UML and xUML history of
languages and their specifications. Executable UML is a key criterion in modeling MDA
(Model Driven Architecture) is a new approach to creating specifications and applications
based on the model regardless of the platform on which this system is to function.

Podobne dokumenty