Ohjelmistoarkkitehtuurien ylläpito Arkkitehtuurityylejä ja laatuvaatimuksia Arkkitehtuurin uudistaminen Arkkitehtuurin uudistamisen malleja Arkkitehtuurin arviointi TTY Ohjelmistotekniikka 1 Ohjelmistoarkkitehtuuri Sisältää järjestelmän komponentit, niiden suhteet toisiinsa ja ympäristöönsä TTY Ohjelmistotekniikka 2 1
Arkkitehtuurityylejä Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluperustaiset arkkitehtuurit Viestinvälitysarkkitehtuurit MVC (model view controller) TTY Ohjelmistotekniikka 3 Kerrosarkkitehtuurit Järjestelmä on organisoitu käsitetasoltaan nouseviin kerroksiin Käyttöliittymä Sovelluskohtainen logiikka Sovellusaluekohtainen logiikka Tietokanta TTY Ohjelmistotekniikka 4 2
Tietovuoarkkitehtuurit Komponentit (filter) tuottavat ja kuluttavat tietoalkioita Väylät (pipe) kuljettavat tietoalkioita komponentilta toiselle Leksikaalianalyysi Syntaksianalyysi Semanttinen analyysi Välikoodin generointi Koodin optimointi Koodin generointi TTY Ohjelmistotekniikka 5 Palveluperustaiset arkkitehtuurit Palvelin kontrolloi jotakin resurssia ja tarjoaa siihen liittyviä palveluita Asiakkaat tarvitsevat kyseistä palvelua Palvelun pyytäjä Palvelun tarjoaja Palvelun pyytäjä TTY Ohjelmistotekniikka 6 3
Viestinvälitysarkkitehtuurit Useita keskenään kommunikoivia komponentteja Komponenttien lukumäärää tai niiden palveluita ei tiedetä etukäteen Asiakas palvelupyyntö Palvelija Asiakas palvelun tulos Viestinvälittäjä Palvelija Asiakas Palvelija TTY Ohjelmistotekniikka 7 MVC Käyttöliittymän erottaminen sovelluslogiikasta Erilaisia näkymiä sovelluksen tilasta tilan muutokset heijastuvat käyttöliittymään komento vaste Ohjain (controller) sovelluksen toiminto Malli (model) Näkymä (view) sovelluksen tilan muutos TTY Ohjelmistotekniikka 8 4
Muutettavuus Laatuvaatimuksia Suorituskyky Muutettavuus [prosessi] Muutettavuus [data] Suorituskyky [muisti] Suorituskyky [aika] Uudelleenkäytettävyys TTY Ohjelmistotekniikka 9 Arkkitehtuurityylit vs. laatuvaatimukset Kerros Tietovuo Palveluperustainen Viestinvälitys MVC Muutettavuus [prosessi] + + + + + Muutettavuus [data] ++ - - ++ + Suorituskyky [muisti] -- ++ Suorituskyky [aika] - - - Uudelleenkäytettävyys + + - + + TTY Ohjelmistotekniikka 10 5
Arkkitehtuurin uudistamisen vaiheet 1. Arkkitehtuurin tunnistaminen 2. Arkkitehtuurin muuttaminen 3. Uuteen arkkitehtuuriin perustuva ohjelmiston kehittäminen vrt. takaisinmallinnuksen kautta tapahtuva uudistaminen TTY Ohjelmistotekniikka 11 Arkkitehtuurin uudistaminen T u n n i s t a m i n e n Toiminnallinen taso Arkkitehtuurin muuttaminen Koodaustyylit Kooditaso Vanha lähdekoodi Suunnittelumallit ja -tyylit Ohjelman toiminnalliset suunnitelmat Arkkitehtuuritaso Uusi lähdekoodi K e h i t t ä m i n e n TTY Ohjelmistotekniikka 12 6
Kooditason muutokset (1) 1. taso Tekstuaaliset muutokset merkkijonojen sovittaminen ja korvaaminen esim. Y2K nimien ja tunnusten muuttaminen esim. järjestelmän siirtäminen uuteen ympäristöön muutokset yksinkertaisia, suoraviivaisia ja halpoja Jäsennyspuuhun kohdistuvat muutokset muutokset eivät riipu yksityiskohtaisesta syntaksista esim. uuteen ohjelmointikieleen siirtyminen automaattiset koodimuunnokset esim. Y2K TTY Ohjelmistotekniikka 13 Kooditason muutokset (2) 1. taso Sopivat seuraaviin tilanteisiin: muutokset t rajoittuvat t yksittäisiin ii koodikohtiin rakenteelliset tai toiminnalliset muutokset eivät ole tarpeellisia lähdekoodi on pääasiallisin tai ainoa saatavilla oleva tietolähde käytettävissä olevat resurssit rajoittavat uudistamista rakenteellisten (isompien) muutosten aiheuttama riski on suurempi kuin niiden tuoma hyöty Olennaisia i asioita it (vaatimuksia): i käytettävissä olevat työkalut tekstin ja jäsennyspuun käsittelyyn ohjelmoijien saatavuus lähdekoodin hallinta TTY Ohjelmistotekniikka 14 7
Toiminnallisen tason muutokset (1) Muutokset ohjelman osien välisissä suhteissa esim. funktioiden kutsusuhteet esim. koodin ja datan väliset suhteet esim. tiedostojen väliset suhteet (uudet ryhmittelyt) Muutosten toteuttaminen toiminnallisuuden kapselointi (kääriminen) erilaista ympäristöä varten esim. siirtyminen proseduraalisista ohjelmista oliokeskeisiin toiminnallisuuden pelastaminen (salvage) uuteen ympäristöön uudelleenkäyttö 2. taso TTY Ohjelmistotekniikka 15 Toiminnallisen tason muutokset (2) Sopivat seuraaviin tilanteisiin: rakenteelliset muutokset ovat välttämättömiä ohjelman osien ja niiden välisten yhteyksien rakenne on hyvin dokumentoitu tai se voidaan jäljittää käytettävissä olevat resurssit rajoittavat vain jonkin verran uudistamista rakenteellisten muutosten aiheuttamat riskit ovat keskinkertaisia Olennaisia asioita (vaatimuksia): käytettävissä olevat työkalut moduulien ja rajapintojen tunnistamiseen järjestelmän asiantuntijoiden ja ohjelmoijien saatavuus uudelleenkäytettävien osien tunnistaminen ja kapselointi 2. taso TTY Ohjelmistotekniikka 16 8
Arkkitehtuuritason muutokset (1) 3. taso Arkkitehtuurin elementtien muuttaminen esim. komponenttien tyypin ja rakenteen muuttaminen esim. komponenttien välisten suhteiden (connector) muuttaminen esim. järjestelmän ajoaikaisten mallien muuttaminen Suurten muutosten tai puutteiden vaatima rakenteellinen muutos Vaatii paljon resursseja, mutta tuo suurimmat hyödyt TTY Ohjelmistotekniikka 17 Arkkitehtuuritason muutokset (2) Sopivat seuraaviin tilanteisiin: pyrkimykset k tuotteen tt parantamiseen ovat korkeat k järjestelmän arkkitehtuuri on hyvin dokumentoitu käytettävissä olevat resurssit eivät suuresti rajoita uudistamista järjestelmän ylläpidon jatkaminen aiheuttaa suuremman riskin kuin järjestelmän kehittäminen Olennaisia asioita (vaatimuksia): käytettävissä olevat työkalut arkkitehtuurin tunnistamiseen järjestelmän rakentajien, asiantuntijoiden ja ohjelmoijien saatavuus arkkitehtuuriin perustuva kehittäminen tuoterunkoarkkitehtuurin tunnistaminen 3. taso TTY Ohjelmistotekniikka 18 9
Arkkitehtuurin ominaisuuksia 1. vaihe Sovellusalueesta riippumattomat ominaisuudet tiedon siirto (parametrivälitys, globaalit muuttujat) järjestelmän kontrolli (aktiivinen, passiivinen) dynaaminen käyttäytyminen (prosessit, samanaikaisuus) järjestelmän rakenne (kerroksittainen, tietovirtaan perustuva) Sovelluskohtaiset ominaisuudet varmistus (kaksinkertaiset tiedot, tarkistussummat) turvallisuus (kryptaus, digitaaliset it t allekirjoitukset) it k t) Tuoteperheeseen liittyvät ominaisuudet varianssi (standardit, käyttäjien tarpeet) arkkitehtuurityyli TTY Ohjelmistotekniikka 19 Arkkitehtuurin muuttaminen Suunniteltu (käsitteellinen) arkkitehtuuri Toteutettu (konkreettinen) arkkitehtuuri Etenevä muuttaminen konkreettinen arkkitehtuuri muutetaan vastaamaan käsitteellistä arkkitehtuuria Peruuttava muuttaminen käsitteellinen arkkitehtuuri muutetaan vastaamaan konkreettista arkkitehtuuria 2. vaihe TTY Ohjelmistotekniikka 20 10
Arkkitehtuuriperustainen ohjelmistokehitys 3. vaihe Tarvittavien komponenttien toteuttaminen Arkkitehtuurityylin huomioon ottaminen Uudistaminen voi ulottua monelle tasolle: arkkitehtuuritasolla komponentit ja niiden suhteet muuttuvat toiminnallisella tasolla olemassa olevaa koodia voidaan kääriä kooditasolla ohjelmointikielet ja ympäristöt (alustat) voivat muuttua TTY Ohjelmistotekniikka 21 Esimerkki (1/2) Alkutilanne: Kulukorvaukset Henkilöstö Tilit Palkanmaksu Hankintakulut Asiakaslaskutus Varasto Hankinnat TTY Ohjelmistotekniikka 22 11
Tavoite: Esimerkki (2/2) Kulukorvaukset Palkanmaksu Henkilöstö Tilit Hankinnat Hankintakulut k t Asiakaslaskutus Varasto TTY Ohjelmistotekniikka 23 Arkkitehtuurin uudistamisen ongelmatilanteita? Arkkitehtuurin uudistamisen malleja Mikä on riittävä joukko arkkitehtuurinäkymiä? Miten voidaan säilyttää yhteys suunnitellun ja toteutetun arkkitehtuurin välillä? Miten arkkitehtuurin elementit vaikuttavat laatutekijöihin ja millaisia vaikutuksia laatutekijän muuttumisella on? Miten tunnistetaan yhteiset ja vaihtelevat osat (toisiaan muistuttavissa järjestelmissä)? Miten arkkitehtuurin uudistamisessa voidaan hyödyntää valmiita komponentteja? TTY Ohjelmistotekniikka 24 12
Arkkitehtuurinäkymät Kuvaus: arkkitehtuurin uudelleendokumentointiin kuuluu näkymien ja niiden suhteiden tunnistaminen Ongelma: mikä on riittävä määrä näkymiä Ratkaisu: arkkitehtuurinäkymien luettelo näkymät eri rooleissa olevien kannalta (kehittäjä, arkkitehti, projektin johtaja, ylläpitäjä, testaaja) sopivan notaation käyttö näkymät ovat erilaisia eri tyyppisille järjestelmille esim. oliokeskeiset tai proseduraaliset järjestelmät esim. räätälöidyt tai tuoterunkoarkkitehtuuriin perustuvat TTY Ohjelmistotekniikka 25 Suunniteltu vs. toteutettu arkkitehtuuri Kuvaus: arkkitehtuurityyleille ei ole vastaavia käsitteitä ohjelmointikielissä laatuvaatimusten huomioiminen voi rikkoa arkkitehtuuria Ongelma: miten arkkitehtuurin suunnittelusta voidaan päätellä sen toteutus (ja päinvastoin) Ratkaisu: toteutustyökalun pitäisi pakottaa arkkitehtuurin toteutuksen noudattamaan suunnittelua järjestelmän perustuminen hyvin määriteltyihin komponentteihin TTY Ohjelmistotekniikka 26 13
Laatutekijän sijainti Kuvaus: suunnitteluratkaisut on valittu sen perusteella, mitä laatuvaatimuksia ti i järjestelmän j ä tulee täyttäättää eri laatuvaatimukset voivat olla ristiriitaisia toistensa kanssa Ongelma: miten voidaan päätellä arkkitehtuurielementtien ja laatuvaatimusten suhde Esimerkki: web-pohjaiseen ympäristöön siirtyminen tehokkuus, varmuus (security) Ratkaisu: työkalu tai menetelmä, joka auttaa selvittämään, miten järjestelmä tukee jotakin tiettyä laatutekijää selvitetään, mikä arkkitehtuurityyli tukee mitäkin laatutekijää (miten tämä voidaan mitata?) TTY Ohjelmistotekniikka 27 Yhteiset ja vaihtelevat osat Kuvaus: oleellista tuoterunkoarkkitehtuureissa Ongelma: miten tunnistetaan yhteiset osat olemassa olevista järjestelmistä Esimerkki: yrityksen kolmella osastolla kehitetään samanlaisia tuotteita valitaan joka osastolta tyypillinen tuote ja verrataan niiden samanlaisuutta Ratkaisu: työkalu tai menetelmä samankaltaisuuden tunnistamiseen vertailu kooditasolla ongelmallista erilaiset koodirakenteet, nimeämiskäytännöt, ohjelmointikielet arkkitehtuurikuvausten vertailu arkkitehtuurimallit, laatutekijät, komponenttien rajapinnat, suunnitteluperusteet TTY Ohjelmistotekniikka 28 14
Kaupalliset komponentit Kuvaus: valmiita komponentteja käytetään yhä enemmän komponenttien toiminnan ymmärtämisen tärkeys Ongelma: miten uusi arkkitehtuuri voi hyödyntää valmiita komponentteja Esimerkki: järjestelmään tulee komponentteja eri toimittajilta, jolloin joudutaan selvittämään, mitä liimakoodia tarvitaan Ratkaisu: työkalu tai menetelmä, joka tukee arkkitehtuurin rakentamista valmiista komponenteista avoimia kysymyksiä: milloin komponentin kuvaus on riittävä? mistä tiedetään, että komponentti sopii järjestelmän arkkitehtuuriin? miten luotettavia komponenttien kuvaukset ovat? TTY Ohjelmistotekniikka 29 Järjestelmän arkkitehtuurin arviointi Skenaarioihin perustuva arviointi SAAM (software architecture analysis method) ATAM (architecture trade-off analysis method) Kysymyksiin perustuva arviointi Tarkistuslistaan perustuva arviointi Simulaatioon perustuva arviointi i Metriikkoihin perustuva arviointi TTY Ohjelmistotekniikka 30 15
SAAM-menetelmä 1. Laadi skenaarioita a 2. Kuvaa arkkitehtuuri(t) uu() 3. Luokittele skenaariot 4. Arvioi epäsuorat 6. Suorita lopullinen skenaariot arviointi 5. Arvioi skenaarioiden vaikutukset toisiinsa TTY Ohjelmistotekniikka 31 SAAM-menetelmän vaiheet Skenaarioiden laatiminen skenaarioille annetaan painoarvo (kerroin) Arkkitehtuuri(e)n kuvaaminen karkealla tasolla Skenaarioiden luokittelu suora skenaario arkkitehtuuri tukee skenaariota suoraan, ei tarvita muutoksia epäsuora skenaario arkkitehtuuria joudutaan muuttamaan Epäsuorien skenaarioiden arviointi tarvittavat t muutokset t ja niiden vaikeusasteet t Skenaarioiden vaikutukset toisiinsa vaativatko muutosta samaan komponenttiin? Lopullinen arviointi tuloksena paras tapa jakaa järjestelmä komponentteihin TTY Ohjelmistotekniikka 32 16
Arvioinnin tavoite Kahden (tai useamman) arkkitehtuurin vertailu Yhden arkkitehtuurin arviointi tavoitteet laatutekijöille esimerkkitavoitteita muutettavuudelle: järjestelmä on helposti muutettava, jos todennäköisimmät muutokset onnistuvat vain korkeintaan kahta komponenttia muuttamalla edellisen tulee olla voimassa vähintään 50 % muutoksista, jotka arvioinnissa otetaan huomioon TTY Ohjelmistotekniikka 33 Skenaarioiden kattavuus Varastonhallintajärjestelmä tietokannan muuttaminen järjestelmä olemassa olevien rajapintojen muuttaminen järjestelmän rajapinnat käyttöliittymän muuttaminen näyttöjen muuttaminen kommunikaatioteknologian muuttaminen sisällön muuttaminen toimittajan muuttuminen käyttöjärjestelmän muuttaminen uusien rajapintojen lisääminen ominaisuuden muuttaminen ominaisuuden lisääminen käyttäjän toiminnon muuttaminen sisäisen toiminnon muuttaminen käyttäjän toiminnon lisääminen sisäisen toiminnon lisääminen A B C D E F G H I J TTY Ohjelmistotekniikka 34 17
Esimerkkejä muutosskenaarioista A Uusia tekstikenttiä lisätään asiakastietodialogiin. M-1 C Asiakas- tai tuotenumeroiden tietotyyppiä laajennetaan. M-2 C Uusi pakkaustyyppi lisätään. M-3 C Tuotteille lisätään uusia attribuutteja (esim. väri, koko). M-4 D Tietokannan toimittaja vaihtuu. M-5 E Käyttöjärjestelmä muuttuu. M-6 F Järjestelmä muutetaan automaattiseksi tietovarastoksi M-7 (data warehouse). G Tilaustoimintoa muutetaan niin, että tilaus voidaan ottaa M-8 vastaan, vaikka kaikkia tavaroita ei ole heti saatavissa. H Järjestelmään lisätään uusi käyttäjätyyppi (pääkäyttäjän, M-9 operaattorin ja vuoropäällikön lisäksi). I Järjestelmään lisätään tuntiraportointi. M-10 J Joitakin toimintoja muutetaan niin, että niiden M-11 suorittaminen on mahdollista vain varaston sisältä. TTY Ohjelmistotekniikka 35 Esimerkkejä käyttöskenaarioista Vastaanottaja antoi tuotteiden määrän väärin, ja K-1 virhe yritetään korjata vahvistuksen jälkeen. Operaattori yrittää perua aikaisemmin tehdyn tilauksen mutta ei tiedä tilausnumeroa. Tavallinen käyttäjä toimii vuoropäällikön sijaisena ja tarvitsee väliaikaisesti laajemmat käyttöoikeudet. Aikaisemmin tehty tapahtuma täytyy ajaa uudelleen lokitietojen perusteella. K-2 K-3 K-4 TTY Ohjelmistotekniikka 36 18
Arkkitehtuurin kuvaaminen Asiakas1 Asiakas2 Asiakas3 Asiakashallinta Viestijono Käsittelijä1 Käsittelijä2 Käsittelijä3 Java database connectivity JDBC Tietokanta TTY Ohjelmistotekniikka 37 Uusia skenaarioita Tuotteiden vastaanottoa muutetaan niin, että jos tuotetta ei ole vielä rekisteröity, niin se rekisteröidään vastaanoton yhteydessä. Asiakkaiden määrä ylittää asiakashallinnan kapasiteetin. M-12 M-13 TTY Ohjelmistotekniikka 38 19
Skenaarioiden luokittelu Skenaario M2 vaatii vain yhden koodirivin muutoksen tuotteiden ja asiakkaiden ID-numeroita varten on oma tietotyyppi lisäksi tarvitaan pieni muutos tietokantatauluihin skenaariota voidaan pitää suorana Skenaario M5 on suora JDBC erottaa tietokannan käsittelijöistä Muut skenaariot ovat epäsuoria TTY Ohjelmistotekniikka 39 Epäsuorien skenaarioiden arviointi (esimerkkejä) M-1: Tekstikenttien lisääminen ei ole kovin suuri muutos XML-pohjaisessa viestin välityksessä, mutta lisäksi tarvitaan muutos viestien käsittelyssä. M-3: Pakkaustyypin lisääminen aiheuttaa paljon muutoksia. Pakkaustyyppi täytyy lisätä tietokantaan, lisäksi kaikki tuotteita käsittelevät näytöt ja viestien käsittelijät joudutaan muuttamaan. M-4: Toisistaan i riippumattomia i attribuutteja lisättäessä ä (esim. koko, väri) joudutaan lisäämään uusi tietokantataulu, koska uudet attribuutit pitää lisätä kaikille tuotteille. Lisäksi tarvitaan muutoksia näyttöihin ja käsittelijöihin. TTY Ohjelmistotekniikka 40 20
Skenaarioiden vaatimat muutokset M-1 ++ + näytöt skenaario käsittelijä(t) XMLformaatti tietokanta viestijono asiakashallinta arkkitehtuurikuvaus M-3 ++ ++ ++ M-4 ++ ++ ++ M-6???? M-7 ++ ++ M-8 ++ ++ M-9 + M-10 ++ + M-11 ++ ++ M-12 ++ ++ M-13 ++ ++ TTY Ohjelmistotekniikka 41 21