Introduktion Kort allmän presentation och översikt Objektorienterad Realtidsprogrammering 2000 Introduktion Kort allmän presentation och översikt Kursledare Björn Eiderbäck, NADA, KTH Email: bjorne@nada.kth.se Adress: Rum 1641, 6tr NADA Osquars Backe 2 Tel: 7906277 Viktiga adresser Kursens hemsida: http://www.nada.kth.se/kurser/kth/2D4501 som innehåller allmän info, labblydelser, föreläsningsanteckningar, pekare till intressanta web-sidor och kursnyheter. Sidan kommer uppdateras kontinuerligt. Delfi och systemgruppens mottagning ligger på Osquars Backe 2 bottenplanet.

Presentation "bakgrund" Matematikerlinjens dataloglinje OO sen 1981 Simula 1981 Smalltalk 1985 (Java 1995) Objective Systems CASE-verktyg, databasgränssnitt och prototyper KTH Forskning inom framförallt CSCW och Distribuerad OO programmering Undervisning Egen (liten) "verksamhet" Kurslitteratur Programutveckling Föredrag och kurser Konsultverksamhet

... "intressen" OO, OOA, OOAD IDEer GUI CSCW CASE Distribuerade system Internet, CORBA Designmönster Från MVC (1985), via allmänt designintresse till designmönster (1995)

... "kurser idag" "preferenser" Objektorienterad Modellering Programmering och Analys Grafik och Interaktionsprogrammering Internetprogrammering "preferenser" Favoritspråk: Smalltalk Favorit IDE: VisualWorks Favoritmönster: (I det lilla) Strategy, (Större) MVC Roligast att programmera: Distribuerade realtidssystem inom CSCW Favoritwhiskey: Lagavulin ...

Deltagarna presenterar sig Tex Vem är jag? Var jobbar jag? Vad har jag för programmeringsbakgrund? språk metod system realtid, parallella eller distribuerade system Hur kommer objektorientering, UML och realtid in mitt arbete? Vad förväntar jag mig av kursen och hur vill jag utnyttja kunskaperna i mitt arbete?

Vad går kursen ut på? Kursens mål är att för att deltagarna ska ge fördjupad förståelse av dom olika faserna i analys, design och konstruktion av objektorienterade realtidsproblem, ge fördjupad inblick och förståelse av hur UML kan användas för att beskriva objektorienterade realtidssystem, ge inblick i möjliga problem och sätt att lösa dem i framförallt icke hårda realtidssystem, men även insikter i problem vid konstruktion av hårda realtidsproblem. för att deltagarna ska kunna utforma och konstruera objektorienterade realtidssystem

Efter genomgången kurs ska deltagarna kunna ta fram objektstruktur för multitrådat system/delsystem utifrån teknisk specifikation, t.ex. en funktionsspecifikation för ett paket; innefattande analys, modellering, strukturering och implementation beskriva syftet med, och UML-notation för olika modeller: användningsfallsmodell, modell av statisk struktur, modeller för att beskriva dynamik, sekvens, objektsamverkan, aktiviteter, tillståndsövergångar beskriva begrepp inom de olika modellerna, t.ex. klass, metaklass, kvalificerad association, paket, etc. Även definiera när de är användbara, samt hur de kan avbildas på en implementation. beskriva vad tråd-/process-objekt och ”passiva” objekt har gemensamt och vad som skiljer dem åt samt hur man delar upp systemet i trådar förstå vilka hänsyn som måste tas vid utformningen av multitrådade system behärska olika strategier och mekanismer för att vidmakthålla konsistenta tillståndsrepresentationer hos objekt, synkronisering, begränsning, lås, etc. behärska olika strategier och mekanismer för att hantera tillståndsberoende handlingar, "guarded methods", semaforer, "latches", transaktioner, etc. behärska olika idiom för trådbegreppet: aktörsbaserade, uppgiftsbaserade; behärska effektiva sätt att skapa trådar och trådstrukturer

Uppläggning av kursen Tre delar Del 1 (föreläsning 1-6, 7-10/3) Allmän introduktion (idag) UML, översikt Java kort introduktion med fokus på trådar och synkronisering Problem i "Concurrent Programming" Speciella tekniker för synkronisering Javas RMI (Remote Method Invocation) som vi använder för att "emulera" parallella processer och konstruera distribuerade system OCTOPUS översikt Översikt Parallella system RMI Översikt av krav- och arkitekturfaserna

... tre delar ... Del 2 (föreläsning 7-10, 26-27/4) Kravspecifikationer Systemarkitektur Analys Olika diagramtyper för analys (både OCTOPUS och UML) Strukturella modeller Funktionell modell Dynamisk modell Designfas och olika diagramtyper Prioritera processer Från design till implementation OOA, OOD fördjupning Modeller UML för realtid Processprioritering Implementation

... tre delar ... Del 3 (föreläsning 11-13 + projektpresentationer, 5-7/6) Större exempel ur Awad Speciella realtidsproblem, ett urval ur Lea, tex Exklusiva processer Synkronisering Lås Tillståndsberoenden Felhantering Transaktioner Trådar och relaterade problem Presentationer av färdiga eller pågående projektuppgifter Stort exempel Utvalda problem och lösningar ur Lea Hantering av trådar Projektuppgifter

