Luento 6 Kertaus Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu arkkitehtuurigenret, tyylit ja mallit Kerrosarkkitehtuuri 1
Kertausta <<includes>> <<includes>> <<includes>> <<includes>> <<includes>> <<includes>> <<includes>> 2
Soveltuvat lait ja pohdiskelun aiheita Vain piilossa olevaa voidaan muuttaa riskittä / no 8, Parnas 1972 Suunnittelumallien käyttö johtaa nopeampaan ja parempaan ylläpitoon / hyp_no 4, Gamma 1995 Oliosuuntautuneita ohjelmia on vaikea ylläpitää / hyp_no 16, Wilde 1993 3
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
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
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 / ISO/IEC 25010:2011 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, coexistence, replaceability 6
FURPS+ Design constraints I/O devices or DBMS constrain how the software must be built? Implementation requirements Programming standards need to be used? Test driven development (TDD) required? Is statistically sound testing (Cleanroom) required? Interface requirements What I/O interfaces must be created? What other systems must this one interface with? How frequently this happens? Physical requirements Different hardware the system will be deployed? Size, environmental requirements? 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 kokonaiskustannukset modulien määrä integrointikustannukset kustannukset/ moduuli 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 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 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 http://www.informit.com/articles/article.aspx?p=1400866 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 12
Analyysitasosta suunnittelutasolle Pohjapiirros tyyppi ulkomitat lisääkamera() lisääseinä() lisääikkuna() tuhoaelementti() pirrä() 1 * Kamera tyyppi kameraid paikka valittuzoom * Elementti alkukoordinaatti loppukoordinaatti poimityyppi() piirrä() SeinäElementti Ikkuna 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ö 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 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 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) PC Control Panel Tunnistin Security Security External Access Tunnistin Surveillance Comp. Server Tunnistin Homeowner Access Home Management Communication 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 2005 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 2000 19
Arkkitehtuurityylit putket prosessointiyksikkö prosessointiyksikkö sovellusohjelma sovellusohjelma prosessointiyksikkö prosessointiyksikkö prosessointiyksikkö tietovarasto sovellusohjelma prosessointiyksikkö prosessointiyksikkö prosessointiyksikkö sovellusohjelma sovellusohjelma prosessointiyksikkö Tietovarastopohjainen arkkitehtuuri Tietovuoarkkitehtuuri Pipes & Filters 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 Olioperustainen arkkitehtuuri Pääohjelma/aliohjelma arkkitehtuuri 21
Arkkitehtuurityylit Selain Selain HTML JavaScript CSS Sovelluspalvelin Sovellusohjelmat (Java, C++,...) Tietokantapalvelin Tietokantakyselyt (SQL,...) Palveluun rekisteröityminen Selain etsi julkaise Kerrosarkkitehtuuri Palvelua pyytävä sido Palvelun tuottaminen Asiakas-palvelin arkkitehtuuri (client-server) Palvelukeskeinen arkkitehtuuri (SOA) Palvelu 22
Kerrosarkkitehtuuri Kerros- eli tasoarkkitehtuuri OSI -mallissa 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) 24
Lisää kerrosarkkitehtuureista Myös kerrosten sisällä ohjelman loogisesti toisiinsa liittyvät komponentit kannattaa ryhmitellä omiksi kokonaisuuksiksi joka voidaan UML:ssa kuvata pakkauksena (package) 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 25
Pakkausnotaatioita (Pohjalainen P., 2009) 26
Kerrosten väliset 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 riippuvuudet (Pohjalainen P., 2009) 27
(Pohjalainen P., 2009) 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) 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) 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ä Siirrettävyys (esim. mobiilisovellukset) 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) 31
Soveltuvat lait ja pohdiskelun aiheita 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 (rajapinta) säilyy samana. 32
Soveltuvat lait ja pohdiskelun aiheita 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 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 33