Ohjelmistotekniikka: Luento 6

Transkriptio

1 Ohjelmistotekniikka: Luento 6 Jouni Lappalainen Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu arkkitehtuurigenret, tyylit ja mallit Kerrosarkkitehtuuri Jouni Lappalainen 1

2 Soveltuvat lait ja pohdiskelun aiheita 1. Vain piilossa olevaa voidaan muuttaa riskittä / no 8, Parnas Suunnittelumallien käyttö johtaa nopeampaan ja parempaan ylläpitoon / hyp_no 4, Gamma Oliosuuntautuneita ohjelmia on vaikea ylläpitää / hyp_no 16, Wilde

3 Soveltuvat lait ja pohdiskelun aiheita Conway:n laki (L16) esittää, että järjestelmän rakenne heijastaa sitä rakentavan organisaation rakennetta Mitä tämä mielestänne tarkoittaa ja löytyykö siihen esimerkkejä? Esitä kaksi sovellusesimerkkiä seuraaville arkkitehtuurityylille.» Kerrosarkkitehtuuri» Tietovuoarkkitehtuuri» Asiakas/palvelin arkkitehtuuri» Tietovarastopohjainen arkkitehtuuri Garlan et al. esittelee kolme perustekniikkaa arkkitehtonisen yhteensopimattomuuden käsittelemiselle (hoitamiselle). Mitä ne ovat ja mihin periaatteisiin ne nojautuvat? 3

4 Suunnittelutekniikat Skenaariopohjaiset elementit Käyttötapaukset Käyttötapauskaaviot Aktiviteettikaaviot Uimaratakaaviot Luokkapohjaiset elementit Luokkakaaviot Analyysipakkaukset CRC mallit Yhteistyökaaviot Analyysimalli Vuosuuntautuneet elementit Tietovuokaaviot Ohjausvuokaaviot Käsittelykertomukset Käyttäytymiselementit Tilakaaviot Sekvenssikaaviot Komponenttitason suunnittelu Rajapintasuunnittelu Arkkitehtuurisuunnittelu Tieto / Luokkarakennesuunnittelu Suunnittelumalli 4

5 Hyvän suunnitelman tunnusmerkit Suunnitelman tulisi kuvata arkkitehtuuri, joka noudattaa tunnettuja arkkitehtuureja (esim. suunnittelumallit) koostuu komponenteista, jotka noudattavat hyviä periaatteita (esim. modulaarisuus) voidaan toteuttaa evolutionaarisesti olla modulaarinen kuvata erikseen tieto, arkkitehtuuri, rajapinnat ja komponentit johtaa tietorakenteisiin, jotka ovat sopivia toteutettaville luokille johtaa komponenetteihin, jotka esittävät itsenäisiä toiminnallisia kokonaisuuksia johtaa rajapintoihin, jotka poistavat liitäntöjen mutkikkuutta olla kuvattu helposti ymmärrettävällä esitystavalla 5

6 Suunnitelman laatuattribuutit HP:n FURPS Functionality (Toiminnallisuus) generality, security Usability (Käytettävyys) overall aesthetics Reliability (Luotettavuus) failure rate, MTTF Performance (Suorituskyky) response time, throughput Supportability (Tuettavuus) extensibility adaptability serviceability ISO 9126 Toiminnallisuus (Functionality) suitability, accuracy, interoperability, security Luotettavuus (Reliability) maturity, fault tolerance, recoverability Käytettävyys (Usability) understandability, learnability, operability, attractiveness Tehokkuus (Efficiency) time behaviour, resource utilisation Ylläpidettävyys (Maintainability) analysability, changeability, stability, testability Siirrettävyys (Portability) adaptability, installability, co-existence, replaceability 6

7 Suunnittelun peruskäsitteet Abstraktio keino hallita mutkikkuutta esim. avata ovi, ovi Arkkitehtuuri rakenne, jolla voidaan lisätä järjestelmän käsitteellistä yhdenmukaisuutta Suunnittelumallit mahdollistavat kokeiltujen ratkaisujen käytön suunnittelussa Ositus (separation of concerns) vaikean ongelman ratkaisu on helpompaa, kun sen jakaa osiin Modulaarisuus tekee ohjelmasta hallittavan työkustannukset moduulin määrä kokonaiskustannukset integrointikustannukset kustannukset/ moduuli 7

