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

41 //Spør om døren i en spesifikk heis er lukket doorblocked(elevator:int):boolean //Spør om hvorvidt sensorene i en spesifikk heis har detektert at døren er //blokkert (og dermed ikke kan lukkes før obstruksjonen er fjernet). Ressurser - Prosessering - Data - Side 41 av 65

42 3.15 Beskrivelse av komponent IEP-in IEP-In Komponentnavn: IEP-In Attributt Beskrivelse Identifikasjon KO-14 Type Interface Hensikt IEP-In er den andre halvdelen av Grensesnitt mot Heisfysikk. Definerer grensesnitt mot heiskontrollsystem, i form av metoder, som et fysisk heissystem/simulatorgui kan benytte seg av. Metodene tilfredsstiller kravene: F-A-14, F-B-1, F-B-2, F-B-3, F-B-4, F-B- 5, F-B-6. Funksjon Interfacet definerer metoder som må implementeres i komponenten som representerer grensesnitt mot heiskontrollsystem. I vårt tilfelle blir IEP-In implementert av CentralProcessingUnit. Underordninger - Avhengigheter CentralProcessingUnit implementerer IEPIn. Grensesnitt IEP-in tilbyr følgende metoder: adddestination(elevator:int, destination:int):void //Legger en destinasjonsetasje inn i køen til aktuell heis callelevator(direction:int, floor:int):void //Kalles når en passasjer tilkaller en heis. //Fører til at systemet velger en passende heis. opendoor(elevator:int):void //Kalles når noen vil åpne døren til en bestemt heis closedoor(elevator:int):void //Kalles når noen vil lukke døren til en bestemt heis stopelevator(elevator:int):void //Kalles når noen vil stoppe en bestemt heis alarm(elevator:int):void //markerer at alarm er blitt aktivert i aktuell heis reportfault(f:fault):void //rapporterer feil til heiskontrollsystem Ressurser - Prosessering - Data - Side 42 av 65

43 3.16 Beskrivelse av komponent ICS-in ICS-In Komponentnavn: ICS-In Attributt Beskrivelse Identifikasjon KO-15 Type Interface Hensikt Definere grensesnitt mot heiskontrollsystem, i form av metoder, som en kontrollsentral kan benytte seg av. Metodene tilfredsstiller kravet F-C-1. Funksjon Interfacet definerer metoder som må implementeres i komponenten som representerer grensesnitt mot heiskontrollsystem. I vårt tilfelle blir ICS-In implementert av CCC [KO-17] Underordninger - Avhengigheter Grensesnitt Ressurser - Prosessering - Data - CCC implementerer ICS-In. querystatus( ):SystemStatus[] // Sender status (for hver enkelt heis) til KS takecontrol( ):void //Initierer overstyring fra KS. Sletter kø for hver heis, og blokkerer alle kall //fra Elevator > heisfysikk releasecontrol( ):void // Avslutt overstyring, og la systemet gå som normalt. gotofloor(elevator:int, floor:int):void // Overstyringskommando. Kommander en heis til å gå til en bestemt etasje. opendoor(elevator:int):void //Overstyringskommando. Send åpnekommando til en bestemt heis. closedoor(elevator:int):void //Overstyringskommando. Send lukkekommando til en bestemt heis stopelevator(elevator:int):void //Overstyringskommando. Send stoppkommando til en bestemt heis. Side 43 av 65

44 3.17 Beskrivelse av komponent ICS-out ICS-Out Komponentnavn: ICS-out Attributt Beskrivelse Identifikasjon KO-16 Type Hensikt Funksjon Interface Definere grensesnitt mot kontrollsentral, i form av metoder, som en heiskontrollsystemet kan benytte seg av. Tilfredsstiller krav F-A-20, F-A- 21, F-A-22, F-A-23, F-A-24, F-A-25 Interfacet definerer metoder som må implementeres i komponenten som representerer kontrollsentralen. Underordninger - Avhengigheter Modul som representerer kontrollsentral implementerer ICS-Out Grensesnitt IEP-out tilbyr følgende metoder: Ressurser - Prosessering - Data - reportfault(f:fault):void //Rapporterer en feilmelding til kontrollsystemet Side 44 av 65

