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 Requirements specification 1995) Arkkitehtuurin suunnittelu Abstrakti spesifikaatio Rajapintojen suunnittelu Komponenttien suunnittelu Tietorakenteiden suunnittelu Algoritmien suunnittelu Ohjelmiston spesifikaatio Rajapintojen spesifikaatio Arkkitehtuuri 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
Näköjärjestelmä Järjestelmän ositus esimerkki Liukuhihnan pakkausrobotti Esineen tunnistusjärjestelmä Käden ohjaus Otteen ohjaus Pakkauksen valintajärjestelmä Pakkausjärjestelmä Liukuhihnan ohjain
Tietovarastomalli yhteinen tieto Henkilöstö, palkanlaskenta Kirjanpito WWW-palvelu Tietovarasto Laskutus, reskontrat Asiakasrekisteri Varastokirjanpito
Jokaisella osalla oma tietokanta Henkilöstö, palkanlaskenta Kirjanpito WWW-palvelu Laskutus, reskontrat Asiakasrekisteri Varastokirjanpito
Yhteisen tietovaraston etuja ja Tehokas tapa jakaa paljon tietoa Osajärjestelmien ei tarvitse tarjota tietoon liittyviä palveluja ulkopuolelle Backupit, käyttöoikeudet, toipuminen yms. keskitettyä -> paremmin hallittavissa haittoja 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
Integrointitilanne Henkilöstö, palkanlaskenta Kirjanpito WWW-palvelu Laskutus, reskontrat Tietovarastoohjain Asiakasrekisteri Varastokirjanpito
N-kerroksinen arkkitehtuuri Client 1 Client 2 Client 3 Middleware Middleware Palvelin 1 Palvelin 2 Palvelin 3 verkko verkko
Kontrollin mallinnus - keskitetty kontrolli Pääohjelma Rutiini 1 Rutiini 2 Rutiini 3 Rutiini 1.1 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. Lexical analyser pätkii koodin sisäiseen muotoon 2. Symbol table tulos edellisestä, nimet ja tyypit 3. Syntax analyser tarkistaa syntaksin 4. Syntax tree tulos edellisestä, ohjelman sisäinen esitys 5. Semantic analyser tarkisitaa puusta semanttisen oikeellisuuden 6. Code generator generoi suoritettavan koodin