8 Suunnittelun peruskäsitteet Tiedon kätkentä moduulien välinen kommunikointi tapahtuu hallitusti rajapintaa käyttäen, moduulin sisältöä ei näytetä Toiminnallinen riippumattomuus saavutetaan korkean koheesion ja alhaisen kytkennän avulla Askeleittain tarkentaminen esimerkki top-down suunnittelustrategiasta abstraktio ja tarkentaminen ovat toisiaan täydentäviä Piirteet (aspects) liittyy osittamiseen ja asetettuihin vaatimuksiin esim. jos kaksi vaatimusta leikkaavat jonkin piirteen osalta, tämä piirre kannattaa toteuttaa omana moduulina Refaktorointi yksinkertaistaa suunnitelmaa tai koodia muuttamatta itse toimintaa ja käyttäytymistä (tutkitaan käyttämättömät elementit, päällekkäisyys, tehottomat tai tarpeettomat algoritmit, huonot tietorakenteet) Suunnittelutason luokat suunnittelija luo tyypillisesti viidentyyppisiä luokkia rajapintaluokat, liiketoiminta-alueen luokat, prosessiluokat, talletusluokat, järjestelmäluokat 8

9 Refaktorointi - hyödyt parantaa ohjelman rakennetta muuten koodi rappeutuu helpottaa koodin ylläpitoa kahdentuneet (duplikoidut) osat poistetaan koodista saadaan luettavampaa korostetaan ymmärrettävyyttä, vähentää datariippuvuutta ohjelmisto saadaan ymmärrettävämmäksi ohjelman toiminta tulee selvemmäksi ohjelmasta löydetään helpommin virheet kun koodi on selkeämpää auttaa ohjelmistojen jatkokehitystä kun koodi ei rappeudu 9

10 Refaktorointi - pahat hajut Kahdentunut koodi Pitkä metodi Suuri luokka Pitkä parametrilista Erisuuntaiset muutokset Haulikkoleikkaus Ominaisuuskateus Tietorykelmä Primitiivipakkomielle Case-rakenteet Rinnakkaiset periytymishierarkiat Laiska luokka Spekuloiva yleistäminen Väliaikainen instanssimuuttuja Viestiketjut Välittäjä Sopimaton läheisyys Vaihtoehtoiset luokat erilaisilla rajapinnoilla Keskeneräinen kirjastoluokka Dataluokka Kielletty perintö Kommentit 10

11 Milloin suunnittelutason luokka on hyvä? Täydellinen ja riittävä attribuutit ja operaatiot ovat luokan toiminnan kannalta odotettuja ja välttämättömiä Yksinkertainen operaatiot toteuttavat vain isäntäluokan tarvitseman palvelun Korkea koheesio luokalla on vain pieni, fokusoitu joukko vastuita (hyvin määritelty ja selkeä tehtävä) Alhainen kytkentä mittaa luokkien välisiä sidonnaisuuksia vaikka luokkien välinen yhteistyö on normaalia, se tulisi pitää minimissä alhainen kytkentä takaa, että muutokset luokkaan eivät aiheuta muutoksia useisiin muihin luokkiin 11

12 Analyysitasosta suunnittelutasolle Pohjapiirros tyyppi ulkomitat lisääkamera() lisääseinä() lisääikkuna() tuhoaelementti() pirrä() 1 * Kamera tyyppi kameraid paikka valittuzoom SeinäElementti * Elementti alkukoordinaatti loppukoordinaatti poimityyppi() piirrä() Ikkuna 12