45 3.18 Beskrivelse av komponent CCC CCC Komponentnavn: CCC Attributt Beskrivelse Identifikasjon KO-17 Type Klasse Hensikt Komponenten implementerer metodene i ICS-In dvs. den tar imot forespørseler fra kontrollsentralen i henhold til krav F-C-1. Den tar også imot overstyringskommandoer i henhold til krav F-A-6. Funksjon CCC sender status til kontrollsentralen, og kan sende overstyringskomandoer fra kontrollsentralen til heisfysikken. Underordninger - Avhengigheter CCC implementerer metodene i ICS-In. Den arver også fra klassen Controller [REF], og kan dermed sende styringskommandoer til heisfysikken via ControlSwitch. Grensesnitt CCC tilbyr følgende metoder: Ressurser - Prosessering - Data - querystatus():systemstatus[] takecontrol():void releasecontrol():void gotofloor():void opendoor(elevator:int):void closedoor(elevator:int):void stopelevator(elevator:int):void // Se komponent ICS-In for beskrivelse av disse metodene. Side 45 av 65

46 3.19 Beskrivelse av komponent AccessControl AccessControl Komponentnavn: AccessControll Attributt Beskrivelse Identifikasjon KO-18 Type Interface Hensikt Funksjon Brukes for å sjekke om brukeren har tilgang til destinasjonsetasje Interfacet AccessControl definerer grensesnitt mot adgangskontrollsystem som et Elevator objekt kan benytte seg av, for å finne ut om en passasjer har adgang til en gitt etasje som krever adgangskontroll. Underordninger - Avhengigheter Interfacet AccessControll implementeres av modul som representerer adgangskontrollsystem Grensesnitt Består av metoden: queryaccess(elevator:int):boolean //returnerer true hvis adgang er tildelt, ellers false Ressurser - Prosessering - Data - Side 46 av 65

47 3.20 Beskrivelse av komponent SHA SHA Komponentnavn: SHA Attributt Beskrivelse Identifikasjon KO-19 Type Klasse Hensikt SHA inneholder en implementasjon av metoden chooseelevator, som velger mest gunstige heis, i henhold til krav F-A-2. Funksjon Komponenten velger gunstigste heis ut fra etasje, og heisenes nåværende status. Denne implementasjonen bruker antall destinasjoner i heisens kø, avstand fra etasjen og hvorvidt heisen er på vei forbi etasjen uansett, for å bestemme hvilken heis som er mest gunstig. Algoritmen har som mål å fordele oppgavene på heisene, slik at de har mest mulig jevn arbeidsmengde. Underordninger - Avhengigheter SHA arver komponent KO-# (ESL). Den bruke også Elevator-klassen for å hente informasjon om køens nåværende status. Vi trenger minst et Elevatorobjekt. Grensesnitt SHA tilbyr følgende metoder: Ressurser - Prosessering Data chooseelevator(elevators[]:elevator,fod,int,direction:int):elevator // Se KO-# ESL for beskrivelse av metoden Algoritmen for å velge heis gir hver heis en "score" på hvor bra den er, og velger den med best "score". Faktorene som påvirker "scoren" er, i prioritert rekkefølge, lengde på køen, avstand fra FOD og hvorvidt heisen er på veg forbi FOD. Dersom det kun finnes et Elevator-objekt er valget åpenbart. Se beskrivelse av metoden chooseelevator og metodene i Elevator som er public. Side 47 av 65

48 3.21 Beskrivelse av komponent Fault Fault Komponentnavn: Fault Attributt Beskrivelse Identifikasjon KO-20 Type Klasse Hensikt Komponenten representerer en feilmelding til heisstyringssystemet, og tilfredsstiller kravene F-A-16, F-A-24. Funksjon Komponenten gjør ingen prosessering av data. Den inneholder en streng med en tekstlig beskrivelse av feilen, samt en integer som representerer alvorlighetsgraden. Underordninger - Avhengigheter - Grensesnitt Fault tilbyr følgende metoder: gettext():string // Returnerer den tekstlige beskrivelsen av feilen getimpactlevel():int // Returnerer alvorlighetsgraden til feilen Ressurser - Prosessering - Data text:string inneholder den tekstlige beskrivelsen. impact:int inneholder alvorlighetsgraden. Denne kan inneholde verdiene: Fault.CRITICAL, Fault.NONCRITICAL eller Fault.NOTIFICATION. Side 48 av 65

