Tik-76.115 Toiminnallinen määrittely

 
 

Synapsi: Automaattinen ohjelmiston etäpäivitys
NetSeal Technologies
Tietojenkäsittelyn ohjelmatyö Tik-76.115

 

Dokumentin muutoshistoria
Versio Editoija Päiväys Kommentti
0.1 Mikko Varso 1.11.2000 Luonnos - 1. versio
0.2 Mikko Varso 3.11.2000 Korjauksia sisällysluetteloon
0.3 Mikko Varso 5.11.2000 Palaverissa päätetyt muutokset
0.4 Ville Rannikko 6.11.2000 Tarkennettu dokumenttia
1.0 Juho Anttila 6.11.2000 Lisätty viitteet, palautettava versio
1.1 Mika Mäntylä 2.12.2000 Tarkennettu kohtaa 4.1 NC:n käynnistys
1.2 Mika Mäntylä 3.12.2000 Lisätty numerointia. Muutettu kohtia 4.2.4, 4.2.7
2.0 Mika Mäntylä, Juho Anttila 11.12.2000 Katselmoitu ja hyväksytty
2.1 Mika Mäntylä 11.2.2001 Lisätty Netsealin tarjoama tiedostoformaatti.
3.0 Mika Mäntylä, Juho Anttila 12.02.2001 Katselmoitu ja hyväksytty
3.1 Mikko Varso 16.3.2001 Siirretty koneen uudelleenkäynnistysvastuu asennusohjelmalle.
4.0 Mika Mäntylä, Juho Anttila 19.03.2001 Katselmoitu ja hyväksytty
5.0 Mika Mäntylä, Juho Anttila 23.04.2001 Tarkistettu ja hyväksytty lopulliseksi versioksi

1. Johdanto

2. Yleiskuvaus

3. Tiedot ja tietokanta

4. Toiminnot

5. Ulkoiset liittymät

6. Muut ominaisuudet

7. Suunnittelurajoitteet

8. Viitteet

 

1. Johdanto

1.1 Tarkoitus ja kattavuus

Dokumentin tarkoitus on kuvata projektissa toteutettavan Neuron-ohjelmiston toiminnallinen rakenne. Dokumentti on tarkoitettu palvelemaan sekä asiakasta että ohjelmiston toteuttavaa ryhmää. Sen tarkoitus on antaa tarkennettu kuva asiakkaan vaatimuksista ja selventämään, mitä ohjelma oikeasti tulee tekemään. Käyttöliittymä dokumentoidaan erikseen.

1.2 Tuote

Tuotteella ei sinällään ole omaa nimeä, koska projektista tulee asiakkaan tuotteen RoamMate:n osa. Työnimi on Neuroni. Sen tulee toteuttaa asiakkaan tuotteen etäpäivitysominaisuus. Käyttäjälle etäpäivitysominaisuus helpottaa huomattavasti RoamMaten päivitykstä. Palvelinpään ylläpitäjän työtä moduuli helpottaa enemmän kuin asiakkaan. Luultavasti Neuroni myös vähentää tuotetukeen tulevia kyselyjä päivityksistä.

1.3 Määritelmät, termit ja lyhenteet

RM
NetSeal Technologiesin RoamMate-ohjelmisto
RMS
RoamMate-ohjelmiston palvelinversio
RMC
RoamMate-ohjelmiston asiakasversio
Neuroni
Projektin tuottaman ohjelmiston työnimi
NRNI
Synapsi-projektin tuottama "Automaattinen ohjelmiston etäpäivitys" -ohjelmisto
NS
NRNI:n palvelinosa
NC
NRNI:n asiakasosa

1.4 Yleiskatsaus dokumenttiin

 

2. Yleiskuvaus

2.1 Ympäristö

Ohjelmistoympäristönä toimii NetSeal Technologies:n RoamMate-ohjelmisto. Projektin tuotteesta tulee ainoastaan oma moduuli tähän ohjelmistoon. Periaatteessa ei ole haittaa, vaikka ohjelma toimisi ilman RoamMateakin, mutta tätä ei tulla toteuttamaan. Asiakaskoneessa käyttöjärjestelmänä on ainakin aluksi Windows NT4.0, palvelinpään tulisi toimia myös Linuxissa. Laitteistoalustana tuetaan Intel:in PC-arkkitehtuuria.

