Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen vlill

Suunnittelu

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

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

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

Suunnitteluprosessi (Sommerville 1995) Requirements specification Arkkitehtuurin suunnittelu Arkkitehtuuri Abstrakti spesifikaatio Ohjelmiston spesifikaatio Rajapintojen suunnittelu Komponenttien suunnittelu Tietorakenteiden suunnittelu Algoritmien suunnittelu Rajapintojen spesifikaatio Komponenttien spesifikaatio Tietorakenteiden spesifikaatio Algoritmien spesifikaatio

Suunnitteludokumentti 1/2 1. Johdanto 2. Viitekehys 2. 1 Vaatimusmäärittely 2. 2 Laitteisto- ja ohjelmistotoimittajat 2. 3 Tekninen kuvaus 3. Suunnittelukuvaus 3. 1 Tietorakenteet 3. 2 Toiminnot 3. 3 Arkkitehtuuri

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

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 (topdown)

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

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

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

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: 1. Järjestelmän rakenne – jako pääosiin 2. Järjestelmän osien kontrollin määrittely 3. Järjestelmän osien jako komponentteihin

Järjestelmän ositus esimerkki Liukuhihnan pakkausrobotti Näköjärjestelmä Esineen tunnistusjärjestelmä Käden ohjaus Otteen ohjaus Pakkauksen valintajärjestelmä Pakkausjärjestelmä Liukuhihnan ohjain

Tietovarastomalli – yhteinen tieto Henkilöstö, palkanlaskenta WWW-palvelu Kirjanpito Tietovarasto Asiakasrekisteri Varastokirjanpito Laskutus, reskontrat

Jokaisella osalla oma tietokanta Henkilöstö, palkanlaskenta Kirjanpito Laskutus, reskontrat WWW-palvelu Asiakasrekisteri Varastokirjanpito

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

Integrointitilanne Henkilöstö, palkanlaskenta WWW-palvelu Kirjanpito Tietovarastoohjain Asiakasrekisteri Varastokirjanpito Laskutus, reskontrat

N-kerroksinen arkkitehtuuri Palvelin 1 Middleware Client 1 Client 2 Palvelin 2 Middleware Client 3 verkko Palvelin 3 verkko

Kontrollin mallinnus - keskitetty kontrolli Pääohjelma Rutiini 1. 1 Rutiini 2 Rutiini 1. 2 Rutiini 3. 1 Rutiini 3. 2

Kontrollin mallinnus - tapahtumapohjainen Keskeytykset Keskeytysvektori TK 1 TK 2 TK 3 TK 4 Prosessi 1 Prosessi 2 Prosessi 3 Prosessi 4

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

Sovellusaluekohtaiset arkkitehtuurimallit • • Yleistä mallia arkkitehtuurille ei ole, mutta joillekin tietyille sovellusalueille on Esim. kääntäjäteknologia: 1. 2. 3. 4. 5. 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 6. Code generator – generoi suoritettavan koodin