010758002 Ohjelmistotuotanto - Suunnittelu

1. 010758002 Ohjelmistotuotanto- Suunnittelu Kevät 2005 Jani Vaara LTY/Tite

2. Sisältö • Ohjelmistojen suunnittelusta • Suunnittelun tavoitteet ja yleisiä periaatteita • Arkkitehtuurisuunnittelusta • Ohjelmistojen toteutusfilosofiasta • Suunnittelun dokumentoinnista • Uudelleenkäytöstä

3. Yleistä suunnittelusta • Tarkoituksena muuntaa asiakkaan tarpeiden mukaan tehty määrittely tekniselle kielelle – järjestelmän toteutuksen kuvaukseksi • Vastaa kysymykseen: miten järjestelmä toteutetaan? • Jaetaan kahteen osaan: • arkkitehtuurisuunnittelu ja • moduulisuunnittelu

4. Määrittelystä suunnitteluun Määrittely Tuote asiakkaan kannalta Arkkitehtuurisuunnittelu Jako moduuleiksi, rajapintojen määrittely Moduulisuunnittelu Moduulien suunnittelu ja toteutus

5. Määrittelystä toteutukseen 1/2 Määrittelystä suunnittelun kautta toteutukseen edetessä näkökulma muuttuu toteutustekniseksi. Järjestelmää ositetaan kunnes jokainen osa on riittänän pieni kuvattavaksi ohjelmistotason välineillä.

6. Määrittelystä toteutukseen 2/2 • Arkkitehtuurisuunnittelussa järjestelmä jaetaan moduuleihin ja moduulien rajapinnat määritellään. • Moduulisuunnittelussa suunnitellaan kunkin moduulin sisäinen rakenne. • Tasoja voi olla useampia, tarkoituksen on hienontaa järjestelmä niin pieniin osiin, että osat voidaan antaa yksittäisten suunnittelijoiden tehtäväksi.

7. Suunnittelu ohjelmistokehityksessä Esitutkimus Asetetaan asiakasvaatimukset: mitä asiakas haluaa? Miksi ohjelmisto tulisi tehdä? Analysoidaan asiakasvaatimukset: mitä voidaan toteuttaa? Johdetaan ohjelmistovaatimukset: mitä projektissa tehdään? Määrittely Suunnitellaan, kuinka määrittelyssä kuvatut vaatimukset toteutetaan. (Arkkitehtuurisuunnittelu, moduulisuunnittelu) Suunnittelu Toteutetaan suunniteltu. Toteutus Integrointi: yhdistetään toteutetut osat niin, että niistä saadaan yksi toimiva kokonaisuus. Testaus: etsitään ohjelmiston virheitä ja korjataan ne. Integrointi ja testaus Käyttöönotto: toimitaan ohjelmisto asiakkaalle Ylläpito: ratkotaan asiakkaan ongelmia, korjataan virheitä, muutetaan tarvittaessa ohjelmistoa uusia vaatimuksia vastaavaksi. Käyttöönotto ja ylläpito

8. Ohjelmistosuunnittelun tavoitteet • Suunnittelulle asetettava keskeinen tavoite on varsin usein asiakkaan kokema laatu. • Asiakkaan kokema laatu on usean osatekijän summa. • Osatekijät esimerkiksi: • Kustannukset • Tuotteen laatu • Tuotteen valmistuminen aikataulussa

9. Yleisiä periaatteita yksinkertaisuus ja suoraviivaisuus Laadun osatekijöitä osittaminen ja lokaalisuus tehokkuus abstraktioiden hyödyntäminen virheettömyys toteutusfilosofia(t) luotettavuus käytettävyys ylläpidettavyys siirrettävyys uudelleenkäytettävyys ymmärrettävyys muunnettavuus toteutettavuus testattavuus toteutusvälineitä moduulirakenne abstraktit tietotyypit asiakkaan kokema laatu luokat oikea tuote oikeaan aikaan oikeaan hintaan Periaatteista ja toteutusvälineistä laatuun

