Arkkitehtuuriperustainen. Tuoterunkoihin perustuva ohjelmistotuotanto. Tuoterunkoarkkitehtuurien hyödyntäminen uudistamisessa

Transkriptio

1 Tuoterunkoarkkitehtuurien hyödyntäminen uudistamisessa Järjestelmän arkkitehtuurin tarkoituksena edistää uudelleenkäyttöä ohjelmisto- tai tuoteperheiden Järjestelmän arkkitehtuurin uudistaminen Arkkitehtuurin uudistamisen vaiheet uudistamisen laajuuden valinta Arkkitehtuurin uudistamisen malleja Liittyvät takaisinmallinnukseen Liittyvät ohjelmien evoluutioon Tuoterunkoihin perustuva ohjelmistotuotanto Runkoarkkitehtuurin rakentaminen Analyysi Analyysi Suunnittelu Sovellusten rakentaminen Suunnittelu Tietolähteet: domain engineering sovellusalue olemassa olevat ohjelmat Löydetyt ominaisuudet yhteiset (mandatory) valinnaiset (optional) vaihtoehtoiset (alternative) Sopivien komponenttien tuottaminen application engineering Sovellusten rakentaminen (kokoaminen) komponenteista 1 2 Tuoteperheajattelun tarve ohjelmistotuotannossa Komponentteihin liittyviä ongelmia Tuoterunkoarkkitehtuurin ongelmia Tilanne ohjelmistokehityksessä: uusia ominaisuuksia odotetaan yhä nopeammassa tahdissa käytössä ja kehitteillä olevien ohjelmien täytyy pysyä tuotantokäytössä hyvin pitkään olemassa olevia ohjelmia täytyy hyödyntää olemassa olevia vanhoja ohjelmia täytyy parantaa suunnittelussa tulee yhä enemmän ottaa loppukäyttäjät huomioon Ohjelmistokehityksen tukeminen: oikean ohjelmiston kehittäminen ohjelmiston kehittäminen oikein ohjelmiston kehittäminen nopeasti ja tuottavasti ohjelmiston kehittäminen vastaamaan muuttuvia tarpeita Komponenttien päällekkäiset versiot erilaiset (ristiriitaiset) laatuvaatimukset suuri vaihtelevuus Komponenttien väliset riippuvuudet riippuvuuksien lisääntyminen ajan kuluessa esim. komponenttien jakaminen osiin esim. toiminnallisuuden lisääminen Komponenttien käyttäminen uusissa tilanteissa komponenttien mukauttaminen () 3 4 Tuoterunkoarkkitehtuurin muutostarpeita Uuden runkoarkkitehtuurin rakentaminen Uuden jäsenen lisääminen tuoteperheeseen Uusien piirteiden (ominaisuuksien) lisääminen Standardituen lisääminen Ympäristössä (laitteisto, käyttöjärjestelmä) tapahtuvat versiomuutokset Laatutekijän parantaminen Arkkitehtuurin evoluutio 5 Arkkitehtuurin Arkkitehtuurin uudistaminen Kooditaso Toiminnallinen taso Vanha lähdekoodi Arkkitehtuurin Arkkitehtuuritaso Koodaustyylit Suunnittelumallit ja -tyylit Ohjelman toiminnalliset suunnitelmat Uusi lähdekoodi Arkkitehtuuriperustainen kehittäminen 6 1

