Luku 9: Arkkitehtuurisuunnittelu. Luku 10: Komponenttitason suunnittelu. arkkitehtuurigenret, tyylit ja mallit Kerrosarkkitehtuuri

Transkriptio

1 Ohjelmistotekniikka: Luento 5 Jouni Lappalainen Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu arkkitehtuurigenret, tyylit ja mallit Kerrosarkkitehtuuri Luku 10: Komponenttitason suunnittelu komponentin määrittely luokkapohjaisten komponenttien suunnittelu 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 Näkökulmia arkkitehtuuriin / 4+1 malli (Kruchten, 1995) + 1 (Koskimies, Mikkonen 2005) Looginen näkymä Skenaarionäkymä (Scenario view) kuvaa, kuinka järjestelmä on vuorovaikutuksessa sen ulkopuolella olevien käyttäjien ja muiden järjestelmien kanssa tietyssä käyttöskenaariossa Looginen näkymä (Logical view) kuvaa, miten toiminnallisuus on jaettu järjestelmän eri osien kesken ja mitä velvollisuuksia kullakin komponentilla on -> miten skenaarionäkymän esittämä toiminnallisuus saadaan aikaan Prosessinäkymä (Process view) Kehitysnäkymä Prosessinäkymä Skenaarionäkymä kuvaa, miten järjestelmän toiminta on jaettu loogisiin prosesseihin ja miten prosessit kommunikoivat voidaan arvioida järjestelmän suorituskykyä ja skaalautuvuutta Fyysinen näkymä 19

20 Näkökulmia arkkitehtuuriin / 4+1 malli (Kruchten, 1995) + 1 (Koskimies, Mikkonen 2005) Kehitysnäkymä (Development view) kuvaa, miten järjestelmä on jaettu osiin, jotka voidaan toteuttaa erillisinä yksikköinä olennainen suurten ohjelmistojen tapauksessa Fyysinen näkymä (Physical view) Looginen näkymä Kehitysnäkymä Prosessinäkymä Skenaarionäkymä kuvaa, millaisista fyysisistä prosessointiyksiköistä järjestelmä koostuu, miten nämä ovat yhteydessä toisiinsa ja mitä fyysisiä ohjelmistoartifakteja (esim. komponentteja, tietokantoja) kuhunkin prosessointiyksikköön sijoitetaan Muuntelunäkymä (Variability view) kuvaa, millaista muuntelua järjestelmä tukee kuvaa järjestelmän variaatiopisteet (joissa muuntelu tapahtuu), niiden edellyttämät vaatimukset muunnelmille ja niiden käytön muunnelmien toteuttamiseksi (laajennusrajapinta) olennainen tuoterunkojen tapauksessa Fyysinen näkymä 20

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

22 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 22

23 Arkkitehtuurityylit Selain Selain HTML JavaScript Visual Basic Sovellus- palvelin Sovellus- ohjelmat (Java, C++,...) Tietokanta- palvelin Tietokanta- kyselyt (SQL,...) Palveluun rekisteröityminen Selain Kerrosarkkitehtuuri Asiakas-palvelin arkkitehtuuri (client-server) etsi Palvelua pyytävä sido julkaise Palvelun tuottaminen Palvelukeskeinen arkkitehtuuri (SOA) Palvelu 23

24 Kerrosarkkitehtuuri Selain Selain Selain HTML JavaScript Visual Basic Sovellus- palvelin Sovellus- ohjelmat (Java, C++,...) Tietokanta- palvelin Tietokanta- kyselyt (SQL,...) 24

25 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)" 25

26 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 26

27 Pakkausnotaatioita (Pohjalainen P., 2009)" 27

28 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)" 28

29 (Pohjalainen P., 2009)" 29

30 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)" 30

31 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)" 31

32 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)" 32

33 Arkkitehtuurin arviointi ATAM (An Architecture Trade-Off Analysis Model) koostuu neljästä osiosta esittely, analyysi, testaus ja raportointi Analyysivaiheessa tunnistetaan olennaiset arkkitehtuuriratkaisut, jotka tukevat tiettyjä laatuominaisuuksia laaditaan laatupuu ja liitetään laatuominaisuuksiin skenaarioita ja arvioidaan niiden tärkeys onnistumisen kannalta ja kuinka vaikea skenaario on toteuttaa (riski) tärkeimpiin skenaarioihin liitetään niitä tukevat arkkitehtuuriratkaisut tunnistetaan riskit, turvalliset ratkaisut, herkkyyskohdat (kriittinen jonkin laatuominaisuuden kannalta) ja tasapainokohdat (vaikuttaa useampaan laatuominaisuuteen, +/-) Koskimies & Mikkonen: Ohjelmistoarkkitehtuurit 33

34 tärkeys H vaikeus M Laatupuu 34