10. Suunnittelun laatutavoitteita • Suunnittelun laatutavoitteisiin vaikuttavia ohjelmiston ominaisuuksia on paljon (esim. luettavuus, tehokkuus, käytettävyys, uudelleenkäyttö, -käytettävyys, ylläpidettävyys, siirrettävyys...) • Usein nämä tavoitteet ovat keskenään ristiriitaisia ja eri tilanteissa eri tavoitteille annetaan eri arvoja. • Yleispätevien tavotteiden antaminen lähes mahdotonta.

11. Arkkitehtuurisuunnittelu • Järjestelmän tai komponentin arkkitehtuuri on rakenne tai järjestelmärakenne, joka käsittää ohjelmistokomponentit, näiden komponenttien ulkoisesti näkyvät ominaisuudet sekä niiden suhteet toisiinsa. • Arkkitehtuurisuunnittelu on pääasiassa osien välisten työnjaon ja rajapintojen suunnittelua.

12. Arkkitehtuurisuunnittelu • Modulaarinen suunnittelu pyrkii minimoimaan yksittäiseen moduuliin sisälle tehtävän muutoksen vaikutukset muihin moduuleihin. • muutosten tekeminen helpottuu. • projektin osat voidaan toteuttaa toisistaan mahdollisimman riippumattomasti. • uudelleenkäytettävyys paranee.

13. Arkkitehtuurisuunnittelu • Arkkitehtuurisuunnittelussa kiinnitetään järjestelmän arkkitehtuuriin kuuluvat valinnat • järjestelmän kerrokset • jako alijärjestelmiksi, komponenteiksi • korkean tason suunnittelumallit • arkkitehtuurityylit (asiakas-palvelin jne.) • ohjelmistojen sijoittelu laitteistoihin • prosessit ja niiden kommunikointi • tiedon talletusratkaisut • tietoturva • jne.

14. Arkkitehtuurisuunnittelu • Arkkitehtuurisuunnittelussa tehdyt huonot ratkaisut kostautuvat myöhemmin korkeina toteutus- ja ylläpitokustannuksina. -> Ohjelmistojen keskeisiksi laatutekijöiksi nousee ymmärrettävyys ja muunneltavuus. • Mikäli arkkitehtuurisuunnittelu on tehty hyvin, yksittäinen huono moduuli on tavallisesti helppo korvata paremmalla.

15. Hyvä arkkitehtuurisuunnittelu... • parantaa osapuolten kommunikaatiota Ohjelmistoarkkitehtuuri esittää yleistä korkean tason abstraktiota järjestelmästä ja lähes kaikki osapuolet voivat käyttää sitä yhteisen ymmärtämisen perustana, yksimielisyyden muodostamiseen ja keskinäiseen kommunikaatioon. • auttaa aikaisissa suunnittelupäätöksissä Ohjelmiston arkkitehtuuri esittää ilmentymää järjestelmän suunnittelupäätöksistä ja nämä päätökset tulevat vaikuttamaan kehitystyöhön, käyttöönottoon ja ylläpitoon. • toimii siirrettävänä järjestelmän abstraktiona Ohjelmiston arkkitehtuuri muodostaa suhteellisen pienen, selkeän mallin siitä miten järjestelmä on rakennettu ja miten sen komponentit toimivat yhdessä. Tälläinen malli on siirrettävissä järjestelmien välillä, se esittää suuren mittakaavan uudelleenkäyttöä.

16. Arkkitehtuurisuunnittelun prosessisuosituksia • Arkkitehtuurin tulee olla yhden arkkitehdin tai nimetyn arkkitehdin vetäjän arkkitehtiryhmän suunnittelema. • Arkkitehdillä tulee olla selkeät ja priorisoidut järjestelmän tekniset vaatimukset, jotka arkkitehtuurin tulee täyttää. • Arkkitehtuurin tulee olla hyvin dokumentoitu käyttäen sellaisia sovittuja kuvaustapoja , joita kaikki osapuolet ymmärtävät.