2 Kooditason muutokset Tekstuaaliset muutokset merkkijonojen sovittaminen ja korvaaminen esim. Y2 K nimien ja tunnusten 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. Y2 K Toiminnallisen tason muutokset 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ö 7 8 Arkkitehtuuritason muutokset Arkkitehtuurin elementtien esim. komponenttien tyypin ja rakenteen esim. komponenttien liittymien (connector) esim. järjestelmän ajoaikaisten mallien Suurten muutosten tai puutteiden vaatima rakenteellinen muutos Vaatii paljon resursseja, mutta tuo suurimmat hyödyt Kooditason muutokset rakenteelliset tai toiminnalliset muutokset eivät ole tarpeellisia muutokset rajoittuvat yksittäisiin koodisegmentteihin lähdekoodi on pääasiallisin tai ainoa saatavilla oleva tietolähde käytettävissä olevat rahat ja aika rajoittavat uudistamista rakenteellisten (isompien) muutosten aiheuttama riski on suurempi kuin niiden tuoma hyöty käytettävissä olevat työkalut tekstin ja jäsennyspuun käsittelyyn ohjelmoijien saatavuus lähdekoodin hallinta 9 10 Toiminnallisen tason muutokset Arkkitehtuuritason muutokset 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 rahat ja aika rajoittavat vain jonkin verran uudistamista rakenteellisten muutosten aiheuttamat riskit ovat keskinkertaisia käytettävissä olevat työkalut moduulien ja rajapintojen tunnistamiseen järjestelmän asiantuntijoiden ja ohjelmoijien saatavuus uudelleenkäytettävien osien ja kapselointi pyrkimykset tuotteen parantamiseen ovat korkeat järjestelmän arkkitehtuuri on hyvin dokumentoitu käytettävissä olevat rahat ja aika eivät suuresti rajoita uudistamista järjestelmän ylläpidon jatkaminen aiheuttaa suuremman riskin kuin järjestelmän kehittäminen käytettävissä olevat työkalut arkkitehtuurin tunnistamiseen järjestelmän rakentajien, asiantuntijoiden ja ohjelmoijien saatavuus tuoterunkoarkkitehtuurin arkkitehtuuriin perustuva kehittäminen

3 Tason valinnassa huomioitavaa Käytettävissä oleva aika Käytettävissä olevat rahat Riskien huomioiminen Yrityksen ilmapiiri Pyrkimykset tuoterunkoarkkitehtuurin rakentamiseen miten tärkeä ja järkevä asia tuoterunkoarkkitehtuuri kyseisessä tilanteessa on Arkkitehtuurin uudistamisen vaiheet 1. Arkkitehtuurin 2. Arkkitehtuurin 3. Arkkitehtuuriin pohjautuva ohjelmiston kehittäminen vrt. takaisinmallinnuksen kautta tapahtuva uudistaminen Arkkitehtuurin Yksittäisten järjestelmien arkkitehtuurin ja kuvaaminen uudelleendokumentointi järjestelmän (arkkitehtuurin) arviointi arkkitehtuurin uudelleensuunnittelu ylläpito (muutosvaikutukset) järjestelmän jatkokehittely uuden järjestelmän kehittäminen vanhan pohjalta Järjestelmäperheen arkkitehtuurin ja kuvaaminen uusien ohjelmien lisääminen perheeseen ylläpidon helpottuminen uusien ohjelmaperheiden kehittäminen 15 Arkkitehtuurin ominaisuuksien olemassa olevat sovellukset Yksittäisten sovellusten ominaisuuksien yksittäisten sovellusten kuvaus (ominaisuudet) Ohjelmistoperheen arkkitehtuurin yhteisen arkkitehtuurin kuvaus 16 Arkkitehtuurin ominaisuuksia Esimerkkejä arkkitehtuurityyleistä 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, tietovirtoihin perustuva, itsenäisiin komponentteihin perustuva) Sovelluskohtaiset ominaisuudet varmistus (kaksinkertaiset tiedot, laitteistotestaukset, tarkistussummat) turvallisuus (kryptaus, digitaalinen allekirjoitukset) Tuoteperheeseen liittyvät ominaisuudet varianssi (standardit, käyttäjien tarpeet) 17 Kerroksittainen Tietokeskeinen Tietovirtoihin perustuva Leksikaalianalyysi Syntaksianalyysi Semanttinen analyysi Koodin generointi Koodin optimointi 18 3

