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-

Ohjelmistokehykset ohjelmistorunkoja uudelleenkäyttö olioperustaisista ohjelmistorunko

Ohjelmistokehykset ohjelmistorunkoja uudelleenkäyttö olioperustaisista ohjelmistorunko Ohjelmistokehykset Määritelmä & tavoitteet, taustaa & peruskäsitteitä, kehykset vs. suunnittelumallit, erikoistamisrajapinnat & kontrollinkulku, kehystyypit, kehysten rakenne ja evoluutio, esimerkki: JHotDraw,

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2008

Ohjelmistoarkkitehtuurit. Syksy 2008 Ohjelmistoarkkitehtuurit Syksy 2008 Kai Koskimies 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto, Tampereen yliopisto, Teknillinen korkeakoulu, Turun yliopisto, Vaasan yliopisto, Tampereen teknillinen

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

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

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

Ohjelmistoarkkitehtuuri

Ohjelmistoarkkitehtuuri Ohjelmistoarkkitehtuurien ylläpito Arkkitehtuurityylejä ja laatuvaatimuksia Arkkitehtuurin uudistaminen Arkkitehtuurin uudistamisen malleja Arkkitehtuurin arviointi TTY Ohjelmistotekniikka 1 Ohjelmistoarkkitehtuuri

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

12. Kehysarkkitehtuurit

12. Kehysarkkitehtuurit 12. Kehysarkkitehtuurit Johdanto Kehystyypit Kehysten osittaminen Kehykset ja suunnittelumallit Kehysten etuja ja ongelmia Yhteenvetoa Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Johdanto

Lisätiedot

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

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

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

ohjelman arkkitehtuurista.

ohjelman arkkitehtuurista. 1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä

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

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit Viestinvälitysarkkitehtuurit

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

Ohjelmistoarkkitehtuurit. Kevät 2014

Ohjelmistoarkkitehtuurit. Kevät 2014 Ohjelmistoarkkitehtuurit Kevät 2014 Samuel Lahtinen (Johannes Koskinen) http://www.cs.tut.fi/~ohar/ 1 Yleisiä asioita Luennot keskiviikkoisin 10:15- Viikkoharjoitukset jatkuvat taas 8.4. Arviointien paikat

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

9. Muunneltavuuden hallinta

9. Muunneltavuuden hallinta 9. Muunneltavuuden hallinta Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat, jotka auttavat kuvaamaan, toteuttamaan ja hyödyntämään tuoterungon mahdollistamaa ohjelmistotuotteiden

Lisätiedot

OHJELMISTOARKKITEHTUURIT

OHJELMISTOARKKITEHTUURIT SAIMAAN AMMATTIKORKEAKOULU Tekniikka Lappeenranta Tietotekniikan koulutusohjelma Ohjelmistotekniikka Juha-Matti Seppänen OHJELMISTOARKKITEHTUURIT Opinnäytetyö 2010 TIIVISTELMÄ Juha-Matti Seppänen Ohjelmistoarkkitehtuurit,

Lisätiedot

Muutamia peruskäsitteitä

Muutamia peruskäsitteitä Muutamia peruskäsitteitä Huom. 1: nämä peruskäsitteet eivät muodosta hyvin määriteltyä keskenään yhteensopivien käsitteiden joukkoa, vaan käsitteet ovat osittain päällekkäisiä ja eri yhteyksissä niillä

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (7) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

3. Käsiteanalyysi ja käsitekaavio

3. Käsiteanalyysi ja käsitekaavio 3. Käsiteanalyysi ja käsitekaavio lehtori Pasi Ranne Metropolia ammattikorkeakoulu E-mail: pasi.ranne@metropolia.fi sivu 1 Käsiteanalyysi Selvitetään mitä tietokantaan pitää tallentaa Lähtökohtana käyttäjien

Lisätiedot

TIE-20200 Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely

TIE-20200 Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely Lyhyt UML-opas UML -pikaesittely UML, Unified Modeling Language Standardoitu, yleiskäyttöinen mallinnuskieli, jota ylläpitää/hallitsee (Object Management Group) OMG Historiaa: 90-luvulla oli paljon kilpailevia

Lisätiedot

Arkkitehtuuri muutosagenttina