2.2 Toiminta

Ohjelman toiminta koostuu seuraavista osista:

2.3 Käyttäjät

Tyypillinen tilanne on sellainen, jossa suurella organisaatiolla on RoamMate-palvelin ja useita asiakkaita. Tyypillinen ostaja voisi olla ISP. Asiakaspäässä ei ole olemassa tyypillistä käyttäjää, mummo Pihtiputaaltakin saattaa olla käyttäjä. Tällainen asiakas voi käyttää tuotetta päivittäin, mutta moduulipäivityksiä tehdään huomattavasti harvemmin. Palvelinpäässä käyttäjän tulee olla kokenut ylläpitäjä.

2.4 Yleiset rajoitteet

Ohjelmiston siirrettävyys oltava samalla tasolla kuin RoamMate-ohjelmiston.

2.5 Oletukset ja riippuvuudet

NC:n oletetaan toimivan NT4.0 ympäristössä RMC:n alaisuudessa. NS:n on taas toimittava sekä NT4.0 ja Linux-ympäristössä. Ohjelmisto on riippuvainen verkon toiminnasta.

3. Tiedot ja tietokanta

Tässä luvussa on kuvattu ohjelmiston tietosisältö sekä tiedon kulku ohjelmiston sisällä.

3.1 Tietosisältö

NS sisältää:
  1. Kaikkien asiakkaiden versionumerot ja käyttöjärjestelmätiedot viimeisen asiakkaalta tulleen yhteydenoton perusteella.
  2. Tieto siitä mihin käyttäjäryhmään kukin asiakas kuuluu. Asiakas kuuluu täsmälleen yhteen ryhmään.
  3. Joka ryhmälle versionumero, jota tarjotaan tähän ryhmään kuuluvalle asiakkaalle. Joka ryhmällä on täsmälleen yksi versionumero.
  4. Päivitysten historialista, jossa näkyy kaikki tehdyt päivitykset kaikille asiakkaille.
  5. Päivityspakettien yhteydessä kulkee Netseal Tech:n määrittelemä tiedosto kertoen oleelliset asiat päivityspakettista. Esimerkki löytyy täältä.
NC sisältää:
  1. Nykyinen RMC:n versio numero, joka saadaan suoraan RMC:ltä.
  2. Tieto siitä haluaako käyttäjä automaattisia päivityksiä vai ei.
  3. Ennen edellistä käynnistystä ajossa ollut versio.
  4. Versio joka pitäisi olla ajossa käynnistyksen jälkeen.

3.2 Tietosisältö tietovirtakaavioina

NC:n käynnistys

NC:n päivitysyritys

3.3 Käyttöintensiteetti

Yhtäaikaisten käyttäjien määrä voidaan rajoittaa haluttuun. (Käyttäjien ohjelmiston päivitystä yritetään kun käyttäjä ottavat yhteyden serverille. Jos kapasiteetti on täynnä, päivitetään RMC vasta seuraavan yhteydenoton tapahtuessa)

3.4 Kapasiteettivaatimukset

4. Toiminnot

Tässä kuvataan ohjelmiston toiminta käsitteellisellä tasolla. Käyttöliittymä kuvataan omassa dokumentissaan Käyttöliittymän määrittely.

4.1 NC:n käynnistys

Joka kerta käynnistyessään NC:n on tarkistettava, onko edellisen ajon päätteeksi tehty ohjelmistopäivitys ja onko päivitys mahdollisesti epäonnistunut. Rekisterissä on siis kolme arvoa. Edellinen (E) kertoo edellisen käyttökerran lopussa olleen version. Nykyinen (N) ilmoittaa sillä hetkellä ajossa olevan version. Pitäisi (P) arvo kertoo, minkä version pitäisi olla sillä hetkellä käytössä.

4.1.1 Talletettujen versioarvojen lukeminen

NC lukee NT:n rekisteristä versionumeron, joka pitäisi olla ajossa kyseisellä hetkellä (P) ja versionumeron joka oli ajossa ennen edellistä käynnistystä (E).

4.1.2 Nykyisen version lukeminen

NC lukee rekisteristä RMC:n nykyisen versionumeron (N).

4.1.3 Arvojen vertailu ja tallennus

