Wojciech Complak, Adam Czajka, Jerzy R. Nawrocki
U rT-HOOD (Hard Real-Time Hierarchical Object Oriented Design) jest metodą projektowania systemów silnie uwarun
kowanych czasowo. Metoda ta została opracowana w latach 90. w ramach projektu Europejskiej Agencji ds. Przestrzeni (ESA) jako rozwinięcie metody HOOD [3]. W stosunku do swojego pierwowzoru HRT-HOOD jest rozszerzona o możliwość bezpo
średniego ujęcia w projekcie cech charakterystycznych dla systemów silnie uwarunkowanych czasowo (takich jak linie krytyczne czy maksymalny czas wykonania) oraz wsparcie dla programowania zorientowanego obiektowo (mechanizm defi
niowania klas obiektów). Najważniejszą cechą metody jest jed
nak możliwość sprawdzenia już na etapie projektowania, czy dla danego projektu systemu istnieje uszeregowanie dopusz
czalne - to znaczy, czy wszystkie operacje zawsze zakończą się przed swoimi liniami krytycznymi. Pozwala to na wczesne roz
poznanie błędów projektowych i modyfikację architektury sys
temu przy stosunkowo niewielkim nakładzie wysiłku i kosztów.
Ta cecha metody obok mechanizmów bezpośredniego opisy
wania cyklicznych i sporadycznych zdarzeń zachodzących w większości systemów czasu rzeczywistego decyduje o prze
wadze metody HRT-HOOD nad innymi metodami (MASCOT, JSD, MOON itd.) również pretendującymi do miana metod pro
jektowania systemów uwarunkowanych czasowo.
Celem artykułu jest przedstawienie elementów metody HRT- HOOD. Dokładniejszy opis znajduje się w pracach [ 1 ], [2] oraz w informacjach udostępnianych w Internecieprzez Real-Time Research Gmupdziałającą na The University o f York (spis grup naukowych tego uniwersytetu znajduje się pod adresem http://
www.cs.york.ac.uk/research/gtvups.html,a strona macierzysta grupy - http://dcpul.cs.york.ac.uk:6666/real-time/).
Obiekty i operacje
W metodzie HRT-HOOD nie narzuca się formalnego sposobu specyfikacji systemu docelowego. Zakłada się jednak, że sys
tem jest pisany w konwencji obiektowej - m etoda powstała z m yśląo języku Ada. Graficzna reprezentacja obiektów w me
todzie HRT-HOOD - przedstawiona na rys. 1 - jest praktycznie identyczna jak w metodzie HOOD (wyjątkiem jest jawne ozna
czanie typu obiektów pasywnych).
Do obiektów pasywnych i aktywnych znanych z m eto
dy HOOD dodano nowe typy obiektów: chronione, cyklicz
ne i sporadyczne. Obiekty pasyw ne nie m ają w pływu na to, kiedy udostępniane przez nie operacje są wykorzystywane.
Po wywołaniu operacji sterowanie natychmiast je st przeka
zywane do obiektu. Każda operacja zawiera tylko sekw en
cyjne fragmenty kodu nie synchronizujące się z żadnym innym obiektem. N a rys. 2 przedstaw iono obiekt pasywny Kolejka jjr io r y te tudostępniający dwie operacje: WstawE- lemw staw iającą element do kolejki oraz PobierzM inpobie
rającą najmniejszy element z kolejki.
Obiekty aktywne (zdefiniowane identycznie ja k w meto
dzie HOOD) udostępniają operacje z ograniczeniami
(uwa-42 Inform atyka 1/98
PU BLIKACJE
^Pa Kolejka_priorytet ' WstawElem
PobierzMin
^ J
Rys. 2. Obiekt pasywny Kolejka_priorytet
runkowane) i operacje bez ograniczeń (nieuwarunkowane).
Operacje nieuwarunkowane wykonywane są natychmiast po ich wywołaniu, podobnie jak dzieje się to w obiektach pasyw
nych. Z operacjami uwarunkowanymi związane są dwie klasy ograniczeń:
■ funkcjonalne ograniczenia aktywacji - niektóre operacje m ogą być niedostępne w danym stanie obiektu (na przy
kład operacja włożenia obiektu do skończonego bufora jest niedostępna, gdy jest on pełen) oraz
■ ograniczenia związane z typem schematu współpracy obiek
tów określające sposób przepływu sterowania między usłu
gobiorcą a usługodawcą. Wyróżnia się trzy schematy współpracy:
♦ ASER (Asynchronous Execution Request) - tryb asyn
chroniczny, w którym wołający nie jest w żaden spo
sób blokowany po wywołaniu usługi;
♦ LSER (Loosely Synchronous Execution Request) - tryb słabo zsynchronizowany, w którym wołający czeka, aż wołany obiekt będ zie gotow y do obsługi żądania, po czym natychmiast kontynuuje swoje obliczenia;
♦ HSER (Highly Synchronous Execution Request) - tryb silnie zsynchronizowany, w którym wołający czeka, aż wołany obiekt zakończy obsługę żądania.
Na rys. 3 przedstawiono obiekt aktywny ObsługaHotelo
wa, udostępniający cztery operacje uwarunkowane:
■ operację ZostawienieKlucza typu ASER - klucz można od
dać w dowolnej chwili, pozostawiając go na ladzie lub w przegródce niezależnie od tego, czy recepcjonista jest zaję
ty, czy nie;
■ operację PobranieKlucza typu HSER - występuje tu jed
nocześnie uwarunkowanie stanem (jeżeli klucza nie ma, to nie można go wydać) jak i schematem współpracy (recep
cjonista musi być gotowy do współpracy i musi zakoń
czyć wydawanie klucza, aby można było kontynuować swoje działanie);
■ operację ZgłoszenieUsterki typu LSER - wystarczy, że ob
sługa hotelowa przyjmie informacje o usterce, a samo usu
nięcie usterki może zostać wykonane później ju ż bez naszego oczekiwania;
■ operację ZapłatalPokwitowanie typu HSER - aby można było zapłacić, obsługa hotelowa musi być gotowa do współpracy, a usługobiorca musi poczekać na wydanie pokwitowania.
Jak widać każda operacja, która ma parametry wyjścio
we, musi być operacją HSER (tak było w przypadku pobiera
nia klucza i wydawania pokwitowania zapłaty).
ASER
h s e rZ ) LSER ~ Z l HSER
ObsługaHotelowa
ZostawienieKlucza 'PobranieKlucza
ZgłoszenieUsterki ZapłatalPokwitowanie
Rys. 3. Obiekt aktywny ObsługaHotelowa
Podobnie jak w metodzie HOOD operacje typu LSER i HSER mogą mieć przypisane ograniczenie czasowe maksymalnego czasu obsługi nazywane odpowiednio TOER_LSER (Timed Operation Execution Request LSER) i T O E R H S E R . Obiekt OkienkoPocztowe przedstawiony na rysunku 4 udostępnia między innymi usługęRozmowaTelefoniczna z nałożonym ogra
niczeniem maksymalnego czasu oczekiwania na połączenie.
LSER *
TOER_HSER
i A OkienkoPocztowe Wyslar
Rozmo lieListu waTelefoniczna
J Rys.4. Obiekt aktywny ograniczeniami czasowymi
Obiekty chronione
Obiekty chronione (które w metodzie HRT-HOOD są odpo
wiednikami monitorów [4], choć różnią się od nich znacznie) używane są do kontroli dostępu do zasobów wykorzystywa
nych w obiektach systemu silnie uwarunkowanego czasowo.
Umożłiwiająwprowadzenie na etapie projektowania ograniczeń maksymalnego czasu blokowania przy dostępie do współdzie
lonych zasobów. Mogą one udostępniać tylko dwa typy ope
racji uwarunkowanych:
=> PAER -(Protected Asynchronous Execution Request) - od
powiada asynchronicznemu schematowi współpracy, czyli przesłaniu przez usługobiorcę komunikatu do usługodawcy - wynika z tego, że operacja tego typu może zawierać tylko parametry wejściowe;
=> PSER -(Protected Synchronous Execution Request) - od
powiada synchronicznemu schematowi współpracy i taka operacja może również (oprócz parametrów wejściowych) posiadać parametry wyjściowe.
Tylko operacje PSER mogą zawierać funkcjonalne ograni
czenia aktywacji. Obiekty chronione mogą także zawierać opera
cje bez ograniczeń, które są wykorzystywane tak, jak wpizypadku obiektów pasywnych. Na rys. 5 przedstawiono monitor Maga- zynNieskończony udostępniający dwie operacje:
inform atyka 1/98 43
P U B LIK A C JE
WstawElement typu PER - wysyłamy żądanie wstawienia elementu do magazynu i nie czekamy na wyniki, ponieważ magazyn ma nieskończoną pojemność i żądanie nie może zakończyć się niepowodzeniem;
Pobierz element typu PSER - ta operacja ma obok ograni
czenia funkcjonalnego (z pustego magazynu nie da się po
brać elementu) ograniczenie schematu współpracy - musimy poczekać na wydanie elementu (czyli zakończenie obsługi żądania).
PAER PSER Z i
i
Pr MagazynNieskończony W stawElement*PobierzElement
ę---Rys. 5. Obiekt chroniony MagazynNieskończony
Obiekty cykliczne i sporadyczne
Obiekty cykliczne reprezentującyklicznie uruchamiane (aktywo
wane) procesy. Ich wykonywanie jest niezależne od reszty sys
temu. Z pozostałączęścią systemu komunikująsię i synchronizują przez wykonywanie operacji w obiektach chronionych. Na rys. 6 przedstawiono obiekt cykliczny CzujnikMetanu nie udostęp
niający żadnej operacji - obiekty cykliczne mogą udostępniać operacje, ale jest to raczej rzadkością.
' C CzujnikM etanu'''
V J
Rys. 6. Obiekt cykliczny CzujnikMetanu
Obiekty sporadyczne reprezentują procesy uruchamiane asynchroniczne i obsługujące zdarzenia pojawiające się w sys
temie. Udostępniają zwykle pojedynczą operację z ogranicze
niami (zazwyczaj o nazwie START). Operacja ta zazwyczaj jest typu ASER i może być skojarzona z przerwaniem (w takim wy
padku jest etykietowana jako ASER_BY_IT - dziwne jednak wydaje się, że w metodzie HRT-HOOD na etapie projektowania
S NaciśnięcieKlawisza ^
ASER START
Rys. 7. Obiekt sporadyczny NaciśnięcieKlawisza
logicznego nagle schodzi się bardzo nisko na poziom sprzęto
wy i decyduje o tym, w jaki sposób dana operacja będzie akty
wowana). Na rys. 7 przedstawiono typowy obiekt sporadyczny opisujący zdarzenie związane z naciśnięciem klawisza.
Komunikacja między obiektami
Reguły wykorzystywania operacji przez obiekty różnych ty
pów są rozwinięciem zasad zdefiniowanych w metodzie HOOD i są następujące:
■ obiekty aktywne m ogą wywoływać operacje dowolnych obiektów;
■ obiekty pasywne mogą wywoływać tylko operacje obiek
tów pasywnych;
■ obiekty chronione m ogą tylko wywoływać operacje obiek
tów chronionych i pasywnych, chyba że są to operacje asynchroniczne;
■ obiekty cykliczne i sporadyczne nie m ogą wywoływać je dynie operacji obiektów aktywnych, chyba że są to opera
cje asynchroniczne;
■ nie może zaistnieć cykliczna zależność wywołań operacji pomiędzy obiektami pasywnymi lub chronionymi - to zna
czy, że jeżeli A i B są obiektami pasywnymi (lub chroniony
mi) i A wywołuje operację B, to B nie może wywoływać operacji A.
Na rys. 8 przedstawiono przepływ sterowania oraz wymia
nę danych między obiektami aktywnymi Producent i Konsu
ment. Magazyn jest obiektem chronionym (Pr) o skończonej pojemności, stąd obie operacje m ają nałożone funkcjonalne ograniczenia aktywacji i są typu PSER. Producent przesyła do magazynu za pom ocą operacji WstawElement daną InElem, natomiast konsument pobiera z magazynu za pom ocą operacj i Pobierz element daną OutElem.
Niestety, w metodzie (HRT-)HOOD nie przewidziano me
chanizmu klarownej reprezentacji graficznej przepływu stero
wania między obiektami. Z rysunku wiadomo jedynie, że i Producent i Konsument korzystają z Magazynu, ale nie wia
domo, którą operację wykorzystuj e Producent, a którą Konsu
ment
44 Inform atyka 1/98
Sytuacje wyjątkowe
Z wykorzystywaniem operacji związana jest możliwość wystą
pienia sytuacji wyjątkowej (zazwyczaj oznacza to wystąpienie błędu takiego, jak na przykład próba dzielenia przez zero). Sygnał 0 powstaniu wyjątku jest przejmowany i obsługiwany lokalnie lub propagowany dalej. Na rys. 9 przedstawiono operację Brak- Miejsca oznaczoną przekreśloną strzałką, która występuje przy próbie wstawienia elementu do pełnej kolejki prioiytetowej.
Podobnie jak w przypadku opisu przepływu sterowania także 1 tutaj metoda HRT-HOOD nie pozwala określić na rysunku, jaka operacja może spowodować wystąpienie wyjątku i jakie
operacje przekazują dane.
'P a Sortownica >
Sortuj
y EIWe
\
ElWy
^ BrakMiejsca s /
P a KolejkaPriorytet W stawElem
PobierzElem
Rys. 9. Wystąpienie sytuacji wyjątkowej
Atrybuty dotyczące czasu
Ważną zaletą metody HRT-HOOD jest możliwość bezpośred
niego opisywania atrybutów charakterystycznych dla syste
mów silnie uwarunkowanych czasowo. W metodzie przewidziano między innymi następujące atrybuty obiektów cyklicznych:
■ deadline- wszystkie obiekty cykliczne, a także sporadycz
ne, mają określone linie krytyczne, przed którymi muszą za
kończyć się ich obliczenia;
■ opération_wcet - każda operacja udostępniana przez obiekt musi mieć określony maksymalny czas wykonania - oczy
wiście na etapie projektu są to wartości szacunkowe, które weryfikuje się po zakończeniu implementacji;
■ opération budget - każda operacja udostępniana przez obiekt musi mieć zdefiniowany budżet czasu wykonania oraz zastępczą, wewnętrzną operację, która będzie wywoła
na przez system wykonawczy przy przekroczeniu budżetu;
maksymalny czas wykonywania operacji jest więc równy sumie budżetu operacji i budżetu wewnętrznej procedury obsługi błędów;
■ period - okres powtarzania;
■ priority- priorytet wynikający z przyjętej metody szerego
wania (szeregowanie według wielkości okresu lub według linii krytycznych);
■ importance- każdy obiekt cykliczny i sporadyczny muszą mieć zdefiniowany poziom ważności określający, czyjest to
wątek silnie uwarunkowany czasowo, czy też nie (w tym drugim przypadku nie podlega on analizie szeregowalności i jest wykonywany w tle).
Obiekty sporadyczne m ają podobny zestaw atrybutów, z tym, że zamiast atrybutu period, określa się maksymalną czę
stotliwość napływania zdarzeń.
Proces dekompozycji
Dekompozycja jest to stopniowe uszczegółowianie kolejnych składowych projektowanego systemu. N a początku cały sys
tem jest reprezentowany jako pojedynczy obiekt aktywny - przodek dla wszystkich obiektów występujących w projek
cie. W kolejnych krokach procesu dekompozycji obiekt ten jest zatem przedstawiany w coraz bardziej szczegółowy spo
sób. Sama dekompozycja polega na przedstawieniu obiektu dekomponowanego jako zestawu obiektów (tzw. obiektów po
tomnych) i ukazaniu, w jaki sposób operacje obiektu dekom
ponowanego m ają być realizowane przez obiekty stanowiące jego dekompozycję. W metodzie HRT-HOOD dekompozycja przeprowadzana je st na dwóch płaszczyznach: jako dekom
pozycja obiektów i dekompozycja operacji.
Ogólne zasady dekompozycji obiektów można przedstawić następująco:
■ Obiekt aktywny może zawierać każdy inny obiekt;
■ Obiekt pasywny może zawierać tylko obiekty pasywne (tu widać wyraźną różnicę w porównaniu z metodą HOOD, gdzie obiekty pasywne mogły zawierać w swoim wnętrzu także obiekty aktywne);
■ Obiekt chroniony może zawierać inne obiekty pasywne oraz jeden obiekt chroniony. Obiekt chroniony z definicji musi zapewnić wzajemne wykluczanie dla swoich operacji przy dostępie do wewnętrznych danych chronionych. Nie może więc on posiadać oddzielnych, niezależnych wątków stero
wania. Dekompozycja takiego obiektu musi być tak prze
prowadzona, aby nie naruszać jego chronionego charakteru;
■ Obiekt sporadyczny może zawierać przynajmniej jeden obiekt sporadyczny oraz jeden lub więcej obiektów cyklicz
nych, pasywnych i chronionych.
Obiekt sporadyczny może zostać zdekomponowany do grupy obiektów sporadycznych komunikujących się przez obiekty chronione i będących ze sobą w relacji poprze
dzania (jeden obiekt sporadyczny powoduje wywołanie określonej operacji w kolejnym obiekcie sporadycznym i tak dalej). Dekompozycja taka jest oczywiście możliwa tylko w przypadku, o ile nie narusza ona sporadycznego charakteru obiektu-przodka;
■ Obiekt cykliczny może zawierać przynajmniej jeden obiekt cykliczny oraz jeden lub więcej obiektów pasywnych, chro
nionych i sporadycznych. Obiekt cykliczny może więc zo
stać zdekomponowany do grupy obiektów cyklicznych, pasywnych, chronionych oraz sporadycznych, pozostają
cych względem siebie w relacji poprzedzania. Podobnie jak w poprzednim przypadku dekompozycja taka jest możliwa tylko wtedy, o ile nie narusza ona cyklicznego charakteru obiektu-przodka.
Na diagramach obiekty potomne są zawsze przedstawiane wewnątrz swojego obiektu przodka. Z kolei operacje obiektów
inform atyka 1/93 45
P U B LIK A C JE
potomnych, realizujące dane operacje interfejsu obiektu przód- nego, natom iast obiekt SamaKlawiatura je st obiektem spo-ka, są na schematach graficznych połączone z tymi operacjami radycznym.
za pomocą linii przerywanych (patrz rys. 13). Ponadto operacja Obiekt SamaKlawiatura wywołuje procedury DodajZnak, obiektu-przodka podlegająca ograniczeniom funkcjonalnym CofnijZnak oraz KoniecLinii obiektu EkranZBuforem. Wy-powinna być implementowana jako operacja obiektu potomka, woływanie to następuje w sposób sporadyczny, w miarę jak która także podlega podobnym ograniczeniom funkcjonalnym, użytkownik wprowadza kolejne znaki z klawiatuiy. Wówczas to Dla przykładu, dopuszczalnymi dekompozycjami operacji, są: następuje przekazanie kolejnego wprowadzonego znaku
(strzał-ASER ASER ka na rysunku) do obiektu EkranZBuforem. Obiekt
SamaKla-ASER PAER wiatura posiada ponadto bezparametrową procedurę START
LSER PSER służącą do jego inicjalizacji w momencie startu całego systemu.
Dekompozycję tak projektowanego systemu można uwa- Obiekt EkranZBuforem m odeluje z kolei sam ekran, na żać za zakończoną tylko wtedy, jeżeli w jej efekcie zostaną wy- którym są w ypisywane całe linie tekstu oraz bufor na znaki eliminowane z projektu wszystkie obiekty aktywne. wprowadzane przez użytkow nika z klawiatury. Procedury Przykład dekompozycji pokazany jest na lysunku 10 i 11. tego obiektu są w ywoływane przez dwa obiekty: Zarządca-Rozpatrzmy pewien obiekt aktywny Konsola reprezentujący Konsoli i SamaKlawiatura, dlatego też obiekt EkranZBu-konsolę systemową. Jest to obiekt, który udostępnia dwie ope- fo re m m usi być typu chronionego. W idać tutaj kolejną racje: WyświetlLinię oraz CzytajLinię. Pierwsza z nich jest ope- niedoskonałość metody HRT-HOOD. Zauważmy, iż z rys. 13 racją asynchroniczną (ASER), druga natomiast jest operacją wcale nie wynika, które operacje obiektu EkranZBuforem silnie synchronizowaną (HSER) - podczas wywołania tej pro- są wywoływane przez obiekt SamaKlawiatura, a które przez cedury musimy bowiem czekać tak długo, aż na konsoli nie ZarządcęKonsoli. K onieczny je st zatem dodatkow y opis zostanie wprowadzona cała linia tekstu. Obiekt taki można więc słowny do takiego rysunku.
przedstawić graficznie, tak jak na rys. 10. Obiekt ZarządcaKonsoli korzysta z dwóch procedur: Po-bierzLinię oraz WyświetlLinię obiektu EkranZBuforem. N a
stępuje wówczas pom iędzy tymi obiektam i transm isja całej linii albo wprowadzonej przez użytkownika (gdy wywołuje
my procedurę PobierzLinię), albo też linii do w yświetlenia na ekranie (procedura WyświetlLinię). Obiekt chroniony Z a rządcaKonsoli implementuje natomiast dwie procedury udo
stępniane w interfejsie obiektu przodka (obiekt Konsola).
Procedura WyświetlLinię obiektu Konsola je st im plem ento
w ana przez procedurę WyświetlLin obiektu ZarządcaKon
soli, zaś procedura CzytajLinię przez procedurę CzytajLin tegoż obiektu. Fakt ten je st zaznaczony na rysunku za po- W następnej fazie projektow ania Konsola zostaje zde- m ocą strzałek z linią przerywaną,
kom ponowana na trzy obiekty potom ne (patrz rys. 11): Za- Powyższa dekompozycja obiektu-przodka Konsola jest rządcaKonsoli, SamaKlawiatura i EkranZBuforem. Obiekty w pełni zakończona, gdyż w procesie dekompozycji udało się Z arządcaK onsoli oraz EkranZBuforem są typu chronio- nam wyeliminować z systemu wszystkie obiekty aktywne (za
miast pojedynczego obiektu ak
tyw nego K onsola w ystępują trzy obiekty potomne: dwa chro
nione i jeden sporadyczny).
Obiekty środowiska
Specjalnągrupę obiektów w me
todzie HRT-HOOD stanow ią obiekty-środowiska. Za środowi
sko dla danego obiektu uznaje się te wszystkie obiekty, do któ
rych dany obiekt się odwołuje i które znajdują się na zewnątrz rozpatrywanego obiektu (a więc nie są to obiekty potomne da
nego obiektu). Pozwala to pro
jektantow i skoncentrować się tylko na pewnym, wybranym fragmencie systemu, traktując pozostałe jego części jako śro-Konsola
HSER 7 ^
WyświetlLinię CzytajLinię
p P T ZarządcaKonsoli >
________________ I_____________
WyświeLin Czyta Lin
i
£
l
t
-Pr EkranZBuforem DodajZnak
CofnijZnak KoniecLinii 'PobierzLinię
WyświetlLinię
T I
Rys. 11. Dekompozycja obiektu aktywnego ASER
HSER
f A
Konsola ^WyświetlLinię CzytajLinię
Rys 10. Pojedynczy obiekt aktywny przed dekompozycją
46 Inform atyka 1/98
PU BLIKACJE
dowisko, w którym pracuje dany fragment. Jest to szczególnie przydatne przy bardzo dużych i skomplikowanych projektach.
Obiekty środowiska oznaczane są na schematach literą E.
Przykładowe użycie obiektów środowiska podczas projek
towania systemu nadzoru w kopalni zawiera rys. 12. W przykła
dzie tym obiekt M onitorŚrodowiska składa się z dwóch obiektów: miernik H ,0 i detektor CH4 .Środowiskiem pracy dla tych obiektów są obiekty: konsola operatora, sterownik pom
py oraz rejestr stanów środowiska. Obiekty miernik H ,0 i de
tektor CH4 komunikująsię z obiektami środowiska, przekazując im dane: on, off lub Alarm. Zauważmy tutaj jednak pewną nie
doskonałość metody HRT-HOOD. Przy takim zobrazowaniu obiektów środowiska nie wiadomo dokładnie, które z operacji udostępnianych przez te obiekty są wywoływane (wiemy tyl
ko, jakie dane są do tych obiektów przekazywane).
Klasy ^
Jakkolwiek metoda HRT-HOOD jest, jak sama nazwa wskazuje, metodą obiektową to nie występuje w niej pojęcie mechanizmu dziedziczenia. Metoda ta jest bowiem raczej zorientowana na wielokrotne użycie danej klasy w różnych fragmentach tego samego czy też różnych projektów. Zatem klasę w metodzie HRT-HOOD można by raczej porównać do wzorca (template) występującego między innymi w języku C++. Definicja obiektu klasy polega na wyspecyfikowaniu: typu obiektu (aktywny, pasywny, cykliczny, chroniony czy też sporadyczny), jego na
zwy, interfejsu obiektu (operacji udostępnianych przez dany obiekt) oraz parametrów formalnych.
Systemy rozproszone
Przez system rozproszony rozumiemy sieć węzłów przetwarza
jących (procesorów) powiązanych ze sobą za pomocą medium komunikacyjnego. Bardzo ważne jest, iż węzły te nie współdzie
lą ze sobą pamięci operacyjnej. W związku z tym musi istnieć szereg mechanizmów w systemie pozwalających zarówno na
wymianę informacji (danych) pomiędzy obiektami jak i na wy
woływanie operacji innych obiektów, być może zlokalizowa
nych na odległych węzłach. W im plem entacji obiektów rozproszonych dla metody HRT-HOOD przyjmuje się model współpracy na zasadach klient-serwer. Oznacza to, iż węzeł, gdzie znajduje się dany obiekt jest serwerem, a więc udostęp
nia on operacje z interfejsu tego obiektu (na zasadzie zdalnego wywołania procedury) obiektom-klientom znajdującym się na innych węzłach. W metodzie HRT-HOOD fakt rozproszenia jest sygnalizowany przez określenie podziału wśród zdekompono- wanych obiektów (linia przerywana) na grupy obiektów przy
dzielonych do różnych węzłów w sieci.
Odwzorowanie zdekomponowanych obiektów terminalo
wych na poszczególne węzły w systemie rozproszonym nie jest w ogólności zadaniem łatwym. Takie rozmieszczenie musi bowiem uwzględniać wszelkie linie krytyczne (deadlines). Jed
nym z podejść przy przydzielaniu obiektów do węzłów tak, aby zachować wszelkie nałożone na system ograniczenia czasowe
nym z podejść przy przydzielaniu obiektów do węzłów tak, aby zachować wszelkie nałożone na system ograniczenia czasowe