Suunnittelu.

Esitys aiheesta: "Suunnittelu."— Esityksen transkriptio:

1 Suunnittelu

2 Suunnitteluvaihe prosessissa
Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi Korkea abstraktiotaso Sovellusläheisetkäsitteet Epätarkka kuvaus Suunnittelu Toteutus Matala abstraktiotaso Toteutusläheiset käsitteet Tarkka kuvaus

3 Suunnitteluprosessin pääosat
Järjestelmän yleisrakenteen suunnittelu Moduulien (olioiden) suunnittelu Tietorakenteiden ja algoritmien suunnittelu Käyttöliittymän suunnittelu

4 Ei toteudu suurissa järjestelmissä tai uudelleenkäytössä!
Top-down suunnittelu Ei toteudu suurissa järjestelmissä tai uudelleenkäytössä!

5 Suunnitteluprosessi (Sommerville 1995)
Requirements specification Arkkiteh- tuurin suunnittelu Abstrakti spesifikaatio Raja- pintojen suunnittelu Kompo- nenttien suunnittelu Tieto- rakenteiden suunnittelu Algoritmien suunnittelu Arkkiteh-tuuri Ohjelmiston spesifikaatio Rajapintojen spesifikaatio Kompo- nenttien spesifikaatio Tieto- rakenteiden spesifikaatio Algoritmien spesifikaatio

6 Suunnitteludokumentti 1/2
Johdanto Viitekehys 2.1 Vaatimusmäärittely 2.2 Laitteisto- ja ohjelmistotoimittajat 2.3 Tekninen kuvaus Suunnittelukuvaus 3.1 Tietorakenteet 3.2 Toiminnot 3.3 Arkkitehtuuri

7 Suunnitteludokumentti 2/2
Moduulien kuvaukset 4.N.1 Yleiskuvaus (tekstiä) 4.N.2 Liittymät 4.N.3 Algoritmien esitys Globaali tieto 5.1 Ulkoiset tiedostot 5.2 Tietokannat 5.3 Liitäntä tietorakenteisiin Viitteet vaatimusmäärittelyyn Testaus Kirjastointi (yleiskäyttöiset komponentit)

8 Rationaalinen suunnitteluprosessi? (Parnas & Clements 1986)
Rationaalinen suunnitteluprosessi ei ole mahdollista Rationaalisen prosessin ”teeskentely” on kuitenkin mahdollista, mutta vaikeaa ”Teeskentely” on kaikesta huolimatta hyödyllistä eli prosessi kannatta dokumentoida rationaalisesti (top-down) Kerrataan prosessikäsite (Haikala & Märijärvi 2002)

9 Miksi suunnittelu ei suju ideaalisesti?
Asiakas ei tiedä tarkkaan mitä tahtoo Vaikka tietäisikin, suunnittelun aikana tulee muutoksia (tarkempi tutkiminen) Vaikka vaatimukset tiedetään, seuraa monimutkaisuudesta virheitä Projekteihin tulee aina muutoksia Inhimilliset erehdykset Sovelletaan vanhaa, joka ei täysin vastaa vaatimuksia Uusiokäytetään vanhaa tai tehdään uusiokäytettävää

10 Prosessin kuvauksen hyödyllisyys
Ihanteellisen prosessin tuntemus opastaa suunnittelua Päästään lähemmäksi ihanteellista prosessia kuin täysin tapauskohtaisessa toiminnassa Vakioprosessi auttaa henkilöiden ja tiedon siirtoa eri projektien välillä Projektin edistystä voidaan verrata ideaaliprosessin mukaiseen (statistiikan?) esitykseen Katselmukset ovat helpompia (tiedetään, mitä tietyssä vaiheessa voidaan odottaa)

