HUSA (Human Understandable System Analysis) Versio 1.1

Transkriptio

1 HUSA (Human Understandable System Analysis) Versio 1.1 Viimeksi muutettu: :23 Juha Lähteenmäki Versiohistoria: Ensimmäinen versio HUSA.txt (1.0): 14: Juha Lähteenmäki Mikä HUSA on? HUSA on STEP-laatujärjestelmän yhteydessä käytettävä tietojärjestelmien rakenteen ja toiminnallisuuden analysointi menetelmä. HUSA muistuttaa joiltain osin OMT++ menetelmää mutta on tätä suppeampi, arkkitehtuuripainotteisempi eikä kata sen kaikkia osia. HUSA:n osavaiheet: HUSA:n mukainen analyysi jakautuu kaikkiaan 7 osavaiheeseen jotka voidaan edelleen luokitella kolmeen pääryhmään. 1. HUSA:n vaiheista kaksi ensimmäistä painottuu projektin valmisteluun ja yleiskuvan luomiseen. Niistä käytetään yhteisnimitystä yleisanalyysi. 2. HUSA:n tärkeimmän kokonaisuuden muodostaa rakenteellinen ja toiminnallinen analyysi johon kuuluvat yleisanalyysin jälkeiset kolme HUSA:n vaihetta. Näissä tarkemmissa analyysivaiheissa järjestelmä tai komponentti (käytän jatkossa yhteisnimitystä sovellus) pyritään osittamaan sekä käyttöliittymä- että datalähtökohdista. Liikkeelle lähdetään käyttöliittymästä jonka perusteella ositus tehdään usealla tasolla. Käyttöliittymäpalasiin yhdistetään myöhemmin data ja vaatimukset. Viimeisenä suoritetaan puhtaasti data-lähtökohdista tehty ositus lähinnä tietokantaa silmällä pitäen. 3. Toteutuksellinen rakenneanalyysi kattaa HUSA:n kaksi viimeistä vaihetta. Sen tarkoituksena on sovittaa edellä mainitut palaset toteutukseen ja pilkkoa sovellusta edelleen toteutuksen kannalta HUSA:n tärkeimpänä päämääränä on auttaa ymmärtämään sovellusta pilkkomalla sitä rakenteellisesti ja toiminnallisesti vaiheittain. Kussakin vaiheessa edellisen vaiheen osat jakautuvat edelleen enintään niin moneen osaan, että sovellusta toteuttavat ja suunnittelevat osapuolet voivat ymmärtää ko. vaiheen palasten toiminnan ja yhteistoiminnan. Detaljien määrä kasvaa ideaali tilanteessa eksponentiaalisesti vaiheittain. Vaiheistettua pilkkomista jatketaan niin kauan kunnes vaiheessa syntyneet palaset ovat käytännön toteutuksen edellyttämällä tasolla. Seuraavassa kuvataan HUSA:n mukaisen analyysin järjestys sekä sen osavaiheet 1-7. Pääsääntönä on että vaiheet tulee suorittaa numerojärjestyksessä mutta käytännössä ne etenevät rinnakkain siten, että numerojärjestyksessä pienempi vaihe on vähintään hiukan edellä seuraavaa. Näin edeltävä vaihe antaa aina mielekkään perustan myöhemmän vaiheen etenemiselle (ts. ei rakenneta tyhjän päälle) 1

2 1. Sovelluksen yleisanalyysi Varsinkin täysin uuden sovelluksen tapauksessa suunnittelu aloitetaan ns. yleisanalyysillä, jota voidaan käsitellä esim. ensimmäisissä projektipalavereissa. Tähän analyysiin kuuluu toiminnallisen perusidean eli filosofian miettiminen, tärkeimmät käyttötapaukset ja fyysinen ositus. Fyysistä ositusta voidaan havainnollistaa UML-jakelukaavion avulla, mutta yleensä vieläkin informaalimpi kaavio sopii alkuun paremmin. Esimerkkejä kaavioista jossa kuvataan järjestelmän fyysiset osatekijät. Ensimmäisenä UML:n jakelukaavio (Deployment diagram) ja sitten pari informaalimpaa kaaviota. Esimerkkikaaviot eivät liity samaan järjestelmään. Mikäli sovellus on ennestään kaikille osapuolille tuttu (vain uusi versio), voidaan filosofian miettiminen ja käyttötapaukset jättää poiskin. Myös fyysinen ositus voidaan jättää pois jos sovellus 2