49 3.22 Beskrivelse av komponent AlertReception AlertReception Komponentnavn: AlertReception Attributt Beskrivelse Identifikasjon KO-21 Type Klasse Hensikt Varsler Systemet om at noe er galt Funksjon Tar imot varsling fra varslingssystem og genererer en feilmelding, som formidles til CentralProcessingUnit Underordninger - Avhengigheter Genererer en Fault-instans Grensesnitt alertsystem():void recievealert():void Ressurser - Prosessering - Data - Side 49 av 65

50 3.23 Beskrivelse av komponent Init Init Komponentnavn: Attributt Beskrivelse Identifikasjon KO-22 Type Tekst fil Hensikt Det skal finnes en tekst fil som inneholder oppstartsparametre for heiskontrollsystemet, dette for at systemet skal være konfigurerbar. Tilfredstiller krav: F-A-1, F-A-3, F-A-4, F-A-5, IF-A-6, F-A-12 Funksjon Komponenten prosesserer ikke data, men skal innholde ulike oppstartsparametere. Underordninger - Avhengigheter Leses av komponenten CentralProcessingUnit,( KO-3) Grensesnitt - Ressurser - Prosessering - Data Antallheiser = Integer Dette er antall heiser heiskontrollsystemet styrer. Antalletasjer = Integer Dette er antall etasjer heiskontrollsystemet styrer. Utgangsetasje = Integer Dette er etasjen som systemet regner som bygningens primære utgangsetasje. AntallMinutterInaktiv = Integrer Hvor mange minutter en heis skal være inaktiv før den sendes til utgangsetasjen. Adgangskontroll = Kommaseparert liste av Integers Hvilke etasjer som har adgangskontroll Siste_service = DD.MM.ÅÅÅÅ Dato for siste service Service_frekvens = Integer Hvor mange dager det skal være mellom hver service NB: Se vedlegg 4.5 for et eksempel. Side 50 av 65

51 4. Vedlegg Her har vi valgt å legge sporingstabeller, pseudokode for alle komponentene og diagrammer for å vise forskjellige deler av designet. Forkortelser og definisjoner samt referanser finnes også her. 4.1 Sporingstabeller Den første tabellen viser sporing fra krav til komponenter, men den andre viser fra komponenter til krav. (Ett krav kan ha flere komponenter) Sporing frem. Krav Design Komponent Krav F-A-1 F-A-2 F-A-3 F-A-4 F-A-5 F-A-6 F-A-9 F-A-10 F-A-11 F-A-12 F-A-14 F-A-15 F-A-16 F-A-17 F-A-18 F-A-19 F-A-20 F-A-21 F-A-22 F-A-23 F-A-24 F-A-25 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-34 F-A-35 F-A-36 Sporing frem Design komponent KO-3, KO-22 KO-2, KO-19 KO-22 KO-22 KO-22 KO-17, KO-9 KO-3 KO-3 KO-3 KO-22 KO-14 KO-3 KO-3, KO-20 KO-3 KO-8 KO-8 KO-16 KO-16 KO-16 KO-16 KO-16, KO-20 KO-16 KO-1 KO-1, KO-10 KO-1, KO-10 KO-1, KO-10 KO-1, KO-10 KO-1, KO-10 KO-1, KO-10 KO-1, KO-10 KO-10, KO-11 KO-1, KO-10 KO-10 Side 51 av 65

52 F-B-1 F-B-2 F-B-3 F-B-4 F-B-5 F-B-6 F-B-8 F-B-9 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-C-1 F-D-1 F-D-2 F-D-3 F-D-4 F-D-6 F-D-7 F-D-8 IF-A-1 IF-A-2 IF-A-3 IF-A-4 IF-A-5 IF-A-6 IF-B-1 IF-B-2 IF-U-1 IF-U-2 IF-U-3 IF-U-4 IF-U-5 IF-U-6 IF-U-7 IF-U-8 IF-U-9 IF-U-10 IF-U-11 IF-U-12 IF-U-13 IF-HW-1 IF-SW-1 IF-SW-2 KO-3, KO-14 KO-3, KO-14 KO-3, KO-14 KO-3, KO-14 KO-3, KO-14 KO-3, KO-14 KO-13, KO-1 KO-13, KO1 KO-4 KO-4, KO-13 KO-4, KO-13 KO-4, KO-13 KO-4, KO-13 KO-4, KO-13 KO-4, KO-13 KO-4, KO-13 KO-15, KO-17 KO-4 KO-5 KO-7 KO-7 KO-4, KO-5 KO-5 KO-7 KO-8, KO-22 KO-5 KO-7 KO-5 KO-5 KO-5 KO-5 KO-5 KO-5 KO-5 KO-5 KO-5 Side 52 av 65