Arkkitehtuuri muutosagenttina Arkkitehtuuri muutosagenttina Smarter Processes, Development & Integration Hannu Salminen CTO OP-Pohjola 2013 IBM Corporation Taustaa Nykyinen IT-arkkitehtuuri ja liiketoimintatarpeet eivät kohtaa OP-Pohjolan

Lisätiedot

TIETOTEKNIIKAN KOULUTUSOHJELMA

TIETOTEKNIIKAN KOULUTUSOHJELMA TIETOTEKNIIKAN KOULUTUSOHJELMA Tietotekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Tietotekniikan koulutusohjelmasta valmistuneet insinöörit sijoittuvat suunnittelu-, ohjelmointi-, esimies-,

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

1. Olio-ohjelmointi 1.1

1. Olio-ohjelmointi 1.1 1. Olio-ohjelmointi 1.1 Sisällys Olio-ohjelmointi on eräs ohjelmointiparadigma. Olio-ohjelmoinnin muotoja. Ohjelmiston analyysi ja suunnittelu. Olioparadigman etuja ja kritiikkiä. 1.2 Ohjelmointiparadigmoja

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

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

Lisätiedot

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi 1. Luento: Sulautetut Järjestelmät Arto Salminen, arto.salminen@tut.fi Agenda Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit

Lisätiedot

Tietorakenteet ja algoritmit - syksy 2015 1

Tietorakenteet ja algoritmit - syksy 2015 1 Tietorakenteet ja algoritmit - syksy 2015 1 Tietorakenteet ja algoritmit - syksy 2015 2 Tietorakenteet ja algoritmit Johdanto Ari Korhonen Tietorakenteet ja algoritmit - syksy 2015 1. JOHDANTO 1.1 Määritelmiä

Lisätiedot

10. Muunneltavuuden hallinta: variaatiopisteet

10. Muunneltavuuden hallinta: variaatiopisteet 10. Muunneltavuuden hallinta: variaatiopisteet Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat, jotka auttavat kuvaamaan, toteuttamaan ja hyödyntämään ohjelmistotuotteiden variaatiota.

Lisätiedot

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa 4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat

Lisätiedot

Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari Korhonen

Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari Korhonen Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari 1 1. JOHDANTO 1.1 Määritelmiä 1.2 Tietorakenteen ja algoritmin valinta 1.3 Algoritmit ja tiedon määrä 1.4 Tietorakenteet ja toiminnot 1.5 Esimerkki:

Lisätiedot

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Fiksumpi käyttöliittymä kuntaan Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Otso Kivekäs 20.8.2015 Otso Kivekäs+ Codento Kehittämispäällikkö, kunta-alan projektit

Lisätiedot

11.4. Context-free kielet 1 / 17

11.4. Context-free kielet 1 / 17 11.4. Context-free kielet 1 / 17 Määritelmä Tyypin 2 kielioppi (lauseyhteysvapaa, context free): jos jokainenp :n sääntö on muotoa A w, missäa V \V T jaw V. Context-free kielet ja kieliopit ovat tärkeitä

Lisätiedot

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

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

Lisätiedot

17/20: Keittokirja IV

17/20: Keittokirja IV Ohjelmointi 1 / syksy 2007 17/20: Keittokirja IV Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/10 Tavoitteita

Lisätiedot

Onnistunut Vaatimuspohjainen Testaus

Onnistunut Vaatimuspohjainen Testaus Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen

Lisätiedot

Yhteydelle voi antaa nimen kumpaankin suuntaan Sille ei tarvise antaa lainkaan nimeä Yhteysnimen asemasta tai lisäksi voidaan käyttää roolinimiä

Yhteydelle voi antaa nimen kumpaankin suuntaan Sille ei tarvise antaa lainkaan nimeä Yhteysnimen asemasta tai lisäksi voidaan käyttää roolinimiä DO NOT PRINT THIS DOCUMENT DO NOT PRINT THIS DOCUMENT Olioiden väliset yhteydet Yhteyden nimi Nimen lukusuunta pankkitili 0..10 Omistaja-> 1..3 asiakas

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (6) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus Versio: 1.0 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Arkkitehtuurikehyksen

Lisätiedot

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Tuotanto, konseptit, oppiminen yritystoiminnan kehittämisen uudet näkökulmat 25.5.2011 Aalto-yliopiston

Lisätiedot

