SDS Software Design Specification

Transkript

1 SDS Software Design Specification Heiskontrollsystem Gruppe 7 Gunhild Kristiansen, Arne Enger Hansen, Cecilie Vådahl, Kristian Vågen, Magnus Asbjørnsen, Martin Stenmark Høgskolen i Østfold 2003

2 FIGUROVERSIKT... 3 TABELLOVERSIKT INTRODUKSJON HENSIKT OMFANG DEFINISJONER OG FORKORTELSER REFERANSER OVERSIKT ARKITEKTONISK DESIGN OVERSIKT OVER MODULER/ KOMPONENTER STRUKTURER OG RELASJONER Klasse diagrammer Sekvensdiagrammer Collaboration diagram State diagrammer DETALJERT DESIGN MAL, FOR BESKRIVELSE AV KOMPONENTENE BESKRIVELSE AV KOMPONENT ELEVATOR BESKRIVELSE AV KOMPONENT ESL BESKRIVELSE AV KOMPONENT CENTRALPROCESSINGUNIT BESKRIVELSE AV KOMPONENT SIMULATORGUI BESKRIVELSE AV KOMPONENT EPANEL BESKRIVELSE AV KOMPONENT POSITION BESKRIVELSE AV KOMPONENT GUIELEVATOR BESKRIVELSE AV KOMPONENT CONTROLSWITCH BESKRIVELSE AV KOMPONENT CONTROLLER BESKRIVELSE AV KOMPONENT SORTEDQUEUE BESKRIVELSE AV KOMPONENT SQNODE BESKRIVELSE AV KOMPONENT STATUS BESKRIVELSE AV KOMPONENT IEP-OUT BESKRIVELSE AV KOMPONENT IEP-IN BESKRIVELSE AV KOMPONENT ICS-IN BESKRIVELSE AV KOMPONENT ICS-OUT BESKRIVELSE AV KOMPONENT CCC BESKRIVELSE AV KOMPONENT ACCESSCONTROL BESKRIVELSE AV KOMPONENT SHA BESKRIVELSE AV KOMPONENT FAULT BESKRIVELSE AV KOMPONENT ALERTRECEPTION BESKRIVELSE AV KOMPONENT INIT VEDLEGG SPORINGSTABELLER Sporing frem. Krav Design Komponent Sporing tilbake. Design komponent Krav FORKORTELSER OG DEFINISJONER PSEUDOKODE Side 2 av 65

3 4.4 KORTVERSJON AV KRAV EKSEMPEL PÅ INIT FIL REFERANSER Figuroversikt Figur_nummer Navn Side Figur 2.1 Overordnet systemoversikt 5 Figur 2.2 Klassediagram med ControlSwitch 8 Figur 2.3 Klassediagram som viser deler av modulen 10 heiskontrollsystem Figur 2.4 Klassediagram for GUI 12 Figur 2.5 Sekvensdiagram 1 - Tilkalle heis 14 Figur 2.6 Sekvensdiagram 2- Løkke i GUIElevator 15 Figur 2.7 Sekvensdiagram 3- Viser hva som skjer i løkka til 16 Elevator-objektene Figur 2.8 Collaboration diagram 1 - Gå til etasje 17 Figur 2.9 Statediagram 1 - Viser hvordan heis går opp og ned 19 Figur 2.10 Statediagram 2 Viser hvordan ControlSwitch skifter tilstand 19 Tabelloversikt Tabell_nummer Navn Side Tabell 2.1 Notasjonselementer, Sekvensdiagram 13 Tabell 2.2 Notasjonselementer, Collabration diagram 17 Tabell 2.3 Notasjonselementer, Statediagram 18 Tabell 3.1 Mal, for beskrivelse av komponentene 20 Side 3 av 65

4 1. Introduksjon Denne seksjonen skal inneholde en oversikt over hele dokumentet 1.1. Hensikt Hensikten med dette dokumentet er å presentere softwaren og beskrive hvordan systemet er strukturert for å tilfredsstille de kravene som ble funnet i SRS. Mens SRS fokuserte på hva vi skulle gjøre, fokuserer dette dokumentet på hvordan systemet vil bli konstruert. Kravene tolkes og er grunnlaget for beskrivelse av systemstrukturen, software komponentene, grensesnitt og data som er nødvendige for implementasjonen Omfang Vi skal utvikle et heiskontrollsystem. Det vil si at vi primært ikke implementerer noen annen del av systemet. Heiskontrollsystemet er heissystemets hjerne, og utfører alle de logiske beslutningene (se figur 2.1). Det skal lages et GUI for å simulere heisfysikken, som skal kunne brukes for å bekrefte at heiskontrollsystemet virker. Vi vil også definere et grensesnitt mot de andre systemene. Vi skal altså ikke implementere de andre systemene Definisjoner og forkortelser Vi har valgt å legge definisjoner og forkortelser i vedlegg Referanser Vi har valgt å legge referanser i vedlegg Oversikt Dette dokumentet er skrevet etter Software Design Specifications (IEEE Std 1016), men vi har valgt å lage noen underpunkter der vi har sett nødvendigheten av dette. I punkt 2 kommer vi til å ta for oss det arkitektoniske designet. Ved hjelp av diagrammer og tekst skal vi å illustrere systemet på en overordnet og oversiktlig måte. I punkt 3 skal vi beskrive den detaljerte design. Her vil en detaljert beskrivelse av hver enkelt komponent ligge. Hensikten med den detaljerte designen, er å produsere en total design spesifikasjon som vil tilfredsstille alle kravene til systemet. I punkt 4 ligger alle vedleggene vi mener er relevante for denne rapporten. Sporingstabeller, forkortelser/definisjoner, referanser, pseudokode og en kortversjon av de kravene som danner grunnlaget for denne rapporten.. Side 4 av 65

5 2. Arkitektonisk design Denne seksjonen gir en oversikt over systemets arkitektur. Alle moduler eller komponenter, samt deres relasjoner skal nevnes her Oversikt over moduler/ komponenter Her vil det finnes en oversikt over alle moduler og en kort beskrivelse av deres funksjonalitet, data input, data output og ressursbruk. Figur 2.1 er en overordnet oversikt over hele heissystemet som viser de ulike komponentenes tilknytning til hverandre. Heisfysikk reell eller simulator Grensesnitt mot heisfysikk Modul for mottak fra varslingssystem Heiskontroll system Modul for spørring mot adgangskontroll Grensesnitt mot kontrollsentral Kontrollsentral Figur 2.1 Overordnet systemoversikt Heiskontrollsystemet: Med heiskontrollsystemet mener vi den logiske delen av heissystemet. Det er denne modulen som er heissystemets hjerne. Det er heiskontrollsystemet som f.eks bestemmer hvilken heis som skal gå til hvilken etasje og som behandler knappetrykk ifra heisfysikken på en logisk måte. Heiskontrollsystemet styrer også alle funksjoner i heisen, som for eksempel åpne/lukke dør og heispanelets lys. Side 5 av 65