3 on hyvin yksinkertainen (ei koostu useista osista) tai jos osajako on kaikille itsestään selvä vaikkapa edellisen version kautta. 2. Sovelluksen alustava vaatimusanalyysi Sovelluksen vaatimusanalyysi alkaa palautteen tai palaverien ideoinnin kautta saatujen vaatimusten luokittelulla ja kokoamisella yhteen paikkaan (dokumenttiin tai erillisen vaatimustyökalun kautta tietokantaan). Näin vaatimuksia voidaan helposti päivittää, muokata ja ylläpitää koko projektin ajan. Missään nimessä tuloksena ei ole lopullinen vaatimuslista johon ei enää sen koommin kosketa. Olennaista on että vaatimusten ylläpidon tulee olla helppoa ja vaatimuksia on voitava luokitella sekä etsiä eri kriteereillä. Vaatimusjärjestelmän tai vaatimusdokumentin pystytyksessä sekä vaatimusten käsittelyssä tulee huomioida seuraavat tekijät: a. Kategorialuokittelu 1. Toiminnalliset ideat (functional ideas) 2. Käyttöliittymä- ja ulkoasuideat (look and feel ideas) 3. Käsiteltävään dataan liittyvät vaatimukset (data requirements) (kenttien pituus yms. formaatti vaatimukset) 4. Suorituskykyyn liittyvät vaatimukset (performance requirements) (liittyvät yleensä tiettyihin toimintoihin) 5. Käyttöympäristöön liittyvät vaatimukset (environment requirements) (laitteisto ja ohjelmistoympäristö) 6. Käyttöedellytyksiin liittyvät vaatimukset (mitä esitietoja käyttäjä tarvitsee, ammattihenkilö jne.) 7. Sovelluksen kriittisyyteen liittyvät vaatimukset ts. aiheuttaako kaatuminen eri 3

4 tilanteissa kuinka vakavia vahinkoja --> Tietoturva vaatimukset, vakauteen ja testaukseen liittyvät vaatimukset. 8. Yleiset tekniset rajoitteet (esim. lakisääteiset tai yrityksen lisenssi- yms. politiikan sanelemat) Lisäksi vaatimukset on voitava jatkon kannalta ryhmitellä näyttökohtaisesti b. Tärkeysaste eli prioriteetti (prioriteetteja voisivat olla) 1. pakollinen (lakisääteinen tai muuten sellainen vaatimus että ilman sitä järjestelmää ei ole mielekästä toteuttaa.) 2. tärkeä (erittäin suositeltava) 3. neutraali (mikäli kohtuullisella työllä mahdollinen) 4. lisä (mikäli ylimääräistä aikaa toteutukselle jää) c. Määrittele vaatimuksen toteutuksen kiireellisyys ts. mihin versioon se otetetaan (vähintään seuraavalla tasolla). 1. Seuraavaan versioon 2. Tuleviin versioihin Mikäli järjestelmästä on jo ennestään olemassa tuotantokäytössä oleva versio on jaottelu syytä päivittää kolmijakoiseksi. 1. Service pack tyyppinen päivitys jo olemassa oleviinkin versioihin 2. Seuraavaan versioon 3. Tuleviin versioihin d. Perustele vaatimukset Lisäksi jokainen prioriteetiltaan 1:s tai 2:s tason vaatimus on perusteltava erillisellä selitteellä (perustelu). e. Kuvaus, lähteen yksilöivä tieto, syöttöpäivämäärä ja versiohistoria Vaatimuksilla on oltava kuvaus, lähteen yksilöivä tieto sekä syöttöpäivämäärä. Mahdollinen versiohistoria on oltava tallessa vähintään muokkaajan tunnisteen ja muokkauspäivämäärän osalta. f. Määrittele kunkin vaatimuksen tila ja ylläpidä sitä Vaatimuksilla on oltava tila joka kuvaa sen nykyistä suhdetta toteutukseen. Näitä tiloja on oltava vähintään 2 aktiivinen tai hylätty mutta erillistä järjestelmää käytettäessä mahdolliset tilat voisivat olla: odottamassa, työn alla, valmis, hylätty. g. Viitteet ja liitteet Jokaiseen vaatimukseen on voitava lisätä rajoittamaton määrä viitteitä ja liitteitä. 4