53 IF-SW-3 IF-SW-4 YT-A Sporing tilbake. Design komponent Krav Sporing tilbake Design komponent Krav KO-1 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, F-B-9 KO-2 F-A-2 KO-3 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 KO-4 F-D-1, F-D-6, F-B-10, F-B-11, F-B-12, F-B-13, F-B-14, F-B-15, F-B-16, F-B-17. KO-5 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 KO-6 KO-7 F-D-3, F-D-4, F-D-8 og IF-B-2. KO-8 F-A-6, F-A-18, F-A-19 KO-9 F-A-7 KO-10 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 KO-11 F-A-34. KO-12 KO-13 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. KO-14 F-A-14, F-B-1, F-B-2, F-B-3, F-B-4, F-B-5, F-B-6. KO-15 F-C-1. KO-16 F-A-20, F-A-21, F-A-22, F-A-23, F-A-24, F-A-25 KO-17 F-A-6, F-C-1, KO-18 KO-19 F-A-2. KO-20 KO-21 KO-22 F-A-16, F-A-24. F-A-1, F-A-3, F-A-4, F-A-5, IF-A-6, F-A-12 Side 53 av 65

54 4.2 Forkortelser og definisjoner Ord AccessControll Adgangskontrollsystem Algoritme Alvorlighetsgrad Animere Attributter Collobrationdiagram Controller ControlProcessingUnit ControlSwitch Destinasjon Destinasjonsetasje Eksekvering Elevator EPanel Event Grafikk Grensesnitt GUIElevator Heisfysikk Definisjoner Beskrivelse Dette er en av våre klasser. Brukes for å sjekke om brukeren har tilgang til destinasjonsetasje System som mottar id og verifiserer data om en heisbruker Ett sett av definerte regler eller metoder for å løse et problem i et gitt antall trinn Betegner hvor alvorlig en feil som oppstår i forbindelse med heiskontrollsystemet er Bevegelig grafikk Egenskaper til en entitet/klasse Dette diagrammet beskriver ett sett med interaksjoner mellom klasser og typer og viser forholdet mellom objekter Controller representerer et objekt som kan gis kontroll i klassen CCC Dette er en av våre klasser. Den legger til destinasjoner i kølisten, tilkaller heis, åpner dør, stenger dør, stopper heis, alarm og reporterer feil. Den knytter også objektene sammen Dette er en av våre klasser. Hensikten med ControlSwitch er å bestemme hvilke komponenter som har tilgang til å styre heisfysikken Dit passasjeren vil dra Den etasjen passasjeren har valgt som sitt mål Kjøring Dette er en av våre klasser. Elevator skal representere selve heisen i vårt system. Den skal simulere en heis og har metoder som aktiverer handlinger som en heis utfører. Dette er en av våre klasser. Presentere brukergrensesnitt mot heissimulatoren, i form av knapper og grafiske framstillinger av GUIElevatorinstanser. Hendelse Med grafikk menes bilder og figurer som genereres og behandles av en datamaskin, Grensesnitt betyr måten to enheter kommuniserer med hverandre Dette er en av våre klasser. Hensikten med GUIElevator er å representere den grafiske fremstillingen av en heis (av en eller flere), i SimulatorGUI. De fysiske mekaniske delene til heisen som f. eks motor og sensorer Side 54 av 65