6 Ved oppstart av heiskontrollsystemet leses det inn ett oppsett ifra fil med ulike variabler. Dermed kan heiskontrollsystemet lett modifiseres til å behandle varierende kombinasjoner heiser og/eller etasjer. Kontrollsentral: Med kontrollsentral mener vi den delen av vårt heissystem som implementerer brukergrensesnittet mot heiskontrollsystemet. Fra kontrollsentralen kan man overstyre heisene og benytte seg av grensesnittets funksjonalitet. Dette kan f.eks være oppstart/nedkjøring av systemet. Kontrollsentralen vil av funksjonelle årsaker ofte bli plassert i en bygnings resepsjon, sikkerhetsavdeling eller lignende, der det vil finnes en kyndig operatør av systemet. Det er dog ikke utelukket at kontrollsentralen kan plasseres et annet sted, så lenge man har en mulighet til å koble seg opp mot grensesnittet mot heisstyringssystemet. Vi har valgt å ikke implementere kontrollsentralen som en del av dette prosjektet. Heisfysikk: Med heisfysikk mener vi de fysiske delene som heisen består av. Dvs. dører, sensorer, heisvogn, knapper osv. For at heisstyringsmodulen skal kunne gi kommandoer til heisfysikken vil man måtte skrive moduler tilpasset den enkelte heisfysikk, som kommuniserer med heisstyringsmodulen via grensesnitt mot heisfysikk. Vi kommer til å implementere et GUI som vil emulere en faktisk heisfysikk. Modul for spørring mot adgangskontroll: Denne modulen kommuniserer med adgangskontrollsystem dersom et er tilstede. Her vil man måtte skrive moduler tilpasset det enkelte system. Modulen er begrenset til en enkel spørring om hvorvidt det er gitt adgang eller ikke. All annen prosessering (f.eks. innhenting av identifikasjon og kode) foregår internt i adgangskontrollsystemet. Modulen brukes av systemet der det er definert at det skal være adgangskontroll for en etasje. Modul for mottak fra varslingssystem: Denne modulen registrerer varslinger fra et eksternt varslingssystem (dette kan f.eks. være brannvarsling). Ved varsling sender modulen en feilmelding til heisstyringssystemet. Grensesnitt mot kontrollsentral: Grensesnittet mot kontrollsentralen representerer interaksjonen fra heiskontrollsystemet til kontrollsentralen. Det gir heiskontrollsystemet mulighet til å kontakte kontrollsentralen for å rapportere om feil som oppstår i systemet. Heiskontrollsystemet kan kobles opp mot grensesnittet via metoder som implementeres av grensesnittet mot heisfysikken. Det blir i grensesnittet definert metoder som må implementeres i komponenten som representerer kontrollsentralen. Grensesnitt mot heisfysikk: Heiskontrollsystemet er konstruert med tanke på at det skal være mest mulig uavhengig av den virkelighet det skal kontrollere. Det er altså likegyldig om systemet styrer et sett med ekte heiser i en ekte bygning, eller om det styrer en simulator som demonstrerer systemets funksjonalitet. For å oppnå dette, har vi definert et grensesnitt mellom heiskontrollsystemet og det man som en fellesbetegnelse kan kalle heisfysikk. Implementasjon av metodene som utgjør dette grensesnittet er det eneste kravet som må bli tilfredsstilt for at Side 6 av 65

7 heiskontrollsystemet skal kunne interagere med en ekstern virkelighet. Interne detaljer i denne eksterne virkeligheten er irrelevante. På den ene siden har vi definert et sett med metoder som definerer interaksjon mot heisfysikk. Disse metodene gjør det mulig for heiskontrollsystemet å styre heisfysikken, samt å få tilgang på informasjon fra heisfysikken som er nødvendig for å kunne ta riktig styringsbeslutninger. Metodene representerer altså heiskontrollsystemets kontakt med "omverdenen". Metodene må implementeres av modulen som representerer virkeligheten som skal bli styrt, og vil kalles av heiskontrollsystemet. (I vårt tilfelle implementeres disse metodene av SimulatorGUI) På den andre siden har vi definert et sett med metoder som heisfysikken kan bruke for å gi beskjeder til heiskontrollsystemet. Disse metodene implementeres av heiskontrollsystemet, og kalles av heisfysikken Strukturer og Relasjoner I denne delen presenterer vi designet for systemet ved hjelp av UML. UML-diagrammene er bindeleddet mellom de overordnede modulene og de detaljerte komponentbeskrivelsene. For å illustrere designet vårt har vi tatt med et utvalg av diagrammer som på en lettfattelig måte beskriver systemet. Alle detaljer som ikke kommer til syne i disse diagrammene er beskrevet i kapittel 3 Detaljert Design Klasse diagrammer Klassediagram viser et sett av klasser, interfaces, deres interne struktur (attributter og operasjoner) og deres relasjon. Pilene som kobler klassene sammen viser forholdet mellom de respektive klassene. For en komplett beskrivelse av systemet har vi valgt å bruke flere klassediagram. For å få en grunnleggende forståelse av hvordan system fungerer har vi også valgt å legge ved en beskrivelse av hver klasse samt beskrive deres relasjoner med andre klasser Side 7 av 65

8 Klassediagram 1 Klassediagrammet (figur 2.2) viser alle klassene som heiskontrollsystemet består av og de eksterne delene, SimulatorGUI og Heisfysikken, som heiskontrollsystemet har grensesnitt mot. Relasjonene mellom de forskjellige delene i systemet viser hvordan klassene benytter seg av metoder fra andre klasser. SimulatorGUI Actual EP IEP-In «interface» IEP-Out «interface» Grensesnitt mot Heisfysikk Fault Controls «Implements» 1 ControlSwitch -controllers[]:controller +setexclusivecontrol(c:controll er):void +freecontrol():void +regcontroller(c:controller):void Controls * CentralProcessingUnit CCC Control Center Control Implementasjon av ICS-In (grensesnitt mot kontrollsentral) 1...* Elevator -currentfloor:int=1 -direction:int=atfloor Controlled by +adddestination(floor:int):void +getcurrentflorr():int +getdircetion():int +setcurrentfloor(f:int):void +setdirection(d:int):void +getqueuelength():int +emptyqueue():void +queuecontains(x:int):boolean 1 +adddestination(elevator:int,destination:int):void +callelevator(direction:int:floor:int):void +opendoor(elevator:int):void +closedoor(elevator:int):void +stopelevator(elevator:int):void +alarm(elevator:int):void +reportfault(f:fault):void -readsetup(f:file):void SortedQueue -increasing_sort:boolean=true -allow_duplicates:boolean=true +setsortincreasing(inc:boolean):vo id +sortedincreasing():boolean +length():int +insert(n:int):void +contains(n:int):boolean +peek():int +dequeue():int #reverseorder():void #preceeds(a:int,b:int):boolean Controller getcontroller():controller Makes decisions for ESL chooseelevator(elevators[]:ele vator, FOD:int, direction:int):elevator SHA 1 ESL - Elevator Selection Logic FOD - Floor of Departure Possible other logic imlementation SHA - Stenmark-Hansen Algorithm Figur 2.2. Klassediagram med controlswitch Side 8 av 65