5 Seuraavat vaiheet ovat järjestelmän varsinaista pilkkomista ihmisen kannalta ymmärrettäviin kokonaisuuksiin 3. Määrittele alustavasti järjestelmän näytöt tai komponentin rajapinnan ulospäin näkyvät osat Pilko sovellusta ylimmän tason (käyttöliittymän) kannalta Piirrä hahmotelmat järjestelmän tärkeimmistä näkymistä ja mieti mitä siirtymiä näkymistä toiseen voi olla. Mieti myös mitä tehtäviä näkymän vastuulle liittyy (ts. mikä toiminnallinen vaatimus kuuluu mihinkin näkymään). Kukin näkymä muodostaa automaattisesti yhden kokonaisuuden joka hoitaa tiettyä osatehtävää järjestelmän kannalta. Mikäli näkymissä on usein toistuvia osia, erota nämä omiksi kokonaisuuksikseen. Yhdistele keskenään samanlaisia osia eri näkymien kesken. Jos sovelluksella ei ole rajapintaa käyttäjän kanssa, voidaan näkymien tulkita vastaavan ulospäin näkyviä, muiden komponenttien tai järjestelmien käytettävissä olevia rajapintoja, toiminnallisten osien näiden palveluita ja siirtymien ko. rajapintojen välillä tapahtuvia vuorovaikutuksia. Järjestelmän näyttöjen määrittely alkaa yleensä ns. päänäkymien eli osioiden määrittelyllä. Osiot ovat järjestelmän toiminnallisia kokonaisuuksia jotka jakautuvat varsinkin suuremmissa järjestelmissä useisiin alinäyttöihin. Osioiden määrittelyn jälkeen jatketaan näiden lapsinäyttöjen määrittelyllä. Kunkin näytön määrittelyn yhteyteen seuraavat tiedot: ID eli yksilöllinen tunniste Nimi Tarkoitus Kuva (ei lopullinen käyttöliittymä vaan hahmotelma) Vaatimukset (sisältävät mm. näyttöön liittyvät toiminnot) joilla kullakin samat tiedot ja sisäinen luokittelu kuin edellisessä alustava vaatimusanalyysi vaiheessa on selostettu. Käytännössä liitetään edellisen vaiheen näyttökohtaiset vaatimukset näyttöihin ja täydennetään tarvittaessa uusia näyttökohtaisia vaatimuksia. Toistuvat mahdollisesti yleiskäyttöisiksi kontrolleiksi erotettavissa olevat osat Riippuvuudet muihin näyttöihin o Siirtymät (linkit) toisiin näyttöihin o Parent-child relaatiot (onko jonkun näytön lapsinäyttö ja/tai emonäyttö) Näyttöön liittyvä data (käsitellään seuraavassa vaiheessa) Mikäli näyttöön liittyy selkeitä lapsinäyttöjä, näitä ei määritellä emonäytön yhteydessä, vaan kuvataan ainoastaan integroituminen emonäyttöön. 4. Määrittele näyttökohtaisesti kuhunkin näyttöön liittyvä data Datan määrittelyn yhteydessä on määriteltävä seuraavat seikat: Nimi ja yksilöllinen tunniste Kuvaus 5