NC vertailee saamiansa arvoja ja päättelee onko ennen edellistä käynnistystä tehty mahdollinen ohjelmistopäivitys onnistunut. Eli siis meillä on kolme tapausta: 1. ei päivitystä (E == P), 2. päivitys epäonnistunut (E != P && E==N), ja 3. päivitys onnistunut (E != P && P == N). Lisäksi NC päivittää rekisteriin nykyiset versiotiedot mikäli päivitys on onnistunut.

4.1.4 Käyttäjän informointi

Käyttäjää informoidaan mahdollisen ohjelmapäivityksen onnistuminen/epäonnistuminen. Jos päivitys epäonnistunut ja vanha versio edelleen ajossa, niin kysytään haluaako käyttäjä yrittää päivitystä uudelleen.

4.2 Päivitys

Mikäli RMC:n versionumero on erisuuri kuin sen ryhmälle kuuluva versionumero, NS ehdottaa version päivitystä NC:lle. NC yrittää suorittaa päivityksen.

4.2.1 Ilmoitus nykyisestä versionumerosta

NS saa tiedon RMC:n saapumisesta RMS:n alueelle RMS:ltä. NS lähettää NC:lle kyselyn versionumerosta ja NC vastaa ilmoittaen nykyisen RMC:n versionumeron.

4.2.2 Nykyisen versionumeron tarkistus

NS saa tiedon uuden käyttäjän yhteyden avaamisesta ja sen käyttämästä versionumerosta. NS tarkistaa vastaako RMC:n versio versiota, joka on määritelty ryhmälle johon RMC kuuluu.

4.2.3 Ilmoitus päivitystarpeesta

Jos versionumero ei täsmää, NS ilmoittaa NC:lle päivitystarpeesta ja versionumeron johon tämän tulisi päivittää. Jos yhtäaikaisia RMC:n päivityksiä on meneillään enemmän kuin ylläpitäjän sallima maksimi, laitetaan päivitystarve jonoon odottamaan resurssien vapautumista. Jonossa olosta ei tule NC:lle mitään ilmoitusta, eikä se vaikuta RMC:n toimintaan millään lailla.

4.2.4 Päivityspyyntö käyttäjälle

Eli siis kolme tilannetta 1. älä päivitä koskaan, 2. päivitä aina älä kysy käyttäjältä mitään, 3. päivitä, mutta kysy käyttäjältä. 

NC tarkistaa onko käyttäjä sallinut automaattiset päivitykset, mikäli on, tarkastetaan tarvitseeko käyttäjältä kysyä mielipidettä ohjelmiston päivittämisestä. Jos automaattiset päivityksen on sallittu ja käyttäjältä pitää kysyä, kysytään käyttäjältä haluaako tämä päivittää ohjelmistonsa uudempaan/vanhempaan. Käyttäjälle ilmoitetaan myös vanha ja uusi versionumero.

4.2.5 Käyttäjän vastaus päivityspyyntöön

Käyttäjä ilmoittaa suostuuko hän ohjelmistopäivitykseen ja koneensa uudelleenkäynnistykseen.

4.2.6 Päivityspaketin siirto

Jos NC päättää yrittää päivitystä, niin sen on saatava RM:n uusi versio päivityspaketin muodossa.

4.2.6.1 Pyyntö päivityspaketin saamiseksi

NC lähettää viestin NC:lle, että se on valmis vastaanottamaan päivityspaketin.

4.2.6.2 Päivityspaketin lähetys

NS lähettää päivityspaketin NC:lle ja ilmoittaa, kun lähetys on valmis.

4.2.6.3 Siirron visualisointi

Pakettien vastaanoton aikana NC näyttää käyttäjälle status-tietoa siirron tilasta.

4.2.6.4 Siirron keskeytys

Käyttäjä käskee NC:tä lopettamaan siirron, jolloin päivitysyritys keskeytyy.

4.2.6.5 Päivityspaketin kelvollisuuden tarkistus

NC tarkistaa onko päivityspaketti saapunut ehjänä ja purkaa sen sekä tarkistaa sisällöstä vastaako versionumero NS:n ilmoittamaa versiota

4.2.6.6 Hyväksymisviestin lähetys

NC ilmoittaa NS:lle että se on saanut kunnollisen päivityspaketin ja että RMC:n päivitysyritys alkaa.

