6 Ohjelmistoarkkitehtuurit

Koko: px
Aloita esitys sivulta:

Download "6 Ohjelmistoarkkitehtuurit"

Transkriptio

1 Esipuhe Tämä teos on tarkoitettu yliopistotason opetusmateriaaliksi kursseille, joilla käsitellään ohjelmistoarkkitehtuureja. Sen kohderyhmänä ovat erityisesti opiskelijat, jotka perehtyvät syvällisesti ohjelmistotuotantoon tai ohjelmistotekniikkaan. Teoksen toivotaan antavan myös teollisuudessa työskenteleville ohjelmistoammattilaisille yleiskuvan ohjelmistoarkkitehtuurien keskeisistä teemoista. Koska teoksesta on haluttu tehdä kattava, monet sen sisältämistä asiakokonaisuuksista voidaan käsitellä vain pintapuolisesti. Toisaalta monesta tällaisesta asiakokonaisuudesta on jo nyt kirjoitettu kokonaisia oppikirjoja. Tämän teoksen tavoitteena on antaa tiivistetty esitys myös tällaisista aiheista. Tämän teoksen aihepiiri liittyy läheisesti ohjelmistotuotantoon. Oletamme, että lukijalla on perustiedot paitsi ohjelmoinnista yleensä myös ohjelmistokehitysprosesseista. Monessa kohdin oletamme myös, että lukija hallitsee ainakin pintapuolisesti olioparadigman ja UML:n (Unified Modeling Language). Kuten monet muut ohjelmistotekniset tuotokset, tämäkin teos on syntynyt kiinteässä yhteistyössä useiden tahojen kanssa, joita kaikkia yhdessä ja erikseen haluamme kiittää. Jan Bosch on ystävällisesti antanut käyttöömme materiaalia, jota olemme hyödyntäneet kirjan tekstissä. Maarit Harsu ja Tommi Myllymäki ovat auttaneet tuoterunkoja koskevan luvun kirjoittamisessa. Kirjan eri osia ovat ansiokkaasti kommentoineet Ilkka Haikala, Juha Hautamäki, Mika Korhonen, Tero Laine, Mika Pussinen, Petri Selonen ja Tarja Systä. Haluamme myös kiittää materiaalin erilaisia esiversioita opiskelussaan käyttäneitä opiskelijoita Tampereen teknillisen yliopiston ohjelmistoarkkitehtuurikurssilla vuosina ja kurssien toteuttamiseen osallistunutta henkilökuntaa, sekä teollisuudessa pidettyjen koulutustilaisuuksien osallistujia, joiden kommentit on myös pyritty ottamaan huomioon teosta kirjoitettaessa. Lisäksi kiitämme

2 6 Ohjelmistoarkkitehtuurit Ohjelmistotekniikan laitoksen henkilökuntaa ja Practise-tutkimusryhmää ymmärryksestä proffien kirjaprojektin aikana sekä teollisuusyhteistyökumppaneitamme kannustuksesta. Kirjan kirjoittamista on tukenut Nokia Säätiön apuraha. Tampereella, Kai Koskimies ja Tommi Mikkonen sähköposti:

3 7 Sisällys Esipuhe... 5 Sisällys Johdanto Arkkitehtuuri ohjelmistokehityksessä Mikä on ohjelmistoarkkitehtuuri? Ohjelmistoarkkitehtuurin määritelmä Arkkitehtuurin tehtävät Arkkitehtuurin dokumentointi Arkkitehtuuripainotteinen ohjelmistokehitysprosessi Arkkitehtuurin käyttö toteutusvälineenä Arkkitehtuurin ja organisaation yhteys Arkkitehtuurinäkymät Arkkitehtuurin abstraktiotasoista Johdatus teoksen muihin lukuihin Yhteenveto Harjoitustehtäviä Ohjelmistoarkkitehtuurin kuvaus Arkkitehtuurikuvauksen merkitys Arkkitehtuurikuvaukseen liittyvät käsitteet Arkkitehtuurikuvauksen abstraktiotaso Näkökulmat arkkitehtuurien kuvauksessa Arkkitehtuurikuvausten tyypit Arkkitehtuuriviipaleiden kuvaus Arkkitehtuuridokumentit...41

4 8 Ohjelmistoarkkitehtuurit 2.8 Malliperustainen arkkitehtuuri Yhteenveto Harjoitustehtäviä Komponentit ja rajapinnat Komponentit Komponentin määritelmä Komponentit arkkitehtuurin yksikköinä Komponentit ohjelmistokehityksen yksikköinä Rajapinnat Rajapinnan käsite Tarjotut ja vaaditut rajapinnat Rajapintojen määrittely Komponenttien räätälöinti Komponentin tilan muuttaminen Vaadittujen rajapintojen toteuttaminen Periytymisen avulla toteutettu räätälöinti Yhteenveto Harjoitustehtäviä Komponenttien vuorovaikutustekniikat Komponentit ja niiden vuorovaikutus Rajapinnat Roolirajapinnat Usean komponentin välinen vuorovaikutus Kutsun siirtäminen Edustajakomponenttien käyttö Takaisinkutsut Tapahtumiin perustuva vuorovaikutus Rajapintariippuvuuksien poistaminen Luontiriippuvuus ja sen purkaminen Yhteenveto Harjoitustehtäviä Suunnittelumallit Johdatus suunnittelumalleihin

5 Mikä on suunnittelumalli? Suunnittelumallit ohjelmistotekniikassa Suunnittelumallin sisältö Suunnittelumallien kuvaaminen Antisuunnittelumallit Esimerkki: Rekursiokooste-suunnittelumalli Ongelma: hierarkkisen oliokokoelman hallinta Vaihe 1: kooste ja lehdet Vaihe 2: koosteen ja lehtien samaistaminen Vaihe 3: erityyppiset oliot Vaihe 4: koosteen eriyttäminen Suunnittelumallin esittäminen Suunnittelumallien edut ja ongelmat Suunnittelumallien tarjoamat edut Suunnittelumalleihin liittyviä ongelmia Suunnittelumallit ja UML Yhteenveto Harjoitustehtäviä Arkkitehtuurityylit Arkkitehtuurityyli ryhmittelyn perustana Kerrosarkkitehtuurit Tietovuoarkkitehtuuri Palveluperustaiset arkkitehtuurityylit Asiakas-palvelin-arkkitehtuurit Viestinvälitysarkkitehtuurit Sovellusaluekohtaiset arkkitehtuurityylit Malli-näkymä-ohjain -arkkitehtuurit Tietovarastoarkkitehtuurit Tulkkipohjaiset arkkitehtuurit Esimerkki: auton polttoaineenkulutuksen valvontaohjelmisto Arkkitehtuurityylit ja UML Yhteenveto Harjoitustehtäviä...152

6 10 Ohjelmistoarkkitehtuurit 7 Tuoterunkoarkkitehtuurit Arkkitehtuurin rooli ohjelmistokehityksessä Tuoterunkoarkkitehtuurit ja niiden hyödyt Tuoterungon edut Tuoterunko investointina Tuoterungon rakentaminen ja evoluutio Ohjelmistokehitysprosessi tuoterunkoa käytettäessä Prosessin yleiskuvaus Alustakehitysprosessi Tuotekehitysprosessi Muunneltavuus tuoterungossa Muunneltavuus vaatimustasolla Muunneltavuus suunnittelussa ja toteutuksessa Muunneltavuus testauksessa Tuoterunko ja organisaatio Tuoterunkoarkkitehtuurin kerrosmalli Resurssialusta Arkkitehtuurialusta Sovellusalusta Sovelluskerros Esimerkki: auton valvonnan tuoterunko Tuoterunkojen ongelmia Yhteenveto Harjoitustehtäviä Ohjelmistokehykset Johdatus ohjelmistokehyksiin Mikä on ohjelmistokehys? Erikoistamisrajapinta Kehykset ja suunnittelumallit Hollywood-periaate Erikoistamismekanismit Kehykset ohjelmistokehitysparadigmana Kehyslajit Abstraktit kehykset

7 Muunneltavat kehykset Plugin-kehykset Koottavat kehykset Kehysten strukturointi Kerroksittaiset kehykset Hierarkkiset kehykset Komponenttikehysten käyttö Kehysten suunnittelu Kehysten suunnittelu ja oliosuunnittelu Kehysten iteratiivinen rakentamisprosessi Kehyksen kehitysprosessin vaiheet Kerroksittaisen kehyksen suunnittelu Erikoistamismallit Kehysten riskejä Tekninen vaativuus ja monimutkaisuus Kehysten yhdistely Monoliittisuus Laadullinen varianssi Dokumentointi Yhteenveto Harjoitustehtäviä Arkkitehtuurien arviointi Johdatus arkkitehtuurin arviointiin Arvioinnin kohdentaminen Arvioinnin perusteet Arvioinnin sidosryhmiä Arkkitehtuurin arviointi osana ohjelmistoprosessia Arkkitehtuurin arviointimenetelmät ATAM Esittelyosio Analyysiosio Testausosio Raportointiosio...233

8 12 Ohjelmistoarkkitehtuurit 9.5 Esimerkki: auton kunnonvalvontaohjelmiston arkkitehtuurin arviointi Arvioinnin ongelmia Yhteenveto Harjoitustehtäviä Kirjallisuusviitteet Hakemisto...247

9 OSA I Perusteet

10 1 Johdanto Ohjelmistoarkkitehtuurit ovat muodostuneet selvästi omaksi ohjelmistotekniikan alueekseen verrattain myöhään, vasta 1990-luvun loppupuoliskolla. Sitä ennen ohjelmistoarkkitehtuureja pidettiin lähinnä vain korkeamman tason suunnitteluna. Nykyisin ohjelmistoarkkitehtuurien merkitys ohjelmistotekniikan alueena kasvaa jatkuvasti. Uusia arkkitehtuuriaiheisia oppikirjoja julkaistaan, niitä käsitteleviä uusia konferenssisarjoja perustetaan ja arkkitehtuuriin liittyvät kysymykset yleistyvät alan opetuksessa ja tutkimuksessa. 1.1 Arkkitehtuuri ohjelmistokehityksessä Ohjelmallisesti toteutettujen sovellusten ymmärtämisessä ja rakentamisessa on liikuttu primitiivisistä välineistä kohti suurempia kokonaisuuksia (kuva 1.1). Alussa sovellukset pyrittiin näkemään lähinnä muistipaikkoihin ja rekistereihin talletettujen lukujen ja merkkijonojen käsittelynä (esim. assembler-kielet). Sitten opittiin tunnistamaan näiden muodostamia rakenteita, joita toteuttamaan kehitettiin kieliin rakenteisia tietotyyppejä (esim. C, Pascal). Vastaavasti tunnistettiin Sovelluskäsitteet Luvut, merkkijonot ("nimi") Tietorakenteet ("osoite") Toiminnot ("talletus") Tietoabstraktiot ("tili") Palveluyksiköt ("tilin hallinta") Sovellusalue ("pankkiliiketoiminta") Toteutuskäsitteet Muistipaikat, rekisterit Rakenteiset tietotyypit Aliohjelmat Luokat Komponentit, agentit, rajapinnat Tuoterungot, kehykset, alustat Kuva 1.1: Ongelma-alueen ja toteutustekniikan käsitetason siirtyminen kohti suurempia kokonaisuuksia