17. Arkkitehtuurisuunnittelun prosessisuosituksia • Arkkitehtuuria tulee jatkuvasti kierrättää kaikilla osapuolilla, joiden tulee aktiivisesti osallistua arkkitehtuurin katselmointiin. • Arkkitehtuuria tulee analysoida sopivilla mitattavilla suureilla ja laadulliset ominaisuudet virallisesti katselmoida ennenkuin siihen on liian myöhäistä tehdä muutoksia.

18. Arkkitehtuurisuunnittelun prosessisuosituksia • Arkkitehtuurin tulee johtaa itsensä toteutukseen muodostamalla järjestelmästä ”luurankomallin”. • Arkkitehtuurin tulee määritellä erityinen (ja pieni) joukko resurssiongelmia suunnittelu ohjeistuksineen.

19. Arkkitehtuurisuunnittelun rakenteelliset ohjeet • Arkkitehtuurin tulee esitellä hyvin määritellyt moduulit, joiden toiminnalisuus ja rajapinnat on määritelty. • Moduulien tulee noudattaa riippumattomuutta, jotta niistä vastaavat toteutusryhmät voisivat toimia riittävän itsenäisesti. • Moduulien kapselointi takaa sen että koko järjestelmää ei tarvitse välttämättä muuttaa, jos jokin sen toimintaympäristössä muuttuu.

20. Arkkitehtuurisuunnittelun rakenteelliset ohjeet • Arkkitehtuuri ei koskaan saisi olla riippuvainen tietyn kaupallisen tuotteen tai työkalun versiosta. • Moduulit, jotka tuottavat dataa tulee erottaa moduuleista, jotka käyttävät dataa.Tästä seuraa parempi muunneltavuus koska muutokset vaikuttavat yleensä joko datan tuottamiseen tai käyttöön.

21. Arkkitehtuurisuunnittelun rakenteelliset ohjeet • Rinnakkaisprosessi järjestelmissä arkkitehtuurin tulee esitellä hyvin määritellyt prosessit, jotka eivät välttämättä noudata moduulirakennetta. • Jokainen prosessi tulee suunnitella siten että sen osoitus jollekkin prosessorille voidaan vaihtaa jopa ajonaikaisesti. • Arkkitehtuurin tulee esitellä pieni joukko yksinkertaisia toimintamalleja. Järjestelmän tulee tehdä samat asiat joka paikassa samalla tavalla. • lisää ymmärrettävyyttä ja parantaa muunneltavuutta • käsitteellinen yhtenäisyys lisääntyy

22. Miksi suunnittelu on vaikeaa? • Suunnittelun ratkaisut ja tietotekniikka muuttuvat nopeasti • Se mitä opetan tänään on 3 vuoden päästä vanhaa. • Tietokoneiden kapasiteetti laajenee kovaa vauhtia. • Käsiteltävät ongelmat muuttuvat koko ajan monimutkaisemmiksi.

23. Suunnitteluprosessi

24. Arkkitehtuurisuunnittelun tavoitteet • Suunnittelun tavoitteita: • selkeys ja ymmärrettävyys • tehokkuus • luotettavuus • ylläpidettävyys • uudelleenkäytettävyys ja siirrettävyys • Ratkaisut tavoitteiden saavuttamiseksi: • paikallisuus • hierarkkisuus • modulaarisuus • rajapintojen tiiviys • tiedon kätkeminen

25. Viime kädessä... • arkkitehtuurisuunnittelun tarkoitus on ihmiselle hankalan monimutkaisuuden hallinta. • Ohjelmistot ovat monimutkaisia -> yksinkertaisesti toteutettavien osien toteuttaminen vaatii ohjelmistojen osittamista keskenään riippumattomiin moduuleihin.

26. Suunnittelun yleisiä periaatteita • yksinkertaisuus ja suoraviivaisuus • osittaminen ja lokaalisuus • abstraktioiden hyödyntäminen • yhdenmukainen toteutusfilosofia eli arkkitehtuurityyli

