Introduktion Kort allmän presentation och översikt

1. Kursledare Björn Eiderbäck, NADA, KTH Email: bjorne@nada.kth.se Adress: Rum 1641, 6tr NADA Osquars Backe 2 Tel: 7906277 IntroduktionKort allmän presentation och översikt Objektorienterad Realtidsprogrammering 2000 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.

2. 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

3. ... • "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)

4. ... • "kurser idag" • 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 • ...

5. 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?

6. Vad går kursen ut på? • Kursens mål är att • 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

7. 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 Efter genomgången kurs ska deltagarna kunna

8. 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 Parallellasystem RMI Översikt av krav- och arkitekturfaserna

9. ... 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

10. ... 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

11. ... uppläggning ... • Fyra laborationer • 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

12. Tid • Tid är fundamentalt för oss • Ä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

13. ... 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

14. 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, ...

15. 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

16. 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å

17. 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!

18. ... • Felsäkert (fail-safe) • 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

19. 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 Operationelltvid fel Flygkontroll

20. 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

21. 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

22. 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

23. Exempel E1 E2 S behöver kunna reagera på två olika event E1 och E2 S 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

24. ... 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

25. 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

26. 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,...

27. g() h() f() Hur interaktivt, en klassificering lågobjektinteraktion parallellitet medelinterobjekt parallellitet högintraobjekt parallellitet objekt1 objekt4 objekt6 f() f() objekt5 object2 g() g() objekt3 Typiskt inkluderar en högre nivå en lägre tid

28. Olika typer av fel • Hur bör ett RT-system vara? • 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

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

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

31. 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