11 16 Ohjelmistoarkkitehtuurit Johdanto 17 toimenpiteitä, joita näille rakenteille tuli suorittaa; nämä esitettiin kielissä aliohjelmina. Sitten opittiin näkemään sovelluksissa suurempia käsitteitä, joihin liittyy sekä tietoa että käyttäytymistä. Näitä toteuttamaan kehitettiin kieliin tietoabstraktio eri muodoissa. Tietoabstraktio kokoaa yhteen tietorakenteita ja niihin liittyviä operaatioita, ja antaa mahdollisuuden käsitellä tietoa vain näiden operaatioiden kautta. Eräs tietoabstraktion muoto on olioparadigman tuoma luokkakäsite, jossa abstraktiin tietotyyppiin on yhdistetty laajennettavuus (periytyminen). Tämän jälkeen havaittiin tarve muodostaa suurempia kokonaisuuksia loogisesti yhteen kuuluvista palveluista, jotka esitettiin tietyt rajapinnat toteuttavina komponentteina (tai agentteina, jos palvelut olivat proaktiivisia). Vähitellen yksittäisen sovelluksen käsite hämärtyi toteutuksen kannalta: eri sovellukset jakoivat yhteisiä komponentteja ja kirjastoja. Lisäksi opittiin ymmärtämään, että monilla myös eri sovellusalueille tarkoitetuilla ohjelmistoilla on olennaisesti sama perusarkkitehtuuri, ja kehitettiin ohjelmistoalustoja (platform), jotka toteuttavat tällaisen arkkitehtuurin tarvitseman yleisen infrastruktuurin. Edelleen ymmärrettiin, että eri sovellukset ovat usein läheistä sukua toisilleen sekä sovelluksen toteutusrakenteen että toiminnallisuuden kannalta. Tällä tavoin tunnistettiin tietyille sovellusalueille sovellustai tuoteperheitä (product/application family), joiden toteuttamisen tueksi kehitettiin lähinnä olioparadigman sisällä sovelluskehyksen käsite. Ohjelmistojen luominen tapahtuu näin yhä enemmän arkkitehtuuritason käsitteiden ja toteutusmekanismien pohjalta. Tähän suuntaukseen on vaikuttanut ennen muuta järjestelmien jatkuva monimutkaistuminen ja kasvaminen, uudelleenkäytön merkityksen kasvaminen ja yleinen arkkitehtuuritason ratkaisuja korostava teknologian kehitys (esimerkiksi mobiili-, hajautus- ja komponenttiteknologiat). Arkkitehtuurin merkitys näkyy monessa asiassa ohjelmistokehitysprosessissa. Inkrementaalinen ja rinnakkainen ohjelmistokehitys saavutetaan yleensä arkkitehtuuritason ratkaisuilla. Arkkitehtuuri on tärkeä työnjaon kannalta: vain arkkitehtuuritasolla tunnistettavat osat järjestelmää ovat mielekkäitä työn jakamisen yksiköitä. Arkkitehtuuri on olennainen myös testauksen ja ylläpidon kannalta: hyvä arkkitehtuuri jakaa ohjelmiston osiin, jotka on helppo testata erillisinä ja jotka paikallistavat ylläpidossa tarvittavat muutostyöt. Arkkitehtuuri antaa korkean abstraktiotason näkymän ohjelmistoon, mikä mahdollistaa aikaisempaa monimutkaisempien järjestelmien tarkastelun ja myös erilaisten sidosryhmien välisen kommunikoinnin järjestelmästä. Arkkitehtuurin eriytyminen omaksi alueekseen on tukenut erilaisten standardiratkaisujen kehittämistä ja dokumentoimista arkkitehtuuritasolle, jolloin myös arkkitehtuurien käytölle ja määrittelemiselle voidaan asettaa selkeät perussäännöt. Arkkitehtuurien painoarvoa kasvattaa se, että arkkitehtuurin määritteleminen ja dokumentointi mahdollistaa järjestelmän arvioinnin joidenkin kriittisten tekijöiden osalta jo hyvin varhaisessa vaiheessa ohjelmistokehitystä, jolloin järjestelmän muuttaminen on vielä halpaa. Koska arkkitehtuuri toimii yleisenä ohjenuorana ohjelmistokehitykselle ja ohjelmiston ylläpidolle, arkkitehtuurivaiheessa siirrytään ongelman käsitteistöstä ratkaisun käsitteistöön. Epäonnistuneesta järjestelmästä voidaan usein syyttää arkkitehtuuria. Huono arkkitehtuuri voi ilmetä monin eri tavoin järjestelmän kehittämisen, käyttämisen ja ylläpidon aikana. Pahin mahdollisuus on, että järjestelmää ei pystytä lainkaan toteuttamaan tarkoitetussa laajuudessa kyseisessä organisaatiossa. Arkkitehtuuri voi esimerkiksi tehdä olemassa olevasta teknologiasta oletuksia, jotka eivät pidä paikkaansa. Vastaavasti arkkitehtuuri voi tehdä toteuttamisen niin vaikeaksi, ettei sitä pystytä tekemään suunnitellussa aikataulussa. Arkkitehtuurin heikkouksien takia järjestelmä ei ehkä pysty tehokkaasti suoriutumaan kuin pienistä tieto- tai käyttäjämääristä, tai arkkitehtuuri saattaa tehdä esimerkiksi käyttöliittymästä niin hitaan, ettei sitä voi järkevästi käyttää. Arkkitehtuuri voi tehdä myös järjestelmän testauksesta tai ylläpidosta vaikeaa ja kallista, jos se ei tue osien erillistä testausta tai muutosten tekemistä. Jos arkkitehtuuri ei esimerkiksi selkeästi erota ympäristöstä (esim. käyttöjärjestelmä) riippuvia osia, järjestelmän siirtäminen uuteen ympäristöön voi olla vaikeaa. Epäonnistuminen voi tapahtua myös ensimmäisen version onnistuneen käyttöönoton jälkeen. Koska arkkitehtuuri on keskeinen tekijä ohjelmistojen uudelleenkäytössä, epäonnistuminen arkkitehtuurisuunnittelussa voi käytännössä estää suunnitellun laajuisen uudelleenkäytön.

12 18 Ohjelmistoarkkitehtuurit Johdanto Mikä on ohjelmistoarkkitehtuuri? Vaikka ohjelmistoarkkitehtuureista puhutaan paljon, usein niillä tarkoitetaan hivenen eri asiaa puhujan kokemusmaailman mukaisesti. Tarkastelemme seuraavassa lähemmin ohjelmistoarkkitehtuurin määritelmää Ohjelmistoarkkitehtuurin määritelmä Ohjelmistoarkkitehtuureille on esitetty useita erilaisia määritelmiä kirjallisuudessa. IEEE:n arkkitehtuurien kuvaamista koskeva standardi määrittelee ohjelmistoarkkitehtuurin järjestelmän perusorganisaatioksi, joka sisältää järjestelmän osat, niiden keskinäiset suhteet ja niiden suhteet ympäristöön sekä periaatteet, jotka ohjaavat järjestelmän suunnittelua ja evoluutiota (IEEE 2000). Olennaista määritelmässä on, että arkkitehtuuri ei kata pelkästään järjestelmän jakamista osiin, vaan myös näiden osien välisiä suhteita ja niiden kehittymistä. Koska suhteet ovat usein luonteeltaan ajoaikaiseen käyttäytymiseen liittyviä, arkitehtuuri koskee paitsi rakennetta myös käyttäytymistä. Toisaalta arkkitehtuuri ei koske ainoastaan ohjelmiston staattista rakennetta (koodin rakennetta), vaan myös ohjelman suorituksen aikaisia rakenteita, esimerkiksi dynaamisia oliorakenteita. Yksinkertaisuuden vuoksi ohjelmiston arkkitehtuuria tarkastellaan usein jostakin tietystä näkökulmasta, esimerkiksi tiedostorakenteen, loogisen rakenteen, prosessirakenteen jne. näkökulmista. Olennaista on myös, että arkkitehtuuriin katsotaan kuuluvan tiettyjen ratkaisujen perustelu, ei ainoastaan kuvaus. Lisäksi arkkitehtuuriin yleensä liittyy joukko sääntöjä ja periaatteita, jotka säätelevät sitä, miten järjestelmiä kehitetään tähän arkkitehtuuriin perustuen. Säännöt, joita tietyn arkkitehtuurin mukaan rakennettavassa järjestelmässä on noudatettava, voivat koskea teknologian käyttöä (esim. käytettävä JavaBeans-komponentteja), algoritmien valintaa (esim. lajittelussa käytettävä quicksortia), tietorakenneratkaisuja (esim. joukot toteutettava kahteen suuntaan linkitettyinä listoina), sekä suunnittelu- ja toteutusmalleja (esim. kommunikointiin käytettävä Observer-suunnittelumallia). Voidaankin ajatella, että arkkitehtuuri on järjestelmän perustuslaki. Sitä on noudatettava järjestelmää rakennettaessa, ja sitä voi- daan muuttaa vain erittäin painavilla perusteilla. Samaa asiaa korostavat Catalysis-suunnittelumenetelmän kehittäjät d'souza ja Wills, jotka määrittelevät arkkitehtuurin joukoksi päätöksiä, jotka estävät toteuttajia ja ylläpitäjiä olemasta tarpeettoman luovia (D Souza ja Wills 1998). Toisin sanoen arkkitehtuuri määrittelee rajat, joiden puitteissa järjestelmää on rakennettava ja ylläpidettävä. Arkkitehtuuri määrittelee siis järjestelmän ytimen, joka pysyy olennaisesti samana kehityksen ja ylläpidon aikana. Niitä osia, jotka eivät kuulu tähän ytimeen, voidaan vapaasti muunnella tarkoituksenmukaisemmiksi. Tämä ajattelutapa pätee erityisen hyvin nk. tuoterunkoarkkitehtuureihin, joihin tutustumme myöhemmin tässä teoksessa; tällöin vaihtuvat osat vastaavat sovelluskohtaisia osia. Tämä määritelmä on sikäli yleinen, että se sallii myös arkkitehtuurit, joissa tärkein osa ei ole varsinainen ohjelmistokuvaus, vaan esimerkiksi jokin tietty menettelytapa, jonka avulla ohjelmistoa voidaan muunnella. Esimerkiksi jokin tietty käyttöjärjestelmä voi vaatia, että kaikki resurssit näkyvät sovellusohjelmille niitä hallinnoivien palvelinten kautta. Tällaisia periaatteita kutsutaan joskus myös arkkitehtuurien filosofioiksi Arkkitehtuurin tehtävät Arkkitehtuurin tehtävänä on ottaa kantaa keskeisiin ohjelmiston ratkaisuihin, jotka voivat koskea paitsi yleistä jakamista osiin myös osien välistä komminkointitapaa, prosesseja ja niiden välistä kommukointia, 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. Koska monia näistä ratkaisuista on vaikea arvioida etukäteen, joudutaan arkkitehtuurin toimivuutta usein kokeilemaan osin puutteellisella tai keinotekoisesti rakennetulla järjestelmällä. Näiden kokeilujen systematisointi johtaa ns. inkrementaaliseen kehitykseen. Tällöin ensimmäinen vaihe joutuu tyypillisesti ottamaan kantaa perusarkkitehtuuriin, ja muut vaiheet tuovat olemassaolevaan runkoon enemmän ja enemmän toiminnallisuutta (Boehm 1988). Arkkitehtuuri perustuu ohjelmiston ositukseen tietyllä periaatteella. Ohjelmistojen dekompositio (osiin pilkkominen) voidaan teh-