6 Tyyppi (int, string jne) Rajoitteet (esim. välillä 0 100) Säilytys (talletettava tai pääteltävä/laskettava ei vastinetta tietokannassa) Näkyvyys ja esitys käyttäjälle (näkyvissä sellaisenaan, näkyvissä muunnettuna, näkyvissä olo riippuu muusta datasta, ei näkyvissä) Lisäys: Suora käyttäjän lisäys, epäsuora muusta datasta riippuva lisäys, ei lisättävissä Poisto: Suora käyttäjän poisto, epäsuora muusta datasta riippuva poisto, ei poistettavissa Muokkaus: Suora käyttäjän muokkaus, epäsuora muusta datasta riippuva muokkaus, ei muokattavissa 5. Ryhmittele ja yhdistele edellä saadut data-alkiot: Pilko sovellusta alimman tason (tallennettavan/käsiteltävän) datan kannalta Kokoa edellisen vaiheen perusteella lista siitä, mitä dataa järjestelmässä/komponentissa talletetaan ja käsitellään. Mieti miten datan voisi ryhmitellä. Mieti miten eri data liittyy toisiinsa ja kuinka paljon ko. tyyppistä dataa tarvitaan. Yritä löytää datasta seuraavat yhteiset tekijät: Perusalkio eli elementti (vastaa yleensä tietokannan yksittäistä dataalkiota esim. Käyttäjän sukunimi) Alkiokokonaisuus eli entiteetti (entity) (vastaa yleensä tietokannan taulun riviä) Entiteetti ryhmä (eli entity group) (vastaa yleensä tietokannan taulua) Lopuksi voit vielä yhdistää datan toimintoihin eli miettiä mitä muutoksia datassa mikäkin toiminto aiheuttaa. 6. Mieti sovelluksen jaon kehykset (kerrosjako) Jaa järjestemä/komponentti 2:een tai useampaan tehtävälliseen tasoon (kerrokseen) (Riippuvuuksia mielellään vain ylemmältä kerrokselta seuraavaksi alemmalle) Mahdollisia kerroksia ovat esim. 1. Käyttöliittymä (Toimii sovelluksen rajapintana käyttäjälle) (esim. windows-formin formiosa tai ASP.NET:n Aspx osa) 2. Käyttöliittymälogiikka (Vastaanottaa käyttöliittymältä tulevat tapahtumat (eventit) ohjaa niiden käsittelyn kerrosjaossa alaspäin ja liittää alemmilta kerroksilta tulevan datan käyttöliittymään) (esim. windows-formin koodi tai ASP.NET:n Codebehind-luokka) 3. Toiminnallisuudenhallinnontilogiikka. Tämä sanahirviö vastaa/hallinnoi tiettyä toiminnallista kokonaisuutta ja käyttää datalogiikan olioita/data-apia järkevästi. Tähän kerrokseen kuuluvat yleensä erilaiset manageri luokat. Kerroksen 6

