Objektorienterad modellering i realtid
Objektorienterad modellering i realtid ( ROOM ) är ett domänspecifikt språk .
ROOM utvecklades i början av 1990-talet för modellering av realtidssystem . Det initiala fokuset låg på telekommunikation , även om ROOM kan appliceras på alla händelsestyrda realtidssystem.
ROOM stöddes av ObjecTime Developer (kommersiellt) och implementeras nu av det officiella Eclipse-projektet eTrice
När UML2 definierades (version 2 av UML med realtidsförlängningar) antogs många delar av ROOM.
Koncept och nyckelbegrepp i RUM
ROOM är ett modelleringsspråk för definition av mjukvarusystem. Det tillåter fullständig kodgenerering för hela systemet från modellen. ROOM kommer med en textuell såväl som med en grafisk notation. Typiskt åtföljs den genererade koden med manuellt skriven kod, t.ex. för grafiska användargränssnitt ( GUI ). Koden kompileras och länkas mot ett runtime-bibliotek som tillhandahåller basklasser och bastjänster (t.ex. meddelandehantering).
ROOM beskriver ett mjukvarusystem längs tre dimensioner: struktur, beteende och arv. Följande avsnitt kommer att förklara dessa tre aspekter mer i detalj.
Strukturera
Den strukturella synen i ROOM är sammansatt av skådespelare eller kapslar . Skådespelare kan kommunicera med varandra med hjälp av portar . Dessa portar är anslutna med bindningar . Skådespelare utbyter meddelanden asynkront via portar och bindningar. Till varje port är ett unikt protokoll tilldelat. Ett protokoll i ROOM definierar en uppsättning utgående och en uppsättning inkommande meddelanden. Portar kan kopplas ihop med en bindning om de tillhör samma protokoll och är konjugerade till varandra. Det betyder att en port skickar protokollets utgående meddelanden och tar emot de inkommande. Denna port kallas den vanliga hamnen. Dess peer-port, den konjugerade porten, tar emot de utgående meddelandena och skickar de inkommande i protokollet. Med andra ord är en port kombinationen av ett obligatoriskt och ett tillhandahållet gränssnitt i en roll (eftersom ett och samma protokoll kan användas av flera portar hos en aktör).
En skådespelare kan innehålla andra skådespelare (som en komposition ). I ROOM kallas dessa för skådespelarereferenser eller förkortat actor refs . Detta gör det möjligt att skapa strukturella hierarkier av godtyckligt djup.
Aktörens portar kan vara en del av dess gränssnitt (synlig från utsidan) eller en del av dess struktur (används av sig själv) eller båda. Portar som endast ingår i gränssnittet kallas reläportar . De är direkt anslutna till en port för en underaktör (de delegerar till underaktören). Portar som endast ingår i strukturen kallas interna ändportar . Portar som hör till båda, struktur och gränssnitt, kallas externa ändportar .
Beteende
Varje aktör i ROOM har ett beteende som definieras med hjälp av en hierarkisk finita-state-maskin , eller bara tillståndsmaskin för kort. En tillståndsmaskin är en riktad graf som består av noder som kallas tillstånd och kanter som kallas övergångar . Tillståndsövergångar utlöses av inkommande meddelanden från en intern eller extern slutport. I detta sammanhang kallas meddelandena ibland även för händelser eller signaler . Om en övergång anger en viss utlösare sägs den utlösas om tillståndsmaskinen är i källtillståndet för övergången och ett meddelande av den typ som anges av utlösaren anländer. Därefter ändras tillståndet till måltillståndet för övergången.
Under tillståndsändringen exekveras vissa delar av kod. Programmeraren (eller modelleraren) kan koppla dem till tillstånden och övergångarna. I ROOM är denna kod skriven på det så kallade detaljnivåspråket , vanligtvis målspråket för kodgenereringen. En stat kan ha ingångskod och utgångskod . Under en tillståndsändring exekveras först utgångskoden för källtillståndet. Därefter åtgärdskoden för avfyrningsövergången och slutligen ingångskoden för måltillståndet. En typisk del av dessa koder är sändningen av meddelanden genom skådespelarens portar.
Tillståndsmaskiner i ROOM har också en grafisk notation som liknar UML-tillståndsdiagrammen . Ett exempel visas i diagrammet i detta avsnitt.
En tillståndsmaskin kan också ha en hierarki i den meningen att stater kan ha undertillståndsmaskiner. I likhet med strukturen kan detta utökas till godtyckligt djup. För detaljer om semantiken för hierarkiska tillståndsmaskiner hänvisar vi till originalboken.
Ett viktigt koncept i samband med tillståndsmaskiner är exekveringsmodellen för körning till slutförande . Det betyder att en aktör bearbetar ett meddelande helt innan den accepterar nästa meddelande. Eftersom run-to-completion semantiken garanteras av exekveringsmiljön, behöver programmeraren/modelleraren inte hantera klassisk trådsynkronisering. Och detta trots att typiska RUM-system är mycket samtidiga på grund av den asynkrona kommunikationen. Och kanske är det värt att betona att den asynkrona karaktären hos ROOM-system inte är av misstag utan återspeglar den inneboende asynkroniciteten hos t.ex. den maskin som styrs av programvaran. Detta kräver definitivt ett annat tankesätt än det som behövs för funktionell programmering av synkrona system. Men efter en kort stunds vana kommer det att vara uppenbart att asynkront kommunicerande tillståndsmaskiner är perfekt lämpade för kontrollprogramvara.
Arv
Liksom andra objektorienterade programmeringsspråk använder ROOM konceptet klasser . Aktörer är klasser som kan instansieras som objekt flera gånger i systemet. Naturligtvis spårar varje instans av en skådespelare sitt eget tillstånd och kan kommunicera med andra instanser av samma (och andra) klasser.
I likhet med andra moderna programmeringsspråk tillåter ROOM nedärvning av skådespelarklasser. Det är ett enskilt arv eftersom en skådespelarklass kan härledas från en annan skådespelarklass (dess basklass ) . Den ärver alla funktioner i basklassen som portar och actor refs, men även statsmaskinen. Den härledda aktörsklassen kan lägga till ytterligare tillstånd och övergångar till den ärvda.
Skiktning
Ett sista kraftfullt koncept för ROOM är skiktning . Detta begrepp hänvisar till de vertikala skikten av ett mjukvarusystem som består av tjänster och deras klienter. ROOM introducerar begreppen tjänståtkomstpunkt (SAP) för klientsidan och tjänsteförsörjningspunkt (SPP) för serversidan. Ur en aktörs implementeringssynpunkt fungerar SAP och SPP som hamnar. Liksom portar är de associerade med ett protokoll. Men förutom portar behöver de inte (och kan inte ens) bindas explicit. Snarare är en aktör bunden till en konkret tjänst genom en lagerkoppling och denna bindning av en tjänst sprids rekursivt till alla underaktörer till denna aktör. Detta koncept är mycket likt beroendeinjektion .
Litteratur
- Bran Selic, Garth Gullekson, Paul T. Ward: "Real-Time Object-Oriented Modeling", New York, John Wiley & Sons Inc, 1994, ISBN 978-0-471-59917-3
externa länkar
-
Media relaterade till objektorienterad modellering i realtid på Wikimedia Commons