13 20 Ohjelmistoarkkitehtuurit Johdanto 21 dä monilla perusteilla, esimerkiksi toiminnallisuuteen, yleisyyteen, hajautukseen, käsitemalliin, joustavuusnäkökulmaan ym. perustuen. Aspektiperustainen ohjelmointi pyrkii strukturoimaan ohjelmiston paitsi perinteisen arkkitehtuurin, myös erilaisten arkkitehtuurin määrittelemien rakenneyksiköiden yhteisten aspektien (kuten vaikkapa virheidenkäsittely, tiedon pysyvyys, hajautus, tietty järjestelmän ulkoisesti havaittava piirre jne.) kannalta (Filman et al. 2005). Koska tällaiset aspektit ovat yleensä riippumattomia komponenttijaosta, aspektit edustavat komponentteja läpileikkaavia (cross-cutting) viipaleita järjestelmästä. Näin järjestelmä voidaan samanaikaisesti strukturoida useassa eri ulottuvuudessa. Kärjistettynä tämä näkemys johtaa ajatukseen, että ohjelmistot ovat perusluonteeltaan moniulotteisia rakenteita ja että mikään yksittäinen komponenttijako ei pysty tavoittamaan tätä ominaisuutta Arkkitehtuurin dokumentointi Jos arkkitehtuuri ei ole selkeästi dokumentoitu, sitä ei ole oikeastaan olemassa: arkkitehtuuri materialisoituu kuvauksena. Vaikka järjestelmän dokumentoimattomasta arkkitehtuurista voidaan puhua, eri henkilöt tekevät tällöin todennäköisesti hyvin erilaisia olettamuksia siitä, mikä kuuluu järjestelmän arkkitehtuuriin ja mikä ei. Vaikka järjestelmällä olisikin alun perin ollut selkeä arkkitehtuuri, arkkitehtuurikuvauksen puuttuminen johtaa jossain vaiheessa järjestelmän ja sen arkkitehtuurin rapautumiseen (Clements et al. 2003). Periaatteena tulisi olla, että ohjelmistoprojektia, joka ei ole saavuttanut selvää arkkitehtuurin kuvausta, ei pitäisi päästää jatkamaan: projektilta puuttuu sen perustuslaki, jolloin sen kehitys saattaa helposti muuttua anarkiaksi. 1.3 Arkkitehtuuripainotteinen ohjelmistokehitysprosessi Arkkitehtuuripainotteisessa ohjelmistokehitysprosessissa korostetaan arkkitehtuurin suunnittelua ja arviointia keskeisenä vaiheena ennen siirtymistä yksityiskohtaiseen suunnitteluun ja toteutukseen. Arkkitehtuuri pyritään johtamaan inkrementaalisesti ja iteratiivisesti lähtien arkkitehtuurin kannalta merkittävistä vaatimuksista. Arkkitehtuuriin vaikuttavat toisaalta kaikkein keskeisimmät toiminnalliset vaatimukset ja toisaalta laadulliset (ei-toiminnalliset) vaatimukset. Prosessi etenee tyypillisesti siten, että ensimmäinen versio arkkitehtuurista tehdään toiminnallisten vaatimusten pohjalta, ja sitä arvioidaan sitten vasten laadullisia vaatimuksia. Tarpeen vaatiessa arkkitehtuuria uudistetaan niin, että kukin laadullinen vaatimus täyttyy. Kun kaikki laadulliset vaatimukset on saatu näin täytettyä, järjestelmän perusarkkitehtuuri on valmis. Tämän pohjalta edetään yksityiskohtaiseen suunnitteluun, toteutukseen ja testaukseen, jolloin saadaan ensimmäinen, keskeisimmät toiminnalliset vaatimukset täyttävä toteutus. Tämän jälkeen tarkastellaan sekundaarisia toiminnallisia vaatimuksia ja toteutetaan ne perusarkkitehtuurin pohjalle. Tässäkin vaiheessa voidaan vielä havaita tarvetta muuttaa arkkitehtuuria. Toteutus tehdään yleensä inkrementaalisesti vaatimus (tai kokokoelma toisiinsa liittyviä vaatimuksia) kerrallaan. Mikäli sovelluksen käyttöönoton jälkeen tulee uusia vaatimuksia tai vaatimukset muuttuvat, joudutaan prosessi periaatteessa käymään läpi alusta lähtien: jos esimerkiksi uudet vaatimukset ovat arkkitehtuurin kannalta merkittäviä, joudutaan myös arkkitehtuuri muuttamaan tai ainakin arvioimaan uudestaan. Jos arkkitehtuurisuunnittelussa sovelletaan käyttötapauksiin (use case) pohjautuvaa prosessia, primääriset ja sekundääriset toiminnalliset vaatimukset saadaan jakamalla käyttötapaukset arkkitehtuurin kannalta kriittisiin ja vähemmän kriittisiin. Käyttötapaukset voivat tällöin suoraan edustaa vaatimuksia. Kuvassa 1.2 esitetty prosessimalli on monessa suhteessa idealistinen mutta antaa kuitenkin karkean mallin, jota voidaan soveltaa käytännöllisissä prosessimalleissa. Vaikka arkkitehtuurin suunnittelun lähtökohtana ovat yleensä tärkeimmät toiminnalliset vaatimukset, lopullisen arkkitehtuurin muodon sanelevat kuitenkin usein pikemmin ei-toiminnalliset, laatuun liittyvät vaatimukset ("*ilities"). Varsinkin joustavuus ja muunneltavuus sekä toisaalta tehokkuus ja muistin kulutus ovat keskeisiä, arkkitehtuuriin usein vastakkaisesti vaikuttavia tekijöitä. Toisaalta voidaan kysyä, minkä suhteen halutaan olla joustavia, sillä kaikkien ohjelmiston ominaisuuksien kannalta joustavuuden vaatiminen on epärealistista. Jos joustavuuden kohdetta ei määritellä etukäteen, voi tuloksena olla järjestelmä, joka on periaatteessa joustava mutta jossa

14 22 Ohjelmistoarkkitehtuurit Johdanto 23 Uusia tai muuttuneita vaatimuksia Käyttöönotto Toissijaiset toiminnalliset vaatimukset Testaus Arkkitehtuurin kannalta merkittävät vaatimukset Alustava arkkitehtuurisuunnittelu Toteutus Alustava arkkitehtuuri Arkkitehtuurin muunnos Vaatimusanalyysi Yksityiskohtainen suunnittelu Arvioi laatuominaisuus Toiminnalliset perusvaatimukset Laatuvaatimukset Perusarkkitehtuuri Kuva 1.2: Arkkitehtuuriperustainen ohjelmistokehitysprosessi väärät tässä tapauksessa siis vakiona pysyvät asiat voidaan muuttaa helposti, mutta käytännössä muuttuvat asiat vaativat enemmän työtä. Vaikka arkkitehtuurisuunnittelussa on periaatteessa kyse kokoelmasta yhteensopiva ratkaisuita, joiden avulla voidaan täyttää kaikki vaatimukset, toteutuksista on usein luettavissa, että jokin vaatimus tai jotkin vaatimukset ovat selvästi dominoineet arkkitehtuurisuunnittelua. Tyypillisesti jokin arkkitehtoonisesti merkittävistä vaatimuksista on niin paljon tärkeämpi kuin muut, että se on käytännössä johtanut tiettyyn perusarkkitehtuuriin, johon muut vaatimukset on sitten pakotettu. Arkkitehtuurin eräs olennainen tehtävä onkin kuvata, kuinka (tai missä määrin) arkkitehtoonisesti merkittävät vaatimukset täyttyvät annetulla arkkitehtuurilla. Tässä mielessä arkkitehtuuri voidaan nähdä kokoelmana korkean tason suunnitteluratkaisuja, jotka pyrkivät tiettyjen, erityisesti laadullisten vaatimusten ja niistä seuraavien ongelmien ratkaisuun. ei OK OK 1.4 Arkkitehtuurin käyttö toteutusvälineenä Toinen puoli arkkitehtuuripainotteista ohjelmistokehitystä on, että uusia ohjelmistoja toteutetaan yhä enemmän perustuen olemassaolevaan arkkitehtuuriin. Tämä johtuu yleisestä pyrkimyksestä lisätä ohjelmistojen uudelleenkäyttöä, joka ilmenee erilaisina ohjelmistoalustoina. Kun ohjelmistoalustalla on arkkitehtuuri, joka sovelluskehittäjän täytyy ottaa huomioon, arkkitehtuurille tulee toteutusvälineen rooli, joka on verrattavissa ohjelmointikielen rooliin. Arkkitehtuurin tarjoamat välineet ovat vain korkeammalla tasolla kuin ohjelmointikielen tarjoamat välineet. Sovelluskehittäjän kannalta olennaiseksi ongelmaksi tulee pikemmin se, miten sovelluksen vaatimukset saadaan toteutettua alustan tarjoamalla arkkitehtuurilla, kuin se, miten ne saadaan toteutettua tietyllä ohjelmointikielellä. Tässä roolissa arkkitehtuurilta edellytetään ominaisuuksia, jotka tavallisesti liitetään ohjelmointikieliin. Arkkitehtuurin tulee olla määritelty täsmällisesti ja täydellisesti (syntaksi ja semantiikka), ja sen dokumentoinnin tulee olla käyttäjälle suuntautunutta. Arkkitehtuurilla voidaan myös ajatella olevan staattiset ja dynaamiset oikeellisuussäännöt kuten ohjelmointikielillä (esimerkiksi tyyppisäännöt). Työkalujen kannalta kiinnostava havainto on, että arkkitehtuurille voidaan rakentaa samantapaisia tukiympäristöjä kuin ohjelmointikielille, tukemaan esimerkiksi arkkitehtuurin oikeellisuussääntöjen noudattamista, koodin generointia, visualisointia, takaisinkääntämistä ym. Suuntaus kohti arkkitehtuuritason toteutusvälineistöä antaa aiheen puhua uudesta ohjelmointiparadigmasta, arkkitehtuuriperustaisesta ohjelmoinnista. Tarkastellaan esimerkkinä Enterprise Java Beans -teknologiaa (EJB). Kun sovellus tehdään EJB:n pohjalle, olennainen suunnitteluongelma on se, miten sovelluksen käsitteet toteutetaan EJB:n tarjoamilla välineillä esimerkiksi mitkä asiat toteutetaan nk. istuntopavulla (session bean), mitkä nk. säilykepavulla (entity bean) ei niinkään miten Javalla toteutetaan tietyt asiat. Toinen esimerkki on graafisen käyttöliittymän toteutus esimerkiksi Swingin (Java-ympäristön GUI-kehys) pohjalle. Tässäkään tapauksessa ongelmana ei ole niinkään Javan käyttö sinänsä, vaan Swingin tarjoamien mekanismien käyttö toteutusvälineenä.

