HUSA (Human Understandable System Analysis) =========================================== Viimeksi muutettu: 14:35 3.3.2003 Juha Lähteenmäki Mikä HUSA on? ============== STEP-laatujärjestelmän yhteydessä tietojärjestelmien ja komponenttien määrittelyssä ja suunnittelussa käytettävä rakenteen ja toiminnallisuuden analysointi menetelmä tai lopputuloksen tarkastusperiaate. HUSA -muistuttaa joiltain osin OMT++ menetelmää mutta on tätä suppeampi, arkkitehtuuripainotteisempi eikä kata sen kaikkia osia. Husan tärkeimpänä päämääränä on järjestelmän tai komponentin järkevä pilkkominen ihmisen ymmärtämiin mahdollisimman itsenäisiin kokonaisuuksiin jotka mahdollistavat järjestelmän tai komponentin kaikkien tarpeellisten (HUSA:n vaatimusanalyysi) vaatimusten täyttämisen. HUSA:n periaatteet ovat seuraavat: =================================== Seuraavassa kuvataan HUSA:n mukaisen järjestelmäanalyysin vaiheet yhdestä viiteen. Pääsääntönä on että vaiheet tulee suorittaa numero järjestyksessä mutta käytännössä vaiheet etenevät rinnakkain siten että numerojärjestyksessä pienempi vaihe on kuitenkin vähintään hiukan edellä seuraavaa vaihetta niin että se antaa mielekkään perustan myöhemmän vaiheen etenemiselle (ts. ei rakenneta tyhjän päälle) 1. Määrittele (alustavasti) ylimmän tason järjestelmä tai komponentti ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Määrittely tulee tehdä niin että voit sen perusteella ilman ulkopuolista tietoa järjestelmästä tai komponentista todeta: - Miten järjestelmä/komponentti toimii a) Normaalitilanteessa b) Virhetilaneessa - Missä ympäristössä ja millä ehdoilla järjestelmä/komponentti toimii a) Laitteistoympäristö b) Ohjelmistoympäristö c) Mitkä ovat normaalitoiminnan rajat - Mitä edellytyksiä järjestelmän/komponentin toimintakunnon säilyminen asettaa käyttäjän kannalta. (ylläpitotoimet?) - Mitä järjestelmän/komponentin käyttö (uloimman rajapinnan käyttö) vaatii käyttäjältä (asiantuntemusta, esitietoja?) - Kuinka turvallinen tai varmatoiminen järjestelmän/komponentin on oltava - Määrittele tekniikoita vain sen verran kuin ulkoiset tekijät ja seuraavat vaiheet edellyttävät (Seuraava osa voidaan jättää pois sellaisista järjestelmistä/komponenteista joilla ei ole käyttäjän ja itsensä välistä rajapintaa) - Miltä järjestelmä/komponentti näyttää/tuntuu käyttäjästä (esim. hauska/asiallinen) Muut kuin itsestäänselvät vaatimukset on myös perusteltava. Ensimmäisessä vaiheessa tämä osa tehdään alustavasti ja se tarkentuu 2:s ja 3:s vaiheen jälkeen. Vaihe on ajantasalla silloin kun se vastaa yllämainittuihin kysyksiin kunkin ko. hetken tietämyksen mukaan niin hyvin kuin mahdollista. 2. Pilko järjestelmää ylimmän tason (käyttöliittymän) kannalta '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' --> korjaa vaiheen valmistuttua tarpeen mukaan ylempää vaihetta. 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 (mikä toiminnallinen vaatimus liittyy 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ä omikse kokonaisuuksikseen. Yhdistele keskenään samanlaisia osia eri näkymien kesken. Sellaisilla komponenteilla ja järjestelmillä joilla ei ole rajapintaa käyttäjän kanssa, voidaan näkymien tulkita vastaavan ko. komponenteista/järjestelmästä ulospäin näkyviä, muiden komponenttien/järjestelmien käytettävissä olevia rajapintoja, toiminnallisten osien näiden rajapintametodeita tai propertyjä ja siirtymien ko. rajapintojen välillä tapahtuvia vuorovaikutuksia. Näin ollen em. analyysi voidaan suorittaa myös tälläisille järjestelmille/komponenteille. Välttämätöntä tämä ei em. tilanteessa kuitenkaan ole mikäli rakenne saadaan selville toiminnallisuuden perusteella. 3. Pilko järjestelmää alimman tason (tallennettavan/käsiteltävän) datan kannalta ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' --> korjaa vaiheen valmistuttua tarpeen mukaan ylempiä vaiheita. -Mieti mitä dataa järjestelmä/komponentti tallettaa ja käsittelee sekä miten datan voisi ryhmitellä. Mieti miten eri data liittyy toisiinsa ja kuinka paljon ko. tyyppistä dataa tarvitaan. Yritä löytää eri tyyppisestä 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. 4. Mieti järjestelmän/komponentin jaon kehykset (kerrosjako) '''''''''''''''''''''''''''''''''''''''''''''''' --> korjaa vaiheen valmistuttua tarpeen mukaan ylempiä vaiheita. 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 järjestelmän/komponentin 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 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ätää 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ä melko 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 komponenteissa tai järjestemissä yksinkertaisesti 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 järjestelmän/komponentin perustoiminnot eri kerrosten vastuulle kuuluviin osatehtäviin. 5. Jaa järjestelmä sopiviin palasiin eli ILE:hin (Independent Logical Entity) ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' --> korjaa vaiheen valmistuttua tarpeen mukaan ylempiä vaiheita. 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 ihmisen hahmotetavissa ilman ylimääräistä perehtymistä. Esim. Jos yhden ILE:n sisältämistä luokista piirretty kaavio ei mahdu yhdelle A4:lle edes vaakasuunnassa, on se 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äsiä loogisia kokonaisuuksia (huom. ILE = Independent Logical Entity) myös mahdollisimman saman kokoisia. 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 vaiheen 3 ja kolmen ylemmän (Käyttöliittymä, käyttöliittymälogiikka, toiminnallisuudenhallintalogiikka) pilkkomiseen vaiheen 2 yhteydessä 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. Husan 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 järjestelmä/komponentti Vaatimusten täyttymisen tarkastamiseksi on hyvä tehdä niin sanottu toiminnallisuuden rakennelähtöinen analyysi jossa ainakin tär- keimpien toimintojen aiheuttamat rajapintakutsut (ja toimenpiteet) eritellään esim. tapahtumasekvenssi- tai oliointeraktiokaavion avulla.