Arkkitehtuurityylit ohjelmarakenteen perustana
|
|
- Maarit Katajakoski
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 arvosana päiväys arvostelija Arkkitehtuurityylit ohjelmarakenteen perustana Teemu Tverin Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET THE UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion - Faculty Matemaattis-luonnontieteellinen tdk Tekijä Författare - Author Teemu Johannes Tverin Työn nimi Arbetets titel - Title Arkkitehtuurityylit ohjelmarakenteen perustana Oppiaine Läroämne - Subject Tietojenkäsittelytiede Työn laji Arbetets art - Level Tutkielma Tiivistelmä Referat - Abstract Aika Datum Month and year Laitos Institution - Department Tietojenkäsittelytieteen laitos Sivumäärä Sidoantal Number of pages 20 sivua + 0 liitettä Tässä tutkielmassa esitellään ohjelmistojen arkkitehtuurityylejä, arkkitehtuurityylien merkitystä ohjelmiston rakenteen kannalta. Lisäksi esitellään arkkitehtuurityylien käyttöä erilaisten ohjelmistojen perusrakenteen pohjana. Lisäksi esitellään eri arkkitehtuurityylien sovelluksia. ACM Computer Classification System (CCS): A.1 [Introductory and survey], D.2.11 [Software Architectures] Avainsanat Nyckelord -Key words ohjelmistoarkkitehtuuri, arkkitehtuurityyli, ohjelmistosuunnittelu Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information
3 Sisältö 1 Johdanto Arkkitehtuurityylien jaottelu Arkkitehtuurityyli ohjelmiston ryhmittelyn perustana Kerrosarkkitehtuuri Kerrosarkkitehtuurityylin sovelluksia Tietovuoarkkitehtuuri Palveluperustaiset- ja sovellusaluekohtaiset tyylit Asiakas-palvelin arkkitehtuurityyli Malli-näkymä-ohjain -arkkitehtuuri Yhteenveto...18 Lähteet... 20
4 1 1 Johdanto Nykyaikaisessa ohjelmiston tuottamisessa on tärkeää määritellä ja dokumentoida ohjelmiston rakenne huolellisesti jo suunnitteluvaiheessa. Ohjelmistojen koko on kasvanut sekä niiden monimutkaisuus lisääntynyt. Ohjelmiston arkkitehtuuri tarkoittaa ohjelmiston perusrakennetta. Se määrittelee ohjelmiston komponentit sekä niiden suhteet toisiinsa [KoMi05, s. 18]. Olennaista ohjelmiston arkkitehtuurissa on, että se ei pelkästään jaa ohjelmistoa osiin, vaan myös määrittelee ohjelmistoon muodostuvien alijärjestelmien välisiä suhteita. Arkkitehtuurin tehtävänä on ottaa kantaa keskeisiin ohjelmiston ratkaisuihin ja niissä käytettäviin ratkaisutapoihin [KoMi05, s. 19]. Ohjelmiston arkkitehtuurin dokumentointi on nykyaikaisessa ohjelmistotuotantoprojektissa ensiarvoisen tärkeää. Dokumentoimatonta arkkitehtuuria ei oikeastaan edes ole olemassa. Ohjelmiston arkkitehtuurin yksi perustehtävä on tarjota ohjelmiston sidosryhmille mahdollisuus muodostaa oma mielikuvansa tuotettavasta ohjelmistosta [Bass98, s. 28]. Arkkitehtuuri materialisoituu arkkitehtuurikuvauksena: jos arkkitehtuuria ei ole dokumentoitu kunnolla, joudutaan helposti tilanteeseen jossa projektin eri henkilöt tekevät kukin tahollaan olettamuksia tuotettavan ohjelmiston arkkitehtuurista [KoMi05, s. 20]. Jos nämä näkemykset poikkeavat toisistaan on projekti todennäköisesti ongelmissa. Arkkitehtuurityyli (architechtual style) on koko järjestelmää luonnehtiva korkeimman abstraktiotason suunnitteluratkaisu. Kirjallisuudessa arkkitehtuurityylistä käytetään myös termiä arkkitehtuurimalli (architectural pattern). Suunnittelumallit (design pattern) ovat arkkitehtuurityylien läheisiä sukulaisia, mutta niiden eroavaisuus on, että arkkitehtuurityyli on abstraktiotasoltaan suunnittelumallia korkeampi: kun suunnittelumalli voi esiintyä järjestelmässä monena ilmentymänä ratkaisten paikallisia suunnitteluongelmia, on arkkitehtuurityyli järjestelmää määräävä kokonaisrakenne [KoMi05, s. 125]. Arkkitehtuurityyli tarjoaa kokoelman valmiita alijärjestelmämalleja sekä määrittelee näiden vastuut ja keskinäiset suhteet [Busc96, s. 25]. Arkkitehtuurityylit ovat yleisiä,
5 sovelluksesta riippumattomia, kuvauksia järjestelmän arkkitehtuurista. Yleisesti arkkitehtuurimallia käytetään tuotettavan järjestelmän hahmottelun työkaluna. 2 Arkkitehtuurityyli asettaa rajat ja säännöt tuotettavan ohjelmiston arkkitehtuurille ja sitä käyttäen voidaan suunnitella toteutettavan järjestelmän rakenteellinen ja toiminnallinen runko. Arkkitehtuurityyli ohjaa järjestelmän kehitystyötä, esimerkiksi jokaista järjestelmään kehitettävää ominaisuutta tai alijärjestelmien tarkkaa suunnittelua ja alijärjestelmien välistä toimintaa [Busc96, s. 26]. Erilaisten järjestelmien vaatimuksia ajatellen on kehitetty erilaisia arkkitehtuurityylejä. Järjestelmälle sopivin arkkitehtuurityyli riippuu sille asetetuista vaatimuksista sekä sovellusalueesta [Busc96, s. 27]. Tunnetuimmat arkkitehtuurityylit ovat kerrosarkkitehtuurit, tietovuoarkkitehtuurit, asiakas-palvelin-arkkitehtuurit sekä sovellusaluekohtaisten arkkitehtuurien ryhmä. Näistä arkkitehtuurityyleistä kerros- ja tietovuoarkkitehtuurit ovat arkkitehtuurityylejä, jotka sopivat ohjelmiston komponenttien ryhmittelyyn ja näin ohjelmiston jäsentämiseen. Erityisesti kerrosarkkitehtuuria voidaan käyttää monenlaisten järjestelmien kuvaamiseen [KoMi05, s. 25]. Asiakas-palvelin-arkkitehtuurityylissä perusajatuksena on kapselointi. Tässä arkkitehtuurityylissä kapseloidaan tietyn arkkitehtuuritason resurssin (palvelin) hallinta siten, että resurssin käyttäjän (asiakas) ei tarvitse huolehtia resurssin käyttöön liittyvistä teknisistä ongelmista. Kapselointi toimii myös toiseen suuntaan, palvelin ei tunne asiakkaan teknistä toteutusta [KoMi05, s. 136]. Sovellusaluekohtaisten arkkitehtuurityylien ryhmä sisältää sellaisia arkkitehtuurityylejä, joiden on huomattu toimivan tietyllä sovellusalueella erityisen hyvin [KoMi05, s. 142]. Suurinta osaa järjestelmistä ei kuitenkaan voida rakentaa ainoastaan yhden arkkitehtuurityylin varaan [Busc96, s. 27]. Monien järjestelmien täytyy tukea laajaa joukkoa vaatimuksia, jotka voidaan saavuttaa vain useampia arkkitehtuurityylejä käyttäen. Käytännössä tämä voi tarkoittaa sitä, että esimerkiksi
6 kerrosarkkitehtuurityylillä suunniteltuun järjestelmään integroidaan osia, jotka noudattavat suunnittelultaan asiakas-palvelin-arkkitehtuurityyliä. 3 Arkkitehtuurityyli, tai yhdistelmä eri arkkitehtuurityyleistä ei ole valmis ohjelmiston arkkitehtuuri [Busc96 s. 27]. Se on ainoastaan rakenteellinen kehys ohjelmistolle. Arkkitehtuurityylit ovat ohjelmistoarkkitehtuurin suunnittelun avaintyökalu, mutta sopivimman vaihtoehdon valinta on usein vaivalloista, eikä oikean, tilanteeseen parhaiten sopivan arkkitehtuurityylin löytäminen ja valitseminen aina ole kiistatonta tai varmaa [AvZd05, s. 1].
7 4 2 Arkkitehtuurityylien jaottelu Buschmann et al. esittelevät teoksessaan Pattern-Oriented Software Architecture: A System of Patterns arkkitehtuurityylien jaottelun kategorioihin. Perusajatus jaottelulle on, että tiettyyn kategoriaan sisältyvät arkkitehtuurityylit auttavat ratkaisemaan samantapaisia ongelmia. [Busc96, s. 26]. Kategoriat ovat: jäsennysarkkitehtuurit (from mud to structure), hajautetut arkkitehtuurit (distributed systems), vuorovaikutusarkkitehtuurit (interactive systems), muokattavuutta tukevat arkkitehtuurit (adaptable systems). Jäsennysarkkitehtuurien ryhmään kuuluvat sellaiset arkkitehtuurit, joita käytetään ohjelmiston rakenteen puuroutumisen estämiseen. Näitä arkkitehtuurityylejä ovat esimerkiksi kerrosarkkitehtuurityyli sekä tietovuoarkkitehtuurityyli. Jäsennysarkkitehtuurit jakavat ohjelmiston pääasiallisen tehtävän suorituksen yhteistyötä tekeville järjestelmän osille. Jäsennysarkkitehtuureita käsitellään tutkielman luvussa 2. Hajautettujen arkkitehtuureiden ryhmään kuuluu arkkitehtuurityylejä, jotka sopivat hajautettujen järjestelmien pohjaksi. Esimerkiksi asiakas-palvelin-arkkitehtuurityylin voidaan ajatella kuuluvan hajautettuihin arkkitehtuureihin. Vuorovaikutusarkkitehtuurit ovat arkkitehtuureita, joiden pääasiallinen sovelluskohde ovat sellaiset järjestelmät, jotka sisältävät ihmisen ja tietokoneen välistä interaktiota. Eräs vuorovaikutusarkkitehtuuri on malli-näkymä-ohjain -arkkitehtuuri, jota käsitellään myöhemmin tässä tutkielmassa.
8 5 Muokattavuutta tukeviin arkkitehtuureihin kuuluvat sellaiset arkkitehtuurityylit, jotka tukevat vahvasti järjestelmän muokattavuutta sekä järjestelmien kykyä sopeutua kehittyvään teknologiaan ja muuttuviin toiminnallisiin vaatimuksiin.
9 6 3 Arkkitehtuurityyli ohjelmiston ryhmittelyn perustana Nykyaikaisen laajan ohjelmiston rakenne, saattaa ilman suunnittelua ohjaavaa aputyökalua, puuroutua komponenttien ja alijärjestelmien vaikeaselkoiseksi massaksi. Arkkitehtuurityyli, joka auttaa ohjelmiston rakennuspalasten ryhmittelyssä ja järjestämisessä, on keino välttää tämä ongelma [Busc96, s. 29]. On yleistä, että arkkitehtuurityyliä käytetään apuna juuri tämän ongelman esiintymisriskin pienentämiseen. Tällöin ryhmittelyyn perustuvan arkkitehtuurityylin mukaisessa järjestelmässä järjestelmän komponentit muodostavat joukkoja, joissa komponentit ovat samassa suhteessa keskenään ohjelmiston arkkitehtuurin kannalta. Tärkeimmät arkkitehtuurityylit, joita käytetään ohjelmiston ryhmittelyn perustana ovat kerrosarkkitehtuurit ja tietovuoarkkitehtuurit [KoMi05, s. 125]. Kerrosarkkitehtuuri voidaan ajatella tapana nähdä järjestelmä organisoituna käyttösuhteiden mukaan jaoteltuihin osiin, jotka koostuvat samassa asemassa käyttösuhteiden kannalta olevista komponenteista [KoMi05, s. 126]. Siksi tällainen arkkitehtuurityyli voidaan ymmärtää sekä järjestelmän hahmotus- että ryhmittelytekniikkana. 3.1 Kerrosarkkitehtuuri Kerrosarkkitehtuurin perusajatus on, että järjestelmä koostuu joukosta eri käsitetasoja. Nämä käsitetasot ovat itsenäisiä. Samalla käsitetasolla sijaitsevat järjestelmän palvelut muodostavat kerrosarkkitehtuurityylissä kerroksen [Busc96, s. 31]. Kuten kuvassa 1, kerrosarkkitehtuurin kerrokset on järjestetty nousevaan järjestykseen sopivaa abstrahointiperiaatetta käyttäen ja palvelukutsut kulkevat ainoastaan ylemmältä kerrokselta välittömästi seuraavalle alemmalle kerrokselle. Yleisin käytetty periaate on skaala laite-ihminen [KoMi05, s. 126]. Laitetta läheisimmät tasot tarjoavat yleisesti lähellä laitteistoa ja käyttöjärjestelmää olevia
10 palveluita ja ovat näin matalammalla tasolla kuin ihmistä lähellä olevat tasot, jotka yleisesti tarjoavat esimerkiksi käyttöliittymäpalveluja [KoMi05, s. 126]. 7 Kuva 1: Puhtaan kerrosarkkitehtuurityylin periaate. Kerrosarkkitehtuurin etu on sen rakenne, joka mahdollistaa ohjelmiston eri osien määrittelyn osissa eri käsitetasoilla. Jokaisella kerroksella on omat määritellyt rajapintansa ulospäin, joten ne eivät aseta rajoituksia muiden kerrosten toteuttamiselle tai käytölle [GrSh94, s. 11]. Rakenteen ansiosta on myös mahdollista muuttaa tai jopa toteuttaa uudelleen jokin yksittäinen kerros ilman, että muihin kerroksiin tarvitsee koskea. Pahimmillaan muuttamisen vaikutukset ulottuvat vain muutamaan lähimpään kerrokseen [GrSh94, s. 11]. Kerrosten abstraktiotasoja voi kuitenkin olla vaikea tunnistaa, sillä usein kerrokset ovat luonteeltaan niin teknisiä, että eri abstraktiotasojen nimeäminen ja erottaminen toisistaan käsitteellisesti on hankalaa [KoMi05, s. 126]. Siksi saatetaan tarvita toinen tapa löytää järjestelmän kerrostusperiaate. Tällöin kerrostusperiaatteen ratkaisee se, että ylempi kerros kutsuu itseään alemman kerroksen tarjoamia palveluita ja tarjoaa palveluitaan itseään ylemmälle kerrokselle. Abstraktiotasoltaan korkeammat palvelut toteutetaan käyttäen abstraktiotasoltaan matalampia palveluita [KoMi05, s. 126].
11 8 Käytännössä tästä kerrosarkkitehtuurin perusideasta joudutaan usein poikkeamaan ja puhdas kerrosarkkitehtuuri on harvinaisuus [KoMi05, s. 126]. Poikkeamia puhtaasta kerrosarkkitehtuurista on kahdenlaisia: palvelukutsun kulkeminen alemmasta kerroksesta ylempään (hierarchy breach) sekä kerrosten ohittaminen palvelukutsun kulkiessa ylemmältä abstraktiotasolta alas (bridging) [KoMi, s. 126]. Kerrosten ohittamista ei pidetä yleisesti pahana poikkeamisena kerrosarkkitehtuurista, sillä kerrosten ohittamiselle on usein perusteita: kerrosten ohittaminen on usein järkevää tehokkuussyistä tai siksi, että haluttua palvelua ei ole saatavilla seuraavassa kerroksessa. Usein käytettynä kerrosten ohittaminen saattaa kuitenkin johtaa kerrosarkkitehtuurin idean heikentymiseen [KoMi05, s. 127]. Palvelukutsun kulkeminen alemmasta kerroksesta ylempään on sen sijaan vakava kerrosarkkitehtuurin ongelma, jos sen seurauksena on alemman kerroksen riippuvuus ylemmästä [KoMi05, s. 127]. Tällainen kutsuminen on kuitenkin välttämätöntä, jos alemman kerroksen on sovitettava palvelunsa ylemmän kerroksen mukaan, ja kutsuu tämän takia oman palvelunsa aikana koodia, joka on ylemmässä kerroksessa. Jotta alempi kerros ei tulisi riippuvaiseksi ylemmästä, on tällainen tilanne toteutettava takaisinkutsuperiaatetta (callback) käyttäen [KoMi05, s. 127]. Kerrosarkkitehtuurityyli on yleinen malli, jota voidaan soveltaa lähes kaikissa järjestelmissä, sekä pienessä, että suuressa mittakaavassa [KoMi05, s. 130]. Koska se jakaa järjestelmän korkealla tasolla osiin, on järjestelmän rakenne helpompaa ymmärtää, ja toisaalta jokainen kerros voidaan myös käsitellä omana kokonaisuutenaan. Kerrosarkkitehtuuri on myös riittävän ymmärrettävä, että sitä voidaan käyttää tukena keskusteltaessa järjestelmästä erilaisten ihmisten kanssa [KoMi05, s. 131].
12 9 3.2 Kerrosarkkitehtuurityylin sovelluksia Käyttöliittymä Sovelluslogiikka Sovellusaluelogiikka Tietokanta Kuva 2: Esimerkki kerrosarkkitehtuurin käytöstä [KoMi05, s. 128]. Koskimies ja Mikkonen esittelevät teoksessaan Ohjelmistoarkkitehtuurit esimerkin kerrosarkkitehtuurityylin soveltamisesta liiketoimintajärjestelmänä, jossa on neljä kerrosta. Esimerkin sovellusalue on vakuutusyhtiön tietojärjestelmä. Tällaisen järjestelmän mahdollinen kerrosarkkitehtuurimallia noudattava rakenne on esitetty kuvassa 2 [KoMi05, s. 128]. Alin kerros tarjoaa yleistä infrastruktuuritukea, esimerkiksi tietokannan ja sen toiminnot, sen yläpuolella sovellusalueen logiikan sekä käsitteet toteuttava kerros. Tämän jälkeen seuraa sovelluksen logiikan toteuttava kerros ja ylimpänä kerroksena on sovelluksen käyttöliittymän toteuttava kerros. Alin kerros on lähinnä laitteistoa, kun taas ylin lähinnä järjestelmän käyttäjää. Esimerkkijärjestelmässä sovellusaluelogiikkakerroksessa on kaikille vakuutuksille yhteiset ominaisuudet, kuten asiakas tai laskutus. Sovelluslogiikkakerros sisältää esimerkiksi liikennevakuutuslogiikan tai henkivakuutuslogiikan. Tällainen arkkitehtuurityyli mahdollistaa kahden alimman kerroksen uudelleenkäytön, jos ilmenee tarvetta tehdä esimerkiksi uusi vakuutussovellus. Toinen tunnettu sovellus kerrosarkkitehtuurityylin käytöstä ovat tietoliikenneprotokollat [Busc96 s. 31]. Näitä protokollia ovat esimerkiksi OSI-malli sekä TCP/IP. Tietoliikenneprotokolliin kerrosarkkitehtuurityyliä sovelletaan järjestämällä yleisen protokollan erikoistuneet aliprotokollat kerrosarkkitehtuurityylin mukaiseen kerrostusjärjestelmään ja kutsuu palveluitaan ainoastaan alemmalta
13 kerrokseltaan. [Busc96 s. 31]. Jokainen kerros on vastuussa ainoastaan omasta erikoistumisalueestaan [Busc96 s. 31]. Kuvassa 3 esitetään OSI-mallin rakenne. 10 Kuva 3: OSI-mallin rakenne [Busc96 s. 31]. Seitsenkerroksisen OSI-mallin kehitti The International Standardization Organization (ISO) poistaakseen yhteensopimattomuusongelmia verkossa [Busc96 s. 31]. Kukin OSI-mallin kerros tarkastelee tietoliikennettä eri abstraktiotasolla. OSI-malli on viitekehys, jossa kullekin kerrokselle voidaan sovittaa useita protokollia [Busc96 s. 31]. 3.3 Tietovuoarkkitehtuuri Tietovuoarkkitehtuuri on arkkitehtuurityyli, joka sopii erityisen hyvin sellaisen järjestelmän malliksi, jossa on luonteenomaista tietovirran jäsentäminen ja jalostaminen [KoMi05, s. 132]. Tietovuoarkkitehtuurityyli on eräänlainen sovellus hajota ja hallitse -ongelmanratkaisutekniikasta: monimutkainen tehtävä jaetaan pienempiin kokonaisuuksiin, jotka voidaan sitten ratkaista pienemmällä resurssitappiolla, kuin jos koko tehtävä ratkaistaisiin kokonaisuudessaan kerralla [AvZd05, s. 12]. Tämän arkkitehtuurityylin merkittävin etu on, että mutkikas tiedon prosessointi voidaan tehdä asteittain, jalostamalla tietoa askel kerrallaan. Näin monimutkaisetkin tietojenkäsittelytehtävät voidaan ymmärtää ja toteuttaa hallitusti [KoMi05, 135].
14 11 Kuva 3: Tietovuoarkkitehtuuri [KoMi05, s. 132]. Tietovuoarkkitehtuurin perusajatus kuvataan kuvassa 3. Tietovuoarkkitehtuuri koostuu prosessointiyksiköistä (filter) sekä niitä yhdistävistä, tietovirtaa kuljettavista väylistä (pipe). Prosessointiyksiköiden tehtävä on tiedon aktiivinen käsittely ja väylien tehtävä on passiivinen tiedon kuljetus prosessointiyksiköiden välillä [GrSh94, s. 6]. Prosessiyksiköiden tehtävä on yksinkertaisesti lukea omaa syötevirtaansa, käsitellä se ja tuottaa tulosteensa [KoMi05, s. 132]. Yleisin ja yksinkertaisin muoto tietovuoarkkitehtuurista on liukuhihna-arkkitehtuuri (pipeline architecture). Liukuhihna-arkkitehtuurissa tietovirta etenee haarautumatta yhtä prosessointiyksiköiden ketjua pitkin. Tiedonvälitys voidaan toteuttaa synkronisena kahdella tavalla: joko työntämällä tai vetämällä tietoa [KoMi05 s. 133]. Tietovuoarkkitehtuurityyli vaatii, että prosessointiyksiköt on toteutettu itsenäisinä, omaa syötettään lukevana ja omaa tulostettaan tuottavana yksikkönä, joka ei ole riippuvainen muista yksiköistä. Yksiköt eivät jaa tilatietoa keskenään, eikä niiden tarvitse tuntea toisiaan [GrSh94, s. 6]. Prosessoinnin täytyy myös tapahtua vain yhdessä vaiheessa: prosessointi ei saa riippua jonkin tulevan tietoalkion prosessoinnista [KoMi05, s. 132]. Tietoa voidaan toki puskuroida, mutta laajamittainen tiedon puskurointi aiheuttaa arkkitehtuurityylin
15 12 perusidean rikkoutumisen ja vaikeuttaa esimerkiksi syötteen rinnakkaista prosessointia [KoMi05, s. 133]. Kukin yksikkö voisi esimerkiksi lukea aina koko tietovirran ensin omaan puskuriinsa ja sen jälkeen prosessoida sen mielivaltaisessa järjestyksessä. Tällöin koko tietovirran käsite häviää, koska tieto välitetään yksiköiden välillä isona rakenteena [KoMi05, s. 133]. Tietovuoarkkitehtuuri ei sovi interaktiivisen järjestelmän suunnittelun perusmalliksi, eikä sitä ole sellaiseen käytettäväksi tarkoitettukaan. Tietovuoarkkitehtuurin perustuvassa järjestelmässä ei ole sellaista globaalia tilaa, jonka näyttäminen käyttäjälle vuorovaikutusta varten olisi mielekästä [KoMi05, s. 135]. Monissa järjestelmissä tietovuoarkkitehtuuria voidaan kuitenkin käyttää pienemmässä mittakaavassa. Sovelluskohde tietovuoarkkitehtuurista on prosessien tulosten siirtäminen seuraavan prosessin syötteeksi putkia käyttäen Unix-järjestelmissä [KoMi05, s. 132].
16 13 4 Palveluperustaiset- ja sovellusaluekohtaiset tyylit Palveluperustaiset arkkitehtuurityylit on rakennettu siten, että niissä katsotaan olevan kahdenlaisia rooleja: palvelun tarjoajat ja niiden käyttäjät. Palvelun tarjoaja voi myös toimia jonkin palvelun käyttäjänä, joten roolit eivät yleensä ole tiukat. Usein palvelun ajatus perustuu johonkin resurssiin, jonka palveluita sen ympärille rakennettu komponentti tarjoaa ympäristölleen [KoMi05 s. 136]. Palveluperustaisuus ja kerrostaminen voidaan yhdistää, jos palveluita halutaan ryhmitellä. Tällöin tiettyjen palveluiden tarjoaminen yhdistetään suoraan johonkin arkkitehtuurin kerrokseen. Tällainen toimintatapa määrittelee yleensä sääntöjä myös sille, kuinka palveluita on mahdollista käyttää [KoMi05 s. 136]. Joillekin sovellusalueille on huomattu toimivaksi tietynlainen toteutustapa, ja se on ajan kuluessa vakiintunut. Näitä toteutustapoja kutsutaan sovellusaluekohtaisiksi arkkitehtuurityyleiksi Toteutukseltaan sovellusaluekohtaista arkkitehtuurityyliä noudattava järjestelmä voidaan rakentaa esimerkiksi palveluiden tai jonkinlaisen kerrostamisen perustalle [KoMi05, s. 142]. Tässä tutkielmassa esitellään palveluperustaisista arkkitehtuurityyleistä Asiakaspalvelin-arkkitehtuurityyli. Sovellusaluekohtaisista arkkitehtuurityyleistä esitellään Malli-näkymä-ohjain -arkkitehtuurityyli.
17 Asiakas-palvelin arkkitehtuurityyli Asiakas-palvelin-arkkitehtuurityyli on yleisin tällä hetkellä käytettävistä arkkitehtuuriratkaisuista [KoMi05, s. 136]. Sen perusajatus on kapseloida tietyn arkkitehtuuritason resurssin hallinta siten, että resurssin hallitsija (palvelin) huolehtii resurssin teknisistä tehtävistä ja resurssin käyttäjät (asiakkaat) voivat pyytää resurssin palveluita välittämättä muista palvelun asiakkaista [KoMi05, s. 136]. Yleensä palvelin ei tiedä asiakkaidensa määrää tai identiteettejä, mutta asiakkaat tietävät palvelimen identiteetin [GrSh94, s. 14]. Kuva 4: Asiakas-palvelin-arkkitehtuuri. Kuvassa 4 on havainnollistettu asiakkaiden ja palvelimien mahdollisia suhteita keskenään sekä asiakkaiden riippumattomuutta toisista asiakkaista: ne voivat pyytää palvelimilta palveluita välittämättä toisista asiakkaista [KoMi05, 136]. Palvelimen harteille jää esimerkiksi asiakkaiden priorisointi sekä muut tekniset kysymykset. Usein toiminta asiakkaan ja palvelimen välillä tapahtuu istunnon (session) puitteissa [KoMi05, s. 136]. Istunnossa suoritetaan jokin asiakkaan tarvitsema palvelukokonaisuus, jonka palvelin toteuttaa. Yleensä palvelimet odottavat passiivisina asiakkaan yhteydenottoa. Kun asiakkaan yhteydenotto saapuu, ryhtyvät palvelimet toimeen ja toteuttavat asiakkaan palvelupyynnön. Palvelukokonaisuuden suoritettuaan
18 15 palvelin vastaa asiakkaalle ja asiakas päättää istunnon [KoMi05, s. 137]. Jos istuntoon liittyy transaktioita, niiden eheys ja peruutus on palvelimen harteilla [KoMi05, s. 137]. Usein kommunikointi asiakkaan ja palvelimen välillä on täsmällisesti säädeltyä. Palvelin myös toimii aina omassa säikeessään tai prosessissaan, mikä pitää sen toteutuksen erillään asiakkaista [KoMi05, s. 137]. Asiakas-palvelin-arkkitehtuurityyli ajatellaan usein hajautettuna järjestelmänä [KoMi05, s. 138]. Asiakas-palvelin-arkkitehtuurityyliä onkin käytetty yleisesti hajautettujen järjestelmien mallina [GrSh94, s. 14]. Toisaalta ideaa siitä, että tietty resurssi kapseloidaan palvelimelle, joka huolehtii resurssin toiminnoista, ei ole sidottu hajautukseen, vaan sitä voidaan käyttää missä tahansa ympäristössä eristämään jokin resurssi oman hallintayksikkönsä valvontaan [KoMi05, s. 138]. 4.2 Malli-näkymä-ohjain -arkkitehtuuri Malli-näkymä-ohjain -arkkitehtuuri (MVC, model-view-controller) erottaa käyttöliittymän varsinaisesta sovelluslogiikasta ja datasta. Tämä arkkitehtuurityyli soveltuu sellaisten interaktiivisten järjestelmien malliksi, jotka sisältävät monimuotoisia käyttöliittymänäkymiä [KoMi05, s. 142]. Arkkitehtuurin avulla pyritään saavuttamaan käyttöliittymän helppo muokattavuus, sekä järjestelmän helppo siirrettävyys toiselle alustalle. Lisäksi halutaan, että käyttöliittymä heijastaa aina sovellusdatan tilaa ja näyttää sen tarvittaessa erilaisissa näkymissä aina oikeassa muodossaan [KoMi05, s. 142].
19 16 Kuva 5: Malli-näkymä-ohjain -arkkitehtuuri. Kuten kuvassa 5, Malli-näkymä-ohjain -arkkitehtuurityyliä noudattava järjestelmä jaetaan kolmen tyyppisiin osiin: malleihin (model), näkymiin (view) ja ohjaimiin (controller) [Busc96 s. 125]. Mallit edustavat osia sovellusdatasta tai sovelluksen tilasta. Ne ovat vastuussa laskentaan liittyvän tiedon tai tilan säilytyksestä. Näkymät edustavat osaa näkyvästä käyttöliittymästä ja ovat vastuussa tiedon esittämisestä käyttäjälle. Ohjaimet käsittelevät käyttäjän syötteet sekä toimivat sovittimina näkymien ja mallien välissä pitäen huolta siitä, että ne vastaavat toisiaan [Busc96, s. 128]. Ohjaimet siis vastaavat käyttäjän ja mallin vuorovaikutuksen ohjaamisesta. Tyypillisesti vuorovaikutus käyttäjän ja järjestelmän välillä kulkee kuvan 5 tapaan seuraavasti: Käyttäjä antaa komennon, jonka ohjain havaitsee. Se pyytää mallia suorittamaan vastaavan sovelluspalvelun. Tämän seurauksena mallin tila muuttuu, josta se informoi kiinnostuneita näkymiä tai ohjaimia, jotka suorittavat tarvittavat operaatiot näytön näyttämiseksi sekä ohjainten päivittämiseksi [KoMi05, s ]. Ohjaimien toiminnan apuna käytetään usein Tarkkailija-suunnittelumallia (observer). Tässä suunnittelumallissa näkymät ja ohjaimet toteuttavat tarkkailijarajapinnan, jota käyttäen ne voivat rekisteröityä tarkkailemaan malleissa tapahtuvia muutoksia. Kun muutoksia tapahtuu, voivat näkymät ja ohjaimet käydä kysymässä mallilta sen muuttunutta dataa [KoMi05 s. 142].
20 17 Malli-näkymä-ohjain -arkkitehtuurityyliin liittyy myös eräitä ongelmia. Malli-näkymäohjain -arkkitehturityylin käyttö saattaa lisätä järjestelmän kompleksisuutta lisäten sen luokkia [KoMi05 s. 144]. Jotta järjestelmän monimutkaisuus ei kasvaisi liikaa, kannattaa ohjain- ja näkymäluokat antaa vain suuremmille käyttöliittymäkokonaisuuksille, kuten esimerkiksi dialogeille [KoMi05 s. 144]. Tarkkailija-suunnittelumallin soveltaminen malli-näkymä-ohjain -arkkitehtuurityylissä merkitsee usein suuria määriä päivityskutsuja, joka on ongelmallista erityisesti jos eri komponentit on hajautettu eri prosesseihin [KoMi05 s. 144]. Tarkkailijasuunnittelumallin soveltaminen saattaa altistaa tehottomuudelle: tarkkailijat joutuvat kysymään mallilta muuttunutta tietoa käyttäen yleisiä mallin operaatioita, mikä voi olla hidasta. Eri tarkkailijat joutuvat myös tekemään samantapaisia tai jopa samoja kyselyjä muutosten jälkeen [KoMi05 s. 144]. Toinen malli-näkymä-ohjain -arkkitehtuurityylin tyypillisistä ongelmista on näkymäja ohjainluokkien kiinteä liittyminen toisiinsa. Jos malli- ja ohjainluokat ovat kiinteästi toisiinsa liittyviä, on niitä vaikea käyttää uudelleen toisistaan irrallaan muissa yhteyksissä [KoMi05 s. 144]. Koska Malli-näkymä-ohjain -arkkitehtuurityyli mahdollistaa mallien uudelleenkäytön useissa tilanteissa, on se sopiva valinta graafisen käyttöliittymän toteutusmekanismiksi [KoMi05, s. 144]. Eräs malli-näkymä-ohjain -arkkitehtuurityylin sovellusalue ovat toiminnalliset web-sivut, joissa käyttäjälle näkyvä HTML-sivu on näkymä. HTMLsivun koodi joka ottaa vastaan tietoa käyttäjältä sekä käsittelee tiedon on ohjain. Esimerkiksi tietokannassa tai XML-tiedostoissa sijaitseva varsinainen tietosisältö on malli.
21 18 5 Yhteenveto Ohjelmiston perusrakennetta kutsutaan ohjelmiston arkkitehtuuriksi. Se määrittelee ohjelmiston komponentit ja niiden suhteet toisiinsa. Arkkitehtuurin täsmällinen määrittely ja kuvaaminen on tärkeä osa nykyaikaista ohjelmistontuotantoa ja ohjelmistotuotantoprosessia. Ilman määriteltyä ja kuvattua arkkitehtuuria on projektiryhmän vaikeaa muodostaa yhtenäistä kuvaa tuotettavan ohjelmiston rakenteesta. Arkkitehtuurityyli on koko järjestelmää luonnehtiva korkeimman abstraktiotason suunnitteluratkaisu. Arkkitehtuurityyliä apuna käyttäen voidaan suunnitella ohjelmiston rakenteellinen ja toiminnallinen runko. Se asettaa rajat ja säännöt tuotettavan ohjelmiston arkkitehtuurille. Arkkitehtuurityylejä on kehitetty erilaisten järjestelmien vaatimuksia ajatellen. Arkkitehtuurityyli, joka auttaa ohjelmiston rakennuspalasten ryhmittelyssä on keino välttää ohjelmiston rakenteen muotoutuminen liian monimutkaiseksi. On yleistä, että arkkitehtuurityyliä käytetään juuri tämän ongelman estämiseen. Tällöin ryhmittelyyn perustuvan arkkitehtuurityylin mukaisessa järjestelmässä järjestelmä on jaettu osajoukkoihin, joissa yhden joukon sisältämät järjestelmän komponentit ovat samassa suhteessa arkkitehtuurityylin kannalta. Palveluperustaiset arkkitehtuurityylit perustuvat roolijakoon. Rooleja on kaksi: palvelun tarjoajat ja niiden käyttäjät. Tällä hetkellä yksi käytetyimmistä arkkitehtuurityyleistä on palveluperustaisiin arkkitehtuurityyleihin kuuluva asiakaspalvelin-arkkitehtuuri. Sovellusaluekohtaisiin arkkitehtuurityyleihin kuuluu sellaisia arkkitehtuurityylejä, jotka ovat ajan kuluessa vakiintuneet tietyn sovellusalueen täsmäratkaisuiksi. Usein ohjelmistoa ei voida rakentaa ainoastaan yhtä arkkitehtuurityyliä käyttäen. On mahdollista käyttää monien eri arkkitehtuurityylien yhdistelmiä ohjelmiston arkkitehtuurin perustana.
22 19 Arkkitehtuurityylin oikea valinta ja käyttö selkeyttää ohjelmiston arkkitehtuurin muodostamista ja auttaa arkkitehtuurin hallinnassa. Väärin valittu arkkitehtuurityyli voi taas olla suurikin haitta ohjelmistoprojektille. Kuten perinteisessä rakennusarkkitehtuurissakin, voi väärin valittu arkkitehtuurityyli jopa estää oikeanlaisen lopputuotteen syntymisen. Goottilaisella tyylillä on vaikea tuottaa modernia tyyliä tavoittelevaa rakennusta, mutta se on omiaan Goottilaista tyyliä noudattavien rakennusten malliksi.
23 20 Lähteet AvZd05 Paris Avgeriou & Uwe Zdun, Architectural patterns revisited - a pattern language. EuroPloP, Bass98 Len Bass, Paul Clements & Rick Kazman, Software architecture in practice. Addison-Wesley, Busc96 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad & Michael Stahl, Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons. Inc., GrSh94 David Garlan & Mary Shaw, An Introduction to Software Architecture. School of Computer Science, Carnegie Mellon University, Pittsburgh, 1994 KoMi05 Kai Koskimies & Tommi Mikkonen, Ohjelmistoarkkitehtuurit. Talentum, 2005.
arvostelija OSDA ja UDDI palveluhakemistoina.
Hyväksymispäivä Arvosana arvostelija OSDA ja UDDI palveluhakemistoina. HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Laitos Institution
LisätiedotOsittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit
6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit Viestinvälitysarkkitehtuurit
LisätiedotOhjelmistoarkkitehtuurit. Syksy 2008
Ohjelmistoarkkitehtuurit Syksy 2008 Kai Koskimies 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto, Tampereen yliopisto, Teknillinen korkeakoulu, Turun yliopisto, Vaasan yliopisto, Tampereen teknillinen
LisätiedotArkkitehtuurityylejä ja ratkaisumalleja
Arkkitehtuurityylejä ja ratkaisumalleja Luento 4 12.9.2013 581358 Ohjelmistoarkkitehtuurit 1 Oppimistavoitteet Esimerkkejä yleisesti käytetyistä arkkitehtuurisista ratkaisumalleista ja tyyleistä Muutama
Lisätiedot6. Arkkitehtuurityylit
6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit - Kerrosarkkitehtuurit - Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit - Asiakas-palvelin arkkitehtuurit - Viestinvälitysarkkitehtuurit
LisätiedotSelainpelien pelimoottorit
Selainpelien pelimoottorit Teemu Salminen Helsinki 28.10.2017 Seminaaritutkielma Helsingin yliopisto Tietojenkäsittelytiede ! 1 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta
LisätiedotOhjelmistoarkkitehtuurit. Syksy 2010
Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin
LisätiedotOhjelmistoarkkitehtuurit, syksy
Arkkitehtonisista tyyleistä ja ratkaisumalleista Ohjelmistoarkkitehtuurit Arkkitehtonisista tyyleistä ja ratkaisumalleista Taylor:n määritelmän mukainen arkkitehtoninen ratkaisumalli (architectural pattern)
LisätiedotAika/Datum Month and year Kesäkuu 2012
Tiedekunta/Osasto Fakultet/Sektion Faculty Laitos/Institution Department Filosofian, historian, kulttuurin ja taiteiden tutkimuksen laitos Humanistinen tiedekunta Tekijä/Författare Author Veera Lahtinen
LisätiedotOhjelmistoarkkitehtuurit. 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ätiedotOhjelmistoarkkitehtuurit. Kevät
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto 2 Kurssin tavoitteet
LisätiedotOhjelmistoarkkitehtuurit kevät
Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit
LisätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
Ohjelmistoarkkitehtuurit Syksy 2009 Kai Koskimies Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto (Kajaani), Tampereen yliopisto, Turun yliopisto,
Lisätiedot6. Arkkitehtuurityylit
6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit (toiminnan ositus) Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit
LisätiedotOhjelmistoarkkitehtuurit 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ätiedotOhjelmistoarkkitehtuurit
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit
LisätiedotOhjelmistoarkkitehtuurit Johannes Koskinen. Osittavat arkkitehtuurityylit
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit
LisätiedotTyön laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages
Tiedekunta/Osasto Fakultet/Sektion Faculty Laitos Institution Department Tekijä Författare Author Työn nimi Arbetets titel Title Oppiaine Läroämne Subject Työn laji Arbetets art Level Aika Datum Month
LisätiedotPalveluperustaiset arkkitehtuurityylit
Palveluperustaiset arkkitehtuurityylit Mukana palvelun tarjoajia ja palvelun käyttäjiä Perusajatuksena tyypillisesti tarjota johonkin resurssiin liittyviä palveluita 1 Asiakas-palvelin -arkkitehtuurit
LisätiedotInteraktiivisten 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ätiedotArkkitehtuurityylejä ja patterneja
Arkkitehtuurityylejä ja patterneja Luento 4 11.9.2014 581358 Ohjelmistoarkkitehtuurit 1 Oppimistavoitteet Esimerkkejä yleisesti käytetyistä arkkitehtuuripatterneista ja -tyyleistä Muutama käydään läpi
LisätiedotOppimistavoitteet. Arkkitehtuurityylejä ja patterneja. Tyylien ja patternien käytöstä. Kolmitasoarkkitehtuuri (N-Tier) Kolmitasoarkkitehtuuri (N-Tier)
Oppimistavoitteet Arkkitehtuurityylejä ja patterneja Esimerkkejä yleisesti käytetyistä arkkitehtuuripatterneista ja -tyyleistä Muutama käydään läpi perusteellisemmin (MVC, tietovuotyylit, kerrosarkkitehtuurit)
LisätiedotArkkitehtuurinen reflektio
Arkkitehtuurinen reflektio Toni Ruokolainen Toni.Ruokolainen@cs.helsinki.fi Helsinki 6.10.2003 Tiivistelmä HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET
LisätiedotKoht dialogia? Organisaation toimintaympäristön teemojen hallinta dynaamisessa julkisuudessa tarkastelussa toiminta sosiaalisessa mediassa
Kohtdialogia? Organisaationtoimintaympäristönteemojenhallinta dynaamisessajulkisuudessatarkastelussatoiminta sosiaalisessamediassa SatuMariaPusa Helsinginyliopisto Valtiotieteellinentiedekunta Sosiaalitieteidenlaitos
LisätiedotLuonnontieteiden popularisointi ja sen ideologia
Luonnontieteiden popularisointi ja sen ideologia Tapauksina Reino Tuokko ja Helsingin Sanomat 1960-luvulla Ahto Apajalahti Helsingin yliopisto Humanistinen tiedekunta Suomen ja Pohjoismaiden historia Pro
LisätiedotOhjelmistoarkkitehtuurit
Ohjelmistoarkkitehtuurit Konnektorit ohjelmistoarkkitehtuurissa 18.9.2012 1 Konnektorit (connectors) Konnektori (connector) (liitos) Arkkitehtuurielementti, jonka tehtävänä on mahdollistaa ja hallita komponenttien
LisätiedotOhjelmistoarkkitehtuuri
Ohjelmistoarkkitehtuurien ylläpito Arkkitehtuurityylejä ja laatuvaatimuksia Arkkitehtuurin uudistaminen Arkkitehtuurin uudistamisen malleja Arkkitehtuurin arviointi TTY Ohjelmistotekniikka 1 Ohjelmistoarkkitehtuuri
LisätiedotViestinvälitysarkkitehtuurit Lähtökohta:
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti
LisätiedotKatsaus korruption vaikutuksesta Venäjän alueelliseen talouskasvuun ja suoriin ulkomaisiin investointeihin
INSTITUUTIOTTALOUSKASVUNEDELLYTYKSENÄ KatsauskorruptionvaikutuksestaVenäjänalueelliseentalouskasvuunjasuoriin ulkomaisiininvestointeihin2000 2010 AshekMohamedTarikHossain HelsinginYliopisto Valtiotieteellinentiedekunta
LisätiedotMaailman muutosta tallentamassa Marko Vuokolan The Seventh Wave -valokuvasarja avauksena taidevalokuvan aikaan
Maailman muutosta tallentamassa Marko Vuokolan The Seventh Wave -valokuvasarja avauksena taidevalokuvan aikaan Pro gradu -tutkielma 31.1.2012 Helsingin yliopisto Humanistinen tiedekunta Filosofian, historian,
LisätiedotViestinvä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ätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
Lisätiedot! #! %! & #!!!!! ()) +
! #! %! & #!!!!! ()) + Tiedekunta/Osasto Fakultet/Sektion Faculty Humanistinen tiedekunta Laitos Institution Department Taiteiden tutkimuksen laitos Tekijä Författare Author Matti Pesonen Työn nimi Arbetets
LisätiedotPro gradu -tutkielma Meteorologia SUOMESSA ESIINTYVIEN LÄMPÖTILAN ÄÄRIARVOJEN MALLINTAMINEN YKSIDIMENSIOISILLA ILMAKEHÄMALLEILLA. Karoliina Ljungberg
Pro gradu -tutkielma Meteorologia SUOMESSA ESIINTYVIEN LÄMPÖTILAN ÄÄRIARVOJEN MALLINTAMINEN YKSIDIMENSIOISILLA ILMAKEHÄMALLEILLA Karoliina Ljungberg 16.04.2009 Ohjaajat: Ari Venäläinen, Jouni Räisänen
LisätiedotOhjelmistoarkkitehtuurit 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ätiedotOhjelmistoarkkitehtuurit
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti
LisätiedotSuunnitteluvaihe 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ätiedotInteraktiivisten 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ätiedotOhjelmistojen mallinnus Ohjelmistoarkkitehtuuri Harri Laine 1
Ohjelmistojen mallinnus Ohjelmistoarkkitehtuuri 2 28.11.2008 Harri Laine 1 Ohjelmistoarkkitehtuuri Rajapinta UML:ssä piirteiden (attribuuttien ja operaatioiden) kokoelma, josta ei voi suoraan luoda ilmentymiä
LisätiedotOppimateriaalin kokoaminen ja paketointi
Oppimateriaalin kokoaminen ja paketointi Pekka Simola Helsinki 14.4.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto
LisätiedotDigi-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ätiedotOhjelmistoarkkitehtuurit Kevät 2014 Arkkitehtuurityylit vol 2
Ohjelmistoarkkitehtuurit Kevät 2014 Arkkitehtuurityylit vol 2 Samuel Lahtinen (Johannes Koskinen) http://www.cs.tut.fi/~ohar/ 1 Yleisesti Huomenna ei luentoa, tapaaminen TC103:ssa Muistakaa harkkavälinäyttöilmo
LisätiedotSisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.
Sisällys Ratkaisumallien historia Jaakko Vuolasto 25.1.2001! Ratkaisumalli! Christopher Alexander! Ohjelmistotuotannosta arkkitehtuuriin! Henkilöhistoriaa! Ensimmäisiä käyttökokemuksia! Yhteenveto 25.1.2001
LisätiedotTiedekunta/Osasto Fakultet/Sektion Faculty Valtiotieteellinen tiedekunta
Tiedekunta/Osasto Fakultet/Sektion Faculty Valtiotieteellinen tiedekunta Laitos Institution Department Politiikan ja talouden tutkimuksen laitos Tekijä Författare Author Virta, Mikko Antero Työn nimi Arbetets
LisätiedotOhjelmistoarkkitehtuurit kevät
Ohjelmistoarkkitehtuurit Kevät 20-202 Johannes Koskinen http://www.cs.tut.fi/~ohar/ Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti
LisätiedotOhjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja
582104 Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja 1 Arkkitehtuurisuunnittelu Ohjelmistoarkkitehtuurin määritelmä & arkkitehtuurisuunnittelun lähtökohta ja tavoitteet Kerrosarkkitehtuuri
LisätiedotUudelleenkä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ätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite
LisätiedotHELIA 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ätiedotOhjelmistoarkkitehtuurit, 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ätiedotSeminaari: Keskusmuistitietokannat. Keskusmuistitietokantojen samanaikaisuuden hallinta Ilkka Pullinen
Seminaari: Keskusmuistitietokannat Keskusmuistitietokantojen samanaikaisuuden hallinta Ilkka Pullinen Sisältö Johdanto Esiteltävien menetelmien taustoja Hajautetun tietokannan spekuloiva samanaikaisuuden
LisätiedotTietojä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ätiedotTestausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter
LisätiedotOhjelmistotuotanto. Luento 9 23.4.2012
Ohjelmistotuotanto Luento 9 23.4.2012 Lisää suunnittelumalleja Olion rikastaminen dekoraattorilla Joskus eteen tulee tarve lisätä olioon jotain ekstraominaisuuksia, pitäen kuitenkin olio sellaisena että
LisätiedotJHS 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ätiedothyväksymispäivä arvosana
hyväksymispäivä arvosana arvostelija Kerrosarkkitehtuurit Henri Karhatsu Helsinki 1.12.2007 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF
LisätiedotOhjelmistojen mallintaminen kertausta Harri Laine 1
kertausta 5.12.2008 Harri Laine 1 Ohjelmiston elinkaari, elinkaarimallit Yleinen puitemalli (reference model) - abstrakti kokonaiskuva ei etenemiskontrollia, ei yksityiskohtia Ohjelmistoprosessimallit
LisätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
Lisätiedotarvostelija Turvallisuuskriittisissä, sulautetuissa järjestelmissä esiintyvien ohjelmistovaatimusten virheanalyysi Jarkko-Juhana Sievi
hyväksymispäivä arvosana arvostelija Turvallisuuskriittisissä, sulautetuissa järjestelmissä esiintyvien ohjelmistovaatimusten virheanalyysi Jarkko-Juhana Sievi Helsinki 6.4.2005 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen
LisätiedotOhjelmistoarkkitehtuurit. Kevät 2012-2013
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestipohjaisten yritysjärjestelmien suunnittelumallit 1 Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit:
LisätiedotOhjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja
582104 Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja 1 Arkkitehtuurisuunnittelu Ohjelmistoarkkitehtuurin määritelmä & arkkitehtuurisuunnittelun lähtökohta ja tavoitteet Kerrosarkkitehtuuri
Lisätiedot9 Edistynyt PHP-ohjelmointi
9 Edistynyt PHP-ohjelmointi Luentokerran tavoitteena on käydä läpi joukko sellaisia PHP-sovelluksen toteuttamiseen liittyviä tekijöitä, joiden avulla voidaan parantaa verkkopalvelun totetustyön tuottavuutta
LisätiedotOhjelmistoarkkitehtuurin suunnittelu
Ohjelmistoarkkitehtuurin suunnittelu Luento 3 10.9.2014 581358 Ohjelmistoarkkitehtuurit 1 Oppimistavoitteet Arkkitehtuuritietämyksen lähteet Yleisiä suunnitteluperiaatteita Kaunis arkkitehtuuri 10.9.2014
LisätiedotTenttikysymykset. + 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ätiedotOhjelmiston 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ätiedotMEMS-muisti relaatiotietokannoissa
MEMS-muisti relaatiotietokannoissa Antti Tikka Espoo 28.2.2009 Seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto
LisätiedotOhjelmistojen 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ätiedotTiedonsiirto- ja rajapintastandardit
Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen
LisätiedotHelsingin yliopisto/tktl DO Tietokantojen perusteet, s 2000 Johdanto & yleistä Harri Laine 1. Tietokanta. Tiedosto
Tietokanta Tiedosto Tietokanta (database) jotakin käyttötarkoitusta varten laadittu kokoelma toisiinsa liittyviä säilytettäviä tietoja Ohjelmointikielissä apumuistiin tallennettuja tietoja käsitellään
LisätiedotOhjelmistojen 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ätiedotHarjoitustehtävät viikolle 42
Harjoitustehtävät viikolle 42 1. Suunnittele pieni työkaluohjelma, joka laskee keskiarvon lukujoukosta. Käyttöliittymä koostuu perusikkunan lisäksi yhdestä valikosta, jossa on kaksi komentoa: Start (aloita
LisätiedotVuorekseen liittyvä tutkimusja kehitysprojekti. Langaton Vuores. Kotikatupalvelin
Vuorekseen liittyvä tutkimusja kehitysprojekti Langaton Vuores Kotikatupalvelin Tutkimuksen tausta Langaton tietoliikenne on arkipäivää Personoidut päätelaitteet (taskutietokone, matkapuhelin, kannettava
LisätiedotSoftware product lines
Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product
LisätiedotSuunnittelumallit (design patterns)
Suunnittelumallit (design patterns) Ohjelmoinnissa Rakennusarkkitehtuurissa Käyttöliittymäsuunnittelussa Sear ch Ohjelmointi Suunnittelumallit Usein toistuvia ohjelmointiongelmia ja niiden ratkaisuja:
LisätiedotOhjelmistojen mallintaminen Tietovuokaaviot Harri Laine 1
Ohjelmistojen mallintaminen Tietovuokaaviot 3.11.2008 Harri Laine 1 t Data flow diagrams Pohjana systeemiteoreettinen järjestelmämalli Input system output Järjestelmän tehtävä on muokata lähtötiedoista
LisätiedotYlläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
LisätiedotOppimistavoitteet kurssilla Rinnakkaisohjelmointi
17.5.2006 1/5 Oppimistavoitteet kurssilla Rinnakkaisohjelmointi Rinnakkaisuus ja rinnakkaisuuden soveltaminen tietojenkäsittelyjärjestelmissä Kurssin Tietokoneen toiminta perusteella ymmärtää, miten ohjelman
LisätiedotPerusarkkitehtuurin 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ätiedotWeb-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ätiedotOhjelmistojen mallinnus, s2008 HY/TKTL, 28/10/2008. Harri Laine 1. Ohjelmisto
jen mallinnus, s2008 jen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän suoritettava
LisätiedotOhjelmistoarkkitehtuurit. Kevät
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestipohjaisten yritysjärjestelmien suunnittelumallit Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit:
Lisätiedot7 Viestipohjaisten yritysjärjestelmien suunnittelumallit
7 Viestipohjaisten yritysjärjestelmien suunnittelumallit Hohpe G., Woolf B.: Enterprise Integration Patterns. Addison-Wesley 2004. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Viestinvälitykseen
LisätiedotFiSMA 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ätiedotGraafisen käyttöliittymän ohjelmointi Syksy 2013
TIE-11300 Tietotekniikan vaihtuva-alainen kurssi Graafisen käyttöliittymän ohjelmointi Syksy 2013 Luento 8 Suunnittelumallit käyttöliittymäohjelmoinnissa Juha-Matti Vanhatupa Yleistä Suunnittelumalli on
LisätiedotTestausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
LisätiedotJä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ätiedotGraafinen käyttöliittymä, osa 1
Graafinen käyttöliittymä, osa 1 Idea, MVC-malli ja ensimmäinen ohjelma Graafinen käyttöliittymä Ensimmäisen kerran tavoitteena on oppia graafisen ohjelman perusidea sekä oppia laatimaan esimerkin mukaan
LisätiedotHallintomallit Suomen valtionhallinnon tietohallintostrategioissa
Hallintomallit Suomen valtionhallinnon tietohallintostrategioissa Lauri Eloranta Helsingin yliopisto Valtiotieteellinen tiedekunta Viestintä Pro gradu -tutkielma, 2014 Hallintomallit)Suomen)valtionhallinnon)tietohallintostrategioissa
Lisätiedothttp://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ätiedotConcurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo
Concurrency - Rinnakkaisuus Group: 9 Joni Laine Juho Vähätalo Sisällysluettelo 1. Johdanto... 3 2. C++ thread... 4 3. Python multiprocessing... 6 4. Java ExecutorService... 8 5. Yhteenveto... 9 6. Lähteet...
LisätiedotTietokantojen suunnittelu, relaatiokantojen perusteita
Tietokantojen suunnittelu, relaatiokantojen perusteita A277, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin
LisätiedotRekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä
Rekursiolause Laskennan teorian opintopiiri Sebastian Björkqvist 23. helmikuuta 2014 Tiivistelmä Työssä käydään läpi itsereplikoituvien ohjelmien toimintaa sekä esitetään ja todistetaan rekursiolause,
Lisätiedot9. 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ätiedotTOIMINNALLINEN MÄÄRITTELY MS
TOIMINNALLINEN MÄÄRITTELY 11.11.2015 MS YLEISTÄ 1/2 jäsennelty etenee yleiskuvauksesta yksityiskohtiin kieliasultaan selkeä kuvaa myös tulevan järjestelmän ympäristöä tarpeellisella tarkkuudella kuvaa
LisätiedotHirviö. Design Patterns
Hirviö SEPA-päiväkirja Design Patterns Anssi Kalliolahti Liia Sarjakoski 8. helmikuuta 2005 1 Sisältö 1 Johdanto 3 2 Menetelmän käytäntöön soveltaminen 3 3 Kokemuksia ja muutoksia 3 3.1 PP..........................................
LisätiedotAlgoritmit 1. Luento 3 Ti Timo Männikkö
Algoritmit 1 Luento 3 Ti 17.1.2017 Timo Männikkö Luento 3 Algoritmin analysointi Rekursio Lomituslajittelu Aikavaativuus Tietorakenteet Pino Algoritmit 1 Kevät 2017 Luento 3 Ti 17.1.2017 2/27 Algoritmien
Lisätiedot10. 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ätiedotFiSMA 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ätiedotOhjelmiston 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