7 rajapintakutsut ovat hyvin käyttöliittymäläheisiä (muistuttavat käyttöliittymän toimintoja) esim. UserMngr.LoginUser(loginId). Kerrokselta saatava data on käyttöliittymän kannalta helpossa ja mielellään yleiskäyttöisessä muodossa. 4. Datalogiikka sisältää järjestelmä spesifiset data-oliot jotka kapseloivat datan järkeviin palasiin ja vastaavat sisältämänsä datan hallinnoinnista, kuten talletuksesta ja lukemisesta järkevästi silloin kun tarve vaatii hyödyntäen data-api:a. Rajapintojen pitäisi olla eri olioiden välillä yhtenäisiä ja sen luokkien jaon pohjana datan jako elementteihin, entiteetteihin ja entiteetti ryhmiin. 5. Datarajapinta eli Data-API sisältää yhden tai useamman rajapintaluokan joiden välityksellä käytetään tietovarastoa (usein tietokanta) esim. storeprosedurien tai ADO.NET:n kautta. Rajapinta on erittäin yhtenäinen (esim. datan välitys hoituu aina samalla tavalla datasetteinä) mutta yleensä kuitenkin sovellus/sovellusryhmäkohtainen. 6. Tietovarasto (usein tietokanta) sisältää kantaspesifiset storeprosedurit ja datan (ryhmiteltynä järkevästi) kantaspesifisessä muodossa. Edellä esitelty kerrosjako ei ole mitenkään ehdoton, eikä kaikissa sovelluksissa edes ole kaikkia osia; jos vaikkapa käyttöliittymä puuttuu tai tietoa ei talleteta mihinkään ulkoiseen tietovarastoon. Toisaalta vaikka kaikki osat olisikin erotettavissa, kerroksia voidaan yhdistellä tai jakaa edelleen. Esim. jos kannasta haettua dataa ei tarvitse muokata/yhdistellä jne. ja toteutusympäristö tarjoaa standardin tavan data-alkioiden käsittelyyn (esim. ADO.NET:n DataSetit) voidaan datalogiikka hyvinkin jättää pois. Samoin jos ei painoteta kantariippumattomuutta ja kanta tarjoaa helppokäyttöiset storeprosedurit lienee Data-API turha. Pienemmissä sovelluksissa kannattanee myös logiikan kerroksia yhdistellä mutta vähimmäismääränä voidaan täysmittaisessa sovelluksessa pitää käyttöliittymää, logiikkaa ja tietovarastoa eli tässä jaossa on siis yhdistetty kerrokset 2, 3, 4 ja 5. Huom. Sopivan kerrosjaon löytämisessä/tarkastamisessa auttaa jos jaottelee ainakin sovelluksen perustoiminnot eri kerrosten vastuulle kuuluviin osatehtäviin. 7. Jaa sovellus sopiviin palasiin eli ILE:hin (Independent Logical Entity) Tee jako esim. alkaen laajoista usein useamman kerroksen alueelle ulottuvista paketeista ja päätyen vähintään luokka/moduulitasolle ja mielellään metodi ja property tasolle. ILE valinnan perusteena on HUSA:ssa seuraava yleissääntö. Yksi ILE voidaan jakaa kerralla enintään niin moneen palaseen että kokonaisuus ja palikoiden väliset riippuvuudet ovat hahmotetavissa ilman ylimääräistä perehtymistä. Esim. Jos yhden ILE:n sisältämistä luokista piirretty kaavio ei mahdu yhdelle A4:lle edes vaakasuunnassa, se on liian laaja ihmisen hahmotettavaksi kokonaisuutena ja sen luokista tulee yhdistellä vielä suppeampia paketteja (ILE:jä) joista muodostuva kokonaisuus on kerralla hahmotettavissa. Tietyllä "tasolla" (huom. tässä tasolla ei tarkoteta edellisen luvun kerrosta) olevat ILE:t (jotka siis esim. alimmalla tasolla voivat olla luokkia, moduuleita, metodeja ja/tai propertyjä) muodostavat ILE-tason. Saman tason ILE:jen pitäisi olla paitsi mahdollisimman itsenäisiä loogisia kokonaisuuksia 7

8 (huom. ILE = Independent Logical Entity) myös mahdollisimman samankokoisia. Ts. jako on huonosti onnistunut jos yhdessä saman tason ILE:ssä on 2 luokkaa ja toisessa 15. ILE-jaon ohjenuoraksi voidaan sanoa myös että: 1. hyvän pohjan kolmen alimman kerroksen (tietovarasto, Data-API, Datalogiikka) ILE:jen suunnitteluun muodostaa edellisten vaiheiden erityisesti vaiheen 5 yhteydessä tehty suunnittelun esityö. 2. ILE-jaon aikana on hyvä pitää mielessään kerrosjako. Vähintään alimman ILE-tason ILE:jen mutta mielellään viimeistään luokkatason ILE:jen tulee olla yhden kerroksen rajojen sisällä. 3. ILE-jaon lähtökohtana ovat HUSA:n kaikki Edelliset vaiheet. TS. HUSA:n tärkeimpänä päämääränä on juuri järjestelmän järkevä pilkkominen ihmisen ymmärtämiin mahdollisimman itsenäisiin kokonaisuuksiin jotka mahdollistavat järjestelmän kaikkien tarpeellisten vaatimusten täyttämisen. 4. ILE-jaon tarkastamiseksi on hyvä tehdä niin sanottu toiminnallisuuden rakennelähtöinen analyysi jossa ainakin tärkeimpien toimintojen aiheuttamat rajapintakutsut (ja toimenpiteet) eritellään esim. tapahtumasekvenssi- tai oliointeraktiokaavion avulla. 8