4 Arkkitehtuurin ominaisuus: vaihtelevuus (varianssi) 2. Arkkitehtuurin Varianssi Syy Esiintyminen Standardit Asiakkaat Laitealustat Tyyppi Käänt. ohjaukset Parametrointi Ajankohta Käännösaika Ajoaika Toiminnallisuus Rakenne Tiedon siirto Järjestelmän kontrolli Suunniteltu (käsitteellinen) arkkitehtuuri Toteutettu (konkreettinen) arkkitehtuuri Etenevä konkreettinen arkkitehtuuri muutetaan vastaamaan käsitteellistä arkkitehtuuria Peruuttava käsitteellinen arkkitehtuuri muutetaan vastaamaan konkreettista arkkitehtuuria Arkkitehtuuriperustainen ohjelmistokehitys Arkkitehtuurin uudistamisen ongelmatilanteita? Arkkitehtuurin uudistamisen malleja Tarvittavien komponenttien toteuttaminen Tuoterunkoarkkitehtuurin toteuttaminen Arkkitehtuurityylin huomioon ottaminen Uudistaminen voi ulottua monelle tasolle esim. arkkitehtuurin CORBA-perustaiseksi arkkitehtuuritasolla komponentit ja niiden suhteet muuttuvat toiminnallisella tasolla olemassa olevaa koodia voidaan kääriä kooditasolla ohjelmointikielet ja ympäristöt (alustat) voivat muuttua alemman tason muutokset tukevat ylemmän tason muutoksia 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? Miten monikielisen järjestelmän arkkitehtuuri voidaan jäljittää? Arkkitehtuurinäkymät arkkitehtuurin uudelleendokumentointiin kuuluu näkymien ja niiden suhteiden mikä on riittävä määrä näkymiä 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 Suunniteltu vs. toteutettu arkkitehtuuri arkkitehtuurityyleille ei ole vastaavia käsitteitä ohjelmointikielissä laatuvaatimusten huomioiminen voi rikkoa arkkitehtuuria miten arkkitehtuurin suunnittelusta voidaan päätellä sen toteutus (ja päinvastoin) toteutustyökalun pitäisi pakottaa arkkitehtuurin toteutuksen noudattamaan suunnittelua järjestelmän perustuminen hyvin määriteltyihin komponentteihin

5 Laatutekijän sijainti suunnitteluratkaisut on valittu sen perusteella, mitä laatuvaatimuksia järjestelmän tulee täyttää eri laatuvaatimukset voivat olla ristiriitaisia toistensa kanssa miten voidaan päätellä arkkitehtuurielementtien ja laatuvaatimusten suhde Web-pohjaiseen ympäristöön siirtyminen tehokkuus, varmuus (security) työkalu tai menetelmä, joka auttaa selvittämään, miten järjestelmä tukee jotakin tiettyä laatutekijää avoin tutkimusongelma: mikä arkkitehtuurityyli tukee mitäkin laatutekijää ja miten tämä voidaan mitata? 25 Yhteiset ja vaihtelevat osat oleellista tuoterunkoarkkitehtuureissa miten tunnistetaan yhteiset osat olemassa olevista järjestelmistä yrityksen kolmella eri osastolla kehitetään samanlaisia tuotteita tuoterunkoarkkitehtuurin rakentamismahdollisuuksien arvioimiseksi valitaan joka osastolta tyypillinen tuote ja verrataan niiden samanlaisuutta työkalu tai menetelmä samankaltaisuuden tunnistamiseen ja arviointiin vertailu kooditasolla ongelmallista erilaiset koodirakenteet, nimeämiskäytännöt, ohjelmointikielet arkkitehtuurikuvausten vertailu arkkitehtuurimallit, laatutekijät, komponenttien rajapinnat, suunnitteluperusteet 26 Kaupalliset komponentit valmiita komponentteja käytetään yhä enemmän komponenttien toiminnan ymmärtäminen miten arkkitehtuurin uudelleenrakentamisessa voidaan hyödyntää valmiita komponentteja järjestelmään tulee komponentteja eri toimittajilta, jolloin joudutaan selvittämään, mitä liimakoodia tarvitaan 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? 27 Monikielisyys järjestelmien toteutuksessa on usein käytetty monia eri ohjelmointikieliä (C, C++, Fortran) lisäksi konfiguraatio-tiedostot, skriptit miten eri työkalujen käyttö onnistuu monikielisen järjestelmän arkkitehtuurin jäljittämisessä monikielisen järjestelmän osia halutaan käyttää toisissa järjestelmissä järjestelmän arkkitehtuurista ei ole dokumentteja eikä kukaan tunne järjestelmää kokonaisuudessaan tarkoitukseen olevia tekniikoita on jonkin verran olemassa 28 5