15 24 Ohjelmistoarkkitehtuurit Johdanto Arkkitehtuurin ja organisaation yhteys Järjestelmän arkkitehtuurilla on myös läheinen yhteys järjestelmää kehittävään tai ylläpitävään organisaatioon. Mielekkäästi toimiva organisaatio alkaa muistuttaa rakenteeltaan järjestelmän arkkitehtuuria. Tämä johtuu viime kädessä siitä, että tyypillisesti komponentti, joka on arkkitehtuurin perusyksikkö, annetaan yhden henkilön kehitettäväksi. Toisiinsa liittyvät komponentit pyritään antamaan tietylle ryhmälle, joka saa näin vastuulleen tyypillisesti jonkin alijärjestelmän. Tämä tulee selvästi näkyviin esimerkiksi tuoterunkoarkkitehtuurien kohdalla: ohjelmistoalustasta vastaa tavallisesti oma organisaation yksikkö, kun taas tuotekohtaisesta ohjelmistosta vastaa oma yksikkö. Vastaavasti organisaatio, joka vuodesta toiseen ylläpitää samaa ohjelmistoa, yleensä jakaa ylläpidon arkkitehtuurin sallimalla tavalla. Yleisesti ilmiö tunnetaan nimellä Conwayn laki (Conway 1968). Ohjelmiston kehittämiseen liittyy useita sidosryhmiä (stakeholder), joita ovat esimerkiksi kehittäjät, ylläpitäjät, testaajat ja käyttäjät. Kullakin sidosryhmällä on yleensä oma näkökulmansa ohjelmistoon, ja tästä näkökulmasta seuraavat odotukset ja vaatimukset. Usein eri sidosryhmien vaatimukset ovat keskenään ristiriitaisia. Arkkitehdin keskeisenä tehtävänä on määritellä arkkitehtuuri, joka tuottaa vaatimusten välille siedettävän kompromissin riittävän monen sidosryhmän kannalta. 1.6 Arkkitehtuurinäkymät Arkkitehtuureja voidaan tarkastella eri näkökulmista (viewpoints). Tässä yhteydessä kutsumme arkkitehtuurin kuvausta tietystä näkökulmasta (arkkitehtuuri)näkymäksi (view). Tätä on havainnollistettu kuvassa 1.3. Kukin näkymä mallintaa jonkin asian järjestelmästä. Kun kyse on saman järjestelmän eri näkymistä, niillä on luonnollisesti paljon riippuvuuksia: jos jotain kohtaa muutetaan yhdessä näkymässä, täytyy mahdollisesti useita kohtia muuttaa muissa näkymissä. Yhdessä näkymät muodostavat kattavan, osittain päällekkäisen kuvauksen järjestelmän arkkitehtuurista. Erilaisilla työkaluilla voidaan jossain määrin tuottaa automaattisesti näkymiä olemassaolevista järjestel- Näkymä Näkökulma Näkymä Kuva 1.3: Arkkitehtuurinäkymiä Näkymä Järjestelmä mistä (reverse engineering) tai koodia näkymien perusteella (code generation). Työkalut voivat myös varmistaa, että näkymät ovat keskenään yhtäpitäviä. Tarkastelemme eri näkökulmia lähemmin luvussa Arkkitehtuurin abstraktiotasoista Järjestelmän arkkitehtooninen malli Arkkitehtuurilla ymmärretään usein ainoastaan ohjelmointitason rakenteita. Tämä on kuitenkin hyvin rajoittunut näkökulma, sillä arkkitehtuurin tarjoamat edut vaativat yleensä useiden erilaisten abstraktiotasojen hyödyntämistä. Hyvin korkealla abstraktiotasolla jonkin järjestelmäkategorian perusrakenne voidaan antaa esimerkiksi nk. arkkitehtuurityylinä tai referenssiarkkitehtuurina; tällainen kuvaus määrittelee arkkitehtuuriin liittyvät käsitteet yleisin tai sovellusaluekohtaisin termein, ottamatta kantaa yksittäiseen järjestelmään. Toisaalta arkkitehtuurikuvaus voidaan antaa konkreettisen järjestelmän lähdekoodin rakenteena eri tarkkuustasoilla riippuen käyttötarkoituksesta. Viime aikoina eri abstraktiotasoilla olevien arkkitehtuurikuvausten väliset transformaatiot ovat herättäneet suurta mielenkiintoa.

16 26 Ohjelmistoarkkitehtuurit Johdanto 27 Eräs konkreettinen hanke on OMG:n (Object Management Group) MDA-hanke, malliperustainen arkkitehtuuri (Model-Driven Architecture) (Object Management Group 2003). Malliperustaisen arkkitehtuurin tavoitteena on tarjota ohjelmoijalle mahdollisuus rakentaa abstrakteja kuvauksia järjestelmän arkkitehtuurista, ja tämän jälkeen generoida sopiva toteutustason arkkitehtuuri jollekin tietylle sovellusalustalle noudattaen tämän nimenomaisen alustan käytäntöjä. Generointi voi tapahtua joko automaattisesti tai suunnittelijan avustamana. Malliperustaisen arkkitehtuurin olennaisena piirteenä voidaankin pitää eri tasojen välisiä mallitransformaatioita, joiden avulla saadaan abstraktimpia tai yksityiskohtaisempia näkymiä arkkitehtuuriin. Samalla arkkitehtuurin merkitys korostuu, sillä se on esitettävä tarkasti ja yksiselitteisesti transformaatioiden mahdollistamiseksi. 1.8 Johdatus teoksen muihin lukuihin Teos koostuu kolmesta toisiaan täydentävästä kokonaisuudesta. Näistä ensimmäinen on johdanto ohjelmistoarkkitehtuurien luonteeseen ja peruskäsitteisiin; osa koostuu tästä johdannosta ja seuraavasta luvusta, jossa tarkastellaan arkkitehtuurien kuvaamista yleisesti. Lukujen yhteinen tavoite on tarjota riittävä käsitteellinen ja terminologinen perusta, jotta seuraavien osien läpikäyminen olisi mahdollista. Teoksen toinen osa käsittelee arkkitehtuureja lähtien liikkeelle arkkitehtuurin peruselementeistä ja siitä, ja millaisilla ratkaisuilla hallitaan niiden välisiä suhteita. Tässä arkkitehtuuri nähdään pienessä mittakaavassa: käymme läpi joukon tekniikoita, joiden avulla tiettyjä komponenttien suhteisiin liittyviä ongelmia voidaan ratkaista. Ohjelmistoarkkitehtuuri on hyvin pitkälle komponenttien välisten riippuvuuksien hallintaa, jolloin arkkitehtuuriratkaisuilla pyritään näiden riippuvuuksien poistamiseen tai heikentämiseen. Toisen osan luvut esittelevät arkkitehtuurin perusyksiköt, komponentit ja rajapinnat sekä kuvaavat erilaisia tapoja hallita komponenttien välisiä riippuvuuksia. Koska käytännössä riippuvuuksia hallitaan usein nk. suunnittelumallien (design pattern) avulla, myös tämä alue tulee suhteellisen kattavasti käsiteltyä tässä osassa: käymme läpi erityyppisiä suunnittelumalleina(kin) esitettyjä perusratkaisuita. Lisäksi suunnittelumallin käsite esitellään erikseen omassa lu- vussaan. Osan tavoitteena on tarjota konkreettista apua käytännön ongelmiin arkkitehtuurisuunnittelussa. Teoksen kolmas ja viimeinen osa keskittyy arkkitehtuuriin suuressa mittakaavassa, jolloin arkkitehtuurin käsitettä tarkastellaan järjestelmätasolla pikemmin kuin yksittäisten komponenttien tasolla. Arkkitehtuuriratkaisujen osalta tarkastelemme kaikkein korkeimmalla järjestelmätasolla sovellettavia ajatusmalleja, nk. arkkitehtuurityylejä, jotka määräävät järjestelmän perusluonteen. Osa sisältää myös tuoterunkoarkkitehtuurien esittelyn ja niiden suositun olioperustaisen toteutustekniikan, sovelluskehysten, kuvauksen. Lisäksi tarkastelemme arkkitehtuurien arviointia ja esittelemme systemaattisen tavan suorittaa arkkitehtuurikatselmus järjestelmän laatuominaisuuksien selvittämiseksi. 1.9 Yhteenveto Ohjelmistoarkkitehtuuri on osa ohjelmistosuunnittelua; kaikki suunnitteluasiat eivät kuitenkaan ole arkkitehtuuria. Komponenttien väliset suhteet kuuluvat arkkitehtuuriin, mutta niiden sisäiset asiat eivät. Arkkitehtuuriin sisältyvät myös ratkaisujen perustelut. Ohjelmistoarkkitehtuuri voidaan nähdä rakennettavan järjestelmän "perustuslakina", joka antaa rajat yksityiskohtaiseen suunnitteluun ja toteutukseen. Arkkitehtuuriperustainen ohjelmistokehitys korostaa arkkitehtuurin roolia kehitysprosessia ohjaavana suunnitteluartifaktina. Ohjelmistoarkkitehtuuri voidaan kuvata eri asioita korostavista näkökulmista käsin ja eri abstraktiotasoilla Harjoitustehtäviä 1.1 Suuressa ohjelmistoprojektissa (tai tuotelinjassa) voi työskennellä useita satoja ohjelmistosuunnittelijoita. Miten mielestäsi arkkitehtuurisuunnittelu tulisi sisällyttää osaksi ohjelmistosuunnittelua tällaisessa ympäristössä?

