Tietojärjestelmät ja Systeemisuunnittelu

Esitys aiheesta: "Tietojärjestelmät ja Systeemisuunnittelu"— Esityksen transkriptio:

1 Tietojärjestelmät ja Systeemisuunnittelu
2/2001 Tietojärjestelmät ja Systeemisuunnittelu Luennoitsija: Tapio Lammi 1

2 Järjestelmien elinkaarimallit

3 Miksi ? Elinkaarimalleja tarvitaan
Luomaan yhtenäinen nimistö eri työvaiheille Kuvaamaan järjestelmän toteutusvaiheiden suhde toisiinsa järjestelmän elinkaaren aikana Luomaan viitekehys varsinaisen kehitysprosessin kehittämiselle

4 Työvaiheet - Määrittely
Kerätään järjestelmän vaatimukset Vastaa kysymykseen “Mitä järjestelmä tekee” Määritellään syötteet, tulosteet, sekä ulkoiset rajapinnat Kerätään vaatimukset suorituskyvyn, käytettyjen standardien ym. suhteen Luodaan yhteinen käsitteistö eri sidosryhmien väliseen kommunikaatioon

5 Työvaiheet - Analyysi Etsitään vaatimusmäärittely pohjalta
Järjestelmän käyttäjät ja käyttötavat Syötteet ja tulosteet kustakin käyttökohteesta Mallinnetaan karkealla tasolla Käyttöliittymät - Toimintaketjut Tilakoneet - Järjestelmäarkkitehtuuri Looginen tietomalli - Korkean tason moduulirakenne

6 Työvaiheet - Suunnittelu
Suunnitellaan yksityiskohdat teknisellä tasolla Nimetään asiat vastaamaan toteutusta Suunnitellaan tietomallin perusteella tietokannat Mallinnetaan yksityiskohtaisesti moduulit, tilasiirtymät, jne.

7 Työvaiheet - Toteutus Toteutetaan järjestelmä kuvatulla tavalla
Ohjelmistojen koodaus Tietokantojen luonti Laitteistojen asennus Käyttöjärjestelmien ja 3. osapuolen ohjelmistojen asennus

8 Työvaiheet - Testaus Varmistetaan, että toteutus vastaa aikaisemmissa työvaiheissa suunniteltua Eri suunnitteluvaiheiden dokumentaatio luo pohjan testattavuudelle Toteuttaja Testattava moduuli Tulokset Testitapaukset

9 Lineaarinen elinkaari
Kuvaa työjärjestyksen yksittäisissä osaprojekteissa Sopii sellaisenaan toteutusmalliksi jos etukäteen tiedetään mitä ollaan tekemässä Ei suositaltava lähestymistapa isoihin järjestelmiin Tunnetaan myös nimellä vesiputousmalli Analyysi Suunnittelu Toteutus Testaus

10 Inkrementaali malli Tehtävän järjestelmän ominaisuuksia lisätään versiosta toiseen Toteutetaan aluksi ohjelman keskeisimmät ominaisuudet ja lisätään niitä hallitusti Tuotepohjaiseen kehitykseen sopiva malli

11 Prototyypitys Testataan toteutettavuus prototyyppien avulla
nopea suunnittelu proto- tyypin teko asiakkaan arvio proto- tyypistä kehittä- minen tuote vaatimusten määrittely alku loppu Testataan toteutettavuus prototyyppien avulla Tehdään karkeat alkuoletukset ja prototyyppi niiden perusteella Kuunnellaan asiakaspalaute ja muokataan toteutusta sen mukaan

12 Spiraalimalli Määrittely Toteutetaan ensin järjestelmän ydin ja laajennetaan ominaisuuksia asiakaspalautteen perusteella Perusmalli asiakaslähtöiselle tuotekehitykselle Tuotehallinnan järjestäminen keskeisesä asemassa Asiakas- kommunikaatio Riskianalyysi Asiakas- toimitukset Suunnittelu Toteutus

13 Rapid Application Development elinkaari
Toteutetaan järjestelmä pieninä kokonaisuuksina Kunkin vaiheen jälkeen muunnetaan tuotetta palautteen perusteella Aikataulu-orientoitunut kehitysmalli Vaarana kokonaiskuvan hämärtymienen 60-90 päivää

14 Muita elinkaarimalleja
Komponenttipohjainen kehitys - Malli, jossa hyödynnetään maksimaalisesti uudelleenkäytettävyyttä Samanaikainen kehitysmalli - Malli, jossa järjestelmää kehitetään samaan aikaan useampia versioita Formaali kehitysmalli - Sovelletaan kehitettäessä järjestelmiä, jotka perustuvat matemaattisiin algoritmeihin Cleanroom Engineering - Pyritään löytämään virheet jo ennen toteutukseen siirtymistä

15 Järjestelmäarkkitehtuurit

16 Mikä ? Järjestelmäarkkitehtuuri on kuvaus, jonka avulla järjestelmän kehittäjät voivat: Arvioida suunniteltavan suorituskyky verrattuna asetettuihin vaatimuksiin Harkita eri toteutusvaihtoehtoja vaiheessa, jossa muutosten tekeminen on vielä suhteellisen halpaa Vähentää itse järjestelmän kehitykseen liittyviä riskejä

17 Arkkitehtuurikuvauksen osat
Tietomallikuvaus Ohjelmistoarkkitehtuuri Laitteistoarkkitehtuuri

