HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT LØSNINGSFORSLAG TIL EKSAMEN I STE6221 Sanntidssystemer Tid: Onsdag 16.03.2005, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator, med tomt minne. Ingen trykte eller håndskrevne hjelpemidler tillatt. Eksamen består av 6 oppgaver og 3 sider. Faglærer: Førsteamanuensis, Dr.ing. Per J. Nicklasson, Tlf. 76 96 64 01 Oppgavenes vekt er angitt i prosent av total poengsum. Hvert delspørsmål gir 5 poeng.
Oppgave 1 (10%) a) Forklar kort hva som er den fundamentale forskjellen mellom sanntidssystemer og andre typer datasystemer. Sanntidssystemer har krav til tidsfrister i tillegg til kravet om logisk korrekt utførelse. Et sanntidssystem må levere et logisk korrekt resultat i umiddelbar tidsmessig nærhet av en gitt tidsfrist. b) Forklar hva som menes med harde sanntidssystemer, og angi 4 kategorier sanntidssystemer. Med harde sanntidssystemer mener vi datasystemer der kravet til tidsfrist for leveranse av resultatet er absolutt, dvs. at systemet feiler dersom kravet til tidsfrist overskrides. Fire kategorier: Hardt-hurtig ( hard-fast ), hardt-langsomt ( hard-slow ), mykt-hurtig ( soft-hard ), mykt-langsomt ( soft-slow ). Oppgave 2 (15%) a) Forklar hva som menes med driftssikker programvare ( dependable software ). Med driftssikker programvare, mener vi programvare som er korrekt, pålitelig og sikker ( correct, reliable and safe ). b) Forklar kort hvilke typer programvarefeil som ofte oppstår ved design og koding av programvare. Syntaktiske feil (bruken av språket) Sematiske feil (mening og tolkning) Logiske feil Algoritmiske feil c) Forklar kort hva som menes med robust programvare. Hvordan kan en oppnå robust programvare. Med robust programvare, mener vi programvare som er i stand til å håndtere (dvs. som er tolerant overfor) feilsituasjoner, uansett om disse er generert internt (f.eks. divisjon med null), eller eksternt (f.eks. feil inngangsdata fra operatør eller feil med eksterne enheter). Oppgave 3 (20%) a) Forklar kort hvilke tjenester som inngår i en såkalt nanokjerne ( nanokernel ). En nanokjene inneholder typisk som et minimum følgende operativsystemtjenester: Opprettelse av oppgaver/prosesser (heretter kalt tasks ) Håndtering av tasks: Tidsfordeling mellom, og skifte av tasks ( scheduling and dispatching ) Håndtering av timing og avbrudd
b) Hvordan skiller en mikrokjerne ( microkernel ) seg fra en nanokjerne ( nanokernel )? En mikrokjerne inneholder flere tjenester (relatert til operasjoner på tasks, initialisering, gjensidig utelukking, synkronisering, kommunikasjon) enn en nanokjerne. Dessuten er det i læreboken lagt vekt på at en mikrokjerne også skiller seg fra en nanokjerne ved at den ofte benytter seg av en såkalt board support package for å forenkle grensenittet mot maskinvare av ulike typer. c) Forklar kort hva som menes med representative og syntetiske benchmarks. Representative benchmarks gir ytelsesmål for spesifikke RTOS tjenester (f.eks. interrupt response latency, process dispatch latency, context switch time, osv.). Ved bruk av syntetiske benchmarks måles ytelsen av operativsystemet ( response, throughput ) ved kjøring av kunstige (syntetiske) programmer som inneholder en rekke tjenester. De syntetiske programmene er satt sammen slik at det er mulighet for å teste ytelsen mhp. forskjellige typer og antall oppgaver, algoritme for tidsfordeling, belastning av systemet, osv. d) Forklar kort følgende begreper: 1. Preemptive scheduling Algoritme (eller rettere gruppe av algoritmer) for fordeling av tid mellom oppgaver, der tidsfordeleren ( scheduler ), kan avbryte en oppgave før den er ferdig, og gi prosessortid til en annen oppgave. 2. Deadlock To eller flere oppgaver som venter på hverandre (eller indirekte på hverandre via ressurser som andre oppgaver har), på en slik måte at ingen av dem får gjort noe som helst. 3. Prority inversion En oppgave med høy prioritet må vente på en oppgave med lavere prioritet før den kan kjøre. 4. Mutual exclusion Gjensidig utelukkelse - mekanisme for håndtering av felles (delte) ressurser som sikrer at to oppgaver ikke kan få tilgang til samme ressurs på en slik måte at det oppstår en feilsituasjon (f.eks. ødelagt data, feil innlesning fra enhet, osv.). 5. Tick Sanntidssystemets minste tidsenhet systemets hjerterytme. Andre tidsenheter er gjerne hele multiplum av et tikk. Oppgave 4 (15 %) a) Forklar kort hvilke faser som inngår i et prosjekt for utvikling av programvare. Tegn en skisse.
Problemanalyse, spesifikasjon, design av arkitektur, fysisk design (allokering til maskinvare), implementasjon (koding), testing og debugging, vedlikehold. b) Fossefallmetoden er en idealisert metode for beskrivelse av programvareutvikling. Forklar kort hvorfor dette ikke er en god beskrivelse av virkelige utviklingsprosjekter. For det første antar man i denne beskrivelsen av et utviklingsprosjekt at kunden kommer til leverandøren med et klart definert problem. Slik er det ikke, og vanligvis er det omfattende kommunikasjon og anbudsrunder involvert før kundens behov er beskrevet i tilstrekkelig grad overfor leverandøren. Den andre svakheten med metoden er at det antas at prosjektet går direkte og uten vanskeligheter fra den ene fasen til den andre. Slik er det ikke i virkeligheten, og ofte må man i et utviklingsprosjekt gå tilbake til tidligere faser for å endre f.eks. kode, design, og kanskje til og med spesifikasjoner. Det er altså en iterasjon mellom de ulike faser i et virkelig prosjekt som fossefallmetoden ikke beskriver. Disse synliggjøres som tilbakekoblinger mellom de ulike fasene. c) Avgjør om følgende påstander vedrørende utvikling av programvare for innebygde systemer er korrekte eller ikke, fulgt av en kort begrunnelse: 1. Feil som introduseres i de første faser av et programvareutviklingsprosjekt kan lett rettes opp senere i prosjektet. Ikke korrekt! Det vil sannsynligvis koste ganske mye å rette opp feil som oppdages i f.eks. spesifikasjoner etter at en har kodet, dersom det i det hele tatt lar seg gjøre uten å begynne på nytt. 2. Så snart kunden har skissert hva han ønsker, kan kodingen begynne. Ikke korrekt! Først må det utformes en skikkelig spesifikasjon via dialog med kunden, deretter må arkitekturen til systemet designes. 3. Det er viktig at hele organisasjonen har samme oppfatning av hva som skal til for å oppnå programvare med god kvalitet. Korrekt! Det er svært vanskelig for enkeltpersoner i en organisasjon å oppretteholde forståelse for, og krav til kvalitet, dersom det ikke er en overordnet forståelse for dette i hele organisasjonen. 4. Dersom koden er i henhold til spesifikasjonen, vil også sluttproduktet være feilfritt. Ikke korrekt! Spesifikasjonen kan også være feil, eller kan tolkes på ulike måter, slik at sluttsystemet ikke gjør det kunden ønsket, selv om koden er feilfri. 5. En stor del av de valg som skal gjøres vedrørende utformingen av koden bør overlates til hver enkelt programmerer. Ikke korrekt! Dette gir rom for såkalte smarte løsninger og programmeringsskikk som i ettertid kan gjøre det vanskelig å vedlikeholde systemet. Hver enkelt programmerer bør ha et sett med overordnede regler som skal følges. Det bør i tillegg være klart spesifisert hva koden skal utføre og hvilket grensesnitt koden skal ha. Oppgave 5 (15%) a) Hva er et use case?
Et use case illustrerer en måte en aktør benytter et system på for å oppnå et ønsket resultat. b) Hva er hensikten med å benytte teknikker som involverer use cases? Use case -teknikker gir en formalisert metode for å: Analysere kundens krav. Organisere og presentere krav på en brukbar, meningsfull og komplett måte. Minimalisere forvirring og misforståelse mellom kunde og utvikler. Validere design på systemnivå. Utvikle spesifikasjoner for programvaren. Definere grenser for systemtest (funksjonalitet, ytelse, bruk). Hensikten med et use case er å illustrere hvorfor systemet benyttes og hvem som benytter det. Et use case kan bestå av aktører ( actors ), use cases og use case - beskrivelser. Hvert system har sin egen modell, der aktører presenterer brukernes roller. Grunnen til at disse aktørene benytter systemet er vist som et sett av use cases innisystemetsytregrense( boundary ). Dette støttes opp av use case beskrivelser. c) Angi hensikten med, og beskriv syntaks og semantikk for et UML sekvens-diagram. Den fundamentale hensikten med UML sekvensdiagram er å vise samhandlinger mellom objekter over tid. Det grunnleggende konseptet for et system med to objekter er vist i figuren under. Time Object 1 Object 2 T 0 T 1 T 2 T 3 T 4 Send message Message arrival and detection Message arrival and detection Send acknowledgement Diagrammet illustrerer: Hvilke meldinger som sendes. Når meldinger sendes.
Hvem sender og mottaker er. Tidsforløp mellom sending og mottak. De vertikale linjene kalles livslinjer (lifelines) i UML. Andre aspekter ved semantikk i UML sekvensdiagrammer er: (i) Focus of control : Tidsperioden som et objekt benytter for å utføre en aksjon kalles dets focus of control. Dette representeres ved å vise livslinjen som et høyt, tynt rektangel mens aksjonen utføres. Ellers er livslinjen tegnet som stiplet linje. (ii) Melding eller stimuli: UML definerer kommunikasjonen mellom objekter som en stimuli, vist som en horisontal pil mellom livslinjer. Notasjon er vist i figur under. Flat flow of control Nested flow of control Procedure return (optional) T 0 T 1 Time elapses during messaging Oppgave 6 (25%) a) Forklar kort hva som menes med begrepene statisk og dynamisk analyse av kode. Med statisk analyse mener vi inspeksjon av kode (listing) for å sjekke om koden er i henhold til gitte kriterier. Ved dynamisk analyse kjøres koden, og vi foretar en dynamisk testing av koden opp mot forventet respons. Sammen med analyse av dekningsgrad ( coverage analysis, dvs. et mål på hvor stor del av koden som er testet), utgjør dynamisk testing det vi betegner med samlebegrepet dynamisk analyse. Både statisk og dynamisk analyse kan utføres manuelt eller automatisk. b) Forklar hva som menes med McCabe s syklomatiske kompleksitetsindex. Angi formelen for denne indeksen v(g). McCabe s syklomatiske kompleksitetsindex er et mål på kompleksiteten av et gitt kodesegment. Først tegner vi kontrollflytgrafen for koden, der hver setning i koden ( statement ) er en node i grafen. Disse forbindes med linjer. Antall noder benevnes med n, og antall linjer mellom nodene med e ( edges ), v(g) (e-n) 2. Indeksen angir antall uavhengige veier gjennom kontrollflytgrafen til koden. c) Gitt koden i figuren under. Hva er v(g) for dette kodesegmentet, og hvordan henger denne verdien sammen med hvor mange tester av koden en minst bør utføre? v(g) (e-n) 2 (5-5) 2 2. Bør minst kjøre 2 tester som er utformet slik at en tester begge de to alternative veiene gjennom koden.
d) Forklar kort hva som menes med analyse av dekningsgrad ( coverage analysis ) og hvorfor dette er viktig ved programvareutvikling. Med analyse av dekningsgrad, mener vi en analyse av koden for å fastsette hvor stor del av koden som er testet. Viktig for å avsløre evt. deler som ikke er testet. e) Angi 3 matematiske mål for dekningsgrad ( coverage ) relatert til et gitt kodesegment. Dekningsgrad defineres generelt som D n/n,dern er antall tilfeller vi har testet av totalt N mulige slike tilfeller. Med dette som utgangspunkt kan vi f.eks. definere flgende fire mål (kun 3 av disse kreves): S s/s Statement coverage, dekning av antall setninger Dc d/d Decision coverage, dekning av antall valg i koden Pc p/p Path coverage, dekning av antall veier gjennom koden Cc c/c Condition coverage, dekning av antall logiske forhåndsbetingelser (Boolske uttrykk)