27. Yksinkertaisuus ja suoraviivaisuus • On kaksi tapaa rakentaa ohjelmistoja • Suunnitteluratkaisut ovat niin suoraviivaisia ja ymmärrettäviä, että virheettömyys on ilmeistä • Suunnitteluratkaisut ovat niin mutkikkaita, että virheet eivät ole ilmeisiä • Kolme hyvää periaatetta: • KISS: Keep It Simple, Stupid • Design for errors • Design for change • Ja erityisesti reaaliaikajärjestelmissä • Design for testing • Ja ehkä se kaikkein tärkein periaate: • Say it once and only once

28. Osittaminen • rakenteellisen monimutkaisuuden hallinta • osittaminen rinnakkaisiin osiin • moduulit toteuttavat osan kokonaisuudesta • hierarkkinen osittaminen • alemman tason moduulit ”palvelevat” ylemmän tason moduuleita

29. Esimerkki hierarkisesta osittamisesta

30. Lokaalisuus • Osittamisen suunnittelua siten, että suunnittelu-päätökset kapseloidaan mahdollisimman hyvin osien sisään • Edut: • muutosten tekeminen helpottuu • ohjelmiston yksittäisten osien toteutus ja testaus erikseen • mahdollistaa osan irrottamisen kokonaisuudesta ja uudelleenkäytön toisessa yhteydessä • Moduulin sisäisen toteutuksen lokalisointi

31. Abstraktioiden hyödyntäminen • Abstraktio • malli, joka kuvaa esittämästään asiasta oleellisen • Epäoleellinen voidaan jättää pois ja tarpeettomat yksityiskohdat koteloidaan (encapsulate) abstraktion sisälle • Informaation kätkeminen (information hiding) • Abstraktiosta näkyy käyttäjälle rajapinta (interface), sen sisään koteloitu toteutus on abstraktion käyttäjälle tuntematon -> ymmärrettävyys & muunneltavuus • Käyttötarkoituksina korkeamman tason abstraktion luominen alemman tason abstraktiosta, erilaisuuden kätkeminen, suunnitteluratkaisun piilottaminen

32. Esimerkki työasemasovelluksen abstraktoinnista

33. Abstraktioiden vastineet • Vastine ohjelmistoa ympäröivässä maailmassa, esimerkiksi ”auto” tai ”kissa”. • ominaisuudet ja toiminnot helppo määritellä. • Ei vastinetta todellisuudessa. • Usein toteutusta helpottavia peruskomponentteja, esim. merkkijonojen käsittely tai sanomajonot. • Määrittely usein työlästä ja vaatii usein useiden vaihtoehtojen kokeilua

34. Toteutusfilosofia (arkkitehtuurityyli) • Yhdenmukaiset toteutusperiaatteet, joilla järjestelmän piirteet toteutetaan. • Toteutusfilosofia kiteyttää periaatteet ja rakenteet, joiden ajatellaan pysyvän muuttumattomana koko ohjelmiston elinkaaren ajan. • Arkkitehtuurisuunnittelu tuleekin ymmärtää laajemmin kuin pelkkinä moduuleina ja niiden välisinä yhteyksinä.

35. Lisää toteutusfilosofiasta • Antaa kehittäjälle mallin siitä, miten uusi ominaisuus toteutetaan järjestelmään. • Antaa ylläpitäjälle tietoa, minkä tapaista ratkaisua on etsittävä ja mihin muutokset on kohdistettava. • Hyvälle arkkitehtuurille on ominaista, että jos jotain asiaa ei tiedä, se on arvattavissa toteutusfilosofian perusteella. • Antaa yleisen mallin, jonka mukaan järjestelmän avainabstraktioita yhdistellään.

36. Esimerkki käyttöjärjestelmän toteutusfilosofioista proseduuriorientoitunut KJ prosessiorientoitunut KJ