17 28 Ohjelmistoarkkitehtuurit 1.2 Mitä ongelmia huonosti määritelty arkkitehtuuri voi aiheuttaa toteutusvaiheessa? Millainen ohjelmistokehitysprosessin tulisi olla, jotta näiltä ongelmilta vältyttäisiin? 1.3 Etsi www:stä kolme ohjelmistoarkkitehtuurin määritelmää (esim. joita pidät tavalla tai toisella oikeaan osuvina (älä kuitenkaan valitse tässä kirjassa esitettyä määritelmää). Vertaile määritelmiä keskenään ja tässä kirjassa annetun määritelmän kanssa. Millainen ohjelmistoarkkitehtuurin määritelmä vastaisi eniten sitä intuitiivista käsitystä, joka sinulla on tähän mennessä ohjelmistoarkkitehtuureista? 1.4 Kuvaa jonkin tuntemasi järjestelmän (esim. jokin harjoitustyö) arkkitehtuuri yhdellä vapaamuotoisella tavalla. Miten hyvin tämä kuvaus vastaa tehtävässä 1.3 esitettyjä ohjelmistoarkkitehtuurin määritelmiä? 1.5 Etsi ja suomenna seuraavien käsitteiden määrittelyt www:stä: a) product-line architecture, b) architectural style, c) design pattern, d) component, e) application framework. 1.6 Argumentoi puolesta tai vastaan seuraavaa väitettä: Ohjelmistojen rakentamisessa pitäisi korkean tason suunnittelu antaa tehtäväksi vain ohjelmistoarkkitehdin tutkinnon suorittaneille henkilöille, samaan tapaan kuin rakennusten suunnittelu annetaan vain arkkitehdin koulutuksen saaneiden henkilöiden tehtäväksi. 1.7 Argumentoi puolesta tai vastaan seuraavaa väitettä: Ohjelmistoarkkitehdin koulutuksen pitäisi poiketa ohjelmistosuunnittelijan koulutuksesta, samaan tapaan kuin rakennusarkkitehdin ja rakennesuunnittelijan koulutus eroavat toisistaan. 1.8 Minkälaisia muunnoksia mielestäsi tarvitaan arkkitehtuurien abstraktiotasojen välille malliperustaista arkkitehtuuria toteutettaessa? Mitkä tasot mielestäsi tarvitsevat tukea suunnittelijalta, ja mitkä voidaan toteuttaa automaattisesti? Minkälaiset työkalut voisivat auttaa malliperustaisuuden toteuttamisessa?

18 2 Ohjelmistoarkkitehtuurin kuvaus Ohjelmistoarkkitehtuurin kuvaus on keskeinen dokumentti, jossa arkkitehtuuri materialisoituu. Tarkastelemme tässä luvussa arkkitehtuurikuvauksen merkitystä ja erilaisia lähestymistapoja arkkitehtuurin kuvaukseen. 2.1 Arkkitehtuurikuvauksen merkitys Ohjelmiston arkkitehtuuri on tärkein ohjelmistoa luonnehtiva informaatio. Tästä syystä ohjelmiston eri sidosryhmien välinen kommunikointi koskee usein arkkitehtuuriin liittyviä kysymyksiä. Jotta kaikilla olisi sama käsitys ohjelmiston arkkitehtuurista, arkkitehtuurilla tulisi olla mahdollisimman kattava ja yksiselitteinen kuvaus. Vain tällaiseen kuvaukseen pohjautuen on mahdollista ilmaista täsmällisiä arkkitehtuuria (ja ylipäänsä koko järjestelmää) koskevia faktoja. Arkkitehtuurilla on näin tärkeä merkitys järkevän kommunikaation mahdollistavana ohjelmistoartefaktina, joka antaa paitsi keskeiset ohjelmistoratkaisut myös käsitteistön ja sanaston, johon pohjautuen järjestelmästä voidaan puhua. Nykyisin teollisuudessakin ymmärretään arkkitehtuurikuvausten merkitys, ja niistä on tullut keskeinen dokumentti ohjelmistokehitysprosesseissa. Ohjelmistoarkkitehtuurien kuvaus on kuitenkin vielä verrattain uusi ja edelleen kehittyvä ohjelmistotekniikan alue. Ohjelmiston arkkitehtuuri on pikemmin järjestelmää koskeva spesifikaatio kuin jokin järjestelmän ominaisuus, joka voitaisiin päätellä suoraan järjestelmästä. On tosin olemassa (puoli)automaattisia tekniikoita, joilla arkkitehtuuritason informaatiota voidaan tuottaa takaisinmallintamalla (reverse engineering) järjestelmää, mutta täl-

19 30 Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurin kuvaus 31 laiset tekniikat tuottavat tyypillisesti vain arkkitehtuurin kuvaukseen tarvittavaa tietoa, eivät varsinaisia arkkitehtuurikuvauksia. Käytännöllisistä syistä on mahdollista ajatella, että arkkitehtuurin kuvaus on ohjelmistoarkkitehtuurin konkreettinen ilmenemismuoto: arkkitehtuuria ei ole olemassa ilman sen kuvausta. Tämä pätee myös silloin, kun itse järjestelmä on olemassa. Tällaisessa tilanteessa järjestelmän arkkitehtuurista puhuminen on erityisen vaarallista, koska eri ihmiset voivat olemassaolevan järjestelmän perusteella helposti tehdä erilaisia tulkintoja siitä, mikä on järjestelmän arkkitehtuuri ja mitkä asiat kuuluvat siihen. Varsinaisen rakenteen lisäksi arkkitehtuuria siis käytetään myös selittämään järjestelmää. Toisaalta arkkitehtuurin kuvaus voidaan antaa eri tarkkuustasoilla. Olennaista on, että kukaan ei tee arkkitehtuurista oletuksia, jotka menevät yli sen kuvauksen. Tätä on usein kuitenkin vaikea välttää, jos kuvaus annetaan hyvin abstraktilla tasolla. Arkkitehtuurikuvaus voitaisiin antaa esimerkiksi seuraavasti: järjestelmä on J2EE-teknologiaan ja asiakas-palvelin-arkkitehtuuriin perustuva liiketoimintasovellus. Tämä on sinänsä validi kuvaus, koska se perustuu käsitteisiin, joiden voi olettaa olevan yleisesti tunnettuja. Sen perusteella voidaan keskustella järjestelmän perusratkaisusta hyvin yleisellä tasolla, vaikkapa sanomalla, että järjestelmä sopisi paremmin web-palveluksi (web service). Mitään tarkempia oletuksia esimerkiksi siitä, mitkä osat ovat asiakaspäässä ja mitkä palvelinpäässä ei voi tämän perusteella tehdä. Siitä huolimatta monet, jotka tietävät jotakin järjestelmän tarkoitetusta toiminnallisuudesta, tekevät todennäköisesti mielessään mahdollisesti tiedostamattaan erilaisia tätä koskevia oletuksia. Arkkitehtuurikuvaus on keskeinen kommunikointiväline arkkitehdin ja toteutus- tai ylläpitoryhmän välillä. Jos arkkitehtuurin tarkka kuvaus on olemassa ainoastaan arkkitehdin päässä, ryhmä tulee varmasti tekemään ratkaisuja, jotka ovat ristiriidassa tuon kuvauksen kanssa. Tällaiset ongelmat voivat tulla esiin vasta hyvin myöhäisessä vaiheessa, ja ne voivat maksaa yritykselle paljon. Arkkitehdin velvollisuutena on siksi huolehtia siitä, että ryhmällä on käytettävissään arkkitehtuurin kuvaus, joka kertoo täsmällisesti, mitkä asiat kuuluvat arkkitehtuuriin ja mitä arkkitehtuuri sallii. Arkkitehtuurin kuvaustekniikat liittyvät läheisesti työkalutukeen. Työkalutukea ei tarvita ainoastaan arkkitehtuurimallien ja -näkymien tuottamiseen, vaan myös varmistamaan, että nämä mallit ovat keskenään ristiriidattomia ja että yksityiskohtaisessa suunnitte- lussa ja toteutuksessa noudatetaan näitä malleja. Työkaluja voidaan myös käyttää tuottamaan automaattisesti arkkitehtuurinäkymiä toisten mallien tai olemassaolevan lähdekoodin perusteella. Tässä suhteessa standardoidut kuvaustekniikat, kuten UML, tarjoavat hyvän pohjan työkalukehitykselle. Ohjelmistotekniikan pitkän tähtäyksen suuntauksena on lisätä ohjelmistojen kuvauksen abstraktiotasoa, ja tuottaa toimivia järjestelmiä yhä korkeamman tason kuvauksista. Arkkitehtuurikuvaus on korkeimman abstraktiotason ratkaisukuvaus, joten voisi ajatella, että tällaisesta kuvauksesta voitaisiin joskus tuottaa toimivia järjestelmiä automaattisesti. Tämä edellyttää kuitenkin arkkitehtuurikuvaukselta täsmällisyyttä ja kattavuutta, joka on toistaiseksi mahdollista vain hyvin rajatussa mielessä, esimerkiksi jollakin kapealla sovellusalueella. 2.2 Arkkitehtuurikuvaukseen liittyvät käsitteet Jotta ymmärrettäisiin mitä asioita ohjelmistoarkkitehtuurin kuvaukseen sisältyy, on tarkasteltava käsitteitä, jotka tavalla tai toisella liittyvät arkkitehtuureihin. IEEE on julkaissut arkkitehtuurien kuvaamisesta standardin (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std ), jossa annetaan arkkitehtuureja koskeva käsitekaavio UML:n luokkakaaviona. Kuvassa 2.1 on esitetty hieman yksinkertaistettu versio tästä kaaviosta. Kuvan 2.1 mukaisesti jokainen järjestelmä täyttää yhden tai useampia tehtäviä (mission) toimintaympäristössään. Järjestelmällä on sidosryhmiä (stakeholder), joista kullakin on omat tavoitteensa ja huolenaiheensa (concern) järjestelmän suhteen. Jos järjestelmällä on arkkitehtuuri, sillä täytyy olla myös täsmälleen yksi arkkitehtuurikuvaus. Huomaa, että vaikka tämä malli esittää arkkitehtuurin ja arkkitehtuurikuvauksen erillisinä käsitteinä, arkkitehtuuri voi mallin mukaan olla olemassa vain, jos siitä on kuvaus. Arkkitehtuurikuvaus muodostuu erilaisista näkymistä (view), jotka seuraavat tiettyjä näkökulmia (viewpoint). Näkökulma määrää tietyn esitysmuodon ja tavoitteen kuvaukselle, näkymä on yksittäiselle järjestelmälle annettu osittainen arkkitehtuurikuvaus, joka noudattaa jonkin näkökulman esitysmuotoa. Tarkastelemme näkökulmia ja näkymiä lähemmin jatkossa.

