Modelowanie systemów typu RT z wykorzystaniem UML

AGH, EAIE, Informatyka
Modelowanie systemów
typu RT z wykorzystaniem
UML
Systemy czasu rzeczywistego
Miroslaw Jedynak, Adam Łączyński
Spis treści
1
2
Wstęp .............................................................................................................................................. 3
1.1
Architektura systemów Real-time ........................................................................................... 3
1.2
Modelowanie systemów RT .................................................................................................... 5
Struktura .......................................................................................................................................... 6
2.1
2.1.1
Typu „Relay” .................................................................................................................... 7
2.1.2
Typu „End”....................................................................................................................... 7
2.1.3
Modelowanie................................................................................................................... 7
2.2
Konektor .................................................................................................................................. 8
2.2.1
Konektor a protokół ........................................................................................................ 8
2.2.2
Modelowanie................................................................................................................... 8
2.3
3
Porty ........................................................................................................................................ 7
Kapsuły .................................................................................................................................... 9
2.3.1
Pluginy ............................................................................................................................. 9
2.3.2
Maszyna stanowa ............................................................................................................ 9
2.3.3
Modelowanie................................................................................................................. 10
Zachowanie.................................................................................................................................... 11
3.1
Modelowanie czasu ............................................................................................................... 11
3.1.1
Funkcja zysku ................................................................................................................. 11
3.1.2
Upływ czasu na diagramie UML .................................................................................... 11
3.1.3
Usługa upływu czasu ..................................................................................................... 12
3.1.4
Timed Transition Net ..................................................................................................... 12
3.2
Protokoły ............................................................................................................................... 13
3.2.1
3.3
Modelowanie................................................................................................................. 13
Maszyny stanowe .................................................................................................................. 14
3.3.1
Modelowanie................................................................................................................. 14
3.3.2
Hierarchia ...................................................................................................................... 14
3.3.3
Modelowanie zawierania .............................................................................................. 15
4
Podsumowanie .............................................................................................................................. 15
5
Bibliografia..................................................................................................................................... 16
2
1 Wstęp
Najbardziej popularna definicją systemu czasu rzeczywistego jest:"System czasu rzeczywistego to
taki, w którym wynik przetwarzania nie zależy tylko i wyłącznie od jego logicznej poprawności, ale
również od czasu, w jakim został osiągnięty. Jeśli nie są spełnione ograniczenia czasowe, mówi się, że
nastąpił błąd systemu."[1]. Ograniczenia czasowe są koniecznością, której niespełnienie prowadzi w
najgorszym przypadku do nieodwracalnych i tragicznych skutków oraz tych, w których czas
wykonania nie jest tak krytyczny i dopuszcza się pewne odstępstwa. Najczęściej systemy czasu
rzeczywistego dzieli się na dwie grupy:
•
•
Rygorystyczne (twarde, ang. Hard real - time systems) - gwarantują terminowe wypełnianie
krytycznych zadań.
Łagodne(miękkie, ang. Soft real - time systems) - są mniej wymagające. W nich krytyczne
zadanie do obsługi w czasie rzeczywistym otrzymuje pierwszeństwo przed innymi zadaniami i
zachowuje je aż do swojego zakończenia. [6]
Systemy czasu rzeczywistego obejmują swoim zastosowaniem takie dziedziny jak telekomunikacja,
lotnictwo, systemy militarne, które często są duże oraz bardzo złożone. Krytycznym wymaganiem dla
tych systemów jest przemyślana architektura. Dobra architektura nie tylko upraszcza konstrukcje
początkowego systemu, ale także, co jest nawet ważniejsze, umożliwia w łatwy sposób
wprowadzanie zmian wynikających z ciągle napływających nowych wymagań.
Referat ten ma za zadanie przedstawić możliwe rozwiązanie tego problemu oparte na wykorzystaniu
UML’a do modelowania systemów czasu rzeczywistego. W dużej mierze opierać się będziemy na
standardzie ROOM – Real-time object oriented modelling. W szczególności pokażemy jak konstrukcje
w tym języku zostały utworzone na podstawie mechanizmu rozszerzeń do UML’a.[5]
1.1 Architektura systemów Real-time
Zazwyczaj architektura tego typu systemów wygląda jak na Rysunek 1. System jest podzielony na
część wewnętrzną (czerwoną), która zawiera logikę przetwarzania oraz na część zewnętrzną
(niebieską), która jest odpowiedzialna za generowanie i odbieranie sygnałów do/z części zawierającej
logikę- sensory i efetktory.[3]
3
Rysunek 1 Ogólna struktura systemów czasu rzeczywistego
W poniższych rozdziałach zostaną omówione konstrukcje używane do reprezentowanie system czasu
rzeczywistego. Konstrukcje te zostały podzielone na dwie grupy:
•
Struktura – elementy statyczne systemu
Rysunek 2 Modelowanie struktury
4
•
Zachowanie – modelowanie części systemu, które się zmieniają
Rysunek 3 Modelowanie zachowania
1.2 Modelowanie systemów RT
Modelowanie systemu składa się z dwóch faz przedstawionych na diagramie poniżej (Rysunek 4):
•
•
Modelowanie – specyfikacja graficzna systemu
Generowanie – generacja kodu (np. c++) na podstawie modelu systemu
Rysunek 4 Modelowanie systemu RT
5
2 Struktura
Za strukturę systemu przyjęło się uważać encje, które są modelowane oraz relacje pomiędzy nimi
(takie jak komunikacja). UML dostarcza dwóch komplementarnych typów diagramów do
modelowanie logicznej struktury
•
•
Diagramy klas
Diagramy kolaboracji
Diagramy klas przedstawiają ogólne relacje między klasami – relacje różnego typu, które istnieją
pomiędzy instancjami danych klas. Diagramy kolaboracji rozróżniają użycie dwóch instancji tej samej
klasy, na podstawie tzw. roli w jakiej dana instancja występuje na diagramie.
W systemach czasu rzeczywistego większy nacisk kładzie się na diagramy kolaboracji, ponieważ
można z ich pomocą wyrazić powiązania między klasami (role) oraz zależności czasowe, na których
opiera się całe modelowanie oparte na restrykcyjnych wymogach czasu wykonania. Diagramy
sekwencji można wygenerować na podstawie pełnego diagramu kolaboracji, jednak wtedy tracimy
przejrzystość zależności pomiędzy poszczególnymi klasami. Nie zmienia to jednak faktu, że kompletna
specyfikacja architektury opiera się przynajmniej na dwóch typach diagramów: modelującym
strukturę (klas) i jednym z diagramów modelujących zachowanie.[11][7]
Do przedstawiania elementów strukturalnych używa się 3 podstawowych elementów:
•
•
•
Kapsuł
Portów
Konektorów
Kapsuły odpowiadają koncepcji aktorów z tradycyjnego podejścia z wykorzystaniem UML’a. Są to
złożone, fizyczne i często rozproszone obiekty, które komunikują się ze sobą wykorzystując koncepcje
portów. Port jest to implementacja części kapsuły, która jest odpowiedzialna za komunikację ze
światem zewnętrznym przez ściśle określony interfejs – odpowiada pojęciu interfejsów
specyfikujących usługi w tradycyjnym podejściu. Każdy port definiuje specyficzną role w jakiej
występuje dana kapsuła przy komunikacji z inną. W celu usystematyzowania często złożonej
semantyki komunikacji wprowadzone zostało pojęcie protokołu, który specyfikuje poprawność
przepływu informacji (sygnałów) pomiędzy kapsułami. Przez wymuszenie na kapsułach komunikacji
wyłącznie przez porty zyskuję się silną niezależności i duża reużywalność poszczególnych
komponentów systemu.
Konektory odpowiadają pojęciu bindingu w tradycyjnym podejściu- są abstrakcją definiującą
powiązania między poszczególnymi portami. Na diagramach kolaboracji przedstawione są jako
połączenie pomiędzy portami, które występują w danej roli. Przedstawiana zależność jest istotna z
punktu widzenia architekta systemu, ponieważ te i tylko te obiektu mogą na siebie wpływać, które są
połączone za pomocą konektora.
Kapsuły są realizowane za pomocą maszyny stanowej. W przypadku bardziej złożonych kapsuł mogą
się one składać z podkapsuł połączonych wewnętrznie konektorami. Poszczególne podkaspuły mogą
być rekurencyjnie dekomponowane na mniejsze elementy – takie podejście umożliwia projektowanie
6
nawet bardzo złożonych systemów wykorzystująca różne abstrakcje na różnym poziomie
modelowania.
2.1 Porty
Porty są obiektami, których zadaniem jest zachowywać się jak obiekty brzegowe dla danej instancji
kapsuły. Porty należą do kapsuły tzn. są przez nią tworzone i usuwane. Każdy port posiada
identyfikator i stan, dlatego może być traktowany jako osobny obiekt, którego czas życia jest
powiązany z czasem życia kapsuły. Mimo że porty zachowują się jak interfejsy dla danej kapsuły nie
mogą być w UML mapowane do tradycyjnych interfejsów, ponieważ posiadają swój stan.
Każdy port odgrywa konkretną rolę w ramach danego protokołu (np. jeden pełni rolę nadawy, a drugi
odbiorcy). Porty są obiektami brzegowymi, dlatego w przeciwieństwie do konektorów i wnętrza
kapsuły mogą być one widziane zarówno z zewnątrz jak i z wnętrza kapsuły.
2.1.1 Typu „Relay”
Porty typu „relay” są portami, które przepuszczają wszystkie sygnały bez ingerencji – pełnią rolę
prostego udostępnienia jakieś funkcjonalności, która jest np. zaimplementowana w podkapsule.
Porty typu relay umożliwiają natychmiastowe przesłanie (delegację) sygnału na dalej bez potrzeby
uruchamiania maszyny stanowej danej kapsuły – brak opóźnienia.
2.1.2 Typu „End”
Porty typu „End” w przeciwieństwie do portów typu „relay” posiadają implementację obsługi danego
sygnału. Nadejście sygnału na porcie typu „end” wymusza uruchomienia maszyny stanowej danej
kapsuły. Z wykorzystaniem portów „końcowych” maszyna stanowa może wygenerować zdarzenie,
które spowoduje wysłanie sygnału przez dany port.
Wysyłanie i odbieranie sygnałów odbywa się asynchronicznie, dlatego porty tego typu muszą
posiadać implementację bufora sygnałów.
2.1.3 Modelowanie
Port jest modelowany z wykorzystaniem stereotypu „port”, który jest nakładany na klasę. Ponieważ
port jest klasą abstrakcyjną dopiero jego użycie definiuje czy jest to port typu „End” czy „Relay”.
Konkretna klasa definiującą port jest również implementacją roli w danym protokole, w którym jest
użyta.
Rysunek 5 Przedstawienie idei portów na diagramie UML
Powyższy diagram (Rysunek 5) przestawia taką strukturę. Klasa PortClassX oznaczona stereotypem
„port” przestawia idee portu w modelowaniu RT. Przedstawiony port pełni rolę maste (stereotyp
protocol role) w protokole ProtocolA (stereotyp protocol). Zaś sam port należy do kapsuły
7
CapsuleClassA. Niektóre pojęcia z tego diagramu zostaną przestawione w późniejszych rozdziałach:
2.3 Kapsuły i 3.2 Protokoły.
Rysunek 6 Przedstawienie na diagramie klas widoczności poszczególnych portów oraz ich krotności.
Na diagramie klas (Rysunek 7) można również przedstawić dodatkowe informacje: krotność (nawiasy
[]) ,widoczność (private/public.protected) oraz rolę (tutaj ::master). Podobnie rolę można
przedstawić na diagramie kolaboracji – wtedy czytelnej pokazane są powiązania (Rysunek 7)..
Rysunek 7 Porty i protokóły na diagramie kolaboracji
2.2 Konektor
Konektory reprezentują kanał komunikacyjny, który wspiera transmisję z wykorzystaniem protokółu
opartego na sygnałach. Należy zauważyć, że konektor umożliwia łączenie tylko takich portów, które
implementują odpowiadające sobie końcówki protokołu. W szczególności porty nie muszą należeć do
tego samego protokołu, ale ich implementacja musi być zgodna ze specyfikacją wykorzystywanego
protokołu.
2.2.1 Konektor a protokół
Podobieństwo między pojęciem konektora a protokołem może sugerować, że są one równoważne.
Różnica pomiędzy nimi polega na tym, że protokół jest abstrakcyjnym pojęciem definiującym
zachowanie, natomiast konektor jest konkretną implementacją protokołu- może się zdarzyć, że
konektor implementuje specyfikację kilku protokołów jednocześnie.
Zazwyczaj konektory zachowują się jak pasywne medium, niewpływające na przesyłane komunikaty,
jednak czasami, konektory mogą być wykorzystywane do bardziej zaawansowanego modelowania:
mogą porzucać niektóre komunikaty, zmieniać ich kolejność, duplikować wiadomości itp..
2.2.2 Modelowanie
W UML’u konektory modelowane są jako skojarzenie i są deklarowane jako rola danego skojarzenia
na diagramie kolaboracji. Skojarzenie istnienie pomiędzy przynajmniej dwoma portami
odpowiadających sobie klas. W niektórych przypadkach koniecznie jest zamodelowanie konektora
jako klasy, ponieważ posiada swój stan, który wpływa na jego zachowanie.
Modelowanie na diagramie nie wymaga użycia specjalnego stereotypu, dlatego też nie ma
konieczności wprowadzanie rozszerzenia języka UML. Na diagramie klas konektor jest powiązaniem
(association) lub osobną klasą; konektory z więcej niż dwoma końcówkami są modelowane jako romb
8
(tak samo jak wielokrotne powiązania). Na diagramie kolaboracji konektor jest pokazywany w
połączeniu z klasą, która z niego korzysta.
Rysunek 8 Konektory na diagramie kolaboracji
2.3 Kapsuły
Kapsuły są z punktu widzenia tego podejścia architektonicznego centralną jednostką. Odpowiedzialne
są za reprezentowanie centralnych części systemu, które typowo komunikują się z innymi kapsułami
poprzez porty. Jak zostało wcześniej wspomniane kapsuła może zawierać w sobie podkapsuły, które
komunikują się ze środowiskiem poprzez porty nadrzędnej kapsuły. [7]
Kapsuła może zawierać w sobie implementacje maszyny stanowej, która może wysyłać i odbierać
sygnały – sposób implementacji tej maszyny odzwierciedla zachowanie kapsuły widzianej jako część
systemu przez pozostałe kapsuły.
Budowa wewnętrzna kapsuły może być w całości przedstawiona na diagramie kolaboracji, który
zawiera:
•
•
•
•
Podkapsuły
Porty
Konektory
Maszyna stanowa
Porty i podkapsuły nie mogą istnieć w oderwaniu od nadrzędnej kapsuły – ich cykl życia jest
kontrolowany. Podkapsuły mogą być tworzone w dowolnym momecie po utworzeniu nadrzędnej
kapsuły, a usuwane mogą być w dowolnym momencie przed jej usunięciem. Takie podejście pokrywa
się pojęciem kompozycji w UML’u.
2.3.1 Pluginy
Struktura kapsuły może zawierać w sobie plug-iny. Są to miejsca, w których podkaspuły mogą być
ładowane dynamicznie. Istnienie pluginów jest wymagane, ponieważ implementacja konkretnej
kapsuły może pozostać nieznana w czasie kompilacji – wybór może zależeć od konkretnego stany
maszyny w czasie uruchomienia. Połączenie do tej dynamicznie ładowanej kapsuły jest nawiązywane
przez konektor, który jest powiązany z danym pluginem.
2.3.2 Maszyna stanowa
Jedną z części kapsuły może być maszyna stanowa. Wyróżnia się ona od innych składowych tym, że:
•
•
•
•
Nie może być złożona z podkapsuł, ale może być dekomponowana na prostsze pod maszyny
stanowe.
Tylko jedna maszyna stanowa może istnieć w ramach danej kapsuły.
Odbiera sygnały od wszystkich portów typu „end” w kapsule
Może wysyłać sygnały przez wszystkie porty kapsuły, do której należy.
9
•
Tylko maszyna stanowa ma dostęp do wewnętrznej struktury kapsuły- może tworzyć
dynamicznie podkapsuły.
Rysunek 9 Maszyna stanowa w kapsule
2.3.3 Modelowanie
Na diagramach UML kapsuła jest przedstawiana jako klasa ze stereotypem „capsule”. Kapsuła jest
powiązana relacją kompozycji z portami i swoimi podkapsułami i wewnętrznymi konektorami.
Wszystkie części kapsuły z wyjątkiem portów publicznych mają dostęp typu „protected”.
Podkapsuły na diagramie kolaboracji również przedstawiane są w postaci klasy, z którymi
współpracuje nadrzędna kapsuła. Rozróżnienie czy dany obiekt przedstawia kapsułę czy plugin
odbywa się na podstawie wartości pola typu true/false, którego wartość jest ustalana dla danej
kapsuły.
Rysunek 10 Kapsuły i podkapsuły na diagramie kolaboracji
W przypadku zwykłych podkapsuł asocjacja z nadrzędną kapsułą przedstawiana jest jako kompozycja.
W przypadku pluginów może być również przedstawiana jako agregacja. Kapsuły pełniące rolę
pluginów mogą występować ze stereotypem „plugin”, zaś maszyny stanowe przedstawiane są jako
owal. Czarne kwadraty to porty (publiczne lub chronione – o widoczności typu protected).
10
Rysunek 11 Kapsuły
uły i podkapsuły na diagramie klas.
klas CapsuleClassB jest tutaj pluginem
3 Zachowanie
3.1 Modelowanie czasu
3.1.1 Funkcja zysku
Dla teorii i praktyki systemów czasu rzeczywistego przydatne jest pojęcie funkcji zysku.
zysku Funkcja zysku
jest funkcją zależną przede wszystkim od czasu i określa korzyść ze zrealizowania zadania przez
system. Źródłem ograniczeń czasowych są zazwyczaj zjawiska fizyczne zachodzące w świecie
rzeczywistym.
Zadanie zostało przez system zrealizowane poprawnie, jeśli z chwilą zakończenia tego zadania
wartość
ość funkcji zysku jest większa od zera.
zera Dla systemów czasu rzeczywistego charakterystyczne są
trzy funkcje zysku (t0 to chwila zlecenia zadania systemowi, uznawana za początek realizacji tego
zadania, tT to najpóźniejsza chwila, w której przetwarzanie może zostać zakończone (ang. deadline))
[5]:
Z tych trzech funkcji wyprowadza się często
c
podział systemów czasu rzeczywistego na "hard"(1.),
"firm"(2.) i "soft"(3.).
3.1.2 Upływ czasu na diagramie UML
Przedstawiony poniżej (Rysunek
Rysunek 12)) diagram pokazuje w jaki sposób można modelować ograniczenia
czasowe nakładane na poszczególne elementy systemu. Ograniczenia te zazwyczaj są górnymi tzn.
ważne jest, aby system odpowiedział „nie później niż”. Wcześniejsza odpowiedź jest zazwyczaj
dopuszczalna. Jeśli konieczna jest odpowiedź systemu w dokładnie określonej chwili czasu korzysta
się z usługi czasowej w opisanej w rozdziale 3.1.3. [8]
11
Rysunek 12 Zależności czasowe na diagramie sekwencji
3.1.3 Usługa upływu czasu
W systemach czasu rzeczywistego najważniejszym ograniczeniem jest czas. Zależności jakie mogą być
modelowane to:
•
•
Wyzwalanie zdarzenia w określonym momencie w czasie
Wyzwalanie zdarzenie po upływie określonego czasu
Zazwyczaj do modelowanie upływu czasu używa się centralnej usługi informującej o upływie czasu.
Powyższa usługa jest dostępna przez zwykły port, gdzie czas żądany interwał czasu konwertowany
jest na zdarzenie. W ten sposób maszyna stanowa może być informowana o upływie zadanego czasu
lub o nadejściu określonego momentu w czasie. [9]
3.1.3.1 Modelowanie
Nie jest konieczne wprowadzanie dodatkowych rozszerzeń do UML’a – usługa czasowa może być
modelowana jako port typu „end”.
3.1.4 Timed Transition Net
Innym sposobem przedstawienia upływu czasu jest reprezentacja w postaci sieci przejść. Ten sposób
modelowania składa się z dwóch etapów [4]:
1. Określenie minimalnego i maksymalnego przedziału czasu jaki może zająć operacja w ramach
przejścia pomiędzy dwoma stanami (Rysunek 13)
Rysunek 13 Czas trwania podstawowej operacji
2. Określenie maksymalnego i minimalnego czasu odpowiedzi całego systemu na podstawia
analizy możliwych zmian stanów maszyny stanowej.
12
Rysunek 14 Zależności czasowe zachodzące przy zmiane stanu
3.2 Protokoły
Protokół jest to specyfikacja pożądanego zachowanie, które może mieć miejsce w przypadku użycia
konektora – rodzaj uzgodnienia pomiędzy uczestnikami. Na protokół składają się uczestnicy, którzy
pełnią określone role. Każda rola jest określona przez unikatową nazwę i zestaw sygnałów, które są
odbierane i które mogą być wysyłane przez końcówkę połączenia. Na protokół może się również
składać zdefiniowane stany i przejścia między nimi.
Szczególnym, ale najbardziej powszechnym przykładem protokołów są protokoły binarne, w których
występuje tylko dwóch uczestników.
3.2.1 Modelowanie
W UML’u rola w protokole jest modelowane za pomocą stereotypu „protocolRole”. Na rolę w
protokole składają się:
•
•
•
Zestaw sygnałów wejściowych
Zestaw sygnałów wyjściowych
Maszyna stanowa
Rysunek 15 Rola w protokole na diagramie klas
W UML’u protokół jest modelowany poprzez użycie stereotypu „protocol” na klasie, która jest w
relacji kompozycji z rolami danego protokołu. Kolejne protokóły mogą powstawać poprzez
dziedziczenie z już istniejących.
13
Rysunek 16 Protokół binarny na diagramie klas (tylko 2 rodzaje sygnałów)
3.3 Maszyny stanowe
Maszyny stanowe mogą występować jako część nadrzędnej kapsuły albo jako specyfikacja
dozwolonych przejść ramach protokołu.
Często zachodzi sytuacja, kiedy w ramach jednej kapsuły dwa porty pełnią tą samą rolę w tym samym
rodzaju protokółu, dlatego konieczne jest wprowadzenie mechanizmu rozróżniania źródła danego
sygnału, który dociera do maszyny stanowej. Takie zachowanie określane jest jako „port based
triggering”, czyli wyzwalanie oparte na portach (a nie na sygnałach) – może to być modelowane na
UML’u jako strażnicy. [9]
3.3.1 Modelowanie
Na diagramach UML’a maszyny stanowe są przedstawiane przy wykorzystaniu standardowego
zapisu- nie jest konieczne wprowadzanie rozszerzeń na potrzeby modelowania systemów czasu
rzeczywistego.
3.3.2 Hierarchia
Istotną w czasie projektowania złożonych systemów czas rzeczywistego może być abstrakcja w czasie
tworzenia maszyn stanowych. Polega ona na tym, że bardziej szczegółowe maszyny stanowe mogą
się zawierać w węzłach bardziej ogólnych maszyn (Rysunek 17).
Rysunek 17 Zawieranie się maszyn stanowych w sobie
14
3.3.3
Modelowanie zawierania
Rysunek 18 Maszyna stanowa na wysokim poziomie abstrakcji w UML'u
Jak przedstawia poniższy rysunek wewnętrzna maszyna stanowa może być modelowana na różne
sposoby. Bardziej ogólna maszyna jest nieświadoma szczegółów implementacji maszyny
wewnętrznej, dzięki czemu zmiany w tej wewnętrznej nie powodują konieczności zmiany maszyny
zewnętrznej.
Rysunek 19 Dwie różnie możliwe implementacji szczegółowej maszyny stanowej
4 Podsumowanie
Używanie UML’a do modelowania systemów czasu rzeczywistego ma wiele zalet m.in.:
•
•
UML jest znanym i szeroko wspieranym standardem, dlatego używanie jego rozszerzeń z
wykorzystaniem dostępnych narzędzi przyspiesza proces nauki i projektowania.
Oczekiwana złożoność systemów czasu rzeczywistego powoduje konieczność wprowadzanie
specyficznego do tego celu sposobu modelowania aplikacji
Modelowanie struktury z wykorzystaniem UML również przynosi wymierne korzyści:
•
•
Modelowanie graficzne struktury powoduje jej łatwiejsze zrozumienie i zazwyczaj przyczynia
się do uniknięcia wielu prostych błędów
Wprowadza abstrakcję na wysokim poziomie
o Protokołów
o Współbieżnie uruchamianych obiektów – kapsuł
15
o
Dynamicznych struktur – pluginów
Modelowanie zachowania podobnie jak modelowanie struktury:
•
•
•
Pozwala na graficzne modelowanie
Umożliwia przedstawianie hierarchicznie maszyn stanowych, co powoduje zmniejszenie
złożoność oraz zwiększenie czytelności projektu
Ułatwia przedstawianie upływu czasu – usługa czasowa
5 Bibliografia
[1] www.ieee.org
[2] Selic, B., Gullekson, G., and Ward, P., “Real-Time Object-Oriented Modeling,”
[3] Z. Gu and K. G. Shin, “Synthesis of Real-Time Implementation from UML-RT Models”
[4] Jyhjong Lin, David Chenho Kung, and Pei Hsia “Towards A Real-Time Object-Oriented Modeling
Approach”
[5] http://en.wikipedia.org/wiki/Real-time_computing
[6] www.kik.pcz.pl
[7] Bran Selic, Jim Rumbaugh, “UML for Modeling Complex Real-Time Systems”
[8] Susanne Graf, Ileana Ober and Iulian Ober “A real-time profile for UML”
[9] www.google.com
[10] www.books.google.com
[11] Robert C Martin “Agile Principles, Patterns, and Practices”
16