55 Heiskontrollsystem Vår prosjekt, som går ut på å styre flere heiser Hit-kall En forespørsel til heisen om å komme til ønsket etasje ICS-out interface Dette er en av våre interface. Definere grensesnitt mot kontrollsentral, i form av metoder, som en heiskontrollsystemet kan benytte seg av ICS- in interface Dette er en av våre interface. Definere grensesnitt mot heiskontrollsystem, i form av metoder, som en kontrollsentral kan benytte seg av IEEE Standard 1016 Mal for beskrivelse av komponenter med 10 forskjellige punkter som skal fylles ut. Denne skal være en del av detaljert design. IEP-in interface Dette er en av våre interface Definere grensesnitt mot heiskontrollsystem, i form av metoder, som et fysisk heissystem/simulatorgui kan benytte seg av. IEP-out interface Dette er en av våre interface IEP-Out er den ene halvdelen av Grensesnitt mot Heisfysikk, som tar seg av og sende kommandoer og forespørsler til heisfysikken. Impact level Se alvorlighetsgrad Inaktivitet Når heisen ikke har blitt brukt i en gitt tid Initfil En fil som inneholder oppstartsparametere som systemet benytter. Fila inneholder data om: antall heiser, antall etasjer, utgangsetasje, antall minutter en heis skal være innaktiv før den går til første etasje, hvilke etasjer som krever adgangskontroll, datoen for siste service og service frekvens. Instans Objekt Interface Grensesnitt Java Dette er et objektorient programmerings språk som er utviklet av Sun Microsystem Klassediagram Klassediagram viser hvordan den statiske strukturen til objektene er, deres interne struktur og relasjon. Komponent En enhet i systemet, f.eks klasse og grensesnitt Kontrollsentral En sentral som kan kontrollere og overstyret heiskontrollsystemet. Modul En større enhet i systemet som klasse og grensesnitt. Objectinteraksjonsdiagram Et diagram som viser beskjeder som er sendt mellom instanser av de klassene, og rekkefølgen de er sendt. Også kalt sekvensdiagram Operasjon Operatør ved kontrollsentral Passasjer Pin-kode Position En hendelse som aktiveres av en metode i systemet Personen som sitter ved kontrollsentralen hvor man kan overstyre systemet. Her gis tilgang til bevegelser og oppførsel for alle heisene. Dette er heisbrukeren. En person som ønsker å benytte heisen Personal Identity Number code. En nummerkode som brukes til identifisering av brukeren. Dette er en av våre klasser. Representere posisjonen til Side 55 av 65

56 Pseudokode Sekvensdiagram SimulatorGUI SortedQueue Sporingstabell SQNode Statediagram Status Tilkalle heis Styringskommandoer Unified Modeling Language Utgangsetasje Varslingssystem View 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. Kode som er skrevet med ord. Et diagram som viser beskjeder som er sendt mellom instanser av de klassene, og rekkefølgen de er sendt. Dette er en av våre klasser. Den representere en grafisk imitasjon av et fysisk heissystem, for demonstrasjonsformål og utnytter grensesnittet som tilbys mot heiskontrollsystemet. Dette er en av våre klasser. Denne skal behandle en kø av heiser og har metoder som setter inn nye heisobjekter i køen, oppdaterer listen og sorterer den. Tabellen som gjør at man kan følge krav og dets avhengigheter Dette er en av våre klasser og den representere en etasjeforespørsel Et statediagram viser hvordan en hendelse gjør at en tilstand endres og hvilke hendelser det resulterer i. Dette er en av våre klasser. Hensikten med klassen er at den skal tilgjengeliggjøre et sett med symbolske tallkonstanter som brukes av de ulike klassene i systemet Sende en forespørsel til systemet om at man ønsker en heis til etasjen man står i. Meldinger som sendes til heisfysikk, som ber heisfysikken om å for eksempel flytte en heis til en bestemt etasje, stoppe en heis eller åpne/lukke dører UML er et modelleringspråk som spesifiserer semantikk og notasjon. Dette er etasjen heisene beveger seg til automatisk hvis brannalarmen går. Utgangsetasjen vil typisk være etasjen som hovedutgangen befinner seg i. Generisk eksternt system i bygningen, som detekterer /varsler kritiske situasjoner i bygningen Synsvinkel Forkortelse CCC ESL FOD GUI IEEE SDS SE SHA Forkortelser Beskrivelse Control Center Control (Dette er en av våre klasser.) Elevator Selection Logic (Dette er en av våre klasser.) Floor of Departure Graphical User Interface Institute of Electrical and Electronics Engineers System Design Specification Software Engineering Stenmark- Hansen Algorithm Side 56 av 65

57 SRS UML Software Requirement Specification Unified Modeling Language Side 57 av 65