20 32 Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurin kuvaus 33 Environment has Mission fulfills System 1..* 1..* has an identifies 1..* Architecture 1 described by Architectural description 1..* organized by provides selects Rationale Konkreettinen arkkitehtuuri Referenssiarkkitehtuuri Metaarkkitehtuuri Yksityiskohtainen suunnittelu Organization * 1..* Stakeholder 1..* View has 1..* 1..* is addressed to conforms to Concern Viewpoint 1..* Tuoterunkoarkkitehtuuri Tuotearkkitehtuuri Lähdekoodi Kuva 2.1: IEEE:n standardin mukainen (yksinkertaistettu) käsitemalli arkkitehtuureille Kuva 2.2: Arkkitehtuurityypit ja niiden väliset suhteet Toisaalta arkkitehtuurikuvaus muodostuu malleista (esimerkiksi UML-kaavioista), joita näkymät hyödyntävät. Kuhunkin näkymään voi liittyä useita malleja, ja malli voi esiintyä useassa näkymässä. Arkkitehtuurikuvauksen tulee antaa myös perustelu (rationale), joka kertoo, miksi kyseiset ratkaisut on tehty. 2.3 Arkkitehtuurikuvauksen abstraktiotaso Tietojenkäsittelytehtävä voidaan kuvata eri abstraktiotasoilla esimerkiksi epäformaalina algoritmina, pseudokoodiesityksenä, parametroituna koodirunkona (esim. C++:n template) tai suoritettavana ohjelmakoodina. Samaan tapaan ohjelmistoarkkitehtuuri voidaan antaa esimerkiksi yleisenä, abstraktina ratkaisumallina tietyn tyyppisille järjestelmille, jonkin järjestelmäperheen yhteisen arkkitehtuurin kuvauksena, tai yksittäisen konkreettisen järjestelmän kuvauksena. Arkkitehtuurikuvausta annettaessa on syytä tehdä selväksi, minkä tyyppisestä arkkitehtuurista on kyse. Kuvassa 2.2 on esitetty eri arkkitehtuurityypit ja niiden väliset suhteet UML:n luokkakaaviona. Riippuvuussuhde (katkonuoli) tarkoittaa, että lähde noudattaa kohdetta (esimerkiksi tuotearkkitehtuuri noudattaa tuoterunkoarkkitehtuuria). Kuvaan on otettu mukaan myös yksityiskohtainen suunnittelu ja lähdekooditoteutus, jotka eivät luonnollisesti ole arkkitehtuuritason kuvauksia. Meta-arkkitehtuuri ei kuvaa ohjelmistoarkkitehtuuria itseään, vaan käsitteistön ja mekanismit, joilla varsinaisia arkkitehtuurikuvauksia annetaan. Meta-arkkitehtuuri voi näin kuvata esimerkiksi komponenttikategorioita ja niiden välisiä suhteita. Esimerkki meta-arkkitehtuurista on UML:n profiili, joka on annettu (tietyn tyyppisten) arkkitehtuurien kuvaamiseen. Profiili mekanismina on UML:n metamallin laajennos, joka erikoistaa joitakin UML:n standardielementtejä ja antaa niitä koskevia ylimääräisiä rajoitteita. Profiili voisi esimerkiksi erikoistaa UML:n komponenttielementin uudeksi mallielementiksi, joka edustaa tiettyä komponenttikategoriaa. Yritys voi antaa meta-arkkitehtuurikuvauksen ohjenuorana, jonka noudattamista edellytetään yrityksen kehittämien järjestelmien arkkitehtuurikuvauksissa. Meta-arkkitehtuuria voi abstraktissa mielessä ajatella kielioppina, jonka mukaisesti varsinaisia arkkitehtuureja kuvataan. Referenssiarkkitehtuuri ei myöskään kuvaa mitään konkreettista järjestelmää, vaan antaa yleisen ratkaisumallin tietyn tyyppisten järjestelmien tai niiden osien arkkitehtuureille. Toisin kuin meta-arkkitehtuuri, referenssiarkkitehtuuri kuvaa arkkitehtuuriratkaisun, mutta abstraktilla tasolla liittämättä sitä mihinkään todelliseen järjestelmään. Esimerkiksi yleiset arkkitehtuurityylit ja -mallit, joita käsit-

21 34 Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurin kuvaus 35 telemme myöhemmin tässä kirjassa, voidaan esittää referenssiarkkitehtuurina. Samoin on usein mielekästä antaa sovellusaluekohtaisia (tai jopa yrityskohtaisia) referenssiarkkitehtuureja, jotka kuvaavat tietyllä sovellusalueella hyviksi havaittuja arkkitehtuuriratkaisuja ja niihin liittyviä erikoiskäsitteitä. Konkreettinen arkkitehtuuri esittää yksittäisen ohjelmiston arkkitehtuurin. Esimerkiksi tietyn sovelluksen arkkitehtuuridokumentti antaa näin aina konkreettisen arkkitehtuurin, joskin siinä voidaan viitata eri referenssi- ja meta-arkkitehtuureihin, joita konkreettinen arkkitehtuuri noudattaa. Sekä konkreettinen arkkitehtuuri että referenssiarkkitehtuuri noudattavat aina jotakin meta-arkkitehtuuria, vaikka tätä ei välttämättä tiedostettaisi. Arkkitehtuurikuvaus nimittäin perustuu aina joihinkin käsitteisiin, joiden oletetaan olevan tunnettuja, ja nämä käsitteet muodostavat meta-arkkitehtuurin. Jos esimerkiksi UML:ää käytetään arkkitehtuurikuvauksiin, meta-arkkitehtuurina on UML:n metamalli. Jos arkkitehtuurikuvaus perustuu UML:n profiileihin, metaarkkitehtuurina on tämän metamallin eräs laajennus. Jos kuvaukseen käytetään erityistä arkkitehtuurin kuvauskieltä (ADL, Architecture Description Language), meta-arkkitehtuurina on tämän kielen spesifikaatio. Mitä erikoistuneempia käsitteitä meta-arkkitehtuuri tarjoaa, sitä enemmän se rajoittaa kuvattavia arkkitehtuureja, mutta toisaalta sitä enemmän se myös tukee arkkitehtuurikuvausten antamista rajoitetulla alueella. Periaatteessa on mahdollista antaa meta-arkkitehtuuri, joka tukee yhden ainoan järjestelmän arkkitehtuurin kuvausta. Tuoterunkoarkkitehtuuri kuvaa toisaalta ohjelmistoalustan arkkitehtuurin ja toisaalta antaa säännöt yksittäisten ohjelmistotuotteiden rakentamiseen alustan pohjalle. Edellisen kannalta tuoterunkoarkkitehtuuri on siis konkreettinen arkkitehtuuri, jälkimmäisen kannalta tuoterunkoarkkitehtuuriin saattaa usein sisältyä meta-arkkitehtuurin piirteitä. Palaamme tuoterunkoarkkitehtuureihin luvussa 7. Tuotearkkitehtuuri on yksittäisen ohjelmistotuotteen arkkitehtuuri. Tällainen tuote voi olla rakennettu tuoterungon päälle, jolloin se noudattaa tuoterunkoarkkitehtuuria, tai se voi olla täysin itsenäinen sovellus. Kummassakin tapauksessa tuotearkkitehtuuri on konkreettinen. Arkkitehtuurikeskeisessä ohjelmistokehityksessä arkkitehtuuria noudatetaan yksityiskohtaisessa suunnittelussa, toteutuksessa ja ylläpidossa. Parhaassa tapauksessa noudattamista valvotaan työkalujen avulla. Kuvan 2.2 "noudattaa"-suhteet (katkonuoli) ilmaisevat, millaisia arkkitehtuuriin liittyviä tarkistuksia ohjelmistokehitysprosessissa voi tehdä: lähdekoodi voidaan tarkistaa yksityiskohtaista suunnittelua vasten, suunnittelu voidaan puolestaan tarkistaa konkreettista arkkitehtuuria vasten, ja konkreettinen arkkitehtuuri voidaan lopuksi tarkistaa meta-arkkitehtuuria vasten. 2.4 Näkökulmat arkkitehtuurien kuvauksessa Ohjelmistoarkkitehtuurin tulisi aikaisemman määritelmän mukaan kertoa, millaisia komponentteja järjestelmässä on ja millaisia suhteita niillä on keskenään. Komponentteihin liittyy kuitenkin niin monenlaisia suhteita ja puolia, että näin yleisen määritelmän perusteella on vaikea tietää, mitä asioita arkkitehtuurin kuvaukseen tulisi sisällyttää ja millainen rakenne kuvauksella tulisi olla. Tätä varten on otettu käyttöön käsite näkökulma (viewpoint): arkkitehtuurikuvaus koostuu tiettyjen näkökulmien mukaisista näkymistä (view) järjestelmään. Tässä näkökulma tarkoittaa yleistä, järjestelmästä riippumatonta tapaa kuvata tiettyä arkkitehtuurin kannalta merkityksellistä ohjelmistojen ominaisuutta. Näkymä on varsinainen järjestelmästä riippuva kuvaus, joka noudattaa jotakin näkökulmaa. Näkökulman ja näkymän suhde on samantapainen kuin esimerkiksi luokan ja olion: näkymä on näkökulman ilmentymä tietyn järjestelmän yhteydessä. Näkökulma on ortogonaalinen järjestelmän strukturoinnin kanssa: mitä hyvänsä osaa järjestelmästä voidaan periaatteessa katsoa mistä hyvänsä näkökulmasta, joskin jotkin näkökulmat saattavat käytännössä olla mielekkäämpiä tietyn järjestelmän osan tapauksessa kuin toiset. Nk. 4+1-malli esittää viisi näkökulmaa ohjelmistoarkkitehtuurien kuvaamiseen (Kruchten 1995). Tästä mallista on esitetty myöhemmin hieman toisistaan poikkeavia versioita. Järjestelmän luonteesta riippuen jotkin 4+1 -mallin näkökulmista ovat keskeisiä, jotkin toiset taas vähemmän tärkeitä. On toisaalta mahdollista, että jossakin järjestelmässä on syytä ottaa myös muita näkökulmia arkkitehtuurin kuvaukseen. Tässä teoksessa seuraamme 4+1-mallia, mutta otamme mukaan uuden näkökulman, joka on olennainen erityisesti tuoterunkoarkkitehtuurien yhteydessä. Tämä kuudes näkökulma (variaatio- eli muuntelunäkökulma) käsittelee sitä, miten arkkitehtuuri tukee jär-

2 Ohjelmistoarkkitehtuurien kuvaus

2 Ohjelmistoarkkitehtuurien kuvaus 2 Ohjelmistoarkkitehtuurien kuvaus 2.1 Arkkitehtuurikuvauksen merkityksestä 2.2 Arkkitehtuurin kuvaukseen liittyvät käsitteet 2.3 Arkkitehtuurikuvaukset eri tasoilla 2.4 Arkkitehtuurinäkymät ja kuvaustyypit

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta

Lisätiedot

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Epäonnistuneen ohjelmistoarkkitehtuurin seurauksia 1.4 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 2 Ohjelmistoarkkitehtuurien kuvaus 2.1 Arkkitehtuurin kuvaukseen liittyvät käsitteet 2.2 Arkkitehtuurikuvaukset eri tasoilla 2.3 Arkkitehtuurinäkökulmat ja kuvaustyypit 2.4 Arkkitehtuuriviipaleiden kuvaus

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2010

Ohjelmistoarkkitehtuurit. Syksy 2010 Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin

Lisätiedot

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa

Lisätiedot

Harjoitustehtävät ja ratkaisut viikolle 48

