Prosjekt: Rational Rose RT - Institutt for teknisk kybernetikk - NTNU

NTNU, Institutt for teknisk kybernetikk/ 

SINTEF Elektronikk og kybernetikk, Avd. Reguerlingsteknikk 

Øyvind Stavdahl 2000 

Trygve Lunheim 2000 

VUE3001-1 

Sanntidsprogrammering 

Prosjekt 

Modellering av heisstyring med 

Rational Rose RealTime 

,QQOHGQLQJ 

ITKs heislab benyttes i flere øvinger i flere fag. I denne øvingen skal vi kun bruke lab’en som 

et prosesseksempel; øvingen går ut på å modellere (beskrive) funksjonaliteten til heisens styresystem 

ved hjelp av CASE-verktøyet 5RVHÃ5HDO7LPH (heretter 5RVHÃ57) fra 5DWLRQDOÃ6RIWZDUHÃ 

&RUS 

2PÃ5RVHÃ57 

Rose RT er basert på en utvidet versjon av modelleringsspråket UML. Utvidelsen gjør det mulig 

å beskrive systemfunksjonalitet på en så komplett måte at Rose RealTime er i stand til å omsette 

modellen til høynivå programkode (foreløpig C eller C++) som så kan kompileres og simuleres/ 

kjøres på en PC og et antall andre maskinvare- og operativsystemplattformer. I denne øvingen 

skal vi imidlertid bare bruke Rose RT som modelleringsverktøy samt genererer C++-kode for 

gitt operativsystem og kompilator, vi skal ikke kjøre/simulere modellen. 

1¡GYHQGLJÃIRUKnQGVNXQQVNDS 

Øvingsteksten forutsetter en viss grunnleggende kjennskap til UML-relaterte begreper og Rose 

RT ut over det som beskrives i det følgende. Bruk Rose RTs on-line hjelpesystem flittig - dette 

er omfattende og oversiktlig. 

$EVWUDNVMRQVQLYnHUÃLÃ5RVHÃ57 

I Rose RT opereres med modell- og systemspesifikasjoner på flere nivåer med hensyn på abstraksjon/teknologiavhengighet. 

Dette muliggjør gjenbruk av modeller på tvers av maskin- og 

operativsystemplattformer. 

Følgende nivåer kan identifiseres: 

80/QLYnÃMed en utvidet UML-modell modelleres blant annet systemets HVVHQVLHOOHÃORJLNN, 

dvs. systemets logiske virkemåteÃbeskrevet uten å ta unødvendig hensyn til teknologiske 

forhold som maskinvareplattform etc. 

UML kan benyttes helt fra utviklingsprosjektets aller første stadium, der en typisk benytter 

XVHFDVHV til å dele inn systemets interaksjoner med omverdenen etter hvilken funksjonalitet 

som benyttes i ulike scenarier. Delfunksjonalitet tilordnes så ulike former for klasser (stere-

SIE3050 Sanntidsprogrammering s. 2 

otyper) kalt NDSVOHU, SRUWHU, SURWRNROOHUÃosvÃDisse klassenes relasjoner (arv/generalisering, 

aggregering etc.)modelleres med et hensiktsmessig antall NODVVHGLDJUDPPHU (&ODVVÃ'LD 

JUDPV). Interaksjon (kommunikasjon) mellom objektene kan konkretiseres med VHNYHQVGLD 

JUDPPHU der dette bidrar til oversikten. 

