Tik-76.115 Vaatimusmäärittely

TNSDL-tietotyyppien versionhallintajärjestelmä Cheetah

RCS-Info: $Id: vm.html,v 1.42 1996/11/26 09:20:09 jkokko Exp $

Sisällysluettelo

1. Johdanto
2. Yleiskuvaus
3. Toiminnot
4. Ulkoiset liittymät
5. Muut ominaisuudet
6. Laatusuunnitelma

1. Johdanto

Cheetah on DX200-suunnittelijan käyttöön tarkoitettu TNSDL-määrittelyjen hallintajärjestelmä, johon talletetaan DX 200 -järjestelmän tietotyyppien TNSDL-kieliset määrittelyt ja niiden toteutukset.

Tässä dokumentissa esitetään vaatimusmäärittelyt Cheetah:in kehitystyölle.

Järjestelmään tietotyyppien lisäksi mahdollisesti tulevaisuudessa otettavien muiden määrittelyjen käsittelyyn soveltuvat samat toiminnot kuin tietotyypeille. Näitä kaikkia määrittelyjä kutsutaan yhteisellä nimellä Määrittelyalkio (Definition item). Tässä dokumentissa käytetään jatkossa kuitenkin selvyyden vuoksi vain tietotyyppi-termiä.

Tietotyyppitiedosto (Data Type File) on tiedosto joka sisältää viittauksia tietotyyppeihin ja tietotyyppijoukkoihin, jotka on kiinnitetty ko. tiedostoon.

2. Yleiskuvaus

DX-ympäristössä kaikkia tietotyyppejä käsitellään tämän työkalun avulla. Sillä luodaan kaikki tietotyypit, mikä ehkäisee nimikonfliktit. Lisäksi sillä voidaan muokata tietotyyppejä ja poistaa niitä käytöstä. Tietotyypin muuttajalla tulee olla siihen oikeudet. Työkalu ylläpitää tietotyypeille luetteloa oikeutetuista käyttäjistä. Työkalu huolehtii myös muutosten aiheuttamasta versioitumisesta.

Työkalun käyttöliittymän tulee toimia vähintään Windows NT -ympäristössä, tietotyypit on säilöttävä Ingres-tietokantaan, joka toimii VAX/VMS -ympäristössä.

Tietotyyppi on objekti, jonka attribuutit ovat:

nimi, versiotunnisteen kanssa avain
vastuuhenkilö, vastaa tietotyypin oikeellisuudesta, saa muuttaa tietotyyppiä sekä tehdä sille tilasiirtoja. Oletusarvoisesti vastuuhenkilö on se, joka luo tietotyypin.
muutoksiin valtuutetut käyttäjät. Tietotyypin vastuuhenkilö voi antaa muille käyttäjille oikeuksia muuttaa tietotyyppiä ja tehdä sille tilasiirtoja.
versiomallin mukainen versiotunniste, avain nimen kanssa.
viimeisimmän muutoksen tekijä
viimeisimmän muutoksen päiväys
tilamallin mukainen tila
viimeisimmän tilamuutoksen tekijä
viimeisimmän tilamuutoksen päiväys
tietotyypin sanallinen kuvaus
avainsanat hakujen nopeuttamiseksi ja helpottamiseksi
historiatiedot (muutosten kuvaukset, tekijät ja päiväykset)
Tietotyyppimäärittely (johon kuuluvat TNSDL-kielinen määrittely ja C-kielinen makro)

2.1 Tilamalli

Tietotyypin kehitystä kuvataan tilamallilla.

Järjestelmässä oleva tietotyyppi on jossakin seuraavista tiloista:

Tietotyypin kehitys tapahtuu Development-tilassa. Siinä tietotyypin tietoja voi muuttaa vapaasti eikä tietotyypin tarvitse läpäistä syntaksintarkistusta. Muutoksia voi tehdä vain se henkilö joka asetti tietotyypin tähän tilaan.
Integration-tilassa tietotyyppiä voidaan testata. Tällä varmistetaan testattavan tietotyypin stabiilius integraatiotilan ajaksi.
Kun tietotyyppimäärittely on valmis se siirretään Accepted-tilaan. Tällöin tietotyyppi "jäädytetään", eikä kyseistä versiota voi enää muuttaa. Tietotyyppi voidaan tämän jälkeen liittää tietotyyppitiedostoon. Jotta tietotyyppi voitaisiin siirtää Accpeted-tilaan täytyy sillä olla historiatiedot sekä sen pitää läpäistä TNSDL-syntaksintarkistus. Mikäli syntaksintarkistusta ei ole tehty, se tehdään automaattisesti Accepted-tilaan siirrettäessä.
Jos tietotyypin tietty versio huomataan virheelliseksi, voidaan se siirtää Dangerous-tilaan. Tämä vastaa hyväksytyn version poistamista käytöstä. Kyseistä versiota voidaan silti käyttää tietotyyppitiedostossa, mutta tietotyyppitiedoston luomisessa tämä aiheuttaa varoituksen. Tätä ominaisuutta voidaan käyttää kun virheellistä tietotyyppiä ja siihen liittyvää koodia ei ole ehditty korjata, mutta halutaan varoittaa muita tietotyypin käytöstä.

Seuraava tilamallikuva havainnollistaa asiaa:

2.2 Versiomalli

Versiomallin on mahdollistettava uuden haaran perustamisen kaikissa tilanteissa minkä tahansa jäädytetyn version seuraajasta. Järjestelmän käyttämä versiomalli on hieman muunneltu RCS:n (viite) versiomallista.

Versiotunnisteen määritelmä BNF-muodossa:

<1digit> ::= 1|2|3|4|5|6|7|8|9 
<digit> ::= 0|1|2|3|4|5|6|7|8|9 
<pitkänumero> ::= <digit>|<digit><pitkänumero>
<numero> ::= <1digit>|<1digit><pitkänumero>
<haara> :== <numero>.<numero>
<versio> :== <haara> | <versio>-<haara>

Päähaaran versio on aina muotoa:

<numero>.<numero>

Versiointia voidaan tehdä kolmella tavalla:

Edition kasvattaa versiotunnisteen viimeistä numeroa yhdellä
Version versioi päähaaran suurinta versiota siten että uudella versiolla ensimmäinen numero yhtä isompi kuin edeltäjällä
Branch tekee lähdeversiolle uuden haaran

Versiomalli ei poissulje edition muutosta päähaaran versiolle, jolle on jo tehty version-muutos. Tämä piirre on haluttu jotta saavutettaisiin riittävä yhdenmukaisuus NTC:llä käytössä olevan SPM-versionhallintajärjestelmän versiomallin kanssa.

Kuva selkeyttänee sanallista kuvausta:

2.3 TNSDL

TNSDL on NTC:n oma määrittely- ja ohjelmointikieli, jota käytetään DX200-ohjelmakehitykseen.

Työkalun pitää pystyä tarkastamaan annetun TNSDL-määrittelyn syntaktinen oikeellisuus. Tilasiirtymää Accepted-tilaan ei tehdä ellei määrittely ole läpäissyt tarkastelua.

3. Toiminnot

3.1 Versiointi

Versiointiin liittyvät toiminnot.

3.1.1 add

Luo uuden tietotyypin, joka on tilassa Development. Käyttäjä antaa tietotyypille nimen, versionumeron, josta versiopuu aloitetaan (oletus 1.1) sekä varsinaisen TNSDL-tietotyyppimäärittelyn (toiminto definition). Tietotyypin nimen tulee olla sallittu, eikä se saa olla jo käytössä. Käyttäjän oikeus luoda uusi tietotyyppi tarkistetaan.

3.1.2 modify

Toiminto antaa käyttäjälle mahdollisuuden muuttaa tietotyyppiä. Käyttäjä voi määritellä millä tavalla versiota kasvatetaan (Version, Edition tai Branch) - systeemi näyttää käyttäjälle mikä on kustakin muutostavasta seurauksena oleva versiotunniste. Uuden version tila on Development. Talletettaessa uutta versiota on historiatietojen antaminen pakollista. Kun versio siirretään tilaan Accepted, kopioidaan historiatiedoista Descr-kenttien tiedot muutosyhteenvetotietoihin.

3.1.3 versions

Mahdollistaa valitun tietotyypin versiotietojen selailun.

3.1.4 history

Mahdollistaa valitun tietotyypin historiatietojen selailun ja muuttamisen. Mikäli tietotyyppi on tilassa Accepted, ei olemassaolevia historiatietoja saa muuttaa, mutta lisäyksiä saa tehdä. Tarjottu täyttölomake on oltava soveltuvin osin ohjelmistokehityksessä käytettävän mallipohjan rakenteen mukainen. Muutoksia ei talleteta ennen käyttäjän varmennusta.

