1.tworzenie systemu z wykorzystaniem współpracujących maszyn

INŻYNIERIA OPROGRAMOWANIA W PROCESACH INTEGRACJI SYSTEMÓW INFORMATYCZNYCH
Pod redakcją J. Górskiego, C. Orłowskiego, 2010
PWNT Gdańsk
1.TWORZENIE SYSTEMU Z WYKORZYSTANIEM
WSPÓŁPRACUJĄCYCH MASZYN STANOWYCH
Anna DEREZIŃSKA∗, Marian SZCZYKULSKI∗
1. Wprowadzenie
W procesie konstruowania systemów informatycznych istotną rolę odgrywa modelowanie, które
służy do abstrakcyjnego opisu systemu i ma na celu ułatwienie inżynierowi pracy nad jego
tworzeniem. Rozwój technologiczny powoduje zainteresowanie coraz to bardziej
skomplikowanymi systemami oraz implikuje wzrost liczby problemów do rozwiązania.
Przykładem takich systemów jest realizacja mobilnych usług przeznaczonych dla całych
społeczności użytkowników w sieci Internet. Wykonanie tych usług zależy od zmieniających się
w czasie i przestrzeni relacji pomiędzy członkami społeczności oraz różnych informacji
określających ich kontekst.
W jednym z podejść do procesu budowy systemu określonym jako inżynieria oparta na
modelu, w skrócie MDE (ang. Model Driven Engineering) [4], kluczową rolę odgrywa tworzenie
modeli oraz proces ich przekształcania. Poszczególne modele dotyczą wydzielonych fragmentów
systemu. W miarę postępu prac nad tworzonym systemem ulegają one kolejnym transformacjom
w celu ich uszczegółowienia, łączenia i stworzenia ostatecznego modelu w postaci konkretnej
implementacji systemu. Dzięki takiemu podejściu integracja systemu złożonego z różnych
współpracujących podsystemów może być przedstawiana i częściowo weryfikowana już we
wczesnych etapach projektowania systemu.
Niniejszy rozdział prezentuje wytwarzanie aplikacji oparte na maszynach stanowych UML
specyfikujących zachowanie klas. Przykład studialny dotyczy serwera obecności dla modelu
predefiniowanych statusów obecności w usługach społecznościowych [3].
Do generacji kodu z modeli UML użyto narzędzia FXU (ang. Framework for eXecutable
UML) [1,10]. Generator FXU wykorzystuje diagramy klas oraz stanów w celu utworzenia
wykonywalnej aplikacji zaimplementowanej w języku programowania C#. Generacja kodu jest
∗
Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut Informatyki, e-mail:
[email protected]; [email protected].
Prawa Autorskie: Materiał był opublikowany przez PWNT w książce lub elektronicznym wydaniu książki pod
tytułem: „Inżynieria Oprogramowania w Procesach Integracji Systemów Informatycznych”. Możliwe jest zrobienie
jednej kopii bądź wydruku tylko i wyłącznie do użytku własnego. Wielokrotne kopiowanie w celach komercyjnych,
bądź modyfikowanie treści materiału jest zabronione. http://konsulting.gda.pl/pwnt.html
2
A. Derezińska, M. Szczykulski
realizowana zgodnie z szablonami generacji. FXU zapewnia pełną transformację maszyn
stanowych na kod języka C#.
2. Model serwera obecności
Serwer obecności jest centralną częścią mobilnego serwisu społecznościowego. Poniżej
przedstawiono podstawowe pojęcia związane z realizacją serwisu, a następnie informacje o
modelowaniu serwera obecności.
2.1. Podstawowe pojęcia
Społeczność jest to zbiór mobilnych użytkowników sieci o zróżnicowanych zmiennych
relacjach. W serwisach obsługujących społeczność występują usługi kontekstowe. Kontekst
dotyczy własności członków społeczności, jak również terminali, czy też aplikacji. Składowe
kontekstu mogą być bardzo różnorodne i istotna jest ich odpowiednia selekcja i filtrowanie.
Opis użytkowników sieci może być wyrażony zgodnie ze schematem formatowania FOAF
(ang. Friend of a Friend). Specyfikacja FOAF opiera się na składni XML i strukturze RDF (ang.
Resource Description Framework) – standardzie służącym do reprezentacji informacji w sieci.
Usługa obecności w ramach serwisu społecznościowego określa czy dany użytkownik jest
aktualnie obecny w sieci, jaki jest jego status, możliwości komunikacyjne jego terminala,
lokalizacja itp. Podstawowym zadaniem omawianej usługi jest filtrowanie informacji o
obecności, zależne od różnych relacji pomiędzy użytkownikami.
Jednym ze standardów wspierającym obsługę obecności jest protokół inicjowania sesji SIP
(ang. Session Initiation Protocol). SIP został zaproponowany przez IETF jako otwarty standard
dla zestawiania sesji pomiędzy jednym lub wieloma klientami. IETF (ang. Internet Engineering
Task Force) jest stowarzyszeniem zajmującym się standardami technicznymi i organizacyjnymi
służącymi współdziałaniu w Internecie. W dokumencie [11] przedstawiono wykorzystanie
protokołu SIP do subskrypcji i przesyłania powiadomień związanych z obecnością.
IMS (ang. Internet Protocol Multimedia Subsytem – multimedialny podsystem IP) jest
środowiskiem, które powstało w celu udostępniania użytkownikom multimedialnych usług
opartych na protokole Internetowym. W pracy [3] przedstawiono implementację serwera
obecności realizującego wybrane funkcje usługi społecznościowej z wykorzystaniem protokołu
SIP w środowisku IMS. Do przetestowania tego zadnia użyto emulatora środowiska IMS. W
niniejszym rozdziale omawiamy rozwiązanie alternatywne, w którym najpierw zbudowano
model serwera obecności, a następnie przetransformowano go do postaci kodu.
2.2. Wymagania systemu
Głównym zadaniem systemu jest stworzenie użytkownikowi możliwości publikacji statusu na
serwerze, jego zmiany oraz odczytywania statusu znajomych. Status jest rozumiany jako
informacja o dostępności danego użytkownika oraz jego kontekst. Kontekst to możliwości
komunikacyjne, lokalizacja, nastrój, aktualnie wykonywane czynności i wiele innych.
Użytkownicy są ze sobą dodatkowo powiązani zależnościami, które z kolei mogą dzielić się na
kategorie np. rodzina, przyjaciele, znajomi itp. Wynikowy status subskrybowanego użytkownika
jest pochodną jego aktualnego statusu oraz relacji w jakiej jest z tym użytkownikiem.
Tworzony model UML obejmuje tylko serwer obecności, który znajduje się w centrum
całego systemu i którego zadaniem jest realizacja logiki biznesowej. Działanie serwera obejmuje
trzy podstawowe zagadnienia:
• subskrypcja statusu innego użytkownika (ang. SUBSCRIBE),
• publikacja nowego statusu wraz z określonymi dla niego regułami ( ang. PUBLISH),
• wysyłanie powiadomienia o statusie innego użytkownika (ang. NOTIFY).
1. Tworzenie systemu z wykorzystaniem współpracujących maszyn stanowych
3
Użytkownik rejestruje się bezpośrednio na serwerze SIP, gdzie jest przechowywana
informacja o jego statusie. Jeżeli inny użytkownik (obserwator) zażąda subskrypcji jego statusu,
komunikuje się z serwerem obecności wysyłając żądanie SUBSCRIBE. Serwer obecności
komunikuje się z serwerem SIP pobiera jego status i analizuje reguły znajdujące się na serwerze
XCAP (ang. XML Configuration Access Protocol), określające status wynikowy na podstawie
rzeczywistego statusu oraz relacji pomiędzy użytkownikami.
Rys. 1.
Przypadki użycia systemu serwera obecności
Wyróżniono cztery główne przypadki użycia serwera obecności (Rys. 1):
• Publikowanie informacji o obecności (ang. Status Publication) – polega na udostępnieniu
różnych informacji o obecności poszczególnym osobom z listy kontaktów, według
warunków utworzonego wcześniej predefiniowanego statusu.
• Subskrypcja do informacji o obecności (ang. Status Subscription) – jest to żądanie
otrzymania informacji o stanie obecności obserwowanego obiektu.
• Usuwanie subskrypcji (ang. Delete Subscription) – polega na wyrejestrowaniu się
użytkownika z usługi i oznacza, że nie chce on być już informowany o zmianach
statusów innych użytkowników ze swojej listy kontaktów.
• Utworzenie predefiniowanego statusu (ang. Status Creation) – polega na utworzeniu
predefiniowanego statusu dostępności sterującego udostępnianą informacją o obecności.
2.3. Architektura systemu
System został podzielony na trzy główne warstwy: komunikacji z klientem, kontrolera oraz
komunikacji z innymi systemami. Ogólna architektura systemu składa się z czterech pakietów i
jest przedstawiona na Rys. 2.
Rys. 2.
Główne pakiety systemu serwera obecności
Pakiet clientConnector obsługuje żądania klientów. Żądania te są przechwytywanie, wstępnie
przetwarzanie i rozsyłanie do dalszej obsługi przez odpowiednie elementy znajdujące się w
pakiecie presenceAgentController. Pakiet ten zawiera elementy realizujące wymagania
4
A. Derezińska, M. Szczykulski
funkcjonalne serwera obecności. Komunikuje się on z innymi systemami poprzez następujące
adaptery zawarte w pakiecie systemAdapters:
• Adapter do serwera SIP, który przechowuje statusy użytkowników.
• Adapter do serwera XCAP, który udostępnia reguły umożliwiające uzyskiwanie statusu
obiektu mając daną relację pomiędzy obiektem, a obserwatorem. Podczas publikacji
nowego statusu serwer ten zapisuje nową regułę dla tego statusu.
• Adapter do serwera FOAF, który udostępnia relacje pomiędzy obiektami określone w
ontologii FOAF [3]. Są one niezbędne do odczytania statusu obiektu.
Czwarty pakiet utils zawiera elementy pomocnicze dla całego systemu.
2.4. Modelowanie działania serwera obecności
Działanie serwera obecności i jego współpraca z innymi podsystemami zostały zamodelowane
przy pomocy diagramów klas i stanów UML. Model systemu składa się z około dwudziestu klas
i interfejsów oraz siedemnastu maszyn stanowych. Maszyny stanowe określają zachowanie
poszczególnych klas. Główny pakiet systemu serwera obecności zawiera trzy klasy realizujące
podstawowe zadania serwera:
• klasa Publisher publikuje status użytkownika na serwerze SIP.
• klasa Subscriber dokonuje subskrypcji statusu użytkownika.
• klasa Notifier powiadamia o statusie innego użytkownika, którego zażądano subskrypcji.
Dla przykładu przedstawimy modele opisujące zachowanie dwóch klas z pakietu serwera
obecności, kluczowych ze względu na realizowaną funkcjonalność.
Obiekty klasy Publisher obsługują żądania PUBLISH klienta, czyli żądania publikujące
informację o jego obecności. Dla każdego żądania jest przeznaczony jeden obiekt tej klasy.
Diagram stanu tej klasy składa się z czterech stanów najwyższego poziomu (Rys. 3). W stanie
Preparation następuje przygotowanie danych do publikacji. Najpierw dane te są zbierane, potem
następuje walidacja danych, na podstawie których tworzony jest dokument mający zostać
opublikowany na serwerze SIP. Jeżeli utworzony dokument jest poprawny następuje przejście do
stanu złożonego Publication. W tym stanie serwer obecności komunikuje się z innymi
serwerami: XCAP, na którym umieszczone są reguły przetwarzania statusów oraz SIP, na
którym są publikowane aktualne statusy użytkowników. Jeżeli nastąpi błąd w połączeniu z
którymś z serwerów, wykonywana jest kolejna próba połączenia się z nimi do momentu aż nie
zostanie przekroczony licznik powtórzeń. Jeżeli komunikacja zakończyła się powodzeniem
zostaje wysłana odpowiedź do klienta, po czym obiekt przestaje istnieć. Wyróżnione stany
odpowiadają za obsługę sytuacji wyjątkowych związanych z możliwymi do wystąpienia
błędami. Źródłem błędów mogą być błędne dane lub błąd podczas komunikacji z serwerami SIP
i XCAP. W obu sytuacjach wysyłana jest odpowiedź do klienta z odpowiednim kodem błędu.
Obsługa żądań SUBSCRIBE klienta, czyli subskrypcja statusu innego użytkownika, jest
realizowana przez obiekty klasy Subscriber. Komunikacja ze zdalnymi serwerami odbywa się
poprzez warstwę adapterów. Subskrybowany status wysyłany jest do użytkownika za pomocą
notyfikacji wysyłanej przez obiekty klasy Notifier.
Diagram stanów (Rys. 4) definiuje działanie związane z subskrypcją statusu użytkownika. Po
inicjalizacji obiektu następuje walidacja parametrów wejściowych. Jeżeli parametry te są
poprawne automat przechodzi do stanu AdapterCommunication, w którym następuje połączenie
oraz pobranie danych z serwera SIP, czyli informacji o statusie użytkownika oraz serwera
FOAF, czyli informacji o relacji pomiędzy użytkownikiem subskrybującym status i
użytkownikiem, którego status jest subskrybowany. Komunikacja z tymi dwoma adapterami jest
niezależna i może nastąpić równolegle. Po otrzymaniu informacji od obu serwerów wyznaczany
jest ostateczny status. Wykonywane jest to zgodnie z regułami znajdującymi się na serwerze
XCAP. Następnie otrzymany status jest odfiltrowywany przez tzw. filtr obserwatora. Kolejnym
krokiem jest wysyłanie odpowiedzi. Równolegle wysyłany jest komunikat potwierdzenia
1. Tworzenie systemu z wykorzystaniem współpracujących maszyn stanowych
5
poprawnej subskrypcji oraz notyfikacja zawierająca subskrybowany status użytkownika. W
stanie CheckingStatus sprawdzane jest, czy nie wystąpił błąd podczas wysyłania odpowiedzi. W
osobnym stanie zaprojektowano realizację obsługi błędów.
Rys. 3.
Diagram stanów klasy Publisher
3. Technologia wytwarzania systemu
Inżynieria oparta na modelach (ang. MDE) potrzebuje narzędzi wspomagających ten proces. W
niniejszym rozdziale koncentrujemy się na możliwościach transformacji modeli
zaprojektowanych za pomocą języka UML, a zwłaszcza maszyn stanowych, w implementację z
użyciem języka programowania C#.
3.1. Generacja kodu C# z diagramów stanu w narzędziach CASE
Generacja kodu z diagramów klas jest możliwa w wielu narzędziach typu CASE dla różnych
języków programowania, w tym również w niektórych przypadkach dla języka C#. Niemiej
jednak generacja kodu z diagramów stanów jest możliwa tylko w przypadku wybranych
narzędzi. O ile generacja kodu z diagramów klas jest zadaniem stosunkowo prostym, to w części
specyfikacji dotyczącej diagramów stanów zawarte jest wiele niejasnych i nieprecyzyjnych
sformułowań. Występują tu tzw. warianty semantyczne (ang. semantic variation point), w
których specyfikacja UML pozostawia swobodę interpretacji [9].
Jeżeli wziąć pod uwagę język programowania to jednym z nielicznych przykładów
umożliwiających generację kodu z diagramów stanów i klas dla języka C# jest Enterprise
Architect [8]. Implementuje on jednak tylko podstawowe zagadnienia związane z diagramami
stanów UML i nie odwzorowuje ich pełnej semantyki. Nie jest generowany kod związany z
6
A. Derezińska, M. Szczykulski
realizacją pseudostanów, czy też wyzwalaczy przejść. Kod odwzorowujący realizację maszyn
stanowych jest umieszczony bezpośrednio w klasie, której ona dotyczy.
Jednym z najbardziej zaawansowanych narzędzi dostępnych na rynku, umożliwiających
kompletną generację kodu z diagramów stanów jest IBM Rational Rhapsody (dawniej firmy
Telelogic) [7]. Jest to komercyjne narzędzie do modelowania UML oraz SysML. Charakteryzuje
się wsparciem dla UML 2.1 oraz XMI 2.1. Umożliwia generację kodu zarówno z diagramów
klas jak i z diagramów stanów do języków C/C++, Java oraz Ada.
Realizację wszystkich elementów diagramów stanu UML 2.x w języku C#
zaimplementowano w systemie FXU (ang. Framework for eXecutable UML) [10]. FXU
wykorzystuje do generacji kodu diagramy klas i diagramy stanów UML. Cała logika maszyn
stanowych została umieszczona w specjalnej bibliotece (środowisku uruchomieniowym), a
generowany jest tylko odpowiedni kod związany z inicjalizacją automatu.
Rys. 4.
Diagram stanów klasy Subscriber
3.2. Architektura i działanie FXU
System FXU składa się z następujących składników:
• FXU Generator – generator kodu
• FXU Runtime Environment – środowisko uruchomieniowe maszyn stanowych
• FXU Application Wizard – narzędzie wspomagające budowę projektu
• FXU Tracer – narzędzie wspomagające śledzenie wykonania maszyn stanowych
Podstawową częścią systemu jest silnik generatora kodu, którego zadaniem jest statyczna
weryfikacja modeli i ich transformacja do postaci kodu [2,10]. Silnik obudowany został w
graficzny interfejs użytkownika. Środowisko uruchomieniowe FXU stanowi implementację
maszyn stanowych UML wykonaną w języku programowania C#. Poszczególne elementy
diagramów stanów zostały zaimplementowane, jako osobne klasy. Realizują one odpowiednie
1. Tworzenie systemu z wykorzystaniem współpracujących maszyn stanowych
7
zachowania tych elementów, ale również obsługują sytuacje nieprawidłowe, wykrywając błędy
na poziomie analizy dynamicznej. Automat w takiej sytuacji może zakończyć swoje działanie,
może też nastąpić wyjście z aktualnego regionu lub zachowanie może być nieokreślone. W
każdej z wymienionych sytuacji odpowiednia informacja o wykrytym błędzie zapisywana jest w
pliku logów.
W celu stworzenia wykonywalnej aplikacji z użyciem FXU należy najpierw stworzyć model
UML w jednym z narzędzi CASE. W przypadku omawianego serwera obecności wykorzystano
IBM Rational Software Architect 7.5 [6]. Kolejnym etapem jest eksport modelu do formatu EMF
2.4.1 (ang. Eclipse Modeling Framework) [5] zgodnego ze standardem XMI 2.1.
Tworzenie systemu z wykorzystaniem FXU składa się z następujących etapów:
1. Wczytanie i walidacja modelu UML
2. Generacja kodu C#
3. Generacja projektu dla środowiska Microsoft Visual Studio 2008
4. Budowa aplikacji
5. Wykonanie aplikacji
6. Śledzenie wykonania aplikacji w kontekście elementów z modelu klas i stanów
W pierwszym etapie model jest wczytywany do generatora FXU. Następuje również
statyczna walidacja modelu pod kontem zgodności ze standardami UML 2.1.2 oraz standardem
języka C# 3.0.
Drugi etap to generacja kodu. Elementy konfigurowalne generatora to m.in. katalog
wyjściowy, domyślne typy danych, parametry logowania zdarzeń, algorytmy dla wariantów
semantycznych specyfikacji UML.
Trzecim (opcjonalnym) etapem jest generacja projektu dla środowiska programistycznego
Microsoft Visual Studio 2008. Dodatkowo, można korzystając z modułu Application Wizard
utworzyć klasę zawierającą funkcję main, w której następuje inicjalizacja oraz uruchomienie
wygenerowanych wcześniej maszyn stanowych.
W środowisku uruchomieniowym możliwa jest modyfikacja kodu, w tym uzupełnienie kodu
operacji, integracja z innymi elementami systemu, które nie podlegały modelowaniu, jak np.
składnikami interfejsu użytkownika. Na tym etapie dołączane są biblioteki środowiska
uruchomieniowego FXU.
Podczas wykonania gotowej aplikacji następuje dodatkowa weryfikacja dynamiczna
wybranych własności maszyn stanowych. Ślad wykonania jest zapamiętywany w plikach logów
zgodnie z przyjętymi wymaganiami. Narzędzie FXU Tracer umożliwia śledzenie wykonania
maszyn stanowych na podstawie logowanej informacji. Ułatwia to interpretację działania
aplikacji w odniesieniu do poszczególnych elementów modelu i jest alternatywą dla zwykłego
przeglądania plików logów, które mogą być złożone i mało czytelne.
3.3. Implementacja serwera obecności z użyciem FXU
Model systemu serwera obecności przekształcono w kod przy użyciu generatora FXU i
stworzono wykonywalną aplikację. Dzięki temu przetestowano poprawności wykonania
wygenerowanych maszyn stanowych. Testowaniu poddano głównie sposób obsługi żądań
PUBLISH, SUBSCRIBE, NOTIFY. Przyjęto odpowiednie założenia dotyczące struktury żądań,
implementacji serwera, obsługi wiadomości itp. W zależności od rodzaju żądania, było ono
przekazywane do jednego z obiektów klas realizujących logikę biznesową znajdujących się w
pakiecie PresenceAgentController.
W celu szczegółowej analizy wykonania aplikacji użyto narzędzia FXU Tracer, który daje
możliwość symulacji przebiegu maszyn stanowych i jej wizualizacji. Prześledzono sekwencje
obsługi żądań na poszczególnych etapach w przypadku poprawnych, jak i niepoprawnych
sytuacji. Wykonanie powyższych testów wskazuje na to, że FXU może zostać użyty do realizacji
i integracji skomplikowanej logiki biznesowej, a wiele problemów może zostać rozwiązanych
8
A. Derezińska, M. Szczykulski
już na etapie projektowania, dzięki czemu nie będzie konieczna późniejsza implementacja
niektórych elementów, gdyż zostaną one wygenerowane i wykonane w środowisku
uruchomieniowym FXU.
4. Podsumowanie
W rozdziale przedstawiono przykład tworzenia aplikacji poprzez złożenie szeregu maszyn
stanowych specyfikujących działanie klas wchodzących w skład aplikacji. Do realizacji tego
zadania wykorzystano aktualną wersję systemu FXU. Rozwiązanie to miało następujące zalety:
• Część problemów rozstrzygana na etapie projektowania systemu, zwłaszcza dotycząca
współdziałania poszczególnych elementów systemu.
• Mniejszy nakład pracy w fazie implementacji ze względu na generację szkieletu aplikacji
w postaci klas i sygnatur operacji oraz generację kodu związanego z przepływem
sterowania w aplikacji i logiką biznesową.
• Generowanie kodu pozbawionego błędów kompilacji (ale nie dotyczy to kodu ręcznie
wpisywanego przez projektanta na diagramie UML).
• Automatyzacja procesu budowania projektu i głównej funkcji systemu.
• Możliwość śledzenia wykonania maszyn stanowych realizowanych w aplikacji.
Podstawowe wady związane z omawianym podejściem, to:
• Wygenerowany kod może być mniej wydajny niż kod napisany ręcznie.
• Narzędzie FXU integruje się ze środowiskiem w którym tworzone są modele oraz
środowiskiem programistycznym .NET (Microsoft VS) tylko na poziomie plików.
• Kod wpisany w modelu UML dla wewnętrznych akcji stanów (sekcje entry, do, exit) oraz
jako implementacja ciała operacji jest weryfikowany dopiero podczas tworzenia projektu.
Ocena ilościowa efektywności omawianego podejścia oraz jakości otrzymanego kodu
wymaga dalszych eksperymentów, w tym zbudowania aplikacji analogicznej do utworzonej z
użyciem FXU, przy zachowaniu porównywalnych warunków realizacji obu procesów.
Bibliografia
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Derezińska A., Pilitowski R.: Event Processing in Code Generation and Execution
Framework of UML State Machines. - Madeyski L. at al. (red.) Software Engineering in
progres, ss. 80-92. Nakom, Poznań, (Polska) 2007.
Derezińska A., Pilitowski, R.; Realization of UML class and state machine models in the
C# Code Generation and Execution Framework. Informatica, vol. 33, no 4, 431-440. 2009.
Dziekan A. M.: Usługi kontekstowe w środowisku IMS Model i implementacja serwisów
społecznościowych, (Praca mag. CD-ROM) Instytut Telekomunikacji, Politechnika
Warszawska, Warszawa (Polska) 2008.
France R., Rumpe B.: Model-driven Development of Complex Software: A Research
Roadmap, Future of Software Engineering at ICSE'07, IEEE Soc., 2007, ss. 37-54.
http: Eclipse Foundation, http://www.eclipse.org/, (2010).
http:
IBM
Rational
Software
Architect,
http://www01.ibm.com/software/awdtools/swarchitect/ (2010).
http: IBM Rational Rhapsody, http://www-01.ibm.com/software/awdtools/rhapsody/,
(2010).
http: Sparx Systems. Enterprise Architect, http://www.sparxsystems.com.au/
products/ea/index.html, (2010).
http: Unified Modeling Language Superstructure v. 2.2, OMG Document formal/2009-0202, 2009, http://www.uml.org, (2010).
1. Tworzenie systemu z wykorzystaniem współpracujących maszyn stanowych
9
[10] Pilitowski R., Derezińska A.: Code Generation and Execution Framework for UML 2.0
Classes and State Machines. - Sobh T. (red.): Innovations and Advanced Techniques in
Computer and Information Sciences and Engineering, ss. 421-427. Springer, 2007.
[11] Rosenberg J.: RFC 3856 – A Presence Event Package for the Session Initiation Protocol
(SIP). 2004, http://tools.ietf.org/html/rfc3856
10
A. Derezińska, M. Szczykulski
{Odrębna strona streszczeń i adresów}
Tworzenie systemu z wykorzystaniem współpracujących maszyn stanowych
A.Derezińska*, M.Szczykulski**
*Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut Informatyki,
[email protected]
** Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut
Informatyki, [email protected]
Rozdział 5. Tworzenie systemu z wykorzystaniem współpracujących maszyn stanowych.
Budowa systemów realizujących złożoną logikę biznesową może być wspomagana przez
rozwiązania inżynierii opartej na modelach. W prezentowanym podejściu działanie
poszczególnych klas systemu zostało opisane przy użyciu maszyn stanowych UML. Wynikowy
model integrujący różne części systemu został przetransformowany do kodu i uruchomiony
razem z biblioteką implementującą wszystkie elementy specyfikacji maszyn stanowych. Do
generacji kodu i realizacji maszyn stanowych wykorzystano narzędzie FXU (ang. Framework
for eXecutable UML), które przekształca modele klas i stanów do kodu C#. Modelowany system
dotyczył realizacji mobilnych usług kontekstowych dla społeczności użytkowników sieci
Internet. Główną częścią systemu był serwer obecności. Realizował on trzy podstawowe
zadania: publikację statusu użytkownika, informowanie o jego zmianach oraz subskrypcję
informacji o statusie innego użytkownika.
The title in English
A.Derezińska*, M.Szczykulski**
*Warsaw University of Technology, Faculty of Electronics and Information Technology,
Institute of Computer Science, [email protected]
** Warsaw University of Technology, Faculty of Electronics and Information Technology,
Institute of Computer Science, [email protected]
Chapter 5. System creation based on cooperating state machines. The chapter presents
a system development supported by model driven engineering. Complex logic of a system can be
specified using state machines associated with particular classes. Integration of different system
parts can be specified at earlier stages of the system development. A model including class and
state machine models is transformed into a source code. An executable application is built with
usage of a library implementing all single elements of the UML behavioral state machine. This
task was accomplished using the FXU environment (Framework for eXecutable UML), which
transforms UML class and state diagrams into C# code. The approach was illustrated with a case
study devoted to a social network of mobile users. The model and created application realized
a presence server for the statuses services in the network. The server completes three main tasks:
subscription of a status of another user, publication of a new status with given rules and
notification another user about a status.