Kapslenes indre tilstandsdynamikk modelleres i 7LOVWDQGVGLDJUDPPHU (6WDWHÃ'LDJUDPV), ett 

diagram for hver kapsel. Til hver tilstandstransisjon knyttes WULJJHUV, dvs. en spesifiserer 

hvilke meldinger på hvilke porter som skal aktivere den enkelte transisjon. Til en transisjon 

kan en også knytte DNVMRQHU som kapselen skal utføre når den aktuelle transisjonen foretas. 

Separate aksjoner kan også knyttes til hhv. inngang til/utgang fra enhver tilstand i modellen. 

Aksjoner defineres direkte med C/C++-syntaks, og består typisk av datamanipulasjon og/ 

eller utsendelse av et antall utgående meldinger gjennom kapselens port(er). 

I kapsler som inneholder underkapsler (aggregering), benyttes et VWUXNWXUGLDJUDP (6WUXFWXUHÃ 

'LDJUDP) til å modellere meldingsutveksling mellom kapslene. Denne diagramtypen inngår 

ikke i standard UML. Strukturdiagrammet er ekvivalent med det som i Strukturert Analyse 

(SA) omtales som et GDWDIO\WGLDJUDP, men benytter en noe annerledes grafisk syntaks. 

Kapslene 1 tilsvarer det som i SA kalles prosesser, og dataflyten defineres ved å forbinde 

parvis kompatible porter (dvs. porter som har samme protokoll men konjugerte roller) på 

kommuniserende kapsler. 

.ODVVHGLDJUDPPHU, WLOVWDQGVGLDJUDPPHU (med spesifiserte triggere og aksjoner) samt VWUXN 

WXUGLDJUDPPHU danner grunnlaget for senere generert programkode. Øvrige modellelementer 

(som use-casediagrammer og sekvensdiagrammer) benyttes kun som hjelpemidler 

til å få oversikt over den aktuelle problemstillingen. 

.RPSRQHQWQLYnÃNår systemets essensielle logikk er modellert, kan modellen deles inn i 

logiske NRPSRQHQWHU (&RPSRQHQWV). En komponent er et subsett av det totale systemets 

funksjonalitet som vi ønsker å gruppere sammen, gi en samlebetegnelse og endelig kompilere 

og lenke til et kjørbart program eller et bibliotek. 

Den enkleste måten å definere en komponent på, er å bruke Rose RTs innebygde Component 

Wizard, som finnes under Build-menyen. Wizard’en lar oss spesifisere hvilke deler av 

totalmodellen som skal inngå i komponenten (“Top Capsule”), samt hvilket operativsystem 

og hvilken kompilator, lenker, debugger etc. vi ønsker å benytte når komponenten skal bygges. 

Dette må spesifiseres for at Rose RT skal vite hvilket bibliotek som senere skal lenkes 

inn for å danne et ferdig kjørbart system 2 . 

,QVWDQVQLYnÃNår hele systemets funksjonalitet er fordelt på et antall komponenter, må komponentene 

instansieres og fordeles på aktuelle maskinvareplattformer. 

Dette gjøres ved å åpne et 'HSOR\PHQWÃ'LDJUDP, deklarere en ny 3URFHVVRU, definere prosessorens 

(egentlig: plattformens) fysiske prosessorfamilie og operativsystem, og så instansiere 

den aktuelle komponenten på den aktuelle prosessoren. 

For små systemer som skal kjøres på en enkelt datamaskin vil det være aktuelt å definere en 

enkelt komponent med hele systemets funksjonalitet og instansiere denne samlet. Dersom 

1. Egentlig er der kapselUROOHU som modelleres i strukturdiagrammene; En kapselrolle refererer til en gitt 

kapsels grensesnitt (porter), og enhver kapsel avledet av den angitte kapsel kan fyllle kapselrollen. 

Hvilken kapsel som faktisk instansieres i den aktuelle rollen kan avgjøres senere – til og med utsettes 

til UXQWLPH (dynamisk instansiering)! 

2. Biblioteket inneholder realisering av en enkel hendelsesorientert sanntidskjerne med meldingskøer 

etc., som må ligge “i bunnen” av systemet vårt for at kapsler skal kunne kommunisere og prosessere 

meldinger. Dette biblioteket benytter bl.a. funksjonskall til den aktuelle kompilatorens standardbibliotek, 

og må derfor tilpasses den aktuelle programvareplattformen.


systemet skal distribueres på flere (identiske eller ulike) plattformer, er det derimot nødvendig 

å dele inn i et tilsvarende sett komponenter og instansiere disse i henhold til den 

aktuelle distribusjon. (QÃNDQÃLPLGOHUWLGÃJMHUQHÃRSHUHUHÃPHGÃIOHUHÃSDUDOOHOOHÃNRPSRQHQWHUÃRJÃ 

LQVWDQVHUÃPHGÃVDPPHÃHOOHUÃRYHUODSSHQGHÃVXEVHWWÃDYÃV\VWHPHWÃ'HWWHÃJM¡UÃGHWÃPXOLJÃnÃWHVWHÃ 

XWÃKHOHÃV\VWHPHWÃSnÃHQÃHQNHOWÃPDVNLQÃW\SLVNÃXWYLNOLQJV3&HQÃI¡UVWÃRJÃGHUHWWHUÃGLVWULEXHUHÃ 

GHWÃSnÃHWÃDQWDOOÃDQGUHÃSODWWIRUPHU 1 

3HUVRQKHLVÃÃIXQNVMRQHOOÃVSHVLILNDVMRQ 

Heisen skal betjene fire etasjer. Inne i heisen finnes det et panel med ILUHÃNQDSSHU hvor en kan 

velge hvilken etasje man skal til. Bak hver knapp ligger det et O\VVLJQDO som skal settes når 

knappen er trykket. Lyset i knappen skal slukkes når heisen har nådd den angitte etasjen. På 

samme panel er det en VWRSSNQDSS som skal nullstille alle etasjebestillinger og stoppe heisen. 

Heisen inneholder også en REVWUXNVMRQVI¡OHU (berøringsføler). Når denne gir utslag skal heisen 

stoppe (og døren åpnes hvis heisen er ved en etasje). 

Ved hver etasje finnes en HWDVMHGHWHNWRU. Når heisen har nådd ønsket etasje skal døra åpnes og 

holdes åpen i minst 3 sekunder. )LUHÃODPSHU viser hvilken etasje heisen er (eller sist var) i. 

I hver etasje er det to WU\NNQDSSHU merket 233 og 1('. Første etasje har bare 233-knapp og 

fjerde etasje har bare 1('-knapp. Når en av disse knappene er trykket skal heisen gå til vedkommende 

etasje. Hvis heisen allerede har et oppdrag, skal den kunne stoppe og ta med passasjerer 

som skal i samme retning. 233- og 1('-knappene har innebygd lys. Lyset skal tennes 

når knappen trykkes og slukkes når heisen kan ta med passasjerer i ønsket retning fra vedkommende 

etasje. 

Pådrag til heisen gis ved et analogt signal til en elektrisk motor. I tillegg angir et digitalt signal 

retningen på motoren. Figur 1 viser en modell av heisen. 

1. Vel og merke dersom en har mekanismer for meldingsutveksling på tvers av plattformene (via et nettverk).


)LJXUÃÃ6NLVVHÃDYÃKHLVODEHQÃ 

Endestopp 

Heisstyring 

DA1 

DIR 

EN 

Motordriver 

Endestopp 

4. etg. 

NED 

3. etg. 

NED 

OPP 

2. etg. 

NED 

OPP 

1. etg. 

OPP 

S 

Dør 

åpen 

Obstruksjon 

1 2 3 4


2SSJDYHU 

D 8VHFDVHV 

Ta utgangspunkt i den funksjonelle spesifikasjonen i forrige avsnitt og definer DNW¡UHU (DFWRUV) 

og use-cases som til sammen “utspenner” hele spesifikasjonen (dvs. de tekstlige beskrivelsene 

av samtlige use-cases skal til sammen inneholde/realisere alle funksjonelle krav/spesifikasjoner 

som er angitt). 

Tegn use-case-diagram(-mer) v.h.a. Rose RT og dokumenter use-casene i feltet merket “Documentation” 

nederst i vinduet. 

E 

2EMHNWDUNLWHNWXU 

Velg et passende sett av klasser (kapsler, porter, protokoller) som til sammen kan realisere systemets 

funksjonalitet. 

Tegn et (eller flere) klassediagram(-mer) som viser klassene og deres relasjoner. Dokumenter 

hvilken delfunksjonalitet som er tenkt tilordnet hver klasse (“Documentation”-feltet nederst i 

vinduet). 

Modeller kapslenes oppførsel v.h.a. tilstandsdiagrammer og deres samarbeid (kommunikasjon) 

v.h.a. strukturdiagrammer. Spesifiser triggere og aksjoner for transisjoner og tilstander. 

7LSV 

- Anta at det foreligger driverprogramvare for heismotoren, slik at motoren kan styres 

ved å sende meldingene 2SSRYHU, 1HGRYHU og 6WRSS til driveren. Modeller dette grensesnittet 

som en kapsel med én port og en relevant protokoll.Vurder hvilke andre elektromekaniske 

komponenter (knapper, lysindikatorer o.s.v.) som kan/bør abstraheres på 

tilsvarende måte som motoren. 

- Protokoller (klasser av stereotypen 3URWRFRO) brukes egentlig bare til å definere et 

sett meldinger som kan sendes/mottas gjennom porter tilordnet den aktuelle protokollklassen. 

En protokoll kan likevel gjerne ha et tilstandsdiagram som dokumenterer 

hvordan protokollen er tenkt benyttet, dvs. typiske/mulige signalsekvenser etc. Det 

genereres imidlertid ingen kode ut fra et slikt diagram, det er bare tenkt som en dokumentasjon 

av protokollen. Tilstandsmaskinene som faktisk skal benytte protokollen, må 

ligge i de kommuniserende kapslene. 

- Bruk aggregering og generalisering/arving på en hensiktsmessig måte. Tenk objektorientert 

– arving kan være et alternativ til å innføre logisk redundans i modellen. 

- Definer en toppkapsel som innkapsler alle de øvrige; dette er nødvendig for senere å 

kunne definere en NRPSRQHQW for hele systemet, jfr. oppgave c). 

F 

.RPSRQHQW 

Resultatet av de foregående oppgavene skal være en komplett analysemodell. Vi skal nå definere 

en komponent basert på analysemodellen, og knytte denne opp mot et bibliotek tilpasset en 

konkret programvareplattform. 

Definer en komponent som omfatter hele systemet ditt. 

Spesifiser C++ som komponentens kodespråk, “toppkapslen” fra oppgave b) som WRSOHYHOÃ 

FRPSRQHQW og “NT40T.x86-VisualC++6.0” (hvis dette er oppsettet ditt) som &RQILJXUDWLRQ.


Generer C++-kode for komponenten via menyen %XLOG, evt. ved å klikke på hammer-ikonet eller 

ved å trykke F7. 

7LSV 

- En Rose RT-modell kan inneholde flere komponenter. Før Build-operasjonen kan 

utføres må vi derfor spesifisere hvilken komponent som skal buildes. Dette gjøres 

enklest ved å høyreklikke på den aktuelle komponentens ikon i modellbrowserens 

&RPSRQHQWÃ9LHZ, og velge 6HWÃ$VÃ$FWLYH. Modellbrowseren viser den aktive komponentens 

navn med uthevet skrift. 

- Dersom Build-prosessen gir et uhensiktsmessig antall feilmeldinger, kan kapslene 

konsistenssjekkes enkeltvis ved å definere separate komponenter for kapslene og 

builde dem hver for seg. 

Som en øvelse kan du kikke gjennom den genererte koden for å få en føling med at den faktisk 

implementerer “ditt” system. 

På dette stadiet kan Build-prosessen settes til også å omfatte kompilering, slik at eventuelle syntaksfeil, 

udefinerte symboler etc. i aksjonskoden (koden som definerer aksjoner i forbindelse 

med tilstander og tilstandstransisjoner) kan detekteres. 

G 

,QVWDQV 

Vi skal nå ta skrittet helt ut og NM¡UH komponenten vår (siden vi skal kjøre den på en PC som 

ikke er tilknyttet den fysiske heisen, refererer vi gjerne til det vi skal gjøre som en VLPXOHULQJ). 

Vi må derfor spesifisere hva slags plattform GHQQHÃLQVWDQVHQÃDYÃNRPSRQHQWHQ skal kjøre på, inkludert 

prosessor- og operativsystemfamilie. 

Definer en ny prosessor (høyreklikk på 'HSOR\PHQWÃ9LHZ i modellbrowseren, og velg så 1\ 

3URVHVVRU). Åpne den nye prosessorens spesifikasjonsvindu (dobbeltklikk på prosessorikonet) 

og sett feltet &38 til “x86” og feltet 26 til “Windows-NT”. 

Instansier komponenten fra oppgave c) på den nye prosessoren ved å “dra-og-slippe” komponenten 

på prosessorens ikon. 

I større prosjekter vil det kunne foreligge flere komponenter instansiert på flere prosessorer 

samtidig. For oversiktens skyld kan instansieringen illustreres ved et 'HSOR\PHQWÃ'LDJUDP. 

Modellbrowseren inneholder som default et slikt diagram med tittelen 'HSOR\PHQWÃ9LHZ0DLQ; 

åpne dette diagrammet og dra-og-slipp prosessorikonet på diagrammet for å få en grafisk representasjon 

av prosessoren og den nye komponentinstansen. 

H 

6LPXOHULQJ 

Kjør systemetÃved å velge %XLOG5XQ eller ved å klikke på ikonet merket med et lyn. 

7LSV 

- En Rose RT-modell kan inneholde flere instanser. Før Run-operasjonen kan utføres 

må vi derfor spesifisere hvilken instans som skal kjøres. Dette gjøres enklest ved å 

høyreklikke på den aktuelle instansens ikon i modellbrowserens 'HSOR\PHQWÃ9LHZ, og 

velge 6HWÃ$VÃ$FWLYH. Modellbrowseren viser den aktive instansens navn med uthevet 

skrift. 

Dersom kompilering, lenking og oppstart av går greit, vil Rose RT nå sette opp et DOS-vindu 

(konsoll) for den nye prosessen. I Rose RT-vinduet vises nå et debuggings-grensesnitt der vi 

bl.a. aktivt kan starte/stoppe og single-step’e systemet, injisere meldinger til/logge meldinger 

fra systemets porter osv. Det henvisese til Rose RT-dokumentasjon for detaljer rundt debugge-


rens virkemåte og betjening. 

Evaluer modellen din ved å injisere meldinger, logge meldingstrafikk, generere sekvensdiagrammer 

etc. og sammenlikne modellens oppførsel med funksjonsbeskrivelsen i oppgaveteksten. 

I 

,QQOHYHULQJ 

Besvarelsen skal bestå av: 

- en epost evt. diskett med Rose RT-modellen du/dere har laget, samt 

- eventuelle utskrift av automatisk genererte sekvensdiagram(-mer) og annet som sannsynliggjør 

at modellen tilfredsstiller oppgavens funksjonsbeskrivelse. 

³3RVWÃ/DEEXP´ 

Vi har nå simulert vår systemmodell på en PC. Legg merke til at veien herfra og til OHYHULQJV 

IHUGLJÃSURGXNW er kort, og i prinsippet kun innebærer følgende arbeidsoperasjoner: 

- valg av maskinvareplattform (mikrokontrollerkort med den nødvendige I/O-kapasitet), 

- implementasjon av I/O-drivere for betjeningsorganer, indikatorer og motor (som foreløpig 

bare er “tomme” kapsler), 

- instansiering av systemet på den aktuelle prosessortypen, 

- kompilering og nedlasting til target.

Prosjekt: Rational Rose RT - Institutt for teknisk kybernetikk - NTNU

Create successful ePaper yourself

Delete template?

Save as template?