37. Moduulien toteuttaminen • Yksi moduuli kuvaa yhden abstraktion tai koostuu joukosta yhteenkuuluvia aliohjelmia • Useimmiten moduulijako vastaa ohjelman jakoa tiedostoiksi • Moduulien kuvauksessa rajapinnan kuvaus erotettava sisäisestä toteutuksesta • kieleen liittyvä esitystapa • sopimus toteutuskäytännöstä

38. Rajapintojen suunnittelu ja dokumentointi • rajapinta: sopimus toteuttajan ja käyttäjän välillä • modulien sisäinen kiinteys mahdollisimman suuri  helpottaa ylläpitoa • loogisesti yhteenkuuluvat asiat samassa modulissa • modulien väliset kytkennät mahdollisimman pieniä  helpottaa ylläpitoa • modulien väliset riippuvuudet • rajapintojen kapeus ja löyhyys (välitetään vain ne tiedot, jotka on tarpeen)

39. Moduuli

40. Suunnittelun eteneminen • Tehtäviä: • Mietitään ratkaisun yleiset periaatteet (toteutusfilosofia, arkkitehtuurityyli) • Suunnitellaan modulirakenne • Määritellään, mitä tietoa modulit sisältävät • Suunnitellaan modulien rajapinnat • Määritellään modulien näkyvyys: mitä muita moduleja moduli tarvitsee toiminnassaan • Testataan ratkaisua tutkimalla millaisia kutsusekvenssejä ohjelman toiminnot aiheuttavat modulien sisällä (esim. SA menetelmän tapahtumalistana, UML käyttötapauksina) • Suunnitellaan modulien sisäinen toteutus • Varmistetaan kriittisimpien toteutusratkaisujen toimivuus esimerkiksi prototyypillä • Suunnittelun dokumentointi Iteroiden ja rinnakkain

41. Teknisen määrittelyn sisältörunko Lähde: standardista IEEE1016 vapaasti mukailtu

42. Suunnitteluesimerkki • Ohjelmisto muodostaa tekstitiedostosta hakusanaston • Hakusanasto sisältää dokumentissa esiintyneet sanat aakkosjärjestyksessä • Jokaisesta sanasta tulostetaan sen esiintymisrivit tiedostossa • Hakusanasto on muotoa: akku 4 akussa 5,10 alku 1,7 ...

43. Tapahtuma- sekvenssikaavio sanaston muodostamisesta

44. Esimerkkiohjelman luokkakaavio

45. Esimerkkiohjelman rajapintamäärittely

46. Esimerkkiohjelman modulien näkyvyys Hakusanasto Tiedosto Sanasto Sana UML-komponenttikaavio

47. CASE-välineet • edustavälineet (upper-CASE, front-end) • määrittely ja suunnitteluvaiheiden apuvälineet • taustavälineet(lower-CASE, back-end) • toteutusvaiheen apuvälineet, esim. kääntäjät, sovelluskehittimet • IPSE (Integrated Project Support Environment) • kaikki ohjelmistoprojektiin liittyvät työkalut integroitu yhtenäiseksi työvälineeksi

48. Uudelleenkäytettävyys ja uudelleenkäyttö • 60 – 80% kaikesta tehtävästä ohjelmistosta on tehty jo aikaisemmin, osa siitä jopa samassa organisaatiossa • yleiskäyttöiset komponentit • käyttöliittymäkirjastot, matematiikkakirjastot, tietorakennekirjastot • sovellusaluekohtaiset komponentit • esim. televerkon hallintaan liittyvät • sovelluskohtaiset komponentit • sovelluksen oma käyttöliittymäkirjasto • sovelluskehykset (frameworks) • joukko toisiinsa liittyviä komponentteja

49. Uudelleen- käyttö tuotanto- prosessissa

50. Uudelleenkäytön edut • Tuottavuus kasvaa koska ohjelmaa ei tarvitse tehdä kokonaan uudelleen. • Monesti koeteltu komponentti on todennäköisesti virheetön. • Uudelleen käytetettävillä käyttölittymillä saadaan käyttöliittymän eri osat yhdenkumaiseksi sekä ulkonäön että toiminnan osalta.