9 Her er en kort beskrivelse av alle klassene/interfacene som vises i figur 2.2 ControlSwitch Hensikten med ControlSwitch er å bestemme hvilke komponenter som har tilgang til å styre heisfysikken. Elevator Komponenten Elevator er en representasjon av en heis. Den vedlikeholder en destinasjonskø, og er ansvarlig for å kommandere den faktiske heisen (via grensesnitt mot heisfysikk), på bakgrunn av køens innhold. Controller Controller representerer et objekt som kan gis kontroll i CCC. Klassene Elevator og CCC arver Controller: SortedQueue Lagrer og organiserer forespørslene til en heis. SortedQueue skal behandle en kø av forespørsler. Komponenten har metoder som setter inn nye SQNode-objekter i køen, oppdaterer listen og sorterer den. ESL Dette er en abstrakt klasse, som representerer logikkmodulen som skal tildele en heis et hitkall. Klassen må arves av en klasse som tilbyr en konkret implementasjon (I vårt tilfelle: SHA). CentralProcessingUnit Mottar data fra grensesnitt mot heisfysikk, og fordeler oppgaver til Elevator-objekter. Leser initfil ved oppstart og oppretter objekter. IEP-in Definere grensesnitt mot heiskontrollsystem, i form av metoder, som et fysisk heissystem/simulatorgui kan benytte seg av. IEP-out IEP-Out er den ene halvdelen av Grensesnitt mot Heisfysikk, som tar seg av å sende kommandoer og forespørsler til heisfysikken. SHA SHA arver ESL, oginneholder en implementasjon av metoden chooseelevator, som velger mest gunstige heis. Side 9 av 65

10 Klassediagram 2 Dette klassediagrammet (fig. 2.3) viser deler av modulen heiskontrollsystem. Den viser også modulene for spørring mot adgangskontroll,og for mottak fra varslingssystem, samt hvordan disse kommuniserer med heiskontrollsystemet. Vi har også tatt med klassene ICS-In og ICS- Out, som utgjør modulen grensesnitt mot kontrollsentral. ControlSwitch queries wheter access has been granted Elevator CentralProcessingUnit reports status to AccesControl «interface» queryaccess(elevator:int):boole an Modul for spørring mot adgangskontroll alerts CCC +takecontrol():void +releasecontrol():void +querystatus():status +gotofloor(elevator:int,floor:int):voi d +opendoor(elevator:int):void +closedoor(elevator:int):void +stopelevator(elevator:int):void AlertReception +recievealert():void -alertsystem():void Fault #text:string #impact:int +NOTIFICATION:const int +NONCRITICAL:const int +CRITICAL:const int gettext():string getimpact():int Modul for mottak fra varslingssystem «implements» ICS-In «interface» ICS-Out «interface» Grensesnitt mot Kontrollsentral Figur 2.3. Viser deler av modulen heiskontrollsystem Side 10 av 65

11 Her følger en kort beskrivelse av alle klassene/interfacene som vises i figur 2.3 CCC Komponenten implementerer metodene i ICS-In, dvs. den tar imot forespørsler fra kontrollsentralen i henhold til krav F-C-1. Den tar også imot overstyringskomandoer. AccessControl Interfacet AccessControl definerer grensesnitt mot adgangskontrollsystem som et Elevatorobjekt kan benytte seg av, for å finne ut om en passasjer har adgang til en gitt etasje som krever adgangskontroll. Fault Denne representerer en feilmelding til heisstyringssystemet, AlertReception Denne klassen varsler systemet om at noe er galt ICS-in Definere grensesnitt mot heiskontrollsystem, i form av metoder, som en kontrollsentral kan benytte seg av. ICS-out Definere grensesnitt mot heiskontrollsystem, i form av metoder, som en kontrollsentral kan benytte seg av. Side 11 av 65

12 Klassediagram 3 Klassediagrammet (figur 2.4) illustrerer hvordan klassene som representerer brukergrensesnittet simulerer faktisk heisfysikk. JFrame SimulatorGUI <<interface>> ActionListener -setupgui(f:int,e:int):void -go():void +main(args[]:string):void -floors:int -elevators:int EPanel -setupgui():void +paintcomponent(g:graphics):void +actionperformed(e:actionevent):void GUIElevator -destinationfloor:int -floors:int -nr:int -dooropen:boolean +getdestinationfloor():int +setdestinationfloor(df:int):void +getposition():position +opendoor():void +closedoor():void +draw(g:graphics):void +run():void Position -floor:int -direction:int +setfloor(fl:int):void +getfloor():int +getdrawfloor():int +setdirection(int d):void +getdirection():int +increment():void +decrement():void +setarrived():void Figur 2.4. Klassediagram for GUI Her er en kort beskrivelse av alle klassene/interfacene som vises i figur 2.4 EPanel Presentere brukergrensesnitt mot heissimulatoren, i form av knapper og grafiske framstillinger av GUIElevator-instanser. SimulatorGUI Representere en grafisk imitasjon av et fysisk heissystem, for demonstrasjonsformål. Utnytte grensesnittet som tilbys mot heiskontrollsystemet. Oppretter en instans av type EPanel, som den bruker til å vise representasjonen av heisfysikken. GUIElevator Hensikten med GUIElevator er å representere den grafiske fremstillingen av en heis (av en eller flere), i SimulatorGUI. Komponenten skal selv opprettholde en posisjon, og tegne seg ut på EPanel på riktig posisjon. Side 12 av 65

13 Position Representere posisjonen til en GUIElevator, for å den skal kunne tegne seg selv på riktig sted, og for at den skal kunne flytte seg til riktig etasje i henhold til gitt kommando. I tillegg skal heiskontrollsystemet til enhver tid kunne vite hvor den faktiske heisen befinner seg Sekvensdiagrammer Sekvensdiagram er også kjent som Object Interaction Diagram. Det lar deg vise beskjeder som er sendt mellom instanser av de klassene og rekkefølgen de er sendt. Når et objekt sender en beskjed til et annet objekt, hentyder dette at disse to klassene har en forhold som må vises i et klassediagram viser objekter i systemet og hvordan de interagerer med hverandre Tabell 2.1viser de notasjonselementene vi har brukt i sekvensdiagrammet. Notasjonselementer, sekvensdiagram Tegn/ element Forklaring Klasse rolle: objekt Object : Class Objekter som er involvert i sekvensen av hendelser. Bør plasseres på toppen av den horisontale linjen [condition] Beskjed message name Denne indikerer når et objekt kaller en operasjon eller brukes til å indikerer reurnere verdier [condition] message name Timerfunksjonen Aktiv Ikke aktiv Lifeline Dette er den dottede linjen. Dette viser hvor objektet ikke er aktivt Aktiv med brudd Tabell 2.1. Notasjonselementer sekvensdiagram Side 13 av 65

14 Sekvensdiagram 1. Tilkalle heis Figur 2.5 viser et sekvensdiagram for å tilkalle heis. Den viser hvordan klassene sender beskjed til hverandre. En heis blir tilkalt og etter at en heis blir valgt blir denne heisen tildelt oppgaven. Oppgaven blir eventuelt lagt i heiskøen og utført når det blir dens tur. IEP-in :CPU ESL Elevator callelevator chooseelevator returnelevator <<queryparameter>> adddestination toogleilluminate <<addqueue>> <<utfører de som ligger først i køen>> gotofloor () [current position = destination] cancelilluminate [current position = destination] opendoor Timer closedoor () Figur 2.5. Sekvensdiagram 1- Gå til etasje Side 14 av 65