11 Ideaalisen prosessin ”teeskentelyn” merkitys
Tuotetaan ideaalisen prosessin mukainen dokumentaatio, vaikka se ei vastaisikaan todellista toimintatapaa. Merkitään puuttuvat tiedot dokumentteihin. Muutokset päivitetään myös aiempiin dokumentteihin. -> Siis annetaan järkevä perustelu toiminnalle (vrt. matemaattiset todistukset) Kirjataan myös harkitut ja hylätyt vaihtoehdot -> Samoja asioita ei tarvitse miettiä uudestaan

12 Arkkitehtuurin suunnittelu
Suunnittelun perusta: Huonoa arkkitehtuurisuunnittelua ei voi korvata millään möyhemmässä vaiheessa On useita tyylejä jakaa ohjelmisto osiin Usein kuvaus useammasta näkökulmasta Ei ole mitään yleisesti hyväksyttyä prosessimallia arkkitehtuurin suunnitteluun, mutta yleensä seuraavat toiminnot ovat tarpeen: Järjestelmän rakenne – jako pääosiin Järjestelmän osien kontrollin määrittely Järjestelmän osien jako komponentteihin

13 Järjestelmän ositus esimerkki Liukuhihnan pakkausrobotti
Näkö- järjestelmä Käden ohjaus Otteen ohjaus Esineen tunnistus-järjestelmä Pakkauksen valinta- järjestelmä Pakkaus- järjestelmä Liukuhihnan ohjain

14 Tietovarastomalli – yhteinen tieto
Henkilöstö, palkanlaskenta Kirjanpito Laskutus, reskontrat Tietovarasto WWW-palvelu Asiakas- rekisteri Varasto- kirjanpito

15 Jokaisella osalla oma tietokanta
Henkilöstö, palkanlaskenta Kirjanpito Laskutus, reskontrat WWW-palvelu Asiakas- rekisteri Varasto- kirjanpito

16 Yhteisen tietovaraston etuja ja haittoja
Tehokas tapa jakaa paljon tietoa Osajärjestelmien ei tarvitse tarjota tietoon liittyviä palveluja ulkopuolelle Backupit, käyttöoikeudet, toipuminen yms. keskitettyä -> paremmin hallittavissa Osajärjestelmien täytyy sopeutua yhteiseen tietomalliin – se ei ole kaikille optimaalinen Suuren tietomäärän voi olla vaikea mukautua yhteiseen tietomalliin. Onko muunnos mahdollinen? Tehokkuus? Eri osilla voi olla eri vaatimukset tietoturvan, toipumisen yms. suhteen

17 Integrointitilanne Henkilöstö, palkanlaskenta Kirjanpito Laskutus,
reskontrat Tietovarasto-ohjain WWW-palvelu Asiakas- rekisteri Varasto- kirjanpito

18 N-kerroksinen arkkitehtuuri
Palvelin 1 Middle- ware Client 1 Client 2 Palvelin 2 Middle- ware Client 3 Palvelin 3 verkko verkko

19 Kontrollin mallinnus - keskitetty kontrolli
Pääohjelma Rutiini 1 Rutiini 2 Rutiini 3 Rutiini 1.1 Rutiini 1.2 Rutiini 3.1 Rutiini 3.2

20 Kontrollin mallinnus - tapahtumapohjainen
Keskeytykset Keskeytys- vektori TK 1 TK 2 TK 3 TK 4 Prosessi 1 Prosessi 2 Prosessi 3 Prosessi 4

21 Järjestelmän osien jako komponentteihin
Esim. olioperiaatteen mukaisesti

22 Sovellusaluekohtaiset arkkitehtuurimallit
Yleistä mallia arkkitehtuurille ei ole, mutta joillekin tietyille sovellusalueille on Esim. kääntäjäteknologia: Lexical analyser – pätkii koodin sisäiseen muotoon Symbol table – tulos edellisestä, nimet ja tyypit Syntax analyser – tarkistaa syntaksin Syntax tree – tulos edellisestä, ohjelman sisäinen esitys Semantic analyser – tarkisitaa puusta semanttisen oikeellisuuden Code generator – generoi suoritettavan koodin