58 4.3 Pseudokode Vi har valgt å legge ved en pseudokode for Elevator-klassens købehandling // *heis på vei oppover -> kø sorteres synkende (første element har lavest etasjenr) // *heis på vei nedover -> kø sorteres stigende (første element har høyest etasjenr) currentdest = 1 kø er satt til å sortere synkende while(true) { currentfloor = IEPOUT.getPosition(heisnr)[0]; direction = IEPOUT.getPosition(heisnr)[1]; //noe sånt? hvis direction == Status.At_FLOOR og kø.contains(currentfloor) kø.slett(currentfloor); hvis kø ikke er tom hvis direction == Status.UP og kø.contains(currentfloor+1) gotofloor(currentfloor+1) currentdest = currentfloor+1 ellers hvis direction == Status.DOWN og kø.contains(currentfloor-1) gotofloor(currentfloor-1) currentdest = currentfloor-1 ellers newdest = kø.head() hvis newdest!= currentdest hvis newdest < currentdest direction = Status.DOWN //? sorter kø stigende hvis newdest > currentdest direction = Status.UP //? sorter kø synkende gotofloor(newdest) currentdest = newdest } Side 58 av 65

59 4.4 Kortversjon av krav KravId F-A-1 F-A-2 F-A-3 F-A-4 F-A-5 F-A-6 F-A-9 F-A-10 F-A-11 F-A-12 F-A-14 F-A-15 F-A-16 F-A-17 F-A-18 F-A-19 F-A-20 F-A-21 F-A-22 F-A-23 F-A-24 F-A-25 F-A-26 F-A-27 Beskrivelse av kravet Det skal være mulig å bestemme hvor mange heiser og etasjer systemet skal styre, noe man bestemmer før applikasjonen startes. Parametrene angis i en initfil. Systemet skal beregne en heis som innehar en gunstig kombinasjon av posisjon, retning, kølengde og avstand fra passasjeren som tilkaller en heis, og legge passasjerens etasje inn i heisens destinasjonskø. Det skal være mulig å tilby adgangskontroll. Hvilke etasjer dette evt gjelder angis i initfilen. Systemet bør ha oversikt over når vedlikehold ble utført sist. Systemet bør anbefale vedlikehold når det har gått en viss tidsperiode siden forrige gang. Tidsperioden angis i initfilen. Operatøren ved kontrollsentralen skal kunne overstyre heisfunksjoner Systemet skal kunne behandle forespørsler fra brukere om at de ønsker å tilkalle en heis, for å bevege seg oppover Systemet skal kunne behandle forespørsler fra brukere om at de ønsker å tilkalle en heis, for å bevege seg nedover Systemet skal kunne behandle en passasjers forespørsel om å bevege seg til en etasje, ved hjelp av en heis Etter X minutters inaktivitet, skal en heis gå til første etasje og stå med dørene lukket. Antall minutter angis i en initfil. Systemet skal kunne motta signaler fra sensorer i døra Heiskontrollsystemet skal kunne motta hva slags feiltype som har blitt oppstått og rapportere til kontrollsentralen Systemet skal kunne motta feilmeldinger fra kontrollsentral, heisfysikk og varslingssystem Ved varsling om brann, skal alle heisene gå til første etasje og åpne dørene Etter brann skal alle forespørsler fra passasjerer sperres Etter brann settes systemet i normal drift fra kontrollsentral Heiskontrollsystemet skal motta melding om alarm fra heiskupé, og formidle dette til kontrollsentral Heiskontrollsystemet skal motta melding om at noen har trykket på stoppknapp i en heiskupé, og formidle dette til kontrollsentral Heiskontrollsystemet skal motta feilmeldinger om avbrutt strømtilførsel Heiskontrollsystemet skal motta feilmeldinger om at dører ikke er lukket Heiskontrollsystemet skal motta feilmeldinger om at heisen ikke beveger seg Heiskontrollsystemet skal motta feilmeldinger om at heisen har stoppet mellom to etasjer Heisen skal ikke kjøre før døren er lukket Systemet skal vedlikeholde en destinasjonskø for hver enkelt Side 59 av 65