Ohjelmistoarkkitehtuurit

Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurit Tuoteperheet Tuoterunkoarkkitehtuurit 10.10.2013 1 Perinteisessä ohjelmistotuotannossa on keskitytty uusien ohjelmistojen laadukkaaseen tuottamiseen Erikoistuneista ainutlaatuisista

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

10. Muunneltavuuden hallinta: variaatiopisteet

10. Muunneltavuuden hallinta: variaatiopisteet Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 10. Muunneltavuuden hallinta: variaatiopisteet Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat,

Lisätiedot

Kertaus: yleistys-erikoistus ja perintä

Kertaus: yleistys-erikoistus ja perintä Kertaus: yleistys-erikoistus ja perintä Nauta, Lehmä ja Kuttu ovat Kotieläimiä, Kotieläimet Eläimiä Kotieläimillä (siis myös Naudoilla, Lehmillä ja Kutuilla) on Omistaja Kuttu ja Lehmä toteuttavat rajapinnan

Lisätiedot

19/20: Ikkuna olio-ohjelmoinnin maailmaan

19/20: Ikkuna olio-ohjelmoinnin maailmaan Ohjelmointi 1 / syksy 2007 19/20: Ikkuna olio-ohjelmoinnin maailmaan Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007

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

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT KOULUTUKSEN KOHDERYHMÄ SISÄLTÖ Koulutuksen tavoitteena on antaa opiskelijalle valmiudet uusien tietoteknisten menetelmien ja välineiden hyödyntämiseen.

Lisätiedot

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta.

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Malli-näkym kymä-ohjain arkkitehtuurit (Model-View View-Controller, MVC) Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Lähtökohdat: Sovelluksen

Lisätiedot

Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy. 2005 Mermit Business Applications

Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy. 2005 Mermit Business Applications Helia Ohjelmointitaito 14.3.2005 Tuomas Kaipainen Mermit Business Applications Oy Esityksen sisältö Mermit yrityksenä Perustiedot Toimintamalli Mermit työpaikkana ohjelmistoinsinöörille Esimerkkiprojekti

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

HSMT J2EE & EJB & SOAP &...

HSMT J2EE & EJB & SOAP &... HSMT J2EE & EJB & SOAP &... Ville Leppänen HSMT, c Ville Leppänen, IT, Turun yliopisto, 2011 p.1/15 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

OHJ-4301 Sulautettu Ohjelmointi

