Komponenttipohjainen ohjelmistotekniikka (TJTSS56) Osa 5 Kevätlukukausi 2010 Jyväskylän yliopisto Tietojenkäsittelytieteiden laitos Markku Sakkinen.

Esitys aiheesta: "Komponenttipohjainen ohjelmistotekniikka (TJTSS56) Osa 5 Kevätlukukausi 2010 Jyväskylän yliopisto Tietojenkäsittelytieteiden laitos Markku Sakkinen."— Esityksen transkriptio:

1 Komponenttipohjainen ohjelmistotekniikka (TJTSS56) Osa 5 Kevätlukukausi 2010 Jyväskylän yliopisto Tietojenkäsittelytieteiden laitos Markku Sakkinen

2 Polymorfisuus (jatkoa) Tyypit, rajapinnat ja komponentit Szyperski, kohta 6.5 Rakenteellinen (implisiittinen) alityypitys on vaarallinen komponenttien rajapintoihin sovellettuna. Tyypin ”rakenne” on vain osa sopimusta. Nimettyyn rajapintaan liittyy koko sopimus. Komponentin ohjelmoijan on viitattava nimettyyn rajapintaan ja vastattava sopimuksen toteuttamisesta. Kuinka todennäköisesti rakenteellinen alityypitys voi aiheuttaa vahingossa täysin vääriä alityyppisuhteita? Perinteinen esimerkki: jossakin grafiikkaohjelmistossa voisi olla rajapinta, joka sisältää vain metodit ”move” ja ”draw”. Cowboy-luokassa voi olla nämä metodit, mutta ”draw” tarkoittaa ihan muuta. Vahinko ei ole todennäköinen isoille luokille, joissa on monia metodeja. Luokkahierarkioiden juuriluokat (tai –rajapinnat) ovat kuitenkin usein hyvin yksinkertaisia. Ääritapauksissa sellaisessa ei ole yhtään metodia. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 22. 2. 2010 2