35 ATAM analyysin käsitteet /Kazman et al

36 Mikä on komponentti? OMG Unified Modeling Language Specification [OMG01] määrittelee komponentin a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. oliopuolella: komponentti koostuu joukosta yhteistyössä toimivia luokkia perinteisesti: ohjelmiston osa, joka sisältää toimintalogiikan kuvauksen, sen tarvitsemat sisäiset tietorakenteet ja rajapinnan, jonka kautta se voidaan käynnistää ja jonka kautta tietoa siirretään yleisesti: itsenäinen ohjelmayksikkö, joka tarjoaa palveluja rajapinnan kautta 36

37 Komponentit ovat ohjelmistoarkkitehtuurissa käsiteltäviä pienimpiä yksiköitä: raja arkkitehtuurisuunnittelun ja yksityiskohtaisen suunnittelun välillä. Suuri komponentti voi kuitenkin koostua useista pienemmistä komponenteista, jolloin komponentilla on oma sisäinen arkkitehtuurinsa esim. Eclipsen kaltainen ohjelmointiympäristö ja siihen integroidut työkalut Komponentin sisäisen rakenteen ei pitäisi näkyä ulospäin eikä toiminnan riippua käyttöympäristöstä (muuten kuin vaadittujen rajapintojen kautta) 37

38 Komponentti muodostaa toiminnallisen kokonaisuuden, joka tarjoaa joukon loogisesti toisiinsa liittyviä palveluja palvelut käyttävät samoja tietorakenteita palveluja käytetään tyypillisesti samassa yhteydessä Toiminnallisuus on peruste komponentin olemassaololle. Komponenteilla hallitaan järjestelmän muunneltavuutta: eristetään järjestelmän osat, jotka halutaan helposti päivitettäviksi Komponenttityyppejä: esim. plugin-komponentit ja COTS (Commercial Off-The-Shelf )-komponentit 38

39 Komponentti on työnjaon perusyksikkö kaikissa kehitystyön vaiheissa esim. suunnittelu, toteutus, testaus, konfiguraation hallinta, ylläpito Yksi komponentti yhden henkilön vastuulle. Työryhmä kehittää toisiinsa liittyviä komponentteja (esim. tiettyä alijärjestelmää). Järjestelmää kehittävän organisaation rakenne alkaa muistuttaa järjestelmän rakennetta (tai päinvastoin: vrt. Conway:n laki) 39

40 Komponentin ominaispiirteet Riippuvuudet komponentti voi riippua palveluista, joita se olettaa saavansa muilta komponenteilta vaadittujen rajapintojen kautta Käyttöönotto komponentti voidaan ottaa käyttöön lähdekoodisena (käännösaikana) tai käännettynä binäärimuodossa (linkkausaikana) Koko komponentin tulisi olla yhden henkilön hallittavissa Standardointi esimerkkinä Sunin EJB-komponenttistandardi» Koskimies, Mikkonen

41 Komponenttien välinen vuorovaikutus Rajapinta kertoo, miten palvelu otetaan käyttöön palvelun nimi, parametrit ja niiden tyypit ja mahdollisen tuloksen tyyppi = kutsumuoto (signature) palvelun merkitys kuvataan tulo- ja jättöehtojen (pre/post condition) avulla» Koskimies, Mikkonen 2005 PowerSource tarjottu rajapinta Car PowerSource Car vaadittu rajapinta Engine PowerSource Engine 41

42 Esimerkki komponenttimallista: osa yliopistojärjestelmästä UML Superstructure Specification, v2.4 42

43 Komponentin räätälöinti Komponentin uudelleenkäytettävyys edellyttää komponentin soveltumista erilaisiin yhteyksiin. Komponentin voitava muunnella tarjoamaansa palvelua tarpeen mukaan. Komponentin suunnittelussa huomioitava varianssin hallinta (samaan tapaan kuin tuoterungoissa tai sovelluskehyksissä). 43

44 Komponentin räätälöinti periytymisen avulla Määritellään halutut operaatiot aliluokassa uudelleen dynaamisen sidonnan ansiosta suoritusaikana tulee kutsutuksi olion dynaamisen tyypin mukainen operaatio Huono puoli: periytyminen rikkoo kapseloinnin -> semanttinen särkyvän yliluokan ongelma (semantic fragile base class problem) 44

45 Särkyvän yliluokan ongelma Kirjastokomponentti Comp Räätälöity komponentti Custom Muutos alkuperäiseen komponenttiin voi tehdä räätälöidystä komponentista toimimattoman 45