4.2.7 Asennusohjelman käynnistys

Ajetaan asennusohjelma, joka suorittaa varsinaisen päivityksen. Asennusohjelma hoitaa myös koneen mahdollisen uudelleenkäynnistyksen.

4.3 Uusien RMC:n päivitysversioiden lisäys NS:ään

Selvitetty käyttöliittymää kuvaavassa dokumentissa.

5. Ulkoiset liittymät

Tässä luvussa kuvataan ohjelmiston liittymät laitteistoihin ja muihin ohjelmistoihin.

5.1 Laitteistoliittymät

Ohjelmisto ei tue eikä käytä mitään ulkoisia laitteita. Verkkoyhteyden toimiminen oletetaan, koska RM:n käyttö ei muuten ole mahdollista.

5.2 Ohjelmistoliittymät

NRNI liittyy toiminnallisesti RM -ohjelmistoon, ja käyttää sen tarjoamia palveluja (ks. kohta 4.2).

5.3 Tietoliikenneliittymät

Windowsin winsock-rajapintaa käytetään päivityspaketin siirtoon ja NC:n ja NS:n viestien vaihtoon.

6. Muut ominaisuudet

Tässä luvussa kuvataan ohjelmiston muut ominaisuudet, joita ei muissa luvuissa ole mainittu.

6.1 Suorituskyky ja vasteajat

NS:n on kyettävä suoriutumaan vahintään 20 RMC:n yhtäaikaisesta päivityksestä ja vain laitteistoresurssit saavat rajoittaa jonottavien päivitysten määrää. Käytännössä jonon koko on rajoittamaton ja kaikki RMS:n hallinnassa olevat RMC:t voivat olla tässä jonossa vaikka yhtä aikaa. Päivitykseltä ei vaadita mitään tiettyä vasteaikaa.

6.2 Käytettävyys, toipuminen, turvallisuus, suojaukset

NC:n käyttöliittymän on tarjottava riittävä helppokäyttöisyys ja selkeys, jotta kuka tahansa tavallinen RMC:n tavallinen käyttäjä osaa tehdä tarvittavat valinnat ja pystyy ymmärtämään niiden seuraukset. NS:n käyttö edellyttää kohtuullisia ylläpitäjän taitoja ja siinä voidaan käyttömukavuudessa joustaa mikäli tehokkuus sitä vaatii.

6.3 Ylläpidettävyys

Ohjelmisto pyritään suunnittelemaan mahdollisimman helposti ylläpidettävissä. Ylläpidettävyys tullaan huomioimaan ohjelman moduulirakennetta ja tietorankenteita suunniteltaessa.

6.4 Siirrettävyys/kannetavuus, yhteesopivuus

Ohjelmiston on oltava yhtä siirrettävä kuin RMC. Yhteensopivuus vaaditaan paitsi RMC:n osalta myös Windows NT:n julkisten rajapintojen osalta.

6.5 Operointi

Käyttäjältä vaadittava operointi rajoittuu vanhojen versioiden ja lokitiedostojen poistoon.

7. Suunnittelurajoitteet

Tässä luvussa kuvataan ohjelmiston suunnittelua rajoittavat tekijät.

7.1 Standardit

Ohjelmiston suunnittelua ei suoraan rajoita mikään standardi.

7.2 Laitteistorajoitteet

Laitteistona vaaditaan i386 arkkitehtuurin PC, jossa toimii WindowsNT 4.0.

7.3 Ohjelmistorajoitteet

Ohjelmistoympäristöltä vaaditaan NC:n osalta WindowsNT 4.0. NS:n osalta vaaditaan käyttöjärjestelmä, jossa RMS toimii. Koska ohjelmisto tulee osaksi RMC/RMS ohjelmistoa, sitä koskevat myös vähintäänkin samat ohjelmistovaatimukset kuin RM:ää.

7.4 Muut rajoitteet

Muita rajoitteita ei ole.

8. Viitteet

[1] Synapsi, Tik-76.115 Projektisuunnitelma: Automatisoitu ohjelmiston etäpäivitys, versio 3.0, 11.12.2000
Projektisuunnitelma.html

[2] Synapsi, Tik-76.115 Vaatimusmäärittely: Automatisoitu ohjelmiston etäpäivitys, versio 3.0, 11.12.2000
Vaatimukset.html