60 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 F-B-1 F-B-2 F-B-3 F-B-4 F-B-5 F-B-6 F-B-8 F-B-9 F-B-10 F-B-11 F-B-12 F-B-13 F-B-14 F-B-15 heiskupé Heisens nåværende destinasjonsetasje skal til enhver tid være første element i heisens destinasjonskø For hver etasje en heis ankommer (som ikke er nåværende destinasjonsetasje), skal heisen sjekke om etasjen befinner seg i køen. Hvis ja, skal heisen stoppe i etasjen, og fjerne den fra køen. Når heisen er på vei oppover, skal destinasjonskøen være sortert i synkende rekkefølge, etter etasjenr (Head er det høyeste etasjenr) Når heisen er på vei nedover, skal destinasjonskøen være sortert i stigende rekkefølge, etter etasjenr (Head er det laveste etasjenr) Når en heis skifter retning, reverseres sorteringen av heisens destinasjonskø Når systemet startes, skal alle destinasjonskøer være konfigurert til å være sortert i stigende rekkefølge etter etasjenr En destinasjonskø tilhørende en heis skal ikke inneholde flere like destinasjoner (etasjenr) samtidig Når en heis stopper i en etasje, skal forespørselen som tilsvarer denne etasjen fjernes fra heisens destinasjonskø Når en heis blir tildelt en forespørsel, skal denne forespørselen settes inn i heisens destinasjonskø på en slik måte at køen fremdeles er sortert etter innsettingen. Heiskontrollsystemet skal via grensesnittet kunne ta imot et destinasjonsvalg og tildele oppgaven til en heis. Heiskontrollsystemet skal via grensesnittet kunne ta imot alarm fra en heiskupé. Heiskontrollsystemet skal via grensesnittet kunne motta kommando om å stoppe en heis. Heiskontrollsystemet skal via grensesnittet kunne motta kommando om å åpne heisdør. Heiskontrollsystemet skal via grensesnittet kunne motta kommando om å lukke heisdør. Heiskontrollsystemet skal via grensesnittet kunne motta kommando om å tilkalle heis Grensesnittet skal la systemet indikere at heisen ankommer en etasje. Heiskontrollsystemet skal via grensesnittet kunne kommandere en bestemt heis til en bestemt etasje Heiskontrollsystemet skal via grensesnittet få tilgang på informasjon over hvor en bestemt heis befinner seg Heiskontrollsystemet skal via grensesnittet kunne gi heisfysikken beskjed om å åpne en bestemt heisdør Heiskontrollsystemet skal via grensesnittet kunne gi heisfysikken beskjed om å lukke en bestemt heisdør Heiskontrollsystemet skal via grensesnittet kunne gi heisfysikken beskjed om å stoppe en bestemt heis Heiskontrollsystemet skal via grensesnittet kunne gi heisfysikken beskjed om å slå av/på knappebelysning på en bestemt knapp Heiskontrollsystemet skal via grensesnittet kunne gi heisfysikken Side 60 av 65

61 F-B-16 F-B-17 F-C-1 F-D-1 F-D-2 F-D-3 F-D-4 F-D-6 F-D-7 F-D-8 IF-A-1 IF-A-2 IF-A-3 IF-A-4 IF-A-5 IF-A-6 IF-B-1 IF-B-2 IF-U-1 IF-U -2 IF-U -3 IF-U 4 IF-U 5 IF-U 6 IF-U 7 IF-U 8 IF-U -9 IF-U 10 IF-U 11 beskjed om å spille et lydsignal i en bestemt etasje Heiskontrollsystemet skal via grensesnittet kunne finne ut om en bestemt dør er blokkert eller ikke Heiskontrollsystemet skal via grensesnittet kunne finne ut om en bestemt dør er lukket eller ikke I kontrollsentralen skal man hele tiden få info over hvor de enkelte heisene befinner seg. (Returnerer heis objekter) SimulatorGUI må kunne ta imot styringsinstrukser i henhold til grensesnitt mot heisfysikk. SimulatorGUI må tilby knapper som tilsvarer de definert i grensesnitt mot heisfysikk. SimulatorGUI bør animere bevegelsen til heisene. SimulatorGUI bør animere åpning/lukking av heisdører. SimulatorGUI må ved oppstart kunne lese oppsett på samme måte som styringssystemet, og tegne den nødvendige grafikk deretter. I hver etasje skal være mulig å vise posisjonen til hver enkel heis. Grensesnittet skal la systemet indikere at heisen ankommer en etasje. Systemet skal kunne styre opp til fire heiser Systemet skal kunne behandle fra 3 til 20 etasjer. Systemet skal kunne lukke dørene automatisk vh.a timer funksjonen Det tar 1 sekund fra heis stopper til dørene åpner seg Det skal kun ta ett sekund fra dørene stenges til heisen beveger seg Det skal finnes en initfil som inneholder oppstartsparametre for heiskontrollsystemet SimulatorGUI må presentere grafikk som representerer etasjene. SimulatorGUI må presentere grafikk som representerer heis(ene). Interfacet mellom en bruker og systemet skal ha en maksimum responstid på to sekunder Aktive knapper skal lyse Når heis ankommer destinasjonsetasje, skal dette markeres ved et lydsignal I hver etasje skal det være knapper for å tilkalle heisen. En for å indikere at man vil opp, og en for ned. I den første etasjen skal det kun være en opp-knapp I den øverste etasjen skal det kun være en ned-knapp Det skal være en knapp for å stoppe heisen. Det skal være en knapp for å åpne heisdør. Det skal være en knapp for å lukke heisdør. Det skal være en knapp for valg av destinasjonsetasje. Det skal være en knapp for å utløse alarm Side 61 av 65