OHJ-4301 Sulautettu Ohjelmointi OHJ-4301 Sulautettu Ohjelmointi (http://www.cs.tut.fi/~sulo/) 5op, to 12-14, TB 109 Arto Salminen, arto.salminen@tut.fi Läpäisyvaatimukset Hyväksytysti suoritetut: Tentti Harjoitustyöt Harjoitustyöt 3

Lisätiedot

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori SATAFOOD KEHITTÄMISYHDISTYS RY Laatu- ja ympäristöjärjestelmät 24.9.2015 Marika Kilpivuori OMAVALVONTA ISO 9001 ISO / FSSC 22000 BRC ISO 14001 OHSAS 18001 IFS 1 MIKÄ JÄRJESTELMÄ MEILLÄ TARVITAAN? Yrityksen

Lisätiedot

Suunnittelumallien käyttö ohjelmistosuunnittelussa

Suunnittelumallien käyttö ohjelmistosuunnittelussa Suunnittelumallien käyttö ohjelmistosuunnittelussa Mika Rantakeisu Rovaniemen ammattikorkeakoulu Avoin ammattikorkeakoulu mika.rantakeisu@edu.ramk.fi Tiivistelmä Tämä on selvitys suunnittelumallien käytöstä

Lisätiedot

Oppijan palvelukokonaisuus. Tietomallinnuksen laaja katselmointi 7.12.2011

Oppijan palvelukokonaisuus. Tietomallinnuksen laaja katselmointi 7.12.2011 Oppijan palvelukokonaisuus Tietomallinnuksen laaja katselmointi 7.12.2011 Sisältö Tietoarkkitehtuuri Tietomallit ja sanastot Tietomallinnus Tietomallinnus hankkeessa (Hankkeessa käytetyt keskeisimmät mallinnuselementit)

Lisätiedot

Suomen avoimien tietojärjestelmien keskus COSS ry

Suomen avoimien tietojärjestelmien keskus COSS ry Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

TIE-20200 Ohjelmistojen suunnittelu

TIE-20200 Ohjelmistojen suunnittelu TIE-20200 Ohjelmistojen suunnittelu Luento 6: suunnittelua Samuel Lahtinen TIE-20200 Samuel Lahtinen 1 Ajankohtaista Harjoitustyö Protosessioita tällä viikolla Ohjelmassa tänään Ohjelmistojen suunnittelujuttuja

Lisätiedot

Tiedonsiirto- ja rajapintastandardit

Tiedonsiirto- ja rajapintastandardit Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen

Lisätiedot

Tapahtumakalenteri & Jäsentietojärjestelmä Toteutus

Tapahtumakalenteri & Jäsentietojärjestelmä Toteutus Tapahtumakalenteri & Jäsentietojärjestelmä Toteutus Henri Kinnunen, Seppo Tompuri, Tero Malkki, Matti Heiskanen, Tommi Rönkönharju, Tuomas Valkeapää Sisällysluettelo 1. Alkusanat...2 2. Käyttötapaukset...2

Lisätiedot

KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0

KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0 KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014 Käyttäjätutkimus ja käsitteellinen suunnittelu Järjestelmän nimi versio 1.0 Jakelu: Tulostettu: 201543 Samuli Hirvonen samuli.hirvonen@student.tut.fi

Lisätiedot

2. Olio-ohjelmoinista lyhyesti 2.1

2. Olio-ohjelmoinista lyhyesti 2.1 2. Olio-ohjelmoinista lyhyesti 2.1 Sisällys Yleistä. Oliot ja luokat. Attribuutit. Olioiden esittely ja alustus. Rakentajat. Olion operaation kutsuminen. 2.2 Yleistä Olio-ohjelmointia käsitellään hyvin

Lisätiedot

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Arkkitehtuuriin vaikuttavat ympäristötekijät Jo kehittämisen alkuvaiheessa on tarpeellista hahmotella arkkitehtuurin perusratkaisu. Lähtökohdat

Lisätiedot

Taltioni teknisen alustan arviointi

Taltioni teknisen alustan arviointi Taltioni teknisen alustan arviointi Taltioni sidosryhmätilaisuus, 10.1.2012 Jaakko Lähteenmäki, Niilo Saranummi 1/11/2012 2 Selvitystyön kohde Selvitystyö: VTT & Fujitsu Keskeiset vaatimukset Taltioni-palvelulle?

Lisätiedot

11.10.2013 Tekijän nimi

11.10.2013 Tekijän nimi 11.10.2013 Tekijän nimi Arkkitehtuuri kehittämisen välineenä Kokonaisarkkitehtuuri hallitun muutoksen avaimena Etelä-Savon maakuntaliitto 10.10.2013 Markku Nenonen Tutkijayliopettaja Mikkelin ammattikorkeakoulu

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

Lomalista-sovelluksen määrittely

Lomalista-sovelluksen määrittely Thomas Gustafsson, Henrik Heikkilä Lomalista-sovelluksen määrittely Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikka Dokumentti 14.10.2013 Tiivistelmä Tekijä(t) Otsikko Sivumäärä Aika Thomas

Lisätiedot

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia

Lisätiedot

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi

Lisätiedot

KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI. Kehitysvammaliitto / Hyvät käytännöt -projekti

KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI. Kehitysvammaliitto / Hyvät käytännöt -projekti 1 KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI Kehitysvammaliitto / Hyvät käytännöt -projekti 2 Tuotetaan käytännöstä tietoa yhdessä Käytännön kuvaamisen tarkoituksena on

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu

Lisätiedot

CT30A2800. Osa I: (n. 90 min) Käyttäjäkeskeinen Suunnittelu?

CT30A2800. Osa I: (n. 90 min) Käyttäjäkeskeinen Suunnittelu? CT30A2800 Osa I: (n. 90 min) Käyttäjäkeskeinen Suunnittelu? Sisältö Mitä on käyttäjäkeskeisyys ( 5 kalvoa ) Käyttäjäkeskeisyyteen vaikuttavat voimat (8 kalvoa) Käyttäjäkeskeisyys on usein kontekstisidonnaista

Lisätiedot

http://www.enteract.com/~bradapp/docs/patterns-intro.html http://www.hillside.net/patterns/

http://www.enteract.com/~bradapp/docs/patterns-intro.html http://www.hillside.net/patterns/ 5. Suunnittelumallit Suunnittelumallin käsite Suunnittelumallien hyötyjä Suunnittelumallien kuvaaminen Esimerkki: Rekursiokooste Antisuunnittelumallit Suunnittelumallit ja UML Mallikielet Suunnittelumallit

Lisätiedot

UML työvälineenä ja tutkimuskohteena

UML työvälineenä ja tutkimuskohteena UML työvälineenä ja tutkimuskohteena Kai Koskimies, Johannes Koskinen, Mika Maunumaa, Jari Peltonen, Petri Selonen, Mika Siikarla & Tarja Systä Tampereen teknillinen yliopisto Ohjelmistotekniikan laitos

Lisätiedot

Risto Pelin Microsoft Project 2002 projekti- ja yritystason järjestelmänä

Risto Pelin Microsoft Project 2002 projekti- ja yritystason järjestelmänä Risto Pelin Microsoft Project 2002 projekti- ja yritystason järjestelmänä PROJEKTIJOHTAMINEN OY RISTO PELIN 3 Sisällysluettelo ESIPUHE 7 OSA I PROJEKTIN HALLINTA PROJEKTITASOLLA 1 JOHDANTO 11 1.1 Projektiohjelmien

Lisätiedot

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Software design and specification methods Kurssin henkilökunta ja sponsori Luennoitsija DI Antti Karanta, Napa Oy www.napa.fi Assistentti TkL

Lisätiedot

StanForD-XML. Juha-Antti Sorsa, Tapio Räsänen, Vesa Imponen

StanForD-XML. Juha-Antti Sorsa, Tapio Räsänen, Vesa Imponen Projektiryhmä StanForD-XML Juha-Antti Sorsa, Tapio Räsänen, Vesa Imponen Rahoittajat Koskitukki Oy, Metsähallitus, Metsäliitto Osuuskunta, Pölkky Oy, Stora Enso Oyj, UPM- Kymmene Oyj, Vapo Timber Oy, Yksityismetsätalouden

Lisätiedot

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA

Lisätiedot

Viestinvälitysarkkitehtuurit

Viestinvälitysarkkitehtuurit Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti hajautettuja Komponenttien palveluja ei tiedetä tarkasti etukäteen Komponentteja 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

UML- mallinnus: Tilakaavio

UML- mallinnus: Tilakaavio UML- mallinnus: Tilakaavio Karkea kuvaus UML- kaavioiden käytöstä ohjelmistonkehityksen eri vaiheissa ja tehtävissä. Mallinnus tilakaavioilla Tilakaaviolla kuvataan yhden luokan olioiden tilan muuttumista

Lisätiedot

Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita.

Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita. Moniperintä 2 Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita. Oliomallinnus TITE.2040 Hannu K. Niinimäki 1 Delegointi 1 Moniperinnän toteuttaminen

Lisätiedot

OHJELMISTOKEHITYS -suuntautumisvaihtoehto

OHJELMISTOKEHITYS -suuntautumisvaihtoehto OHJELMISTOKEHITYS -suuntautumisvaihtoehto Suuntautumisvaihtoehdon esittely 1. vuoden opiskelijoille Kari Laitinen www.oamk.fi/~karil/opetus.html Ohjelmistokehitys -opintosuunnan valitsevista henkilöistä

Lisätiedot

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä OHJ-5201 Web-palveluiden toteutustekniikat Kurssisisällöstä Tarja Systä 1 Yleistä Esitietovaatimukset OHJ-1400 Olio-ohjelmoinnin peruskurssi (pakollinen) OHJ-5010 Hajautettujen järjestelmien perusteet

Lisätiedot

HOJ J2EE & EJB & SOAP &...

HOJ J2EE & EJB & SOAP &... HOJ J2EE & EJB & SOAP &... Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/18 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

Olio-ohjelmoinnissa luokat voidaan järjestää siten, että ne pystyvät jakamaan yhteisiä tietoja ja aliohjelmia.

Olio-ohjelmoinnissa luokat voidaan järjestää siten, että ne pystyvät jakamaan yhteisiä tietoja ja aliohjelmia. 4. Periytyminen 4.1. Johdantoa Käytännössä vähänkään laajemmissa ohjelmissa joudutaan laatimaan useita luokkia, joiden pitäisi pystyä välittämään tietoa toisilleen. Ohjelmien ylläpidon kannalta olisi lisäksi

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