15 Sekvensdiagram 2. Løkke i GUIElevator Figur 2.6 viser hvordan GUIElevator simulerer heisfysikken. elevator[x]:guielevator :Position while [true] loop [destination=position] timer [destination>position] increment «return control» [destination<position] decrement «return control» :"EPanel" timer while [true] loop paint timer (1/10 sek) Figur 2.6. Sekvensdiagram 2- Løkke i GUIElevator Side 15 av 65

16 Sekvensdiagram 3. Løkken i Elevator Dette sekvensdiagrammet (figur 2.7) viser hvordan Elevator-klassen bestemmer til hvilken etasje systemet skal sende heisen, til enhver tid. Se vedlegg 4.5 for pseudokode som tilsvarer dette diagrammet. : Elevator q : SortedQueue IEP-Out while [true] loop getposition «returns position» contains(currentfloor) «returns contains» [direction=atfloor,contains] remove(currentfloor) length() «returns length» [length=0] delay [q.contains(nextfloortoarriveat)] gotofloor(nextfloortoarriveat) [!q.contains(nextfloortoarriveat)] head() «returns newdest» [newdest<currentdest] sortincreasing(true) [newdest>currentdest] sortincreasing(false) gotofloor(newdest) delay Figur 2.7. Sekvensdiagram 3- Viser hva som skjer i løkka til Elevator-objektene Side 16 av 65

17 Collaboration diagram Dette diagrammet viser ikke spesifikke klasser eller metoder, men viser hvordan systemet sees utenifra. Tabell 2.2 viser de notasjonselementene vi har brukt i collaborationdiagrammet. Tegn Notasjonselementer Collaboration diagram Forklaring Retningen oppgaven går. Selve handlingen er forklart ved siden av pila. Flere oppgaver som går begge veier. Følg forklaringer ved siden av pil. Klasse, rolle eller objekt Tabell. 2.2 Notasjonselementer, Collaboration diagram Collaboration diagram : Gå til etasje I all enkelhet viser dette diagrammet (figur 2.8) gangen i et scenario der passasjeren velger en etasje inne i en heis, til han kommer frem til destinasjonsetasjen. Passasjer 1. Presser Etasjeknapp 2. Oppdaterer forespørsel 3. Knapp lyser 7. Knapp slukker Heiskontrollsystem 4. Flytter 5. Ankommer etasje 6. Stopper 8. Åpner 9. Lukker Heis Dør Fig 2.8. Collaboration diagram- Gå til etasje Side 17 av 65

18 1. Passasjeren presser knappen for ønsket etasje. 2. Forespørselen blir oppdatert i Heiskontrollsystemet. 3. Valgt etasjeknapp lyser for å indikere at etasjen er valgt. 4. Heiskontrollsystemet sender heisen i bevegelse og flytter den mot destinasjonsetasje. 5. Heisen ankommer destinasjonsetasje. 6. Heiskontrollsystemet stopper heisen. 7. Etasjeknapp slutter å lyse fordi heisen er kommet frem. 8. Heiskontrollsystemet åpner døren. 9. Heiskontrollsystemet lukker døren State diagrammer Med state diagrammer ønsker vi å vise hvordan hendelsen gjør at en tilstand blir til en annen og hendelsene det resulterer i. Den beskriver den mulige statusen til et objekt og viser handlingen som utløser transaksjonen fra en status til den neste. Den viser også actions som kommer fra enhver status endring State diagrammet viser det dynamiske viewet til systemet, det kan bli sett på som et komplement til beskrivelsen av klassen. Tabell 2.3 viser de notasjonselementene vi har brukt i statediagrammet Tegn Notasjonselementer State diagram Forklaring Retningen hendelsen går. Start State Tabell 2.3 Notasjonselementer, Statediagram Side 18 av 65

19 Statediagram 1. Viser hvordan heis går opp og heis går ned Her viser diagrammet (figur 2.9) oss at heisen starter i første etasje. Etter at den har fått en forespørsel og gått opp til destinasjonsetasjen, kan den enten stå rolig en stund (Hvilemodus) og gå til første etasje igjen, eller fortsette med flere oppgaver den er blitt tildelt I første etasje goup Heis går opp Ankommet goup Går til første etasje Heis går ned Ankommet Hvilemodus (idle) godown time-out Fig 2.9. State diagram- viser hvordan heis går opp og ned Statediagram 2. ControlSwitch Dette diagrammet (figur 2.10) viser hvordan ControlSwitch skifter tilstand når man starter/stopper overstyring fra kontrollsentral. I tilstanden "systemet har kontroll" virker systemet som normalt, og Elevator-objektene kan sende styringskommandoer til heisfysikken. I tilstanden "systemet er overstyrt", er det kun kontrollsentralen som kan sende styringskommandoer til heisfysikken. Kommandoer fra Elevator-objektene blir ignorert, som igjen fører til at heisene ikke reagerer på input fra brukere. Kontrollsentral overtar kontroll Systemet har kontroll Systemet er overstyrt Kontrollsentral frigir kontroll Fig Statediagram- Viser hvordan ControlSwitch skifter tilstand Side 19 av 65

20 3. Detaljert design De fleste av komponentene som er beskrevet i systemarkitekturdelen vil kreve en mer detaljert beskrivelse. Mens arkitektur går på å identifisere klasser så går detaljert design på å finne ut hva som skal være i klassene. Dette er hva vi ønsker å definere i denne delen av dokumentet. 3.1 Mal, for beskrivelse av komponentene I denne subseksjonen skal vi gi en generell beskrivelse av malen som er gitt. Denne malen som kalles: IEEE Standard 1016, skiller på 10 attributter. Og denne har vi brukt på hver modul. Mal, for beskrivelse av komponentene Komponentnavn: Attributt Beskrivelse Identifikasjon Et unikt navn på komponenten slik at den kan refereres til. Type Hva slags type komponenten er. En modul, et subprogram, den datafil, en kontrollprosedyre, en klasse, eller noe annet. Hensikt Beskrive den eksakte hensikten med denne komponenten. Denne delen refererer tilbake til SRS, og tar for seg hvilke funksjonelle krav og ytelseskrav som gjelder. Her beskrives også krav som ikke er eksplisitt nevnt i SRS. Funksjon Spesifisere komponentens funksjon og beskrive hva den skal utføre. Beskrive transformasjonsprosessen, og hvilke input som blir behandlet. Man skal beskrive algoritmen som blir brukt og hvilke output man får. Hvor data items er lagret og hvilke data items som er modifisert. Underordninger Dette er den interne strukturen til komponentene. Hvilke relasjoner gjelder mot andre komponenter. Hvilke komponenter den enkelte entitet er satt sammen av. Her identifiseres en statisk er-sammensatt-av relasjon mellom entiteter Avhengigheter En beskrivelse av relasjoner med andre komponenter. Hvordan komponentenes funksjon og ytelse er relatert til andre komponenter. Hvordan denne komponenten blir brukt av andre komponenter og hvordan disse er brukt. Detaljer rundt interaksjonen som for eksempel betingelser for interaksjon (som eksekveringsrekkefølge og datadeling), timing og forpliktelser/ansvar til å skape, duplisere, bruke, lagre og eliminere komponenter. Grensesnitt Detaljert beskrivelse av alle eksterne og interne grensesnitt samt alle mekanismer for kommunikasjon gjennom beskjeder, parametere og felles dataområder. Alle feilmeldinger bør identifiseres. Alle skjermformat, interaktivitet og andre komponenter til brukergrensesnitt som er oppgitt i SRS bør beskrives her. Ressurser En komplett beskrivelse av alle ressurser(hardware og software) som er eksterne i forhold til komponentene, men som kreves for å kunne utføre en funksjon. Dette kan være CPU-hastighet, minne (primær og sekundær), buffer, I/O kanaler, printere, mattebiblioteker, hardware-registre m.m Prosessering En fullstendig beskrivelse av funksjonene som er presentert i punktet Funksjoner. En beskrivelse av algoritmen som brukes. Pseudokode kan brukes til å dokumentere algoritmer. Hvordan exceptions initieres og behandles. Side 20 av 65