62 IF-U -12 IF-U -13 IF-HW-1 IF-SW-1 IF-SW-2 IF-SW-3 IF-SW-4 YT-A-1 Operatøren skal kunne bruke 80% av systemet etter to timers opplæring Over hver heis i hver etasje skal det vises i displayet hvor heisen er Stoppemekanisme i tilfelle nødssituasjoner Systemet skal ha et grensesnitt mot en ekstern enhet som lagrer brukerinformasjon Systemet skal ha et grensesnitt mot et eller flere eksterne varslingssystemer Systemet skal ha et grensesnitt mot aktuell heisfysikk Systemet skal ha et grensesnitt mot ekstern kontrollsentral Maskinen på kontrollsentralen bør ha minimum 128 MB RAM, 20 GB harddisk, 800 MHz prosessor Side 62 av 65

63 4.5 Eksempel på Init fil Dette er oppsettet vi skal bruke i vår init fil: Antallheiser = 4 Antalletasjer = 20 Utgangsetasje = 1 AntallMinutterInaktiv = 5 Adgangskontroll = 18,19,20 Siste_service = Service_frekvens = 60 // Initfil for HeisKontrollSystemet // Side 63 av 65

64 4.6 Referanser 1. Tittel: Software Engineering, Theory and practice, Forfatter: Shari Lawrence Pfleeger. Kilde Bokutgivelse: Prentice Hall Inc. Second Edition Tittel: Requirement Engineering, Processes and Techniques. Forfatter: Gerald Kotonya and Ian Sommerville. Kilde Bokutgivelse: John Wiley & Sons, Tittel: Forfatter: Kilde 4. Tittel: Forfatter: Kilder: Kursside: Software Engineering Ky Van Ha A Software Design Specification Template Brad Appleton 5. Tittel: Forfatter: Kilder: Software Design Specification Ukjent 6. Tittel: Forfatter: Kilder: Mal: Software Design Specification Gitt av: Ky Van Ha 7. Tittel: Vår SRS Forfatter: Gruppe 7 Kilder: 8. Tittel: Instant UML Forfatter: Pierre-Alain Muller Kilder: Bokutgivelse: Wrox Press Ltd, Tittel: Forfatter: Kilder: Introduction to Software Engineering: UML Ananda Amatya. Department of CS. University of Warwick Side 64 av 65

65 10. Tittel: Forfatter: Kilder: The Class Model Enterprise Architect Tittel: Forfatter: Kilder: Architecture and design: Unified Modeling language (UML) Amit Bhagwat Tittel: Forfatter: Kilder: The UML Class Diagram Fra Smart Draws sine sider Tittel: SDS Forfatter: Gruppe 2. SE. Høgskolen I Østfold, 2002 Kilder: Gitt av Ky Van Ha 14. Tittel: SDS Forfatter: Gruppe 4. SE. Høgskolen I Østfold, 2002 Kilde: Gitt av Ky Van Ha 15. Tittel: SDS Forfatter: Gruppe 7. SE. Høgskolen I Østfold, 2002 Kilde: Gitt av Ky Van Ha Side 65 av 65