18 Tietomallikuvaus Analysoidaan järjestelmän toimintaketjut ja luodaan data-abstraktiot Etsitään vaatimuksista kunkin abstraktion ominaisuudet eli attribuutit Mallinnetaan data-abstraktioiden väliset suhteet Lopuksi käydään malli läpi ja pyritään yksinkertaistamaan se mahdollisimman pitkälle

19 Tietomallikuvaus - Esimerkki
“Tilaus koostuu yhdestä tai useasta tilausrivistä” “Kukin tilaus yksilöidään tilausnumerolla” “Tilaukseen liittyvät tietoalkiot ovat asiakastunnus ja laskutusosoite” “Tilausrivi koostuu tilatusta tuotelaadusta, tilatusta kappalemäärästä ja toimitusosoitteesta”

20 Tietomallikuvaus - Esimerkki (jatkoa)
Tilaus Tilausnumero Asiakastunnus Laskutusosoite Tilausrivi Tilausnumero Rivinumero Tuotelaatu Kappalemäärä Toimitusosoite 1 1..n

21 Tietomallikuvaus - huomioitavia asioita
Suunnitellun tietomallin tulisi vastata varsinaisen järjestelmän moduulirakennetta Kullekin data-abstarktiolle tulisi kuvata sekä tietosisältö että niihin kohdistuvat operaatiot Tietomallin luonti tulisi tehdä käsiteluettelossa kuvatuin termein Teknisen tason tietomallisuunnittelu tulisi jättää tekniseen suunnitteluun Looginen tietomalli tulisi olla piilotettavissa muilta kuin sitä suoraan käsitteleviltä ohjelmamoduuleilta Tietomalli tulisi suunnitella siten että käytetyt työkalut tukevat kuvaustapaa

22 Ohjelmistoarkkitehtuurit
Data-keskeinen arkkitehtuuri - Järjestelmä(t) rakennetaan suunnitellun tietomallin ympärille Tietovuoarkkitehtuuri - Järjestelmän moduulirakenne suunnitellaan toimintaketjujen ehdoilla Kysely-vastaus arkkitehtuuri - Järjestelmässä ei sisäisiä operaatioiden välisiä tiloja Olioarkkitehtuuri - Järjestelmä suunnitellaan itsenäisinä olioina jotka kommunikoivat keskenään tarkoin määriteltyjen rajapintojen välityksellä Kerrosarkkitehtuuri - Ohjelmamoduulit jaetaan kerroksiin sen mukaan miten paljon varsinaista logiikkaa ne sisältävät

23 Data-keskeinen malli Sovellus 2 Sovellus 1 Sovellus 3 Tietokanta
“Perinteinen” arkkitehtuuri Virhetilanteiden jäljitys haasteellista Muutokset tietomallissa erittäin vaikeita

24 Data-keskeinen malli “Perinteinen” arkkitehtuuri
Virhetilanteiden jäljitys haasteellista Muutokset tietomalliin erittäin vaikeita

25 Tietovuoarkkitehtuuri
Toiminnalliset kokonaisuudet vastaavat osaa toimintaketjussa Kukin vaihe vastaa prosessin yhtä vaihetta

26 Kysely-vastaus arkkitehtuuri
Kukin tapahtuma muodostuu joukosta riippumattomia “atomaarisia tapahtumia” Kukin moduuli tekee ainoastaan sille annetun tehtävän tietämättä muista “samantasoisista” moduuleista Mahdollistaa moduulien välisten riippuvuuksien minimoinnin

27 Kerrosarkkitehtuuri Järjestelmä koostuu eri kerroksista joilla kullakin oma tehtävänsä Ydin muodostuu joukosta atomaarisia operaatioita Varsinainen sovelluslogiikka tuodaan vasta ylemmillä kerroksilla Mahdollistaa moduulien välisten riippuvuuksien minimoinnin ja uudelleenkäytettävyyden Järjestelmän ydin Palvelukerros Sovelluskerros Käyttöliittymäkerros

28 Laitteistoarkkitehtuuri
Kuvataan järjestelmän fyysiset komponentit Kuvataan tiedonvaihto (tietoalkiot) komponenttien välillä Kuvataan käytetyt protokollan komponenttien välillä

29 Lähestymistavat arkkitehtuurin määrittämiseksi
Top Down Lähdetään liikkelle vaatimuksista Kuvataan ensin ylimmän tason toiminnallisuudet ja pilkotaan ne osiin Jatketaan samalla tapaa kerros kerrallaan Sopii useimmin lähestymistavaksi Bottom Up Suunnitellaan arkkitehtuuri ympäristön ehdoilla Suunnitellaan alimman tason liittymät ja sen jälkeen lisätään logiikkaa kerros kerrokselta Soveltuu tietyntyyppisiin komponenttiarkkitehtuurei-hin

30 Työvaiheet arkkitehtuurin määrittelemiseksi
Kerää käyttötapaukset Listaa vaatimukset, oletukset, ja toimintaympäristö Kuvaa arkkitehtuurin osat moduulinäkymä tietomallinäkymä fyysinen näkymä Arvioi kukin komponentti erillisenä, sekä sen vaikutus kokonaisjärjestelmään Pyri yksinkertaistamaan syntynyt malli

31 Mitä hyötyä modulaarisesta arkkitehtuurista
Järjestelmän testattavuus paranee Ylläpidettävyys paranee Muutosten vaikutukset voidaan rajata Parempi laajennettavuus