Systemspecifikation Thord Schibler/Johan André Examensarbetare vid AU-System Mobile 1999 16 augusti
Innehåll 1 Introduktion 1 2 Design av mjukvaruarkitektur 1 2.1 Faser.... 1 2.1.1 Indelning... 1 2.2 Detaljerad systemspecifikation... 2 2.3 Gränssnitt... 2 2.4 Moduler... 2 2.5 Felhantering/Loggning... 4 2.6 Fil/dataformat... 4 3 Krav 5 3.1 Övergripande systemlösningar... 5 3.1.1 Helheten A,S,J,T... 5 3.1.2 Automatisering A,S,J,T... 5 3.1.3 Transportservern JT... 5 3.1.4 Terminering S... 5 3.1.5 Expanderbar S... 5 3.1.6 Testfall JT... 6 3.1.7 Applikationer JT... 6 3.2 Kommunikationsspecifika systemlösningar... 6 3.2.1 SFM A... 6 3.2.2 Protokoll för SMS-C A... 6 3.2.3 Terminal Response A,F... 6 3.2.4 SEND-SM F... 6 3.2.5 SAP F... 6 3.3 Testspecifika systemlösningar... 6 3.3.1 Verifiering S... 6 3.3.2 Loggar JT,F... 6 3.3.3 Testverktyg S... 7 3.3.4 TP-OA H... 7 Referenser 8 Dokument: JTXM02.doc
1 Introduktion Denna Systemspecifikation ämnar beskriva hur kraven i kravspecifikationen ska uppfyllas. Den är en beskrivning av systemets struktur ochhur de olika systemkomponenterna skall samverka. Samtidigt är det en vägledning i det efterkommande konstruktionsarbetet (implementeringen) baserat på de olika systemindelningar, enligt: moduler gränssnitt felhantering fil- ochdataformat eventuella gemensamma datastrukturer Alla krav i Kravspecifikationen kan således härledas till något delmoment i den presenterade lösningen, i sektion 2 finns mer eller mindre implicita kravreferenser för den som är välinsatt i kraven ochi 3 är samtliga krav uppställda med respektive lösningsåtgärd. 2 Design av mjukvaruarkitektur Efter en omskriven, reviderad ochtill viss del utförligare Kravspecifikation, [3], valde JA ochts att fredagen den 6 augusti 1999 genomföra ytterligare en modellering, där vi såg över hur vi skulle uppfylla kraven ochhur dessa skulle implementeras. JA hade redan börjat titta på AU-Systems ramverk ochskrivit lite kod för testa hur det fungerar och agerar. 2.1 Faser Implementeingen delas in i tre stycken delfaser: a) Kommunikationsgränssnitt mellan TS och SIM-ShortCut. Implementeras i moduler som tar hand om in och utgående meddelanden samt utför de nödvändiga datakonverteringar. Initierar nedladdningar till kortet. b) Kortgränssnittet med DLL ochkortläsare. De, för närvarande, två olika nedladdningstyperna, OTA och STK, implementeras utifrån en meddelandetypshuvudklass. Utför nedladdningar på SIM-kort c) Testmiljöer. Script och automatiska testförfaranden kodas och tas fram. I fas c) kommer även loggingen att implementeras. 2.1.1 Indelning Fas a) ochb) utförs parallellt av JA ochts ochsätts samman via de veckomöten beskrivna under 2.2. Detta för att arbetet skall flyta på ochsamtidigt ge inblick i framskridandet ochde eventuella problem som (alltid) uppstår. Utöver dessa faser kommer utvecklingen att indelas i: 1. TS tar hand om gränssnitt mot TS, UCP, med initiering ochuppstart av SIM-ShortCut. 2. JA börjar med gränssnittet mot kortläsare, SIM-kort ochdll, där OTA-tjänsterna utvecklas först, då STK-delen är betydligt h årigare ochkräver ett standarformat över filerna på SIM-kortet. 3. Efter lyckade tester av Fas a) ochb) påbörjas fas c). Dokument: JTXM02.doc 1(8)
Figur 1: Implementeringsfaser. 2.2 Detaljerad systemspecifikation Under implementeringen kommer det att tas fram en mer detaljerad beskrivning av de olika systemdelarna. De olika delarna som vi anser behöver detta kommer att beskrivas utförligt ochall relaterad information ochdata 1 kommer att redovisas. Dokumentet är tänkt som ett komplement till den välkommenterade koden ochdet kommer att växa fram under de veckovisbaserade möten som JA ochts kommer att hålla för att hela tiden arbeta i samma riktning och klargöra de metoder som implementeras. Det blir ej heller ett milstolpedokument. 2.3 Gränssnitt? 2.4 Moduler Efter [4] fastslogs en indelning där det finns 9 stycken moduler, se figur 2 vilken visar modulerna är från översta vänstra hörnet till höger ochdärefter nedåt cykliskt: 1. IP IP-Kanalen som ligger mellan SIM-ShortCut ochtransportservern. Denna kanal svarar för all kommunikation mellan TS och SIM-ShortCut ochstödjer dubbelriktad trafik. 2. SERVER Initierar lyssning på port 4711 som TS, via IP, är uppkopplad mot. När sedan ett meddelande kommer från TS sker tre saker (a) ett MSG-objekt initieras (b) meddelandet sänds vidare till UP (c) en bekräftelse skickas tillbaka till TS, med det format som definierats i GSM 11.11. I de fall där det är STK-meddelanden ochett send-sm genererats på SIM-kortet, skickas dessa till SERVER direkt från MSG. SERVERn initierar även UP ochbuffer via en Supervisor som hanterar alla objekt ochtrafiken emellan dem ochkommer att arbeta i de tillstånd som illustreras i 3. 1 Exempelvis datastrukturer, format, klassträd och algoritmer, mm. Dokument: JTXM02.doc 2(8)
Figur 2: Programarkitekturen för SIM-ShortCut Figur 3: Tillståndsdiagram vid initiering av SIM-ShortCut fram till MSG. Dokument: JTXM02.doc 3(8)
3. UCP Svarar för det protokoll som använder sig av TCP/IP. UCP Universal Computer Protocol. 4. UP (utläses UnPack) Alla meddelanden som kommer in från TS omformateras ochpackas så att de är på samma form som de är innan TS får dem, d.v.s. de är på det format som GSM 11.11 specifierar. 5. Buffer Mellanlagringsutrymme mellan UP (SERVER) ochmsg, där UP fungerar som Producer ochmsg är Consumer. Bufferten inneh åller endast ett meddelande åt gången ochup ochmsg läser i den m.h.a. en binär semafor. 6. MSG Hämtar meddelande från Buffer ochkontrollerar vilken typ av nedladdning det är, STK eller OTA. Därefter skapas lämpligt objekt som tar hand om skrivningen till kortet. Figur 4: Meddelandetyper som objekt i UML. Types är inneh åller alla gemensamma delar som STK ochota har. Ett Types-objekt kommer dock aldrig att initieras utan det är bara STK ochota som skall initieras. 7. STK Formaterar ochladdar ned meddelandet på kortet. Ser även till att eventuella send-sm skickas uppåt tillbaka till MSG. 8. OTA Formaterar ochladdar ned meddelandet på kortet. 9. DLL Dynamisk länkfil som hanterar kommunikationen med SIM-kortet. Skall patchas med envelope och fetch ochmöjligheten att flera applikationer kan läsa från en ochsamma kortläsare. 2.5 Felhantering/Loggning För att få en enhetlig bild av fel- och händelsehantering med AUs övriga mjukvaror kommer det servicepaket för loggning som finns i SAP att implementeras på sådant sätt att SIM-ShortCut uppträder som vilket välprogrammerat AU-program som helst. 2.6 Fil/dataformat Det filformat som är av intresse för SIM-ShortCut är Windows inifiler. Nedan visas syntaxen är för dessa filtyper. [Host] Address="172.16.6.20" Dokument: JTXM02.doc 4(8)
;172.16.252.32 Port="4711" Det som står inom hakparenteser kallas för nyckel ochdet som följer därefter är datavärden associerade med symobliska variabler. Ett semikolon (;) kommenterar bort efterkommande textrad. Dataformatet som SIM-ShortCut kommer att arbeta med är samma som TS, m.a.o. det standardiserade (bytekod) format som GSM 11.11. DF1;DF2;DF3;EF1;CommandHeader1;Data1;EF2;CommandHeader2;Data2;EF3;CommandHeader3;Data3 o.s.v. Nedanstående rad lägger AU-Systems telefonnummer i position 1 i ADN-listan 7F10;;;6F3A;A0DC01041C;41552D53797374656DFFFFFFFFFF06916478625700FFFFFFFFFFFFFF; 3 Krav De tidigare avsnitten under sektion 2 har implicit beskrivit vissa systemlösningar utan att direkt hänföras till några krav. Nedan följer de krav som finns upptagna i [3] med en beskrivning hur de kommer att lösas ochuppfyllas. 3.1 Övergripande systemlösningar 3.1.1 Helheten A,S,J,T Systemet som helhet med dess komponenter skall ej påverkas. Genom att låta all trafik som går mellan TS ochett SMS-C istället gå mellan SIM-ShortCut ochts ochsamtidigt skicka de ackar som SMS-C normalt skickar till TS samt emulera en ME mot kortet kommer systemets funktionalitet ej att påverkas ochuppträdandet blir notmalt. 3.1.2 Automatisering A,S,J,T Testförfarandet skall automatiseras. Iochmed införandet av SIM-ShortCut samt de, i fas c), framtagna testscenarior för Visual Test kommer automatiska tester att vara möjliga. 3.1.3 Transportservern JT Allt som kommer från TS, Transportservern, skall laddas ned på kortet. Garanteras via de bekräftelser (ackar) som genereras ochskickas tillbaka. 3.1.4 Terminering S Tester skall kunna terminera mot ett SIM-kort. Möjliggörs ochuppfylls via införandet ochanvändadet av SIM-ShortCut. 3.1.5 Expanderbar S Det skall vara en expanderbar applikation. Vid programmeringen används god programmeringssed, -teknik ochkoddokumentation samt en modulariserad uppbyggnad av funktionaliteten. Dokument: JTXM02.doc 5(8)
3.1.6 Testfall JT De testfall som skall tas om hand om är endast 4-5 grundfall. I fas c) kommer dessa att implementeras ochutvecklas. 3.1.7 Applikationer JT De applikationer som behöver skall kunna få ta emot bekräftelser (ackar). Enligt 3.1.1 och3.1.3 är detta uppfyllt. 3.2 Kommunikationsspecifika systemlösningar 3.2.1 SFM A Samtliga SMS-typer skall stödjas (7/8/unicode) Möjliggörs via implementeringen av Types{STK, OTA} 3.2.2 Protokoll för SMS-C A Endast ett protokoll i SMS-C bör användas det skall vara UCP som använder sig av TCP/IP. Genom att återanvända källkod från Transportserver ochden inverterade Transportservern. 3.2.3 Terminal Response A,F Vid STK-meddelande skall det alltid skickas ett terminal-response till kortet. Implementeras i fas b). 3.2.4 SEND-SM F Alla send-sm skall skickas vidare till Transportservern. Implementeras i fas a) ochfas b). 3.2.5 SAP F Det internt utvecklade kommunikationsverktyget SAP bör användas för att förenkla kodingen och slippa programmeringstrådning. Ramverket ochdess paket inkluderas ochanvänds flitigt vid kodningen. 3.3 Testspecifika systemlösningar 3.3.1 Verifiering S Det skall gå att verifiera resultatet av en nedladdning. Vid en nedladding låter man en appklikation öppna kortet ochpå såsätt går det att se vad som blev nedladdat ochhur det gick. 3.3.2 Loggar JT,F Alla operationer, transaktioner och bekräftelser (ackar) skall loggas i fil. Dokument: JTXM02.doc 6(8)
Implementeras via ramverkets loggpaket i fas c). 3.3.3 Testverktyg S Visual Test bör användas för att kunna verifiera resutatet av en nedladdning. Uppfylls ochimplementeras i fas c). 3.3.4 TP-OA H Det skall vara möjligt att konfigurera tp-oa, Transfer Protocol Originating Address, i en ini-fil. Implementeras via ett filhanteringspaket från ramverkets i fas a). Övriga normala inställningar kommer även att kunna konfigueras i inifilen. Dokument: JTXM02.doc 7(8)
Referenser [1] //FRMNTW/DOCS/Kravdiskussion990628 v2.doc, sammanställning av mötesanteckningar från 990628. [2] //FRMNTW/DOCS/Krav990706.doc, sammanställning av anteckningar från JA ochts modellering. [3] //FRMNTW/DOCS/JTXM01.doc-990817.pdf, Systemkravspecifikation med nulägesanalys. Milstolpedokument från Modelleringsfasen. [4] //FRMNTW/DOCS/SIM Shortcut Arkitektur990806.doc, sammanställning av anteckningar från JA ochts designmodellering, där systemarkitekturen togs fram. Dokument: JTXM02.doc 8(8)