13 Suunnittelumalli (design model) Suunnittelumalli koostuu viidenlaisista peruselementeistä Tietosuunnittelun elementit (1) sovellustasolla tietosuunnittelu kohdistuu tiedostoihin ja tietokantoihin komponenttitasolla tarkastelee paikallisia tietorakenteita Arkkitehtuurisuunnittelun elementit (2) arkkitehtuurimalliin käytetään (1) sovellusalueen tietoja, (2) analyysimallin tietoja ja (3) soveltuvia arkkitehtuurikaavoja (patterns) Rajapintasuunnittelun elementit (3); kolmenlaisia käyttöliittymät esteettiset, ergonomiset ja tekniset elementit ulkoiset rajapinnat mitä tietoa järjestelmä saa ja mitä se lähettää ulospäin, miten virheen tarkastus ja turvallisuus on hoidettu sisäiset rajapinnat luokkien välinen kommunikointi ja yhteistyö 13

14 Suunnittelumalli.. Komponenttitason suunnittelun elementit (4) esitellään ohjelmistokomponentin yksityiskohdat; tietorakenteet paikallisille tieto-olioille, algoritmit tiedon käsittelemiseksi komponentin yksityiskohdat voidaan kuvata eri kaavioilla aktiviteettikaavio käsittelylogiikan kuvaamiseen proseduurit voidaan kuvata pseudokoodilla, aktiviteettikaavioilla tai vuokaavioilla 14

15 Suunnittelumalli.. Komponenttitason suunnittelun elementit (4) esimerkki komponenttikaaviosta Osa SafeHome järjestelmää Tunnistimen hallinta Tunnistin liittyvät komponentit kannattaa ryhmitellä omiksi kokonaisuuksiksi joka voidaan UML:ssa kuvata pakkauksena 15

16 Suunnittelumalli.. Sijoitustason suunnittelun elementit (5) esitellään miten ohjelmiston toiminnallisuus ja osajärjestelmät sovitetaan yhteen fyysisen tietokoneympäristön kanssa UML kuvaus sijoituskaaviosta (deployment diagram) SafeHome tuottessa on kolme yhdessä toimivaa laskentaympäristöä kotona oleva PC ohjauspaneeli toimittajan palvelin (mahdollistaa Internet yhteyden järjestelmään) Control Panel Tunnistin Security PC Security Home Management External Access Tunnistin Surveillance Communication Comp. Server Tunnistin Homeowner Access 16

17 9. Arkkitehtuurisuunnittelu Arkkitehtuuri The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. Bass, Clements, Kazman 2003 Ottaa kantaa keskeisiin ohjelmiston ratkaisuihin, jotka voivat koskea paitsi yleistä jakamista osiin myös osien kommunikointitapaa, prosesseja ja niiden välistä kommunikointia, tiedon saantitapoja ja pysyvyyden toteuttamista, toiminnallisuuden sijoittelua eri järjestelmän osiin, hajautetun järjestelmän fyysistä rakennetta, järjestelmän kykyä käsitellä suuria tieto- ja käyttäjämääriä, tehokkuutta, varautumista tulevaisuuden tarpeisiin, uudelleenkäytettävyyttä jne. Koskimies, Mikkonen

18 Arkkitehtuurisuunnittelu Arkkitehtuuri on kuvaus, joka mahdollistaa suunnitelmien tehokkuuden analysoinnin (kiinnitettyihin vaatimuksiin nähden) arkkitehtuurivaihtoehtojen arvioinnin (tasolla, jossa muutokset ovat vielä kohtuullisen helppoja) ohjelmiston rakentamiseen liittyvien riskien vähentämisen Ero arkkitehtuurin ja ohjelmiston alemman tason rakenteen kuvausten välillä on häilyvä arkkitehtuuri sisältää ne ominaisuudet, jotka eivät muutu ohjelmiston evoluution aikana / Koskimies

19 Arkkitehtuurityylit putket prosessointiyksikkö prosessointiyksikkö sovellusohjelma sovellusohjelma prosessointiyksikkö prosessointiyksikkö prosessointiyksikkö tietovarasto sovellusohjelma prosessointiyksikkö prosessointiyksikkö prosessointiyksikkö sovellusohjelma sovellusohjelma Tietovarastopohjainen arkkitehtuuri prosessointiyksikkö Tietovuoarkkitehtuuri Jouni Lappalainen & Ilkka Tervonen 19