... uppläggning ... Fyra laborationer Tre övningar En projektuppgift Utförs i grupper om två personer, både i labbsalar på NADA och "hemma" "Publicering" Laboration 1-2 delas ut vid föreläsning 2-3 Resten av labbarna kan anpassas lite efter deltagarnas intresse och delas ut mellan del 1 och del 2 av kursen Tre övningar Görs enskilt eller i grupper om två personer Övning 1 delas ut vid slutet av del 1 Resterande övningar delas ut senast under del 2 En projektuppgift En större enskild realtidsuppgift som innehåller både analys, design och implementation av prototyp Bestäms i samråd mellan kursledning och deltagare Redovisas antingen i slutversion eller som pågående arbete vid sista mötestillfället

Tid Tid är fundamentalt för oss Tidens betydelse i historien Även om vi inte har något tidssinne så lever vi i nuet Vi kan relatera till dåtid och framtid, dvs händelser i tidsdomänen Tidens betydelse i historien I antiken baserades tidangivelser sig främst på subjektiva bedömningar I och med den moderna vetenskapens födelse har vi fått objektiva metoder att mäta tid dessa metoder har sedan successivt förbättrats

... tidmätningens utveckling i historien Sekunder/ år 10-6 Atomuret 10-4 10-2 Kvartsklockan 100 Kompensation för tryck Kompensation för temperatur 102 Pendeln 1600 1700 1800 1900 2000 År

Realtidssystem Ett realtidssystem är ett system som ändrar sitt tillstånd som en funktion av (real-) tiden Ett inbäddat system en blandning av hård- och mjukvara och kanske mekaniska delar, designat för en speciell funktion kontrasterat mot en generell dator som kan göra olika saker Exempel: mikrovågsugn komponent i bil (bromsar, växlar, farthållare, osv) kaffebryggare video i viss mening är en generell dator också inbäddad, om man ser till dom delar som bygger upp det videokort, hårdisk, modem, floppy, ljud, mus, tangentbord, ...

Typiska realtidssystem, några exempel Styrsystem Telefonväxel Automatisk kontroll Intelligenta produkter Web service Beräkningssystem I/O GUI Simulering Mobil kod Inbäddade system i alla möjliga apparater

Ett realtidssystem har begränsad kapacitet Det går inte att konstruera det perfekta realtidssystemet! Load Hypothesis Definierar maximala belastningen som omgivningen antas generera Anges genom Minimala intervallet mellan transaktioner eller maximala intensiteten av händelserna Fault Hypothesis Definierar typerna och frekvenserna av fel som ett feltolerant system måste hantera Om dom identifierade felen inträffar så måste systemet ändå erbjuda en viss servicenivå

Klassificering av realtidssystem Mjukt realtidssystem är ett realtidssystem i vilket ett fel att hantera en händelse inom en viss tid inte betraktas som ett fel. Att något sker inom viss tid betraktas snarare som en kvalitet (dvs det är bra men inte nödvändigt) Exempel: kopiering av fil, nerladdning av websida, telefonväxel, ... Hårt realtidssystem ett svar som kommer för sent betraktas som ett fel. Ett svar som kommer för tidigt kan också betraktas som ett fel. det är alltså viktig att vi tar hand om händelser i tid här, annars kan kanske egendom eller liv gå till spillo Exempel: signalsystem för järnväg, kontrollenhet för kärnkraftverk, flygplan, vissa medicinska system,... Det finns ett kontinum mellan mjuka och hårda realtidssystem Hantering av händelser inom viss tid ej fundamentalt Måste vara färdigt i tid!

... Felsäkert (fail-safe) Feloperationellt (fail-operational) innebär att om något går fel så stoppas systemet Exempel: om signalsystemet för en järnväg fallerar så stoppas alla tågen Feloperationellt (fail-operational) i vissa fall kan vi inte stoppa systemet om fel inträffar utan måste ta hand om det på bästa sätt och fortsätta "operera" Exempel: kontrollenhet i flygplan Garanterad respons om vi bygger ett system efter principen att alla upptänkliga fel skall hanteras och systemet skall fungera även vi extrem belastning pratar vi om system med garanterad respons Bästa möjliga hantering vissa system är byggda efter principen att det är för dyrt att hantera alla möjliga situationer . Dom flesta realtidssystem är faktiskt byggda på detta sätt

Klassificering av realtidssystem Stor tillgänglighet Telefonväxel Mjukt RT-system Stor integritet On-line-bank Realtidssystem Felsäkert Järnvägssignaler Hårt RT-system Operationellt vid fel Flygkontroll

Vi kan också klassificera ett system efter om det är Reaktivt dvs om systemet kan reagera på händelser inom givna tidsramar Event-triggat dvs ett system som reagerar på externa händelser direkt och omedelbart Tids-triggat dvs ett system som reagerar på externa händelser vid fördefinierade tillfällen