Harjoitustehtävät ja ratkaisut viikolle 48 Harjoitustehtävät ja ratkaisut viikolle 48 1. Tehtävä on jatkoa aiemmalle tehtävälle viikolta 42, missä piti suunnitella älykodin arkkitehtuuri käyttäen vain ennalta annettua joukkoa ratkaisuja. Tämäkin

Lisätiedot

Ohjelmistoarkkitehtuurit, syksy 2012 4.9.2010

Ohjelmistoarkkitehtuurit, syksy 2012 4.9.2010 Ohjelmistotutkimuksen painopisteitä Ohjelmistoarkkitehtuurit Johdanto ja peruskäsitteitä 2000 1995 1990 1985 1980 1970 Tuoteperhearkkitehtuurit, MDA, väliohjelmistot, aspektit CASE-välineet: uudelleenkäyttö,

Lisätiedot

2 Ohjelmistoarkkitehtuurien kuvaus

2 Ohjelmistoarkkitehtuurien kuvaus 2 Ohjelmistoarkkitehtuurien kuvaus 2.1 Arkkitehtuurikuvauksen merkityksestä 2.2 Arkkitehtuurin kuvaukseen liittyvät käsitteet 2.3 Arkkitehtuurikuvaukset eri tasoilla 2.4 Arkkitehtuurinäkymät ja kuvaustyypit

Lisätiedot

13/20: Kierrätys kannattaa koodaamisessakin

13/20: Kierrätys kannattaa koodaamisessakin Ohjelmointi 1 / syksy 2007 13/20: Kierrätys kannattaa koodaamisessakin Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy

Lisätiedot

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

Lisätiedot

Ohjelmistokehykset (software frameworks)

Ohjelmistokehykset (software frameworks) Ohjelmistoarkkitehtuurit 1 (software frameworks) Osittain abstraktiksi jätettyjä ohjelmistorunkoja, joita eri tavoin täydentämällä saadaan rakennettua kokonaisia uusia sovelluksia tai sovelluksen osia

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k 1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.

Lisätiedot

Ohjelmistokehykset (software frameworks)

Ohjelmistokehykset (software frameworks) Ohjelmistoarkkitehtuurit 1 (software frameworks) Osittain abstraktiksi jätettyjä ohjelmistorunkoja, joita eri tavoin täydentämällä saadaan rakennettua kokonaisia uusia sovelluksia tai sovelluksen osia

Lisätiedot

10. Tuoterunkoarkkitehtuurit

10. Tuoterunkoarkkitehtuurit 10. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta, organisaatio, prosessi, tekninen Tuoterunkojen etuja ja ongelmia 1 Uudelleenkäytt yttö

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

ALTEn toimintaohjeisto

ALTEn toimintaohjeisto ALTEn toimintaohjeisto Johdanto Vuonna 1994 ALTEn jäsenet tekivät päätöksen tarpeesta luoda virallinen toimintaohjeisto, jossa sekä määriteltäisiin ne standardit, joihin nykyiset ja tulevat jäsenet yksimielisesti

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

UML-kielen formalisointi Object-Z:lla

UML-kielen formalisointi Object-Z:lla UML-kielen formalisointi Object-Z:lla Kalvot ja seminaarityö WWW:ssä: http://users.jyu.fi/~minurmin/opiskelu/form/ UML UML == Unified Modelling Language. OMG:n standardoima kieli ohjelmistojärjestelmien,

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2007

Ohjelmistoarkkitehtuurit. Syksy 2007 Ohjelmistoarkkitehtuurit Syksy 2007 Kai Koskimies 1 Tervetuloa Tampereen yliopisto, Teknillinen korkeakoulu, Turun yliopisto 2 Kurssin tavoitteet Arkkitehtuuritason peruskäsitteiden ymmärtäminen Arkkitehtuurien

Lisätiedot

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri?

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri? 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

Ohjelmistotekniikan menetelmät, UML

Ohjelmistotekniikan menetelmät, UML 582101 - Ohjelmistotekniikan menetelmät, UML 1 Sisältö DFD- ja sidosryhmäkaavioiden kertaus Oliomallinnus UML:än kaaviotyypit 2 Tietovuokaaviot Data flow diagrams, DFD Historiallisesti käytetyin kuvaustekniikka

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

Lisätiedot

Ohjelmistoarkkitehtuurit Kevät käytäntöjä

Ohjelmistoarkkitehtuurit Kevät käytäntöjä Ohjelmistoarkkitehtuurit Kevät 2014 -käytäntöjä Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 8.1.2014 1 Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

Lisätiedot

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 582101 - Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 1 Ohjelmistotuotannon työkaluuista Projektinhallintatyökalut (ei käsitellä tällä kurssilla) CASE- ja mallinnustyökalut (esim. Poseidon)

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702)

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

Luokka- ja oliokaaviot

Luokka- ja oliokaaviot Luokka- ja oliokaaviot - tärkeimmät mallinnuselementit : luokat, oliot ja niiden väliset suhteet - luokat ja oliot mallintavat kuvattavan järjestelmän sisältöä ja niiden väliset suhteet näyttävät, kuinka

Lisätiedot

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } } Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

11. Kehysarkkitehtuurit

11. Kehysarkkitehtuurit 11. Kehysarkkitehtuurit Johdanto Kehystyypit Kehykset ja arkkitehtuuri Kehykset ja suunnittelumallit Kehyspohjainen ohjelmistokehitys Esimerkkikehys Kehysten toteutuksesta Kehysten etuja ja ongelmia Yhteenvetoa

Lisätiedot

Ohjelmistoarkkitehtuurit 2016. Kevät 2016 -käytäntöjä

Ohjelmistoarkkitehtuurit 2016. Kevät 2016 -käytäntöjä Ohjelmistoarkkitehtuurit Kevät 2016 -käytäntöjä Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 13.1.2016 1 Tervetuloa Tampereen teknillinen yliopisto, Oulun yliopisto, Turun yliopisto 13.1.2016 2 Tiedonvälitys

Lisätiedot

UML:n yleiskatsaus. UML:n osat:

UML:n yleiskatsaus. UML:n osat: UML:n yleiskatsaus - voidaan hyödyntää hyvin laajasti. - sopii liiketoimintamallinnukseen, ohjelmistomallinnukseen sen jokaiseen vaiheeseen tai minkä tahansa pysyviä ja muuttuvia ominaisuuksia sisältävän

Lisätiedot

ADM Arkkitehtuuritason automaatio #tdarc

ADM Arkkitehtuuritason automaatio #tdarc ADM Arkkitehtuuritason automaatio #tdarc Kalle Launiala http://abstractiondev.wordpress.com kalle.launiala@citrus.fi Ohjelmistoteollisuus elää murrosta Ohjelmistoteollisuudesta halutaan perusteollisuutta

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

Yleisiä asioita. Harkat alkavat ensi viikolla Vierailuluentoa. Slackin #luennot-kanava taas käytössä. Ensi viikon perjantaina, Janne Viitala, Sandvik

Yleisiä asioita. Harkat alkavat ensi viikolla Vierailuluentoa. Slackin #luennot-kanava taas käytössä. Ensi viikon perjantaina, Janne Viitala, Sandvik Yleisiä asioita Harkat alkavat ensi viikolla Vierailuluentoa Ensi viikon perjantaina, Janne Viitala, Sandvik Slackin #luennot-kanava taas käytössä 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2

Lisätiedot

Yhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014

Yhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014 Yhtälönratkaisusta Johanna Rämö, Helsingin yliopisto 22. syyskuuta 2014 Yhtälönratkaisu on koulusta tuttua, mutta usein sitä tehdään mekaanisesti sen kummempia ajattelematta. Jotta pystytään ratkaisemaan

Lisätiedot

Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development Harri Laine 1

Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development Harri Laine 1 Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development 2.12.2008 Harri Laine 1 Jacobson jakaa ohjelmiston oliot kolmeen tyyppiin liittymäolioiksi (interface objects, boundary objects)

Lisätiedot

Software engineering

Software engineering Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of

Lisätiedot

Käyttötapausanalyysi ja testaus tsoft

Käyttötapausanalyysi ja testaus tsoft Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 582101 - Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 1 Lähestymistapoja Kokonaisvaltainen lähestymistapa (top-down) etsitään kerralla koko kohdealuetta kuvaavaa mallia hankalaa, jos kohdealue

Lisätiedot

Pisteytysohje loppuraporttien vertaisarviointiin

Pisteytysohje loppuraporttien vertaisarviointiin Pisteytysohje loppuraporttien vertaisarviointiin Pisteytys olettaa kaikkien kuvattujen vaatimusten täyttymistä pistemäärän saavuttamiseksi. Esimerkiksi: Raportti täyttää rakenteen ja kieliasun osalta kaikki

Lisätiedot

Harjoitustyö Case - HelpDesk

Harjoitustyö Case - HelpDesk Harjoitustyö Case - HelpDesk Harjoitustyön Case: HelpDesk -sovellus Tietotekniikkatoimittaja AB ja asiakas X ovat viime vuonna sopineet mikrotukiyksikön ulkoistamisesta X:ltä AB:n liikkeenjohdon vastuulle.

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen KEMIA Kemian päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta kemian opiskeluun T2 ohjata ja

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

Lisätiedot

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

ISO Standardisarja Eräitä ulottuvuuksia Kari Komonen

ISO Standardisarja Eräitä ulottuvuuksia Kari Komonen ISO 55000 Standardisarja Eräitä ulottuvuuksia 6.11.2014 Kari Komonen Eräitä käsitteitä omaisuus, omaisuuserä kohteet, asiat tai kokonaisuudet, joilla on tai voi olla arvoa organisaatiolle omaisuudenhallinta

Lisätiedot

Määrittely- ja suunnittelumenetelmät

Määrittely- ja suunnittelumenetelmät Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka

Lisätiedot

Ohjelmointi 1 / syksy /20: IDE

Ohjelmointi 1 / syksy /20: IDE Ohjelmointi 1 / syksy 2007 10/20: IDE Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/8 Tämän luennon rakenne

Lisätiedot

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. II Johdanto olio-ohjelmointiin

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. II Johdanto olio-ohjelmointiin 812347A Olio-ohjelmointi, 2015 syksy 2. vsk II Johdanto olio-ohjelmointiin Sisältö 1. Abstraktiosta 2. Olio-ohjelmoinnin historiaa 3. Olioparadigmasta 4. Peruskäsitteiden esittely 2 II.1 Abstraktiosta

Lisätiedot

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1 Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän

Lisätiedot

UML - unified modeling language

UML - unified modeling language UML - unified modeling language Lähtökohtana: Booch, Rumbaugh, Jacobsson Tavoitteena Unified Method - syntyykö? Kehittäjänä: Rational Inc. Standardointi: Object Management Group (OMG) - vaiheessa Lähteet:

Lisätiedot

Määrittelyvaihe. Projektinhallinta

Määrittelyvaihe. Projektinhallinta Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti

Lisätiedot