3.2 TNSDL

TNSDL:n liittyvät toiminnot.

3.2.1 file

Tallentaa tietotyypin TNSDL-määrittelyn tiedostoon, jonka nimi kysytään käyttäjältä. Oletusarvona käytetään nimeä dat0xxxx.sdt, missä xxxx on tietotyypin numero hexadesimaalina.

3.2.2 definition

Antaa mahdollisuuden muuttaa tietotyypin toteutusta (editorilla). Mikäli määrittelyä ei ole olemassa esitetään tietotyypille runko. Kysyy varmistuksen ennen muutoksen tietokantaan tallettamista.

3.2.3 syntaxcheck

Toiminto tarkastaa tietotyypin TNSDL-syntaksin ja ilmottaa virheestä, mikäli määrittely ei sisällä ko. tietotyypin määrittelyä. Ylimääräisistä esittelyistä annetaan varoitus.

3.2.4 operators

Listaa kaikki tietotyypin käyttämät operaattorit ja sen mihin niiden toteutus on talletettu.

Tätä toiminnnallisuutta ei tehdä Apina-projektissa, mutta se on voitava lisätä myöhemmin, ja sen mukana olo on otettava suunnittelussa huomioon.

3.2.5 fetchdescr

Toiminto hakee TNSDL-määrittelystä määrittelyn kuvauksen TNSDL-toteutuksen Comment-kentästä tietotyypin Description-kenttään. Description-kenttää voi vielä editoida. Vasta update-toiminto tallettaa muutoksen.

3.2.6 macro

Antaa mahdollisuuden muuttaa tietotyyppiin liittyvää C-makroa (editorilla).

Tätä toiminnnallisuutta ei tehdä Apina-projektissa, mutta se on voitava lisätä myöhemmin, ja sen mukana olo on otettava suunnittelussa huomioon.

3.3 Tietotyypin hallinta

Tietotyypin hallintaan liittyvät toiminnot.

3.3.1 state

Siirtää tietotyypin tilasta toiseen tilamallissa. Accepted-tilaan siirto vaatii tietyt oikeudet. Käyttäjälle kerrotaan onnistuiko tilasiirto, ja syy, mikäli ei onnistunut. Käyttäjä voi myös kokeilla onko tilasiirto mahdollinen.

3.3.2 delete

Antaa mahdollisuuden tietotyypin tuhoamiseen. Vain Development-tilassa oleva tietotyyppi voidaan tuhota.

3.3.3 responsible

Mahdollistaa vastuuhenkilön muuttamisen. Vain vastuuhenkilö voi siirtää vastuun toiselle. Vasta update-toiminto tallettaa muutoksen.

3.3.4 priv

Muutosoikeuslistan käsittely:

Vastuuhenkilö kuuluu listaan automaattisesti
Listaa saa katsella kuka vain
Listan muutosoikeus vastuuhenkilöllä

3.3.5 update

Tallettaa muutoksia tietokantaan (history, fetchdescr, responsible). Tarkistaa päivitysoikeudet ja tekee tarvittavat oikeellisuustarkistukset ennen muutetun tiedon tietokantaan viemistä.

3.3.6 attach

Tällä toiminnolla tietotyyppi tehdään pyyntö tietotyypin kiinnittämäseksi tietotyyppitiedostoon. Mikäli käyttäjällä ei ole oikeuksia operaation tekemiseen, työkalu antaa mahdollisuuden pyytää operaation suoritusta tietotyypin vastuuhenkilöltä.

Tätä toiminnnallisuutta ei tehdä Apina-projektissa, mutta se on voitava lisätä myöhemmin, ja sen mukana olo on otettava suunnittelussa huomioon.

3.4 Muut

Muut toiminnot, jotka eivät liity ylläoleviin kategorioihin.

3.4.1 find

Käyttäjän on voitava etsiä tietotyyppejä helposti tietokannasta antamalla hakuehtoja. Hakuehtoina käytetään tietotyypin attribuutteja (ainakin nimi, avainsanat, vastuuhenkilö, versio, tila, kuvaus).

3.4.2 keywords

Mahdollistaa tietotyypin avainsanojen muuttamisen, avainsanojen tulee olla mahdollisten avainsanojen listassa ja ne voidaan hakea tietotyyppiin sieltä, tai kirjoittaa suoraan. Käyttäjä voi myös lisätä mahdollisten avainsanojen listaan uusia avainsanoja ja antaa niille kuvauksen.