20 Arkkitehtuurityylit Pääohjelma Luokka_C Luokka_A Valvova aliohjelma Valvova aliohjelma Luokka_B... Luokka_B... Sovellus aliohjelma Sovellus aliohjelma Sovellus aliohjelma Sovellus aliohjelma Luokka_D Sovellus aliohjelma Pääohjelma/aliohjelma arkkitehtuuri Olioperustainen arkkitehtuuri Jouni Lappalainen & Ilkka Tervonen 20

21 Arkkitehtuurityylit Selain Selain HTML JavaScript Visual Basic Sovelluspalvelin Sovellusohjelmat (Java, C++,...) Tietokantapalvelin Tietokantakyselyt (SQL,...) Palveluun rekisteröityminen Selain Kerrosarkkitehtuuri Asiakas-palvelin arkkitehtuuri (client-server) etsi Palvelua pyytävä sido julkaise Palvelun tuottaminen Palvelukeskeinen arkkitehtuuri (SOA) Palvelu 21

22 Kerrosarkkitehtuuri Selain Selain Selain HTML JavaScript Visual Basic Sovelluspalvelin Sovellusohjelmat (Java, C++,...) Tietokantapalvelin Tietokantakyselyt (SQL,...) 22

23 Kerrosarkkitehtuurin etuja Kerroksittaisuus helpottaa ylläpitoa Kerroksen sisältöä voi muuttaa vapaasti jos sen palvelurajapinta eli muille kerroksille näkyvät osat säilyvät muuttumattomina Sama pätee tietysti mihin tahansa komponenttiin Sovelluslogiikan riippumattomuus käyttöliittymästä helpottaa ohjelman siirtämistä uusille alustoille, esim. toimimaan www-selaimen kautta Alimpien kerroksien palveluja, kuten lokiin kirjoitusta tai tallennuspalvelukerrosta voidaan ehkä uusiokäyttää myös muissa sovelluksissa Ylemmät kerrokset voivat toimia korkeammalla abstraktiotasolla Esim. hyvin tehty tallennuspalvelukerros kätkee tietokannan käsittelyn muilta kerroksilta: sovelluslogiikan tasolla voidaan ajatella kaikki olioina Kaikkien ohjelmoijien ei tarvitse ymmärtää kaikkia detaljeja, osa voi keskittyä tietokantaan, osa käyttöliittymiin, osa sovelluslogiikkaan (Luukkainen & Laine, 2010)" 23

24 Lisää kerrosarkkitehtuureista Myös kerrosten sisällä ohjelman loogisesti toisiinsa liittyvät komponentit kannattaa ryhmitellä omiksi kokonaisuuksiksi joka voidaan UML:ssa kuvata pakkauksena Pakkaus voi sisältää muita (ali)pakkauksia Pakkaus omistaa sisältönsä pakkauksen poistaminen poistaa myös sen sisällön esim. luokka kuuluu yleensä vain yhteen pakkaukseen Pakkaus voi viitata (import) muihin pakkauksiin merkitään riippuvuutena pakkausten välillä tällöin pakkauksen elementit (esim. luokat) voivat viitata kohdepakkaukseen tai sen elementteihin 24

25 Pakkausnotaatioita (Pohjalainen P., 2009)" 25

26 Kerrosten väliset riippuvuudet Ylemmät kerrokset riippuvat alemmista Alempien kerrosten oltava (julkisilta osiltaan) vakaita muutos rajapintaan heijastuu ylempään Toisaalta alemman kerroksen voidaan vaihtaa julkisilta osiltaan samanlaiseen (mutta sisäiseltä toteutukseltaan erilaiseen), koska se on riippumaton ylemmästa (Pohjalainen P., 2009)" 26

27 (Pohjalainen P., 2009)" 27

28 Miten hyötyä kerroksellisuudesta Pelkkä kerroksittaisuus ei tee ohjelman arkkitehtuurista automaattisesti hyvää. Alla tilanne, missä kerroksen n+1 kolmella alipaketilla on kullakin paljon riippuvuuksia kerroksen n sisäisiin komponenttiin Esim. muutos kerroksen n luokkaan 1 aiheuttaa nyt muutoksen hyvin moneen ylemmän kerroksen pakkaukseen (Luukkainen & Laine, 2010)" 28