3 Tyypit, rajapinnat ja komponentit (jatkoa) Javassa (ja C#:ssa) luokka voi toteuttaa useitakin rajapintoja ja rajapinta periä useita toisia rajapintoja. Luokan ei tarvitse toteuttaa yhtään rajapintaa. Komponenteille on luonnollista toteuttaa yksi tai useita rajapintoja. Lähes jokaisen komponentin tarvitsee toteuttaa ainakin yksi. Varsin usein johonkin tarkoitukseen tarvitaan komponentti, joka toteuttaa tietyn joukon rajapintoja. Tällaista vaaditaan esim. kaikilta ActiveX-käyttöliittymäolioilta. Olisi hyvä voida nimetä tällaisia joukkoja, jotta ei aina tarvitse tutkia jokaista rajapintaa erikseen. COMissa tämä mahdollisuus on: kategoriat. Sama rajapinta voi kuulua useaankin kategoriaan. Javassa sama voidaan saada aikaan määrittelemällä haluttujen rajapintojen yhteinen alirajapinta. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 22. 2. 2010 3

4 Riippumattoman laajennettavuuden paradigma Szyperski, kohta 6.6 Määritelmä: Järjestelmä on riippumattomasti laajennettava (independently extensible), jos se on laajennettava ja toisistaan riippumatta kehitettyjä laajennoksia voidaan yhdistää. Esimerkiksi kaikki käyttöjärjestelmät yhdellä tasolla: eri sovelluksia voidaan ladata yhtä aikaa. Nykyään hyvin monet sovellukset ovat laajennettavissa liitännäisillä eli lisäosilla (plugins). Joissakin liitännäisissä on mahdollisuus toisen tason liitännäisiin. Riippumatonta laajennettavuutta on pyritty harrastamaan monitasoisena, rekursiivisena ohjelmistoarkkitehtuurina. Mikroytimeen (microkernel) perustuvat käyttöjärjestelmät. Parantaa järjestelmän sisäistä turvallisuutta (laitetason suojaukset komponenttien välillä). Suorituskyky kärsii, jos periaate viedään liian pitkälle. Kontekstin vaihto on hyvin hidas ja raskas toiminto suoraan kutsuun verrattuna. Mahdollisimman suuren osan vuorovaikutuksista pitäisi olla komponenttien sisäisiä. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 23. 2. 2010 4

5 Turvallisuudesta (safety) Szyperski, kohdat 6.7 – 6.8 Java on (tyyppi)turvallinen kieli. Yhtenä perustavoitteena oli tehdä tuntemattomienkin sovelmien suorittaminen vaarattomaksi. Mahdollisimman perusteelliset tarkistukset tehdään käännösvaiheessa. Muualta saadut luokkatiedostot tarkistetaan vielä ladattaessa. Jotkin tarkistukset (esim. taulukon indeksirajat) tehdään suoritusaikana. Automaattinen muistinhallinta ja siivous (garbage collection). Component Pascal Sekin käännetään välikieleksi, joka voidaan tarkistaa. Ei käytä tulkkia eikä virtuaalikonetta, vaan komponentit käännetään välikielestä binaarikoodiksi (myöhäinen käännös)..NET-ympäristön CLR (Common Language Runtime) Yhteinen, turvallinen välikieli monille ohjelmointikielille. Ei virtuaalikonetta vaan myöhäinen käännös. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 24. 2. 2010 5

6 Turvallisuudesta (jatkoa) Moduuliturvallisuus (module safety) (Szyperski) Ohjelma tai komponentti ei saa käyttää kaikkia mahdollisia palveluja, jotka ovat tarjolla tai ladattavissa. Komponentin on kerrottava, mitä palveluja ja muita komponentteja se haluaa käyttää: tuontilista (import list). Komponenttia käyttöön otettaessa tarkistetaan, ovatko kaikki tuotavat palvelut sallittuja. Kielissä, joissa ei ole erillistä moduulirakennetta, tarkistukset ovat luokkakohtaisia. Moduuleissa voidaan toteuttaa myös useiden luokkien välisiä rajoitteita. Toteutettu sekä Javassa, Component Pascalissa että CLR:ssä. Reflektio on komponenttiohjelmistossa hyödyllinen väline toisten komponenttien löytämiseen suoritusaikana (nimen perusteella). On kuitenkin varottava turvallisuusaukkoja. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 24. 2. 2010 6

7 Turvallisuudesta (jatkoa) Javan turvanhallitsin (?) (security manager) Kutsutaan jokaisen kriittisen operaation alussa. Tutkii kutsupinosta, ovatko sekä operaation suora että kaikki epäsuorat kutsuja oikeutettuja käyttämään operaatiota. Huolimattomasti suunniteltu luotettu palvelu, joka toteuttaa asynkronisesti kutsuja asiakkaidensa puolesta, voi ohittaa tämän suojauksen. Vaikka komponentilla on oikeus käyttää jotakin moduulia, se ei saa päästä käsiksi tämän yksityisiin osiin. Tavallisessa ohjelmoinnissa turvalliset kielet takaavat tämän. Metaohjelmointi voi ohittaa rajoitukset. Tyypilliset metaohjelmoinnin käyttötarkoitukset (esim. virheenetsintä ja olioiden sarjallistaminen) tarvitsevat tällaisia mahdollisuuksia. Järjestelmässä voidaan tarjota erikseen moduuliturvallinen metaohjelmointirajapinta yleiseen käyttöön ja rajoittamaton rajapinta luotetuille komponenteille. CLR:ssä on hyvin monipuolisia ja mielenkiintoisia mahdollisuuksia. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 24. 2. 2010 7

8 Turvallisuudesta (jatkoa) Monikieliset järjestelmät Erikielisten komponenttien väliset rajapinnat määritellään usein jollakin rajapinnanmäärittelykielellä (interface definition language, IDL). Koko järjestelmän turvallisuuden taso on sama kuin heikoimman kielen (joka voi olla myös IDL). Joissakin kielissä (esim. C#:ssa) voidaan määritellä metodeja turvattomiksi, ja vain tällaisissa metodeissa voidaan käyttää kielen turvattomia erikoismahdollisuuksia. CLR ei hyväksy turvattomia metodeja sisältäviä komponentteja, ellei niitä pidetä luotettavina. Riittävätkö edellä mainitut turvallisuustekijät? Yhdessä työasemassa toimivalle ohjelmistolle luultavasti. Järjestelmälle, jossa komponentteja ladataan Internetistä, ehkä juuri ja juuri. Hyvin vahvaa turvallisuutta tarvitseville järjestelmille eivät missään tapauksessa. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 24. 2. 2010 8

9 Turvallisuudesta (jatkoa) Mitä ongelmia sitten on? Ohjelmointikielen semantiikan täytyy olla täysin turvallinen. Se pitäisi määritellä formaalisti ja sen turvallisuusominaisuudet todistaa formaalisti. Käytetty formaali menetelmä itse sekä todistamiseen käytetyt puoliautomaattiset työkalut pitäisi todistaa kelvollisiksi. Vain hyvin harvojen ohjelmointikielten semantiikka on määritelty formaalisti. Ei yhdenkään yleisesti käytetyn oliokielen. Javan joitakin yksinkertaistuksia (mm. Featherweight Java) on määritelty formaalisti, ja niiden turvallisuus- ym. ominaisuuksia on todistettu. Sitten pitäisi vielä todistaa käytetty kielen toteutus oikeaksi ja turvalliseksi. Kääntäjä, latain, tulkki, virtuaalikone, ajonaikaiset kirjastot, … Sitten käyttöjärjestelmä, sitten laitteisto. Mahdoton, rekursiivinen urakka. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 1. 3. 2010 9

10 Turvallisuudesta (jatkoa) Luottamuksen syntyminen on suureksi osaksi sosiologinen prosessi. Esim. Unixin turvallisuusmekanismien yksityiskohdat julkaistiin, ja ihmisiä kannustettiin etsimään niistä aukkoja. Javan turvallisuusperiaatteet julkistettiin samalla tavoin. Samoin DES (Data Encryption Standard) ja jotkin muut salausmenetelmät ja - algoritmit. Havaittujen ongelmien julkistaminen ja niiden nopea korjaaminen lisäävät vähitellen luottamusta. Päinvastaistakin strategiaa, ”security by obfuscation”, on kokeiltu yritysten omisteisissa (proprietary) ohjelmistoissa, mutta se ei ole tehokas ainakaan ajan mittaan. Komponenttipohjainen ohjelmistotekniikka (Markku Sakkinen) – Osa 5 1. 3. 2010 10