4. Ulkoiset liittymät

4.1 Käyttöliittymä

Käyttöliittymä tullaan kehittämään iteratiivisesti aluksi projektiryhmän omien prototyyppien perusteella. Lopullinen käyttöliittymä tullaan suunnittelemaan pitkälti käyttäjien antaman palautteen perusteella.

Käyttöliittymältä vaadittavia ominaisuuksia:

Mahdollisimman ei-modaalinen käyttöliittymä
Mahdollisuus käyttää käyttäjän määrittelemää editoria
Mahdollisuus saavuttaa Toiminnot-kappaleen toiminnot loogisesti ja joustavasti
Virhetilanteissa käyttäjälle on kerrottava selkeästi virheen syy ja annettava tietoa tilanteesta toipumiseen

4.2 Tietokantarajapinta

Ohjelman ja Ingres-tietokannan toteutus tulee suunnitella huolellisesti, mahdollisuuksien mukaan niin, että samaa rajapintaa voivat käyttää myös muut ohjelmat. Tämä voidaan toteuttaa esimerkiksi niin, että tietokantarajapintana toimii dynaamisesti linkattava kirjasto.

5. Muut ominaisuudet

Tavoitteena on interaktiivisesti käytettävä ohjelma, joten missään vaiheessa käyttäjää ei saisi harmittaa toimintojen hitaus. Erityisesti huomioitavia ennalta arvattavia pullonkauloja ovat mm.

Tietokantahaut
Ulkoisiin ohjelmiin (esim. editori) siirtymiset ja niiden käynnistäminen
Verkkokapasiteetti ja massamuistien hitaus

Vastaavasti ratkaisuja näihin ongelmiin voisivat olla

Vaikeiden tietokantahakujen välttäminen. Vaatii prototyyppien kanssa testaamista.
Editorin valintaa tehtäessä on nopeus otettava huomioon, ja harkittava sekä editorin että muiden mahdollisten tarvittavien ulkoisten ohjelmien integroimista
Verkon runsas käyttö on huomioitava suunnittelussa ja pyrittävä välttämään tyhmiä ratkaisuja. Sama koskee massamuistien käyttöä. Ohjelman kannalta verkon takana oleva tietokanta on suorityskykyä arvioitaessa jossain mielessä massamuisti.

Ohjelmaa suunniteltaessa ja työkaluja valittaessa on otettava huomioon ohjelman pitkä elinkaari. On valittava sellaisia menetelmiä jotka eivät vanhene nopeasti, tai ainakin niin että tehtyä työtä ei siitä johtuen jouduta toistamaan.

On käytettävä mahdollisimman standardeja ratkaisuja, vaikkapa sitten de facto standardeja, koska se takaa osaltaan siirrettävyyden ja helpottaa ylläpidettävyyttä.

On huolehdittava siitä, että dokumentaatio tukee sekä käyttäjää (esim. on-line helpin muodossa) että ylläpitäjää ja jatkokehitystä.

On vältettävä ratkaisuja jotka vaarantavat turhaan tietoturvallisuuden, esim. salasanoja ei kysellä turhaan eikä säilötä missään turhaan.

6. Laatusuunnitelma

Seuraavassa on asiakkaan asettamat laatutavoitteet tuotteelle tärkeysjärjestyksessä:

Tuotteen käytettävyys, joka määritellään tuotteen kyvyksi edistää ja nopeuttaa käyttäjien normaalia työnkulkua. Mittarina asiakaspalaute.
Tuotteen helppokäyttöisyys, joka määritellään siten, että tuote informoi käyttäjiä selkeästi virhetilanteessa, sekä tarpeellisilla helpeillä. Mittarina asiakaspalaute.
Tuotteen suorituskyky. Mittarina tärkeimpien (useimmiten käytettyjen) ominaisuuksien nopeus.
Tuotteen ylläpidettävyys. Mittarina katselmoitu ja kommentoitu ohjelmakoodi sekä toteutusdokumentti.
Tuotteen virheettömyys. Mittarina kaikkien projektin aikana havaittujen virheiden korjaaminen.
Kaikki vaatimusmäärittelyn mukaiset toiminnalliset piirteet toteutettu. Mittarina totetuma projektisuunnitelmaan nähden.