29 Miten hyötyä kerroksellisuudesta Kerrosten välille kannattaa määritellä selkeä rajapinta Yksi tapa toteuttaa rajapinta on luoda kerroksen sisälle erillinen rajapintaolio, jonka kautta ulkoiset yhteydet tapahtuvat Tätä periaatetta sanotaan fasaadiksi (engl. facade pattern) Alla luotu rajapintaolio kerrokselle n. Kommunikointi kerroksen kanssa tapahtuu rajapintaolion kautta ylemmän kerroksen riippuvuudet kohdistuvat rajapintaolioon muutos esim. luokkaan 1 ei vaikuta kerroksen n+1 komponentteihin ainoat muutokset on tehtävä rajapintaolion sisäiseen toteutukseen (Luukkainen & Laine, 2010)" 29

30 Käyttöliittymän ja sovelluslogiikan erottaminen Kerrosarkkitehtuurin ylimpänä kerroksena on yleensä käyttöliittymä Yleensä pidetään järkevänä, että ohjelman sovelluslogiikka on täysin erotettu käyttöliittymästä Asia tietysti riippuu myös sovelluksen luonteesta ja oletetusta käyttöajasta Sovelluslogiikan erottaminen lisää koodin määrää, joten jos kyseessä kertakäyttösovellus, ei ylimääräinen vaiva ehkä kannata (Luukkainen & Laine, 2010)" 30

31 Soveltuvat lait ja pohdiskelun aiheita 1. Vain piilossa olevaa voidaan muuttaa riskittä / no 8, Parnas 1972 Parnas jatkoi perinteisen pieni moduuli&selkeä rajapinta suunnitteluperiaatteen kehittelyä. Jako moduuleihin tulisi tehdä niin, että ne ovat pitkälti riippumattomia toisistaan. Silloin moduli olisi helpommin vaihdettavissa. Tällöin yhden moduulin toteutus ei ole riippuvainen muiden moduulien toteutuksesta. Eli, toteutus voidaan piilottaa ja sitä voidaan muuttaa, kunhan moduulin muille tarjoama palvelu säilyy samana. 31

32 Soveltuvat lait ja pohdiskelun aiheita 2. Suunnittelumallien käyttö johtaa nopeampaan ja parempaan ylläpitoon / hyp_no 4, Gamma 1995 väitetään, että suunnittelumallien käyttö (1) parantaa ohjelmoijien tuottavuutta ja ohjelman laatua, (2) parantaa noviisien taitoja (tekevät parempia ratkaisuja), (3) parantaa suunnittelijoiden kommunikointia, (4) rohkaisee hyvien suunnitteluideoiden vaihtoa ja (5) parantaa ohjelmien ylläpitoa 3. Oliosuuntautuneita ohjelmia on vaikea ylläpitää / hyp_no 16, Wilde 1993 luokan operaatioilla on yhteyksiä toisiin luokkiin. Toiminnan ymmärtäminen vaatii monien luokkien tutkimista. jo kolmitasoinen luokkahierarkia kasvattaa ylläpitoajan ja virheiden määrän suuremmaksi kuin ilman hierarkiaa 32

33 Soveltuvat lait ja pohdiskelun aiheita Conway:n laki (L16) esittää, että järjestelmän rakenne heijastaa sitä rakentavan organisaation rakennetta Mitä tämä mielestänne tarkoittaa ja löytyykö siihen esimerkkejä? Esitä kaksi sovellusesimerkkiä seuraaville arkkitehtuurityylille.» Kerrosarkkitehtuuri» Tietovuoarkkitehtuuri» Asiakas/palvelin arkkitehtuuri» Tietovarastopohjainen arkkitehtuuri Garlan et al. esittelee kolme perustekniikkaa arkkitehtonisen yhteensopimattomuuden käsittelemiselle (hoitamiselle). Mitä ne ovat ja mihin periaatteisiin ne nojautuvat? Aiheeseen liittyvää luettavaa: Garlan D., Allen R. and Ockerbloom J., Architectural Mismatch: Why Reuse Is Still So Hard, IEEE Software, vol 26, no 4, 2009, pp