46 Luokkapohjaisten komponenttien suunnittelu (oliosuunnittelun periaatteet) The Open-Closed Principle (OCP). A module [component] should be open for extension but closed for modification. muutokset eivät saa aiheuttaa muutoksia useisiin paikkoihin esim. abstrakteihin rajapintoihin perustuvissa malleissa uuden rajapinnan toteuttavan aliluokan lisääminen ei saisi aiheuttaa muutoksia mallin muissa luokissa <<interface>> Sensor read() enable() disable() test() Window sensor Smoke sensor Motion detector Detector Heat sensor CO2 sensor 46

47 The Liskov Substitution Principle (LSP). Subclasses should be substitutable for their base classes. Ohjelman toiminta säilyy samana, jos luokan T toiminnallisuus korvataan luokalla S, joka on T:n aliluokka Lapsiluokan tulee olla sijoitettavissa kantaluokkiensa tilalle. Ongelma on, että tätä periaatetta ei voi varmistaa tarkastelemalla vain luokkaa itseään, vaan pitää myös tietää miten sitä käytetään. Kuvan vasemmassa osassa oleva rakenne ei noudata korvausperiaatetta, koska lainatililtä ei voi veloittaa. Tilanne on ratkaistu määrittelemällä tileille uusi, yhteinen yliluokka, jonka rajapintaa on rajoitettu (veloitusmetodi poistettu), josta lainatili ja shekkitili on peritty. ChequeAccount accountname balance credit() debit() MortgageAccount interestrate calculateinterest() - debit() Restructuring to satisfy LSP MortgageAccount interestrate calculateinterest() Account accountname balance credit() ChequeAccount debit() 47

48 Oliosuunnittelun periaatteet Dependency Inversion Principle (DIP). Depend on abstractions. Do not depend on concretions. Korkeamman tason modulit eivät saa riippua alemman tason moduleista. Molempien tulisi riippua abstraktioista. Abstraktioiden ei tulisi riippua yksityiskohdista, vaan päinvastoin. The Interface Segregation Principle (ISP). Many client-specific interfaces are better than one general purpose interface. Lihava palvelinrajapinta tulisi erottaa erillisiksi asiakaskohtaisiksi rajapinnoiksi. Rajapinta kuuluu asiakkaalle, eikä palvelimelle. Source: Martin, R., Design Principles and Design Patterns, downloaded from

49 Oliosuunnittelun periaatteet The Release Reuse Equivalency Principle (REP). The granule of reuse is the granule of release. Paketoinnissa käytetään samaa rakeisuutta kuin uudelleenkäytettävyydessä. The Common Closure Principle (CCP). Classes that change together belong together. Luokat joihin kohdistuu samanlaisia muutospaineita kuuluvat yhteen (laitetaan samaan pakettiin). The Common Reuse Principle (CRP). Classes that aren t reused together should not be grouped together. Jos luokkia ei ole uudelleenkäytetty yhdessä, ei niitä myöskään pitäisi käsitellä yhtenä ryhmänä (laittaa samaan pakettiin). Source: Martin, R., Design Principles and Design Patterns, downloaded from

50 Koheesio Perinteisesti: yhden tarkoituksen moduuli OO näkökulma: koheesio tarkoittaa, että komponentti tai luokka kapseloi vain sellaiset attribuutit ja operaatiot, jotka liittyvät läheisesti toisiinsa ja itse luokkaan tai komponenttiin Koheesion tasot (lueteltu koheesion korkeusjärjestyksessä) Toiminnallinen Peräkkäinen toisen osan tuloste on toisen osa syöte Kommunikationaalinen saman datan käsittelyyn liittyvät operaatiot samassa luokassa Proseduraalinen tarkastetaan lupa käyttää tiedostoa ja sitten avataan se Ajallinen virheen sattuessa tietyt operaatiot suoritetaan (suljetaan avoimet tiedostot, kirjataan virhelokiin ja ilmoitetaan käyttäjälle) Looginen samankaltaiseen tehtävään liittyvät, esim I/O käsittelyyn Satunnainen 50

51 Kytkentä Perinteisesti: kytkennän aste komponenttien välillä pyritään alhaiseen kytkentään OO näkökulma: kytkennän aste luokkien välillä Kytkennän tasot (korkeasta matalaan) Sisältökytkentä (haetaan toisen moduulin paikallista dataa) Yleinen kytkentä (globaalin muuttujan käyttö) Ulkoinen kytkentä (kaksi moduulia jakavat ulkopuolisen määrittelemän tietoformaatin, protokollan tai laiterajapinnan) Ohjauskytkentä (operaation A herättää operaation B) Leimakytkentä (moduulit jakavat tietorakennekoosteen ja käyttävät vain osaa siitä) Datakytkentä (tietoa siirretään argumenttien avulla) Viestikytkentä (moduulit eivät ole riippuvia toisistaan, käyttävät julkista rajapintaa viestien vaihdolle) 51

52 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. 52

53 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 53

54 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