21 Data Beskrive hva slags data som behandles. En beskrivelse av verdier, bruken og formatet, semantikk og meningen av interne data. Denne informasjonen vil sannsynligvis ligge i data dictionary. Tabell 3.1 Mal, for beskrivelse av komponentene Punktene under beskriver alle komponentene ut fra de 10 punktene over. I punktene under har vi referert til krav som er satt i SRS. Vi ønsker å presisere at denne kravreferansen gjelder den oppdaterte SRS`en, skal leveres i sluttrapporten. Men som vedlegg har vi lagt kortversjonen av kravene tilhørende den oppdaterte versjonen av SRS. Side 21 av 65

22 3.2 Beskrivelse av komponent Elevator Elevator Komponentnavn: Elevator Attributt Beskrivelse Identifikasjon KO-1 Type Klasse Hensikt Komponenten Elevator skal representere en heis. Det er maks 4 heisobjekter som kan kontrolleres av ControlProcessingUnit om gangen. Opprettholder en destinasjonskø (SortedQueue-instans), som definerer rekkefølgen den skal behandle forespørsler på. Behandling av køen tilfredsstiller disse kravene: F-A-26, F-A-27, F-A-28, F-A-29, F-A-30, F-A-31, F-A-32, F-A-33, F-A-35, F-B-8 og F-B-9 Funksjon Klassen Elevator skal holde styr på hvor heisen er til enhver tid, hvilken retning den går i og hvilken destinasjon den er på vei til. Den skal også vite hvor lang heiskøen er. I tillegg er den ansvarlig for å kommandere den faktiske heisen (via grensesnitt mot heisfysikk), på bakgrunn av heiskøens innhold. Underordninger Klassen Elevator benytter seg av en instans av SortedQueue. Benytter seg også av konstanter definert i Status. Avhengigheter Elevator arver Controller. CentralProcessingUnit benytter seg av en array med Elevator-instanser. Grensesnitt Elevator tilbyr følgende metoder: adddestination(floor:int):void //Denne metoden brukes for å gi heisen en destinasjonsetasje. getcurrentfloor():int //Denne metoden brukes for å finne hvilken etasje heisen er i: getdirection():int // Denne metoden brukes for å finne hvilken retning heisen går i: setcurrentfloor(f:int):void //Denne metoden brukes for å endre etasje setdirection(d:int):void //Denne metoden brukes for å endre heisens retning. getqueuelength():int //Denne metoden brukes for å finne antallet elementer i køen. emptyqueue():void //Denne metoden brukes for å slette alle elementene i køen. queuecontains(x:int):boolean //Returnerer true hvis etasjenr x finnes i heisens destinasjonskø Ressurser - Prosessering Hver Elevator-instans er en separat tråd som itererer over innholdet i sin Side 22 av 65

23 Data destinasjonskø ved hjelp av en evig løkke (se sekvensdiagram nrx). Ut fra innholdet i destinasjonskøen sender den styringskommandoer mot grensesnitt mot heisfysikk. I tillegg har den ansvar for å slette en destinasjon fra køen når heisen er framme ved denne destinasjonen. currentfloor:int=1 //Representerer heisens nåværende etasje direction:int=status.at_floor //Representerer heisens nåværende retning //For mulige verdier, se [KO-X] q:sortedqueue //Representerer heisens destinasjonskø [se KO-X] Side 23 av 65

24 3.3 Beskrivelse av komponent ESL ESL Komponentnavn: ESL Attributt Beskrivelse Identifikasjon KO-2 Type Abstrakt Klasse Hensikt Dette er en abstrakt klasse, som representerer logikkmodulen som skal tildele en heis et hit-kall. Klassen må arves av en klasse som tilbyr en konkret implementasjon. I vårt tilfelle arves den av SHA som tilbyr en algoritme for valg av heis. Tilfredstiller krav F-A-2 Funksjon Komponenten skal velge en gunstig heis. Underordninger - Avhengigheter Klassen ESL tar beslutninger for klassen CPU og blir arvet av klassen SHA. Grensesnitt ESL definerer følgende metode: chooseelevator(elevators[]:elevator, FOD:int, direction:int):elevator //Denne metoden skal velge en heis på bakgrunn av floor of departure, heis //og retning. Implementeres i subklasse(r). Ressurser - Prosessering - Data - Side 24 av 65

25 3.4 Beskrivelse av komponent CentralProcessingUnit CentralProcessingUnit Komponentnavn: CentralProcessingUnit Attributt Beskrivelse Identifikasjon KO-3 Type Klasse Hensikt Mottar data fra heisfysikk. Den knytter også objektene sammen. Tilfredsstiller krav F-A-1, F-A-9, F-A-10, F-A-11, F-A-15, F-A-16, F-A-17, F-B-1, F-B-2, F- B-3, F-B-4, F-B-5, F-B-6 Funksjon Mottar data fra grensesnitt mot heisfysikk, og fordeler oppgaver til Elevator-objekter. Leser initfil ved oppstart og oppretter objekter. Underordninger Inneholder en array med Elevator-objekter. CPU benytter seg av en implementasjon av ESL. Avhengigheter Implementerer interface IEP-In. Grensesnitt CentralProcessingUnit tilbyr følgende metoder: readsetup(f:file):void //leser initfil og genererer riktige objekter på bakgrunn av dette se [KO-X : IEP-IN] for beskrivelser av metodene under adddestination(elevator:int, destination: int): void callelevator (direction: int, floor:int): void opendoor (elevator:int): void closedoor (elevator:int): void stopelevator (elevator:int): void alarm (elevator:int): void reportfault (f:fault): void Ressurser - Prosessering - Data - Side 25 av 65

26 3.5 Beskrivelse av komponent SimulatorGUI SimulatorGUI Komponentnavn: Elevator Attributt Beskrivelse Identifikasjon KO-4 Type Klasse Hensikt Representere en grafisk imitasjon av et fysisk heissystem, for demonstrasjonsformål. Utnytte grensesnittet som tilbys mot heiskontrollsystemet. Tilfredsstiller krav F-D-6 sammen med EPanel. Tilfredsstiller F-B-10, F-B-11, F-B-12, F-B-13, F-B-14, F-B-15, F-B-16, F-B-17 F-D-1 Funksjon Oppretter en instans av type EPanel, som den bruker til å vise representasjonen av heisfysikken. Underordninger Epanel [KO-5] Avhengigheter Arver JFrame, implementerer IEP-Out [KO-13] Grensesnitt SimulatorGUI tilbyr følgende metoder: gotofloor(elevator:int, floor:int):void //Ber aktuell GUIElevator å flytte seg til riktig etasje opendoor(elevator:int):void //Åpner dør på aktuell GUIElevator closedoor(elevator:int):void //Lukker dør på aktuell GUIElevator stop(elevator:int):void //Stopper aktuell GUIElevator toggleillumination(buttontype:int, location:int, illuminated:boolean):void //Slår av/på knappebelysning //buttontype = konstanter som representerer alle knappetyper //location = etasje/heisnr ut fra buttontype audiblesignal(floor:int):void //Initierer et lydsignal currentposition(elevator:int):int[] //Returnerer posisjonen til aktuell GUIElevator doorclosed(elevator:int):boolean //Metode for å finne ut om døren til en GUIElevator er lukket doorblocked(elevator:int):boolean //Metode for å finne ut om døren til en GUIElevator er blokkert Side 26 av 65

27 Ressurser - Prosessering Data - readfile(f:file):void //Leser en initfil med oppstartsparamatre Leser ved oppstart en initfil, og ut fra innholdet i denne filen gir den EPanel-instansen beskjed om hvor mange etasjer/heiser som skal inkluderes i simulatoren. Plasserer deretter EPanel-instansen i sin container. Side 27 av 65

28 3.6 Beskrivelse av komponent EPanel EPanel Komponentnavn: EPanel Attributt Beskrivelse Identifikasjon KO-5 Type Klasse Hensikt Presentere brukergrensesnitt mot heissimulatoren, i form av knapper og grafiske framstillinger av GUIElevator-instanser. Tilfredsstiller krav F-D-2, F-D-6, F-D-7,IF-B-1, IF-U-2, IF-U-4, IF-U-5, IF-U-6, IF-U-7, IF-U-8, IF-U-9, IF-U-10, IF-U-11 Funksjon EPanel tar som input antall etasjer/heiser, og tegner ut fra dette opp riktig antall etasjer og sjakter. Oppretter også riktig antall knapper og GUIElevator-objekter. Tegner seg selv på nytt hvert tiendels sekund, noe som også fører til at hver GUIElevator-instans oppdaterer sin egen grafiske posisjon. EPanel tar seg også av eventer generert av brukeren (f.eks. knappetrykk). Underordninger GUIElevator [KO-7] Avhengigheter EPanel brukes av SimulatorGUI [KO-4]. EPanel implementerer også ActionListener. Grensesnitt EPanel tilbyr følgende metoder: Ressurser - Prosessering Data setupgui():void //Plasserer ut aktuelle knapper paintcomponent(ggraphics):void //Tegner seg selv, inkludert den grafiske representasjonen av hver enkelt //GUIElevator-instans actionperformed(e:actionevent):void //Mottar og videreformidler actioneventer utløst av brukeren I konstruktøren får EPanel beskjed om hvor mange heiser/etasjer SimulatorGUI skal presentere og heiskontrollsystemet skal kontrollere. Ut fra dette oppretter EPanel riktig antall GUIElevator-instanser. Deretter plasserer den ut to hit-knapper (opp/ned) for hver etasje, og riktig antall etasjeknapper for hver sjakt. Dette foregår i metoden setupgui. I metoden paintcomponent tegnes selve sjaktene. I tillegg kalles draw-metoden til alle GUIElevator-instanser. Dette fører til at GUIElevator-instansene tegner seg selv i riktig posisjon, ut fra hvor de befinner seg for øyeblikket. paintcomponent kalles hvert tiendels sekund, ved hjelp av en evig whileløkke og en forsinkelse. I tillegg implementerer EPanel ActionListener. Dette innebærer at metoden actionperformed er definert, for å ta imot og formidle actioneventer fra brukeren av simulatoren til selve heiskontrollsystemet. floors:int //Representerer antall etasjer som skal presenteres elevators:int //Representerer antall heiser/sjakter som skal presenteres Side 28 av 65

29 3.7 Beskrivelse av komponent Position Position Komponentnavn: Position Attributt Beskrivelse Identifikasjon KO-6 Type Klasse Hensikt Representere posisjonen til en GUIElevator, for å den skal kunne tegne seg selv på riktig sted, og for at den skal kunne flytte seg til riktig etasje i henhold til gitt kommando. I tillegg skal heiskontrollsystemet til enhver tid kunne vite hvor den faktiske heisen befinner seg. Funksjon Klassen vedlikeholder en variabel floor, som angir heisens posisjon i forhold til etasjene, samt en variabel direction, som angir om heisen er på vei opp, på vei ned eller i ro i en etasje. Variabelen floor inneholder i utgangspunktet heisens etasjenr multiplisert med 10. Deretter kan denne variabelen inkrementeres/dekrementeres med 1. Begrunnelsen for dette er at GUIElevator-objektet kan tegne seg selv mellom etasjer, og heisens bevegelse blir mer glidende. Underordninger Ingen Avhengigheter Hver GUIElevator [KO-7] benytter seg av en instans av klassen Position Grensesnitt Position tilbyr følgende metoder: setfloor(fl:int):void //setter nåværende etasje getfloor():int //returnerer sist besøkte etasje getdrawfloor():int //returnerer heisens posisjon setdirection(d:int):void //setter heisens retning getdirection():int //returnerer heisens retning increment():void //inkrementerer heisens posisjon decrement():void //dekrementerer heisens posisjon setarrived():void //markerer at heisen er framme ved sin destinasjon //direction settes til Status.AT_FLOOR Ressurser - Prosessering Ved oppstart inneholder variabelen floor heisens etasje multiplisert med 10. Side 29 av 65

30 Data Når heisen (GUIElevator) kaller Position.increment/decrement (for å markere at den er på vei oppover/nedover), inkrementeres/dekrementeres floor med 1. Dette innebærer at increment/decrement kalles 10 ganger for å markere en forflytning fra en etasje til den neste. Metoden getdrawfloor returnerer innholdet i variabelen floor, som brukes av GUIElevator for å tegne seg selv. Metoden getfloor returnerer innholdet i variabelen floor dividert med 10 (rundet opp eller ned til neste hele tall utfra om heisen er på vei henholdsvis ned eller opp). getfloor returnerer dermed den siste etasjen heisen var innom. Denne metoden brukes av GUIElevator for at den skal vite når den er framme ved sin destinasjon. floor:int //Representerer heisens etasje multiplisert med 10 direction:int //Representerer heisens nåværende retning Side 30 av 65

31 3.8 Beskrivelse av komponent GUIElevator GUIElevator Komponentnavn: GUIElevator Attributt Beskrivelse Identifikasjon KO-7 Type Klasse Hensikt Hensikten med GUIElevator er å representere den grafiske fremstillingen av en heis (av en eller flere), i SimulatorGUI. Komponenten skal selv opprettholde en posisjon, og tegne seg ut på EPanel på riktig posisjon. sammen med EPanel [komponent KO-5] tilfredsstiller dette krav F-D-3, F-D-4, F-D-8 og IF-B-2. Funksjon Komponenten opprettholder en oversikt over posisjon, samt en destinasjonsetasje (variablen destinationfloor). Dersom nåværende posisjon ikke er samme som destinasjonsetasje sørger komponenten for at heisen settes i bevegelse [se sekvensdiagram punkt ]. Den har også metoder for å animere åpne/lukke dør. Hvert GUIElevatorobjekt er en separat tråd i systemet. Underordninger Komponent [KO-6]: Position Avhengigheter En eller flere instanser av GUIElevator benyttes av EPanel [komponent KO-5] for å representere heisene. EPanel sørger for å oppdatere data (destinasjonsetasje) og kalle metoder for å utføre en handling (opendoor(),closedoor(),draw()...). EPanel kan også spørre om nåværende posisjon. Metoden draw() er avhengig av et Graphics-objekt, som den får da den kalles fra EPanels drawcomponent()-metode. Grensesnitt GUIElevator tilbyr følgende metoder: getdestinationfloor():int //Returnerer destinasjonsetasje. setdestinationfloor(df:int):void //Setter, evt. overskriver, destinasjonsetasje. Som igjen vil føre til at heisen //settes i bevegelse. getposition():int[] //Returnerer nåværende posisjon, i form av en int-array med 2 elementer. Se komponent [KO-6]. opendoor():void //Iverksetter animasjon for å åpne dør. (Og setter dørens status til åpen?) Når //døren er åpnet, starter en timer. Når den er ferdig lukkes døren automatisk. //Dersom døren er åpen resettes timeren. closedoor():void //Iverksetter animasjon for å lukke dør. //Denne avbryter en timer som beskrevet i opendoor(). draw(g:graphics):void //Tegner ut komponenten ut ifra parametrene i Position-objektet [KO-6]. Side 31 av 65

32 run():void //Setter i gang tråden som kjører på dette objektet Ressurser - Prosessering For hver iterasjon i tråden sjekkes nåværende posisjon opp mot destinasjon, og heisen beveges mot destinasjonsetasjen dersom de ikke er like. Data destinationfloor:int // Representerer destinasjonsetasje. Leses/skrives med getdestinationfloor()/setdestinationfloor(). pos:position //Representerer GUIElevator-instansen nåveærende Posisjon [Komponent KO-6]. Denne oppdateres internt i objektet, men kan leses indirekte med getposition(). nr:int //Identifiserer det enkelte GUIElevator-objekt (ettersom EPanel kan ha flere). dooropen:boolean //Indikerer hvorvidt døren er åpen eller lukket. Denne har verdien true dersom døren er åpen, og false dersom døren er lukket, eller i ferd med å åpnes/lukkes. Side 32 av 65

33 3.9 Beskrivelse av komponent ControlSwitch ControlSwitch Komponentnavn: ControlSwitch Attributt Beskrivelse Identifikasjon KO-8 Type Klasse Hensikt Hensikten med ControlSwitch er å bestemme hvilke komponenter som har tilgang til å styre heisfysikken. Dette gjør det mulig å implementere overstyring i henhold til krav F-A-6. Tilfredsstiller også kravene F-A-18 og F-A-19. Funksjon Komponenten opprettholder en liste over komponenter som kan styre heisfysikken, samt hvilke av disse som har tilgang til å styre heisfysikken til enhver tid. Når en komponent sender en styringskommando sjekker ControlSwitch om denne har tilgang og genererer et nytt kall til Grensesnitt mot Heisfysikk. Underordninger Ingen Avhengigheter Komponenten brukes av CCC [komponent KO-17] og av Elevator [komponent KO-1]. Begge disse arver klassen Controller [komponent KO-9], som definerer metoden getcontroller(), som identifiserer hvilken komponent som prøver sende en kommando til heisfysikken. ControlSwitch er også avhengig av en implementasjon av interfacet IEP-Out [komponent KO-13], som den videreformidler kommandoer til. Grensesnitt ControlSwitch tilbyr følgende metoder: setexclusivecontrol(c:controller):void //Denne metoden gir c og bare c adgang til å kontrollere heisfysikken. freecontrol():void //Denne metoden gir alle registrerte komponenter adgang til å kontrollere. regcontroller(c:controller):void //Registrer en Controller, denne gis adgang til å kontrollere heisfysikken. isallowed(c:controller):boolean //Hjelpefunksjon som brukes for å kontrollere om en komponent er gitt tilgang gotofloor(elevator:int,floor:int,c:controller):void opendoor(elevator:int,c:controller):void closedoor(elevator:int,c:controller):void stop(elevator:int,c:controller):void toggleillumination(buttontype:int,lokasjon:int,illuminated:boolean,c:controller):void audiblesignal(floor:int,c:controller):void currentposition(elevator:int,c:controller):int[] doorclosed(elevator:int,c:controller):boolean doorblocked(elevator:int,c:controller):boolean //Alle de overstående metodene sjekker om c har adgang til å kontrollere //heisfysikken, og kaller metoden med samme navn i IEP-Out [komponent KO-13], //hvis det er tilfelle. Se IEP-Out[komponent KO-13] for beskrivelse av metodene og //de øvrige parametrene. //Dersom den kallende Controller-komponenten ikke har tilgang ignoreres forespørselen Side 33 av 65

34 Ressurser - Prosessering - Data controllers[]:controller // Liste over registrerte Controllere allowed[]:boolean // Controllere som har tilgang Side 34 av 65

35 3.10 Beskrivelse av komponent Controller Controller Komponentnavn: Controller Attributt Beskrivelse Identifikasjon KO-9 Type Klasse Hensikt Controller representerer et objekt som kan gis kontroll i CCC [komponent KO-17]. Tilfredsstiller krav F-A-6, om at det skal være mulig å overstyre kontrollsystemet. Funksjon Controller implementerer en metode som identifiserer det kallende objekt. Underordninger - Avhengigheter Disse klassene arver Controller: komponent KO-1: Elevator komponent KO-17 CCC Grensesnitt Controller tilbyr følgende metoder: getcontroller():controller //Returnerer en referanse til seg selv, slik at CCC kan identifisere hvilket //objekt som prøver å kalle en metode. Ressurser - Prosessering - Data - Side 35 av 65

36 3.11 Beskrivelse av komponent SortedQueue SortedQueue Komponentnavn: SortedQueue Attributt Beskrivelse Identifikasjon KO-10 Type Klasse Hensikt Lagrer og organiserer forespørslene til en heis. SortedQueue skal behandle en kø av heiser. Komponenten har metoder som setter inn nye heisobjekter i køen og sorterer den. Alle metoder som vedrører købehandling, tilfredstiller av disse kravene F-A-27, F-A-28, F-A-29, F-A-30, F-A-31, F-A-32, F-A-33, F-A-34, F- A-35, F-A-36. Funksjon Klassen vedlikeholder en liste av noder (SQNode-objekter). Hver SQNode inneholder et heltall, som representerer en registrert forespørsel i forbindelse med køens heis. Underordninger SQNode Avhengigheter Hver Elevator benytter seg av en og bare en instans av klassen SortedQueue. Grensesnitt setsortincreasing(inc:boolean):void //Angir om køen skal sortere i stigende eller synkende rekkefølge sortedincreasing():boolean // Returnerer true hvis køen er sortert stigende, ellers false length():int //Denne metoden brukes for å hente ut antall elementer i heiskøen: //returnerer køens lengde (antall registrerte forespørsler) insert(n:int):void //Denne metoden brukes for å sette inn et nytt heisobjekt i heiskøen: //legger en forespørsel(etasje) inn i køen, hvis den ikke finnes i køen fra før //(default oppførsel) køen er fremdeles sortert etter forespørselen er lagt til contains(n:int):boolean //Denne metoden brukes for å sjekke om det er noen elementer i heiskøen: //returnerer true hvis n finnes i køen, ellers false peek():int // returnerer verdien i første node (forespørselen som ligger først i køen) dequeue():int // returnerer verdien i første node (forespørselen som ligger først i køen) //fjerner deretter noden remove(x:int):void //fjerner SQNode med etasjenr x reverseorder():void Side 36 av 65

37 //reverserer køen Ressurser - Prosessering Data preceeds(a:int,b:int):boolean //sammenligner to etasjer i henhold til hvordan køen er sortert //(stigende/synkende) brukes av metoden insert, for å kunne sette //forespørsel inn i sortert liste //increasing_sort:boolean=true //allow_duplicates:boolean=true SortedQueue er en modifisert kø, i den grad at man kan kalle den en kø. I likhet med en normal kø, fjerner man elementer (dequeue) i den ene enden, men innsettingen av elementer skjer ut fra elementenes verdi (etasjenr), i og med at køen alltid skal være sortert. SortedQueue tilbyr også metoden remove, slik at det faktisk også er mulig å fjerne elementer hvor som helst i køen. Køen skal være sortert i synkende rekkefølge når heisen er på vei oppover, og i stigende rekkefølge når heisen er på vei oppover. Default oppførsel for køen er å ikke tillate flere enn én forespørsel med samme etasjenr samtidig. increasing_sort:boolean //true hvis køen sorteres i stigende rekkefølge, ellers false head:sqnode //dummy-element som representerer køens utgangspunkt allow_duplicates:boolean //true hvis køen aksepterer flere enn én forespørsel med samme etasjenr samtidig, ellers false Side 37 av 65

38 3.12 Beskrivelse av komponent SQNode SQNode Komponentnavn: SQNode Attributt Beskrivelse Identifikasjon KO-11 Type Klasse Hensikt Representere en etasjeforespørsel Tilfredstiller krav F-A-34. Funksjon Klassen blir opprettet av SortedQueue, blir tildelt en tallverdi(etasjenr), og blir en del av en lenket liste (SortedQueue - destinasjonskø) Underordninger - Avhengigheter SortedQueue benytter seg av SQNode-objekter Grensesnitt - Ressurser - Prosessering SQNode inneholder en tallverdi som representerer en etasje, og en referanse til en annen SQNode. Ved hjelp av denne referansen kan SQNode-objekter danne lenkede lister (destinasjonskø) Data next:sqnode //Referanse til neste SQNode-objekt i destinasjonskøen, evt en nullreferanse value:int //Heltall som representerer en etasje Side 38 av 65

39 3.13 Beskrivelse av komponent Status Status Komponentnavn: Status Attributt Beskrivelse Identifikasjon KO-12 Type Klasse Hensikt Tilgjengeliggjøre et sett med symbolske tallkonstanter som brukes av de ulike klassene i systemet Funksjon Inneholder et sett med statiske tallkonstanter som er tilgjengelige uten å lage instanser av klassen Underordninger Ingen Avhengigheter Elevator, GUIElevator, SHA Grensesnitt - Ressurser - Prosessering - Data static int UP = 0; //representerer en heis som er på vei oppover static int DOWN = 1; //representerer en heis som er på vei nedover static int AT_FLOOR = 2; //representerer en heis som står stille i en etasj static int UNFIT = 11; //representerer en heis som er uegnet for hit-kall static int DEF_STATE = 12; //default-verdi i forbindelse med hit-kall Side 39 av 65

40 3.14 Beskrivelse av komponent IEP-Out IEP-Out Komponentnavn: IEP-Out Attributt Beskrivelse Identifikasjon KO-13 Type Interface Hensikt IEP-Out er den ene halvdelen av Grensesnitt mot Heisfysikk, som tar seg av å sende kommandoer og forespørsler til heisfysikken. Komponenten tilfredstiller kravene F-B-8, F-B-9, F-B-11, F-B-12, F-B-13, F-B-14, F-B- 15, F-B-16 og F-B-17. Alle disse går på at heiskontrollsystemet gir styringskommandoer via grensesnitttet mot heisfysikk. Funksjon IEP-Out formidler styringskommandoer fra styringssystem til heisfysikk. Underordninger - Avhengigheter IEP-Out er avhengig av at en klasse på heisfysikksiden implementerer metodene som spesifiseres her, i vårt tilfelle SimulatorGUI. Grensesnitt IEP-Out tilbyr følgende metoder: gotofloor(elevator:int,floor:int):void //Be en spesifikk heis om å gå til en spesifikk etasje. Parameteren elevator //inneholder hvilken heis, og floor inneholder destinasjonsetasje. Dersom en //destinasjonsetasje allerede er satt overskrives denne av den nye. opendoor(elevator:int):void //Be en spesifikk heis om å åpne døren. Forespørselen ignoreres dersom //heisen er i bevegelse. Dersom døren allerede er åpen resettes timeren som //sier hvor lenge døren skal være åpen. closedoor(elevator:int):void //Be en spesifikk heis om å lukke døren. Forespørselen ignorerers dersom //døren er lukket. stop(elevator:int):void //Be en spesifikk heis om umiddelbart å stoppe bevegelse. Bevegelse startes //igjen ved å sende en gotofloor(...)-kommando. toggleillumination(buttontype:int,location:int,illuminated:boolean):void //Tenner eller slukker lys på en knapp. Parameteren buttontype sier hvilken //knapp som skal belyses/slukkes (etasjevalg i heis, opp i korridor... //Parameteren illuminated definerer hvorvidt lyset skal slukkes eller tennes. audiblesignal(floor:int):void //Gi lydsignal for å indikere at en heis har annkommet etasjen. Parameteren //floor indikerer i hvilken etasje lydsignalet skal lyde. currentposition(elevator:int):int[] //Metoden brukes for å spørre om nåværende posisjon for en spesifikk heis. //Se komponent [Position KO-6] doorclosed(elevator:int):boolean Side 40 av 65