Objektorienterade metoder Baseras på modeller av kommunicerande objekt Tongivande språk Simula-67 första OO-språket för bla simuleringar Spreds via Smalltalk (första versionen 1972, fick vidare spridning med Smalltalk-80) Java (1995) spred ideerna till en bredare allmänhet Metoder Booch Shlaer-Mellor OMT (Object-Modeling-Technique) CRC-kort (Class-Responsibility-Collaboration) av Beck och Cunningham Objectory/OOSE Med användningsfall som utgångspunkt OCTOPUS Baserad på OMT och Fusion med realtidstillägg

Parallellitet i realtidssystem Externa händelser kan inträffa när som helst, även parallellt, och måste behandlas inom givna tidsintervall Parallellitet möjliggör effektivt utnyttjande av hårdvaran Parallellitet ger oss möjlighet att dela upp ett program på separata aktiviteter utan att behöva beskriva den exakta ordningen mellan aktiviteterna

Exempel S E1 E2 S behöver kunna reagera på två olika event E1 och E2 S reagerar på E1 genom tre icke delbara operationer T1, T2 och T3 var och en av dem tar en tidsenhet S reagerar på E2 genom två icke delbara operationer T4 och T2 var och en av dem tar en tidsenhet Vi antar att i båda fallen är den första operationen kritisk men att dom efterföljande bara är viktiga Då en händelse inträffar skall systemet börja processa den första operationen inom en tidsenhet och vara klar med den högst två två tidsenheter senare S måste vara färdig med T3 inom sex tidsenheter efter E1 inträffat och med T2 inom fyra tidsenheter efter E2 inträffat

... Idealt parallellt system Parallellt system utan processbyte Antag att vi har följande situation 1. E1 inträffar vid t=0 2. E2 inträffar vid t=1.5 3. E1 inträffar vid t=3.5 Idealt parallellt system Systemet kan hantera ett godtyckligt antal sekvenser av operationer. Dvs systemet reagerar momentant efter varje händelse. se figur 1-2 s 6 Ett idealt parallellt system kan inte implementeras Parallellt system utan processbyte Varje sekvens av operationer körs obrutna. se figur 1-3 s 6 Vi kan inte uppfylla givna villkor Kvasiparallellt system Systemet kan exekvera olika processers operationer om vartannat. se figur 1-4 s 6 Vi kan uppfylla givna villkor

Objektorienterade realtidsmodeller Från krav till analys till design till implementation Då parallellitet ingår i realtidssystem så bör det ingå i modellen Objektorienterade modeller baseras på objekt Hur kan parallellitet och objektorientering kombineras? Ett objektorienterad angreppsätt är att antingen använda explicit modell för parallellitet (fig 1-5 s 7 högra delen) implicit modell för parallellitet (fig 1-5 s 7 vänstra delen) I den implicita modellen "fördröjs" designen av parallellitet vi utgår från objektmodellen I den explicita modellen utgår vi från parallellitet och processer Exempel explicit första versionen som inte klarar alla krav se fig 1-6 för att klara kraven så delar vi upp det hela på fler processer, se fig 1-7 implicit skapa objekt som utför operationerna (T1, T2 osv) se fig 1-8 för uppdelning, fig 1-9 för ideal modell och 1-10 för kvasiparallell modell

Parallella processer och objektorientering Simula hade visst stöd för parallella processer man använder korutiner, som dock kräver mer explicita beskrivningar av hur man går från en process till en annan Objektorientering (oo) påverkade inte utvecklingen i stort av multitrådade system under 70-talet dock är monitorbegreppet influerat av oo Parallella oo program är ofta uppbyggda mha samma programtekniker som sekventiella oo program OO-program av typ (händelsebaserade) GUI har mycket gemensamt med parallella progam Parallella oo-program skiljer sig från motsvarande i traditionella imperativa programspråk som C inkapsling, moduläritet, utvidgbarhet, säkerhet, polymorfi,...

Hur interaktivt, en klassificering låg objektinteraktion parallellitet medel interobjekt parallellitet hög intraobjekt parallellitet objekt1 objekt4 objekt6 f() f() f() h() object2 objekt5 g() g() g() objekt3 Typiskt inkluderar en högre nivå en lägre tid

Olika typer av fel Hur bör ett RT-system vara? Fel och felorsaker tillförlitligt systemet skall fungera länge säkert systemet skall med största sannolikhet inte fallera tillgängligt systemet skall kunna utföra "sin service" lätt att underhålla om systemet blir fel så bör det vara enkelt att åtgärda Fel och felorsaker Olika typer av fel kan uppkomma i mjuk eller hårdvara se följande två figurer

Klassificering av fel Värde Natur Timing Konsekvent Perception Inkonsekvent Fel Ofarlig Effekt Farlig Enstaka Frekvens Upprepad

Klassificering av felorsaker Slump Natur Avsiktligt Fysisk Orsak Design Intern Begränsning Extern Felorsak Utveckling Källa Operationell Temporär Varaktighet Permanent

Utvecklingsmetoder och tekniker för att beskriva objektorienterade och realtidssystem Under kursen kommer vi också diskutera oo principer, grunder, analys-design och titta närmare på OCTOPUS, UML samt designmönster