Mallintarkistus ja sen

Mallintarkistus ja sen VERSIO 0.1 LUONNOS Mallintarkistus ja sen soveltaminen PLCohjelmien verifioinnissa AS-0.3200 Automaatio- ja systeemitekniikan projektityöt -projektisuunnitelma Markus Hartikainen 2/1/2009 Sisältö 1. Projektityön

Lisätiedot

Ohjelmistotuotteen hallinnasta

Ohjelmistotuotteen hallinnasta Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista

Lisätiedot

8. Kehysarkkitehtuurit

8. Kehysarkkitehtuurit 8. Kehysarkkitehtuurit Johdanto Kehystyypit Esimerkki: Simulointikehyksen malleja Kehyspohjainen ohjelmistokehitys Kehykset ja suunnittelumallit Esimerkkikehys Kehysten toteutuksesta Kehysten etuja ja

Lisätiedot

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7 Viitearkkitehtuurin suunnitteluprosessi Ohje v.0.7 Viitearkkitehtuurin suunnitteluprosessi XX.XX.201X 2 (13) Sisällys 1. Johdanto... 3 2. Viitearkkitehtuurin suunnitteluprosessin vaiheet... 3 2.1. Vaihe

Lisätiedot

Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja

Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja 582104 Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja 1 Arkkitehtuurisuunnittelu Ohjelmistoarkkitehtuurin määritelmä & arkkitehtuurisuunnittelun lähtökohta ja tavoitteet Kerrosarkkitehtuuri

Lisätiedot

Tuoterunko hajautetussa ympäristössä

Tuoterunko hajautetussa ympäristössä Timo Kuosmanen Tuoterunko hajautetussa ympäristössä Tietotekniikan pro gradu -tutkielma 1. maaliskuuta 2007 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Tekijä: Timo Kuosmanen Yhteystiedot: tkuo@iki.fi

Lisätiedot

Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille

Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille Liite Kansallinen vaativuustaso / eurooppalaisen tutkintojen viitekehyksen taso Taso1 Tutkinnot, oppimäärät ja

Lisätiedot

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Terveyden

Lisätiedot

Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen

Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen So far Toimeksianto: Opiskelun ja opetuksen tuen ja hallinnon viitearkkitehtuuri Tietoarkkitehtuurin osuuteen liittyen Synergiaryhmä 4.12.2014 linjannut,

Lisätiedot

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Matti Luukkainen 10.12.2009 Tässä esitetty esimerkki on mukaelma ja lyhennelmä Robert Martinin kirjasta Agile and Iterative Development löytyvästä

Lisätiedot

Vektorien pistetulo on aina reaaliluku. Esimerkiksi vektorien v = (3, 2, 0) ja w = (1, 2, 3) pistetulo on

Vektorien pistetulo on aina reaaliluku. Esimerkiksi vektorien v = (3, 2, 0) ja w = (1, 2, 3) pistetulo on 13 Pistetulo Avaruuksissa R 2 ja R 3 on totuttu puhumaan vektorien pituuksista ja vektoreiden välisistä kulmista. Kuten tavallista, näiden käsitteiden yleistäminen korkeampiulotteisiin avaruuksiin ei onnistu

Lisätiedot

Palvelun versio 1.0 Toimeenpanopalvelun tunnus (ks. M ) 10fea, 9c2f, 4760, 9095, f4f9295f4b19

Palvelun versio 1.0 Toimeenpanopalvelun tunnus (ks. M ) 10fea, 9c2f, 4760, 9095, f4f9295f4b19 1 5. Luokittamispalvelu 5.1. Palveluinformaatio Palvelun nimi Luokittamispalvelu Palvelun versio 1.0 Toimeenpanopalvelun tunnus (ks. M14.4.42) 10fea, 9c2f, 4760, 9095, f4f9295f4b19 5.2 Avainkäsitteet 5.2.1

Lisätiedot

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Tällä kurssilla on tutustuttu ohjelmistojen mallintamiseen oliomenetelmiä ja UML:ää käyttäen Samaan aikaan järjestetyllä kurssilla on käsitelty

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA, Järjestelmäarkkitehtuuri (TK081702) SOA SOA-arkkitehtuuri perustuu xml:ään ja Web Services teknologioihin Mahdollistaa joustavan mukautumisen tuleviin muutoksiin Kustannustehokas Toteutukset perustuvat

Lisätiedot

Työn ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework

Työn ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework Työn ositusmalleista Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Walker Royce, Software Project Management, A Unified Framework 1 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata:

Lisätiedot

TIEA241 Automaatit ja kieliopit, syksy Antti-Juhani Kaijanaho. 16. marraskuuta 2015

TIEA241 Automaatit ja kieliopit, syksy Antti-Juhani Kaijanaho. 16. marraskuuta 2015 ja ja TIEA241 Automaatit ja kieliopit, syksy 2015 Antti-Juhani Kaijanaho NFA:ksi TIETOTEKNIIKAN LAITOS 16. marraskuuta 2015 Sisällys ja NFA:ksi NFA:ksi Kohti säännöllisiä lausekkeita ja Nämä tiedetään:

Lisätiedot

Ohjelmistojen mallintaminen. Matti Luukkainen

Ohjelmistojen mallintaminen. Matti Luukkainen Ohjelmistojen mallintaminen Matti Luukkainen Kurssin aihepiiri: ohjelmistotuotannon alkeita [wikipedia]: Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään,

Lisätiedot

Ohjelmistojen mallintaminen, mallinnustekniikat käytännössä

Ohjelmistojen mallintaminen, mallinnustekniikat käytännössä 582104 Ohjelmistojen mallintaminen, mallinnustekniikat käytännössä 1 Sisältö Oliomenetelmien taustaa Kirjastojärjestelmän käyttötapaukset Kirjastojärjestelmän luokkamalli 2 Oliosuuntautunut suunnittelumenetelmä

Lisätiedot

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 582101 - Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 1 Toteutuksesta ja testauksesta Suunnitteluprosessista Tarkan tason luokkasuunnittelu Siirtyminen UML-kaavioista Java-toteutukseen

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

käyttötapaukset mod. testaus

käyttötapaukset mod. testaus käyttötapaukset Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Kartta hyväksyntä määrittely suunnittelu suunnittelu mod. testaus integrointi sys. testaus Ylläpito koodaus (toteutus)

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia tehtäviä:

Lisätiedot

Hyvät t käytännöt t julkisiksi miksi ja miten?

Hyvät t käytännöt t julkisiksi miksi ja miten? Hyvät t käytännöt t julkisiksi miksi ja miten? Olemme kaikki kuulleet sanottavan, että virheistä opitaan ja kantapää on hyvä opettaja. Tekevälle tapahtuu virheitä ja niiden salliminen on välttämätöntä,

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen 1 FYSIIKKA Fysiikan päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta fysiikan opiskeluun T2 ohjata

Lisätiedot

Tuoterunkoarkkitehtuurit. Ohjelmistoarkkitehtuurit kevät Uudelleenkäyttö. Johannes Koskinen.

Tuoterunkoarkkitehtuurit. Ohjelmistoarkkitehtuurit kevät Uudelleenkäyttö. Johannes Koskinen. Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 11. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta,

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

Lisätiedot

Kurssin sisältö. Kurssilla vähemmän. Johdatus ohjelmistotekniikkaan. Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan?

Kurssin sisältö. Kurssilla vähemmän. Johdatus ohjelmistotekniikkaan. Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan? Kurssin sisältö Johdatus ohjelmistotekniikkaan 2 0 0 8 Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan? Mitä työkaluja ohjelmistoja kehitettäessä käytetään ja miten? Historiaa

Lisätiedot

Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä

Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä 582104 Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä 1 Luokkamallin lisäpiirteitä Erilaiset yhteystyypit kooste kompositio Muita luokkien välisiä suhteita riippuvuudet periytyminen eli luokkahierarkia

Lisätiedot

VBE II Tulosseminaari Teknologian valmiusaste. Virtuaalirakentamisen Laboratorio Jiri Hietanen

VBE II Tulosseminaari Teknologian valmiusaste. Virtuaalirakentamisen Laboratorio Jiri Hietanen VBE II Tulosseminaari Teknologian valmiusaste 1 2 Sisältö Tietomalleihin perustuva järjestelmä Järjestelmän osien valmiusaste Rakennuksen tietomallien tuottaminen Rakennuksen tietomalleihin perustuvat

Lisätiedot

Juulin kehittäminen: tilannekatsaus

Juulin kehittäminen: tilannekatsaus Juulin kehittäminen: tilannekatsaus VIRTA-julkaisuyhteyshenkilöiden kokous, 4.11.2016 Jyrki Ilva Juuli-julkaisutietoportaali Juuli-portaali (www.juuli.fi) ollut käytössä kesäkuusta 2013 lähtien Uutta dataa

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

Scrumin käyttö ketterässä sovelluskehityksessä

Scrumin käyttö ketterässä sovelluskehityksessä Scrumin käyttö ketterässä sovelluskehityksessä 9.4.2008 Janne Kuha Manager, Java Services Descom Oy Janne Kuha Manager, Java Services janne.kuha@descom.fi Kuka? Descom Oy:llä, sitä ennen Wanadu Inc., Mountain

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole

Lisätiedot

Hyvä ympäristölupahakemus

Hyvä ympäristölupahakemus Hyvä ympäristölupahakemus Valvojan näkökulma Uudenmaan ELY-keskus, Ympäristövalvonta, Heli Antson 4.12.2015 Valvojan toiveita hyvälle lupahakemukselle: Millainen ympäristölupahakemus - sellainen lupapäätös!

Lisätiedot

11/20: Konepelti auki

11/20: Konepelti auki Ohjelmointi 1 / syksy 2007 11/20: Konepelti auki Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/11 Tämän luennon

Lisätiedot

Ohjelmoinnin perusteet Y Python

Ohjelmoinnin perusteet Y Python Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2009 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2009 1 / 28 Puhelinluettelo, koodi def lue_puhelinnumerot(): print "Anna lisattavat nimet ja numerot." print

Lisätiedot

Sisällönhallinnan menetelmiä

Sisällönhallinnan menetelmiä Sisällönhallinnan menetelmiä Airi Salminen Jyväskylän yliopisto http://www.cs.jyu.fi/~airi/ Suomalaisen lainsäädäntötyön tiedonhallinta: suuntana semanttinen web RASKE2-projektin loppuseminaari Eduskunnassa

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op) 581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun

Lisätiedot

P e d a c o d e ohjelmointikoulutus verkossa

P e d a c o d e ohjelmointikoulutus verkossa P e d a c o d e ohjelmointikoulutus verkossa J2EE - EJB Session Bean Teoria ja ohjelmointitehtävät J2EE - EJB Session Bean 3 YLEISKATSAUS KURSSIN SISÄLTÖIHIN... 7 YLEISKATSAUS KURSSIN SISÄLTÖIHIN... 7

Lisätiedot

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio 1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...

Lisätiedot