OHJ-3100 Ohjelmien ylläpito ja evoluutio. Harjoitustyö 2011

Koko: px
Aloita esitys sivulta:

Download "OHJ-3100 Ohjelmien ylläpito ja evoluutio. Harjoitustyö 2011"

Transkriptio

1 OHJ-3100 Ohjelmien ylläpito ja evoluutio Harjoitustyö 2011 Sisällys 1. Johdanto Yleisesittely Geneettiset algoritmit Ohjelmistoarkkitehtuurit Perusasioita Arkkitehtuurityylit ja suunnittelumallit Arkkitehtuurin arviointi ja skenaariot Darwin-työkalu Yleiskuvaus GA-moottorin kuvaus Työkalun käyttö Lähteitä Tehtävänanto Yleiskuvaus Skenaarion määrittely Käyttöliittymä Skenaarioiden tulkinta Fitness-arvon laskeminen Output Arvioitu työjakauma Dokumentti Arvostelu ja palautus... 20

2 1. Johdanto 1.1 Yleisesittely Harjoitustyönä toteutetaan Darwin-työkalun laajennus. Darwin on ohjelmistoarkkitehtuurisuunnitteluun liittyvä työkalu, joka käyttää geneettisiä algoritmeja (GA) suunnittelun automatisointiin. Suunnittelija antaa syötteenä suunniteltavan järjestelmän toiminnalliset vaatimukset käyttämällä käyttötapaus- ja sekvenssikaavioita. Näiden pohjalta Darwin rakentaa luokkakaavion, ns. nolla-arkkitehtuurin. Darwin jatkokehittää nolla-arkkitehtuuria lisäten siihen arkkitehtuurityylejä ja suunnittelumalleja. Muokattua arkkitehtuuria arvioidaan kolmen laatuvaatimuksen (muunneltavuus, tehokkuus ja kompleksisuus) kannalta. Laatuvaatimukset on koodattu käyttäen erilaisia ohjelmistometriikoita. Lopputuloksena tuotetaan valmis arkkitehtuurisuunnitelma luokkakaaviona. Nykyään Darwinissa on mahdollista arvioida arkkitehtuuria muunneltavuuden suhteen käyttämällä metriikoiden lisäksi myös skenaarioita (vrt. ATAM-menetelmä). Harjoitustyössä on tarkoitus laajentaa työkalua siten, että myös tehokkuutta voidaan arvioida skenaariotyylisesti. Seuraavassa esitellään lyhyesti geneettiset algoritmit ja ohjelmistoarkkitehtuurien peruskäsitteitä siltä osin kuin on tarpeellista tämän työn kannalta. Luvussa kaksi esitellään harjoitustyön tehtävänanto, ja luvussa kolme käydään läpi arvosteluperiaatteet. 1.2 Geneettiset algoritmit Geneettiset algoritmit kuuluvat meta-heuristisiin etsintäalgoritmeihin. Niitä käytetään etsimään (lähes) optimaalista ratkaisua, kun ratkaisujoukko on hyvin suuri, ja deterministisen algoritmin käyttö ei ole mahdollista. Geneettiset algoritmit nojautuvat biologian ja evoluution käsitteisiin. Jokainen ratkaisu esitetään kromosomina, joka koostuu geeneistä. Geenit ovat ratkaisun muunneltavia osia. Ratkaisua siis muunnellaan käyttämällä (yleensä geeneihin, joskus koko kromosomiin kohdistuvia) mutaatioita. Pelkkiä mutaatioita käyttämällä etsintä rajoittuisi vain hyvin samankaltaisiin ratkaisuihin (nk. naapurustoon), ja olisi suuri riski, että löydetty optimi on vain jokin lokaali huippu. Geneettisen algoritmin vahvuus onkin risteytyksen käyttö hakuavaruuden laajaan haravoimiseen. Risteytyksessä kaksi kromosomia (vanhemmat) yhdistetään, ja niiden tuotoksena saadaan yksi tai useampi uusi yksilö, jo(i)lla on osia kummastakin vanhemmasta. Evoluutio-käsite näkyy geneettisen algoritmin tavassa käyttää luonnonvalintaa. Jokaiselle ratkaisulle lasketaan hyvyysarvo käyttämällä fitness-funktiota. Hyvyysarvo (eli fitness-arvo) kertoo yksilön todennäköisyydestä risteytyä ja selviytyä eteenpäin. Luonnonvalinta karsii huonot yksilöt pois.

3 Geneettisen algoritmin prosessi alkaa populaation luonnilla. Tarvitaan siis jonkinlainen alkuratkaisu, jota kopioimalla saadaan sopiva määrä (esim. 100) yksilöä jatkokehitykseen. Tämän jälkeen ratkaisuihin kohdistetaan mutaatioita ja ratkaisuja risteytetään keskenään. Koska risteytyksen tuloksena syntyy uusia yksilöitä, populaation koko kasvaa yli rajojen ja luonnonvalintaa tarvitaan poistamaan huonot yksilöt. Yksilöille lasketaan hyvyysarvo, ja käyttämällä jotain todennäköisyyksiin perustuvaa menetelmää, valitaan sovittu määrä (esim. 100) yksilöitä seuraavaan sukupolveen, jolloin mutaatio-risteytysfitnesslaskenta-valinta- kierros alkaa jälleen alusta. Algoritmin päätösehtona on yleisesti, että jokin tietty määrä sukupolvia (iteraatioita) tulee täyteen. Muita lopetusehtoja voi olla esim. tietyn hyvyysarvon saavuttaminen. Algoritmi 1 esittää geneettisen algoritmin perusperiaatteet pseudokoodina. Algoritmi 1 geneettinenalgoritmi Input: ratkaisun formalisointi, alkuratkaisu kromosomit luopopulaatio(alkuratkaisu) while NOT lopetusehto do foreach kromosomi in kromosomit p satunnainentodennäköisyys if p > mutaatiotodennäköisyys then mutatoi(kromosomi) end if end for foreach kromosomi in kromosomit cp satunnainentodennäköisyys if cp > risteytystodennäköisyys then lisäävanhempiin(kromosomi) end if end for foreach kromosomi in vanhemmat isä kromosomi äiti valitseseuraavavanhempi(vanhemmat) jälkeläiset risteytys(isä, äiti) lisääjälkeläisetpopulaatioon() poistavanhemmista (isä, äiti) end for foreach kromosomi in kromosomit laskefitness(kromosomi) end for valitseseuraavasukupolvi() end while 1.3 Ohjelmistoarkkitehtuurit Perusasioita Ohjelmistoarkkitehtuuri on ikään kuin ohjelmiston luuranko. ISO standardi määrittelee arkkitehtuurin käsittävän järjestelmän peruskäsitteet tai ominaisuudet omassa ympäristössään, kuvattuna elementteinä,

4 niiden välisinä suhteina ja suunnittelua ohjaavina periaatteina. Arkkitehtuurin voidaan katsoa olevan ikään kuin laki, joka ohjaa järjestelmän toteutusta. Arkkitehtuuria suunnitellessa sovitaan esim. tiettyjen teknologioiden käytöstä, tietorakenteiden käytöstä ja suunnittelumallien käytöstä. Ohjelmiston arkkitehtuuria voidaan mallintaa monella eri tavalla, esim. moduulirakenteella (yksiköt määräytyvät työpakettien mukaan) tai fyysisellä rakenteella (softan mallintaminen komponenttien suhteen). Tässä tehtävänannossa (ja Darwin-työkalussa) käytetään luokkarakennetta: arkkitehtuuri ilmennetään olioperustaisen suunnittelun tapaan UML-luokkakaaviona. Ohjelmistoarkkitehtuurin pääasiallinen tarkoitus on vastata laatuvaatimuksiin. Järjestelmä voidaan yleensä toteuttaa toiminnallisuuden puolesta hyvin monella eri tavalla, mutta nämä eri toteutustavat voivat olla laadultaan hyvin erilaisia. Laatua arvioidaan eri ominaisuuksien perusteella, esim. muunneltavuus, tehokkuus, luotettavuus ja käytettävyys. Arkkitehtuuri pyritään suunnittelemaan niin, että mahdollisimman moni laatuvaatimus täyttyy Arkkitehtuurityylit ja suunnittelumallit Arkkitehtuurityylit (Shaw ja Garlan) ja suunnittelumallit (Gamma et al.)ovat hyväksi havaittuja ratkaisuja tiettyihin ongelmiin. Arkkitehtuurityylejä käytetään yleensä ratkaistaessa korkean tason ongelmia, jotka käsittävät koko arkkitehtuurin, kun taas suunnittelumalleja käytetään paikallisempiin, muutaman komponentin käsittäviin ongelmiin. Etenkin suunnittelumalleista on koottu eräänlaisia katalogeja, jossa voi tilanteen perusteella valita suunnittelumallin, joka ratkaisee ongelman. Yksi tunnetuimmista katalogeista on Gamma et al.:n kirja, jossa esitellään olio-ohjelmoinnissa käytettyjä suunnittelumalleja. Nämä suunnittelumallit pyrkivät yleisesti parantamaan järjestelmän muunneltavuutta ja ylläpidettävyyttä. Darwinissa on käytössä kaksi arkkitehtuurityyliä (viestinvälittäjä ja asiakas-palvelin) sekä viisi suunnittelumallia (Mediator, Façade, Strategy, Adapter, Template Method). Harjoitustyön kannalta on oleellista tuntea näiden arkkitehtuurityylien ja suunnittelumallien rakenne, ts. kuinka tietyn tyylin tai mallin käyttö esitetään luokkakaaviotasolla (Darwinissa). Muutoin ei ole tarpeen tuntea tyylien ja mallien vaikutusta arkkitehtuurin laatuun, tai miten ne käytännössä toteutetaan. Alla on näytetty, miten suunnittelutyylit ja mallit ilmenevät Darwinin tuottamissa luokkakaavioissa, ja miten Darwin niitä käyttää. Tässä ei siis ole tarkoitus antaa yleispätevää kuvausta kyseisistä tyyleistä tai malleista, vaan esitellä ne siten, että työkalun käyttö ja muokkaus on ymmärrettävissä. Arviointi/käyttö tämän tehtävän kannalta on selostettu kohdassa 2.5. Esimerkeissä on käytetty e-koti -järjestelmää, jota on käytetty Darwinilla tehdyissä testeissä esimerkkijärjestelmänä. Kuva 1. Viestinvälittäjä

5 Viestinvälittäjän rakenne on näytetty kuvassa 1. Luokka TemperatureRegulation kutsuu viestinvälittäjää, joka kutsuu HeaterManager-luokan rajapintaa. Ilman viestinvälittäjää TemperatureRegulation kutsuisi itse rajapintaa suoraan. Viestinvälittäjä ilmaistaan stereotypioidulla luokalla. Kuva 2. Asiakas-palvelin Asiakas-palvelin tyyli on näytetty kuvassa 2. Tyyli ilmaistaan stereotypioimalla luokka server - tyypillä. Darwin käsittää kaikki tätä luokkaa käyttävät luokat asiakkaiksi, joita ei identifioida erikseen. Kuva 3. Façade. Façade-tyyli on esitetty kuvassa 3. Façade:lla on vahva lähtöehto: luokkarakenteessa tulee löytyä ryhmittymiä niin, että ryhmittymässä 1 (esimerkissä luokat A, B ja F) kaikki kutsuvat useaa luokkaa ryhmittymässä 2 (esimerkissä C, D, E ja G), ja myös ryhmittymän 2 sisällä on luokkien välisiä kutsuja. Ryhmittymän 2 luokat eivät kuitenkaan tarvitse ryhmittymän 1 luokkia. Façade selkeyttää rakennetta lisäämällä Façade-luokan ja rajapinnan. Ryhmä 1 kutsuu nyt vain Façade-rajapintaa, joka tarjoaa kaikki ryhmittymästä 2 tarvittavat metodit. Façade-luokka välittää kutsun konkreettiselle luokalle, joka toteuttaa aina tarvitun metodin.

6 Kuva 4. Mediator Mediator-tyyli on esitetty kuvassa 3. Mediator on samantyylinen kuin Façade, mutta siinä riittää käytännössä vain yksi ryhmä luokkia, jonka sisällä on paljon ristikkäisiä kutsuja. Mediator selkeyttää Façaden tavoin rakennetta lisäämällä Mediator-rajapinnan, jossa on kaikki tarvittavat metodit. Kaikki luokat kutsuvat nyt tätä rajapintaa, ja Mediator-luokka välittää kutsun toteuttaville luokille. Kuva 5. Strategy Strategia on näytetty kuvassa 5. Strategia mallinnetaan luokalla ja rajapinnalla. Strategian esiehtona on, että luokassa on sisäinen riippuvuus (tässä setroomtemperature kutsuu operaatiota measuretemperature,). Ilman Strategiaa ei siis ole luokkien välisiä kutsuja. Kun Strategia lisätään, luokan sisältä kutsuttu operaatio eriytetään omaan Strategia-luokkaansa, joka toteuttaa Strategia-rajapinnan

7 (kuten kuvassa). (Strategian oikeassa määritelmässä rajapinnan toteuttavia luokkia on useita, mutta Darwinissa käytetään vain yhtä.) Strategia-luokka joutuu usein kutsumaan isäntä-luokkaa, mikäli sen taakse sijoitettu operaatio tarvitsee isäntäluokasta dataa (tässä measureroomtemperature tarvitsee temperaturestate-dataa). Kuva 6. Adapter Adapteri on esitetty kuvassa 6. Adapterin myötä luokkien välille toteutetaan Adapter-luokka ja Adapterrajapinta, jolloin kutsuvan luokan (tässä TemperatureRegulation) ei tarvitse välittää, mikäli alkuperäinen rajapinta (HeaterInterface) muuttuu. Ilman Adapteria TemperatureRegulation kutsuisi suoraan HeaterInterface-rajapintaa. Kuva 7. Template Method Template Method on esitetty kuvassa 7. Esiehtona on Strategian tavoin tilanne, että luokan sisällä on riippuvuus. Toisin kuin Strategiassa, sisäoperaatiota ei kuitenkaan eriytetä kokonaan omaan luokkaansa, vaan sen toteutus siirretään aliluokkaan. Käytännössä Darwinin kannalta Template Methodin ei katsota aiheuttavan ylimääräisiä luokkien välisiä kutsuja Arkkitehtuurin arviointi ja skenaariot Arkkitehtuurien arviointi on työlästä, ja arkkitehtuuria ei voi ikinä arvioida vain yhden laatuominaisuuden kannalta. Yksi tunnetuimpia arkkitehtuurien arviointimekanismeja on ATAM (Clements et al.). ATAMarvioinnissa eri sidosryhmät (suunnittelijat, ohjelmoijat, markkinoinnin edustajat, kirjanpitäjät, käyttäjät) esittävät laatuvaatimuksia omasta näkökannastaan, ja kiinnostusten mukaan nämä vaatimukset ovat usein

8 ristiriitaisia. Esim. suunnittelija haluaa yleensä tehdä mahdollisimman luotettavan järjestelmän, kun markkinointi haluaa järjestelmän kauppoihin mahdollisimman nopeasti, jolloin yleensä luotettavuus kärsii, kun testaamiseen ei ole aikaa. Kirjanpitäjä haluaa mahdollisimman halvan järjestelmän, jolloin kaikkia käyttäjän toimia erikoisominaisuuksia ei välttämättä ole varaa toteuttaa. Laatuvaatimukset esitetään ATAM-arvioinnissa skenaarioiden avulla. Skenaario kuvaa todennäköistä tilannetta (johon järjestelmä käytössä joutuu) jonkin tietyn laatuattribuutin suhteen. Esimerkiksi käytettävyyden yhteydessä skenaariot liittyvät usein käyttöliittymään ja sen toteutukseen, kun taas ylläpidettävyyteen ja muunneltavuuteen liittyvät skenaariot yrittävät ennakoida järjestelmään mahdollisesti kohdistuvia muutoksia tai lisäyksiä ja niiden toteuttamista. Skenaarioille annetaan prioriteetti ja muutosskenaarioiden kohdalla arvioitu todennäköisyys. Darwinin e-koti -järjestelmälle on määritelty muunneltavuusskenaarioita seuraavaan tyyliin ATAMarviointia simuloiden. Kyseisen sovellusalan asiantuntijoiden mukaan on erittäin todennäköistä, että tapa, jolla verhojen sijainti lasketaan, halutaan vaihtaa. Myös vaihtoehtoisen esitystavan lisääminen musiikkilistan näyttämiseen on todennäköisesti edessä. On myös hyvin mahdollista, että halutaan lisätä toinen tapa mitata auringonvaloa. Kahvikoneen tilan näyttäminen halutaan melko varmasti toteuttaa toisin, toinen, mutta hieman epätodennäköisempi vaihtoehto on, että kaksi eri toteutusta ovat rinnakkain. Pieni mahdollisuus on, että kaiuttimen valinta halutaan toteuttaa toisin. Melko epätodennäköistä, mutta kuitenkin mahdollista on myös, että käyttäjärekisterin asettaminen, sekä vedenkulkuun liittyvät toiminnot korvataan täysin toisilla operaatioilla. Käyttäjät puolestaan haluavat ennen kaikkea, että musiikkilistan esitystapa ja verhonsijainnin laskenta ovat vaihdettavissa. Lähes yhtä tärkeää on, että huoneen lämpötilan laskentaan ja musiikkilistan hallinnointiin voidaan vaikuttaa. Mahdollisuus vaikuttaa kahvin laadun ja määrän valintatapaan olisi hienoa, mutta todennäköisesti näille muutoksille ei ole suurta tarvetta. Näillä skenaarioilla voidaan identifioida, mihin osaan järjestelmää muutoksia todennäköisesti tulee, ja kuinka suuri todennäköisyys on. Todennäköisyyden mukaan skenaarioiden kriittisyys voidaan arvioida. Tässä työssä on tarkoitus toteuttaa tehokkuusskenaarioiden arviointi. Skenaariot annetaan käyttötapauksina sekvenssikaavioiden avulla, joten sanallista muotoilua ei tässä vaiheessa tarvita. 1.4 Darwin-työkalu Yleiskuvaus Työkalun perustarkoitus on tarjota käyttöliittymä työkalun taustalla olevalle GA-moottorille. GAmoottori toteuttaa geneettisen algoritmin ja kehittää arkkitehtuurin. Darwinissa puolestaan on toteutettu rajapinnat GA-moottoriin sekä käyttöliittymä. Darwin on toteutettu Java-ohjelmointikielellä, joten Javan osaaminen on oleellista. Darwin on Eclipse plug-in, joten Eclipse API:n tunteminen on suureksi hyödyksi harjoitustyössä. Eri kaavioiden tuottamiseen käytetään Papyrus -plug-iniä, ja fitness-käyrän kuvaamiseen

9 on käytetty JFreeChart -plug-iniä. Kuva 8 kuvaa Darwinin karkeaa arkkitehtuuria. Huomaa, että kuvassa oleva UML2Tools on korvattu Papyruksella nykyisessä toteutuksessa. Darwin JFreeChart UML2Tools Zest GA Engine Eclipse plug-in architecture ECLIPSE Kuva 8. Darwin Darwinin arkkitehtuuri perustuu MVC-tyyliin (Model View Controller). Darwinin MVC-rakenne on näytetty kuvassa 9. Mallina toimii evoluution käsite. Evoluutio koostuu periodeista, ja jokaiselle periodille määritellään mutaatiotodennäköisyydet, osafitness-funktioiden painot sekä muut asetukset. Yksinkertaisimmillaan evoluutiossa on vain yksi periodi, jolloin asetukset pysyvät samana koko evoluution ajan. Periodin käsite ei kuulu suoraan geneettisten algoritmien periaatteisiin, mutta on otettu mukaan, jotta arkkitehtuurin suunnittelua voidaan tarvittaessa ohjailla tarkemmin. Periodi mahdollistaa eri todennäköisyydet ja painotukset evoluution eri osiin, jolloin esim. evoluutio alussa voidaan suosia hyvin korkean tason ratkaisuja ja painottaa tiettyä laatuvaatimusta, kun taas evoluution lopussa voidaan suosia yksityiskohtaisempia vaatimuksia ja pyrkiä tasapainottamaan laatuattribuutit. Jokainen periodi koostuu sen sisältämistä sukupolvista (generation), ja jokainen sukupolvi sisältää populaatiollisen arkkitehtuureja. Periodi sisältää myös skenaariot. Huomaa siis, että työkalussa skenaarioita ei suoraan liitetä yhteen evoluutioon (eli GA-kierrokseen) vaan aina yhteen periodiin. MVC-tyylin mukaisena näkymänä toimivat käyttöliittymän eri näkymät. Kuvassa 9 luetellut näkymät on linkattu käyttöliittymään kuvassa 10. Kontrolleri hoitaa logiikan ja vastaa siitä, että malli ja näkymät ovat synkassa.

10 MODEL CONTROLLER VIEW Evolution Explorer Evolution Controls Generation View Mutations View Settings View Weights View Scenarios View Kuva 9. Darwinin MVC-rakenne Evolution controls Use case diagram Class diagram Family tree Settings view Evolution explorer Menu group Mutations view Scenarios view Weights view Generation view GA-moottorin kuvaus Kuva 10. Näkymät käyttöliittymässä GA-moottori, eli Frankenstein vastaa varsinaisesta arkkitehtuurisuunnittelusta. Jokainen arkkitehtuuri (eli ratkaisu) on yksi kromosomi. Jokainen operaatio arkkitehtuurissa (attribuutit lasketaan operaatioiksi) mallinnetaan yhdellä supergeenillä (SuperGene). Supergeenissä on oma kenttä jokaiselle operaation ominaisuudelle. Operaatioille määritellään erilaisia arvoja, esim. käyttöfrekvenssi ja parametrin koko. Operaatio kantaa myös tiedon siitä, missä luokassa se sijaitsee, missä suunnittelumalleissa se on osallisena, onko luokka, johon se on allokoitu, serveri, ja kommunikoiko se viestinvälittäjän kautta. Huomaa siis, että kromosomikoodaus on operaatio-, eikä luokkalähtöinen! Tämän työn kannalta

11 riittää ymmärtää kromosomikoodaus siltä osin, että saadaan tarvittavat tiedot fitness-arvon laskemista varten. Kuva 11. Yksinkertaistettu luokkakaavio Frankensteinista. Kuva 11 Esittää karkealla tasolla Frankensteinin luokkarakenteen. Kuvaan on merkitty esim. Pattern- ja Scenario-luokista vain yläluokat, ei niistä periytyviä aliluokkia. Luokilla on seuraavia vastuita. Frankenstein: main-luokka Cromosome: päätietorakenne SuperGene: Cromosome koostuu SuperGeneistä Fitness: fitness-funktio, fitness-arvon instanssi GeneticAlgorithm: pyörittää GA:n toimintoja (mutaatio, risteytys, valinta) Pattern: suunnittelumallin instanssi InputDataHandler: käsittelee toiminnalliset vaatimukset, mikäli työkalua käytetään komentoriviltä OutputDataHandler: vastaa logitiedostosta, erityisesti silloin kun käytetään komentoriviltä UMLGenerator: työstää Cromosome:n UML-luokkakaavioksi ScenarioInterpreter: koodaa/tulkitsee muunneltavuusskenaariot Scenario: skenaarion instanssi

12 1.4.3 Työkalun käyttö Käyttäjä aloittaa antamalla syötteenä järjestelmän toiminnalliset vaatimukset. Vaatimusten antamiseen käytetään käyttötapaus- tai sekvenssikaaviota. Näiden pohjalta Darwin rakentaa luokkakaavion, ns. nolla-arkkitehtuurin. Luokkakaaviossa olevia metodeja kutsutaan operaatioiksi, jotka määrittelevät arkkitehtuurin toiminnallisuuden. Operaatiot saadaan suoraan sekvenssikaavioon määritellyistä kutsuista. Arkkitehtuuria toteutettaessa yksi operaatio voidaan koodata useamman metodin (tai jopa luokan) avulla (Darwin ei ota kantaa toteutukseen). Luokkakaaviossa attribuutit edustavat operaatioiden käsittelemää dataa, yleensä jotain tietokantaa tai tilatietoa. Jokaista attribuuttia kohden oletetaan get- ja set metodit, vaikka näitä ei esitetä luokkakaaviossa. Kun nolla-arkkitehtuuri on määritelty, käyttäjä säätää erilaiset GA:n tarvitsemat parametrit. Weights - kohdassa annetaan painotukset fitness-funktion eri osafunktioille (jokaiselle laatuattribuutille oma paino sen mukaan, mitä korostetaan). Jokaiselle mutaatiolle tulee määritellä sen toteutumistodennäköisyys Probabilities -kohdassa. GA:lle asetetaan myös populaation koko ja sukupolvien määrä ( Evolution - tab). Kaikkiin asetuksiin on oletusarvot, joita voi käyttää. Kun käyttäjä on säätänyt parametrit, aloitetaan evoluutio. Darwin kutsuu GA-moottoria, Frankensteinia, joka toteuttaa GA-prosessin (mutaatiot, risteytykset, luonnonvalinta). Darwin näyttää reaaliajassa, miten populaation (arkkitehtuurien) fitness kehittyy. Mikäli fitness-arvo kehittyy väärin, käyttäjä voi keskeyttää evoluution, säätää parametreja, ja aloittaa uudestaan. Muuten evoluutioprosessia jatketaan, kunnes sukupolvet täyttyvät. Kun evoluutioprosessi on valmis, näytetään käyttäjälle luokkakaaviona viimeisen sukupolven paras yksilö (käyttäjä valitsee parhaan yksilön klikkaamalla supermieskuvaketta). 1.5 Lähteitä E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, M. Shaw, D. Garlan: Software Architecture, Perspectives on an Emerging Discipline, Prentice Hall, P. Clements, R. Kazman, M. Klein: Evaluating Software Architectures, Addison-Wesley, Sriharsha Vathsavayi on tehnyt Darwinista DI-työnsä, "Tool support for genetic synthesis of software architectures". Outi Räihä on tehnyt Darwinin taustalla olevasta GA-moottorista (Frankenstein) lisensiaatintyönsä: Genetic Synthesis of Software Architecture, joka on luettavissa verkossa: Darwinin taustalla olevasta geneettisiin algoritmeihin pohjautuvasta arkkitehtuurisynteesistä on tehty useita julkaisuja, kts. Julkaisuja voi pyytää tarvittaessa harjoitustyön ohjaajalta.

13 2. Tehtävänanto 2.1 Yleiskuvaus Tehtävänä on laajentaa Darwin-työkalua siten, että muunneltavuuden lisäksi myös tehokkuutta voidaan arvioida skenaarioiden kautta. Tehokkuusskenaarioarviointia on käytetty arvioitaessa monioptimoivan fitness-funktion tuottamaa ratkaisurintamaa, mutta tuolloin arviointi jouduttiin tekemään manuaalisesti, mikä vei paljon aikaa. Harjoitustyössä on tarkoitus toteuttaa tehokkuusskenaarioarvioinnin automatisointi. Tehokkuusskenaarioina käytetään käyttötapauksia. Skenaarion katsotaan toteutuvan sitä paremmin, mitä nopeammin käyttötapauksesta suoriudutaan. Jokaisesta käyttötapauksesta suoriudutaan tehokkaimmin nolla-arkkitehtuurivaiheessa, kun arkkitehtuurissa ei ole ylimääräisiä yhteyksiä luokkien ja operaatioiden välillä tuomassa tehokkuusrasitetta. Kun arkkitehtuuria parannellaan muunneltavuuden suhteen, sen tehokkuus laskee. Tehokkuusskenaarioiden avulla voidaan tarkastella, kuinka paljon tehokkuus on laskenut tiettyjen käyttötapausten kohdalla, ja arkkitehtuurisuunnittelua voidaan ohjailla arvottamalla tehokkuuskriittiset käyttötapaukset muita korkeammiksi. Lisäksi skenaarioilla voidaan evaluoida metriikoihin perustuvan fitness-funktion oikeellisuutta. Jotta tehokkuusskenaarioita voidaan käyttää, tulee toteuttaa niiden määrittely, tarvittavat muutokset käyttöliittymään, skenaarioiden tulkinta, skenaariofitness-arvon laskeminen ja fitness-arvon näyttäminen käyttäjälle. 2.2 Skenaarion määrittely Yksi käyttötapaus määrittelee yhden skenaarion. Käyttötapaus voi olla yksi (nolla-)arkkitehtuurin määrittelevistä käyttötapauksista, määrittelevän käyttötapauksen osa tai täysin uusi käyttötapaus Käyttötapaus annetaan sekvenssikaaviona, ja se on käytännössä sarja operaatioiden välisiä kutsuja, esim. keitäkahvia laitakahvikonepäälle mittaavesi mittaakahvi avaavesi lämmitäkahvi päivitänäyttö. Sekvenssikaavioon mahdollisesti tulevat toimintaok -tyyliset paluukutsut eivät kuulu skenaarioon. Käyttäjä määrittelee skenaariot antamalla tarvittavat sekvenssikaaviot, joissa yksi sekvenssikaavio kuvaa yhden käyttötapauksen eli skenaarion. HUOM! Uusia operaatioita tai operaatioiden välisiä riippuvuuksia ei voida määritellä skenaarioita määritellessä! Käytännössä siis uusi käyttötapaus tulee rakentaa olemassa olevien (järjestelmän määrittelevien) käyttötapausten pohjalta käyttämällä samoja kutsusekvenssejä tai niiden osia. Mikäli operaatiota A ei seuraa operaatio B missään alkuperäisessä käyttötapauksessa, EI voida tuottaa sellaista skenaariota, jossa olisi A B.

14 2.3 Käyttöliittymä Käyttöliittymää tulee muokata siten, että skenaariot voidaan syöttää erillisinä sekvenssikaavioina. Annetut sekvenssikaaviot (skenaariot) tulee voida tallentaa (esim. XML-muodossa). Tallennetut skenaariot tulee voida ladata, jotta samoja skenaarioita ei tarvitse määritellä joka kerta uudestaan. Scenarios-näkymää tulee laajentaa siten, että nykyisten muunneltavuusskenaarioiden lisäksi sen kautta voidaan tuottaa listana myös tuotetut/annetut tehokkuusskenaariot. Scenarios-näkymässä pitää myös antaa käyttöliittymä tehokkuusskenaarioiden lataamiseksi (vrt. nykyinen näkymä muunneltavuusskenaarioille). Listassa jokaiselle skenaariolle tulee olla nimi sekä sen koko (eli sekvenssikaavion kutsujen määrä). Lisäksi Weights-näkymään tulee lisätä kohta tehokkuusskenaarioille, ts. tehokkuusskenaariolle tulee voida antaa oma painonsa. 2.4 Skenaarioiden tulkinta Kun skenaariot on annettu sekvenssikaavioina, ne tulee koodata muotoon, jota GA ymmärtää, ja jota voidaan käyttää tehokkuuslaskennassa. Olemassa olevaa koodausta ja tulkintaa muunneltavuusskenaarioille voi käyttää pohjana, mutta on huomioitava, että tehokkuusskenaariot ovat luonteeltaan hyvin erilaisia. Valitun koodaus/tulkintatavan tulisi olla joustava ja ottaa huomioon, että vastaisuudessa voidaan haluta lisätä erityyppisiä tehokkuusskenaarioita. 2.5 Fitness-arvon laskeminen Fitness-funktioon tulee lisätä uusi osafitness-funktio tehokkuusskenaarioiden fitness-arvon laskemiseen. Skenaariofitness-arvon käyttöönottoa säädellään painolla; mikäli paino on 0, osafunktiota ei luonnollisesti tule laskea mukaan. Muissa tapauksissa (paino > 0) tehokkuusskenaariofitness käyttäytyy kuten muutkin osafitness-funktiot, eli se lasketaan osaksi kokonaisfitness-arvoa. Tehokkuusseknaariofitness-arvot tulee rekisteröidä erikseen, jotta arvon kehitystä voidaan tarkastella ajon jälkeen. Tehokkuus lasketaan siten, että jokaisesta luokkien välisestä kutsusta tulee rankaisu -1, jokaisesta serverikutsusta lisärankaisu -s ja jokaisesta viestinvälittäjän (dispatcher) käytöstä lisärankaisu -d. Serverija viestinvälittäjärankaisujen kertoimet tulee siis voida asettaa käyttöliittymän kautta! Näiden kertoimien tulisi kutienkin lähtökohtaisesti olla > 1. Huomaa, että kutsu luokasta rajapintaan katsotaan yhtäläiseksi suoran kutsun (luokasta luokkaan) kanssa. Ts. jos operaatio a kutsuu operaatio b:tä, ja b on eri luokassa kuin a, on skenaarion kannalta yhdentekevää, toteuttaako b jonkin rajapinnan vai ei.

15 Esimerkki: Asetetaan d = 2 ja s = 2 (ts. jokainen viestinvälittäjä- ja serverikutsu saa lisärangaistuksen, joka kerrotaan vastaavalla kertoimella). Oletetaan, että käyttötapauksessa on kutsu keitäkahvia laitakahvikonepäälle ts. keitäkahvia(){.. laitakahvikonepäälle(); }. Tapaus 1: keitäkahvia ja laitakahvikonepäälle ovat samassa luokassa: tehokkuusrankaisu 0 (Kuva 12) Kuva 12. Tapaus 1. Tapaus 2: keitäkahvia ja laitakahvikonepäälle ovat luokissa A ja B, luokkien välillä on suora kutsu (kuva 13) tai keitäkahvia kutsuu B-luokan rajapintaa (kuva 14), jonka laitakahvikonepäälle toteuttaa: tehokkuusrankaisu -1 Kuva 13. Tapaus 2, suora yhteys

16 Kuva 14. Tapaus 2, rajapintayhteys Tapaus 3: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa, ja luokkien välissä on ylimääräinen komponentti, esim. Adapteri: tehokkuusrankaisu: -1-1 = -2 (Kuva 15) Huom! Frankensteinin koodissa Adapteri-patterni esiintyy nimellä Proxy. Kuva 15. Tapaus 3, adapteriyhteys Tapaus 4: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa, ja laitakahvikonepäälle luokka on merkattu serveriksi: tehokkuusrankaisu: -1-2= -3 (Kuva 16) Kuva 16. Tapaus 4, yhteys serveriin

17 Tapaus 5: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa ja käyttävät viestinvälittäjää kommunikointiin: tehokkuusrankaisu: = -4 (Kuva 17) Kuva 17. Tapaus 5, yhteys viestinvälittäjän kautta Tapaus 6: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa, ja laitakahvikonepäälle luokka on merkattu serveriksi. Lisäksi laitakahvikonepäälle-operaatiota tulisi käyttää Adapterin kautta: tehokkuusrankaisu lasketaan -1 (keitäkahvia->adapteri) -1(adapteri->serveri)-2 (serverilisä) = -4. (Kuva 18) Kuva 18 Tapaus 6, yhteys adapterin kautta serveriin

18 Tapaus 7: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa, ja kommunikoivat viestinvälittäjän kautta. Lisäksi laitakahvikonepäälle-operaatiota tulisi käyttää Adapterin kautta: tehokkuusrankaisu = -5 (Kuva 19). Kuva 19 Tapaus 7, yhteys viestinvälittäjän ja adapterin kautta Käyttötapauksen lopullinen fitness-arvo on summa kaikista tehokkuusrangaistuksista, jotka lasketaan aina kahden operaation välisestä yhteydestä. Esim. Jos skenaario on yllämainittu keitäkahvia laitakahvikonepäälle mittaavesi mittaakahvi avaavesi lämmitäkahvi päivitänäyttö, saadaan tästä 6 eri operaatioiden välistä yhteyttä, joille jokaiselle lasketaan tehokkuusrankaisu, ja kokonaisrankaisu on näiden summa. Ratkaisun (arkkitehtuurin) tehokkuusskenaariofitness-arvo on luonnollisesti kaikkien yksittäisten käyttötapaustehokkuuksien summa. 2.6 Output Työkalu näyttää reaaliajassa, miten arkkitehtuurien keskimääräinen fitness-arvo kehittyy. Lisäksi on mahdollista erotella eri osafitness-funktioiden fitness-käyrät, kun tulos on valmistunut. Tehokkuusskenaarioiden erillistä fitness-käyrää tulee voida tarkastella vastaavasti kuin muitakin osafitness-funktioiden käyriä nykyisessä toteutuksessa.

19 2.7 Arvioitu työjakauma HUOM! Työmäärä on ARVIO, ja sen tarkoituksena on auttaa ajankäytön suunnittelussa ja selkeyttää työprosessia. Todellinen työmäärä on hyvin todennäköisesti jotain muuta, ja riippuu opiskelijan ajankäytöstä, esitiedoista ja taidoista. DARWIN Syötteen antaminen Vaihe1: n. 20t Sekvenssikaavio Painonäkymä (Weights) Syötteen koodaus FRANKENSTEIN Skenaariototeutus GAlle Koodauksen tulkinta Fitness-funktio Kromosomin lukeminen Vaihe2: n. 30t DARWIN Tulosteen antaminen Vaihe3: n. 10t Fitness-käyrä

20 2.8 Dokumentti Harjoitustyö tulee dokumentoida. Dokumenttipohja on vapaamuotoinen. Dokumentista tulee ilmetä, mitä lisäyksiä/muutoksia koodiin on tehty kussakin eri vaiheessa, minne ko. muutokset/lisäykset on tehty (luokan nimi), ja miten uudet komponentit (erityisesti skenaarioiden (syötteen) koodaus ja tulkinta) on toteutettu (käytännössä tulee käydä läpi edellä olevat kohdat ). Lisäksi koodiin tulee kommentoida tehdyt muutokset SELKEÄSTI. Muutetut/lisätyt kohdat tulee jokainen kommentoida alla olevaan tyyliin /** * * <Ryhmän jäsenten nimet> *<lyhyesti, mitä on lisätty/muutettu> *<lyhyt esittely koodin/muutoksen tarkoituksesta> */ 3. Arvostelu ja palautus Harjoitustyö tulee palauttaa vastaavanlaisena pakettina kuin se on tällä hetkellä ladattavissa. Ts. ryhmien tulee toteuttaa muutoksensa koodiin, tallentaa paketti, ja palauttaa se harjoitustyön ohjaajalle. Zip-paketti tulee nimetä ryhmän mukaan esim: Virtanen_Nieminen_Koskinen.zip Dokumentti tulee olla mukana zip-paketissa. Paketin voi joko ladata verkkoon tai sen voi tuoda USB-tikulla ohjaajan työhuoneeseen TE213 arkisin klo välisenä aikana. Harjoitustyö on palautettava viimeistään Hyväksytystä harjoitustyöstä saa 3 pistettä. Hyväksytyn harjoitustyön kriteerit ovat (pakolliset vaatimukset): - Tehokkuusskenaariot (käyttötapaukset) pystyy syöttämään jotenkin. Ei siis vaadita välttämättä sekvenssikaavioita, vaan riittää esim. teksti- tai XML-tiedosto, jonka voi ladata työkaluun. o Käyttöliittymässä Skenaarionäkymä on päivitetty niin, että syötetyt skenaariot voidaan nähdä listana. Listassa jokainen skenaario on nimetty ja skenaarion suuruus (= sekvenssikaavion kutsujen määrä) on laskettu. - Serveri- ja viestinvälittäjäkertoimet voidaan antaa Skenaarionäkymässä. - Skenaarioiden koodaus ja tulkinta on toteutettu toimivasti

19.10.2011. Harjoitustyö Ohjaaja: Outi Räihä outi.raiha@tut.fi TE213. OHJ-3100 Ohjelmien ylläpito ja evoluutio. Yleiskatsaus.

19.10.2011. Harjoitustyö Ohjaaja: Outi Räihä outi.raiha@tut.fi TE213. OHJ-3100 Ohjelmien ylläpito ja evoluutio. Yleiskatsaus. OHJ-3100 Ohjelmien ylläpito ja evoluutio 1 Yleiskatsaus 2 Harjoitustyö Ohjaaja: Outi Räihä outi.raiha@tut.fi TE213 Yleisesittely Geneettiset algoritmit Ohjelmistoarkkitehtuurit Darwin-työkalu Tehtävänanto

Lisätiedot

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto OHJ-3200 Ohjelmistoarkkitehtuurit 1 Arkkitehtuurien tutkimus Outi Räihä 2 Darwin-projekti Darwin-projekti: Akatemian rahoitus 2009-2011 Arkkitehtuurisuunnittelu etsintäongelmana Geneettiset algoritmit

Lisätiedot

Harjoitustyö Ohjaaja: Outi Räihä TE213

Harjoitustyö Ohjaaja: Outi Räihä TE213 OHJ-3100 Ohjelmien ylläpito ja evoluutio 1 Harjoitustyö Ohjaaja: Outi Räihä outi.raiha@tut.fi TE213 2 Yleiskatsaus Yleisesittely Geneettiset algoritmit Ohjelmistoarkkitehtuurit Darwin-työkalu Tehtävänanto

Lisätiedot

OHJ-3100 Ohjelmien ylläpito ja evoluutio. Harjoitustyö. Ohjaaja: Outi Sievi-Korte outi.sievi-korte@tut.fi TE213 Päivystys ti klo 14-16

OHJ-3100 Ohjelmien ylläpito ja evoluutio. Harjoitustyö. Ohjaaja: Outi Sievi-Korte outi.sievi-korte@tut.fi TE213 Päivystys ti klo 14-16 OHJ-3100 Ohjelmien ylläpito ja evoluutio 1 Harjoitustyö Ohjaaja: Outi Sievi-Korte outi.sievi-korte@tut.fi TE213 Päivystys ti klo 14-16 2 Yleiskatsaus Yleisesittely Geneettiset algoritmit Ohjelmistoarkkitehtuurit

Lisätiedot

Harjoitustehtävät viikolle 42

Harjoitustehtä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ätiedot

Darwin: Tutkimusprojektin esittely

Darwin: Tutkimusprojektin esittely 1 Darwin: Tutkimusprojektin esittely Tutkimusongelma: voidaanko ohjelmistoarkkitehtuuri generoida automaattisesti? Suomen Akatemian rahoittama tutkimusprojekti 2009-2011 TTY & TaY yhteistyö Ks. http://practise.cs.tut.fi/project.php?project=darwin

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 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. Kevät

Ohjelmistoarkkitehtuurit. 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ätiedot

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton 2015 syksy 2. vsk IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton Sisältö 1. Johdanto luontimalleihin 2. Proxy 3. Factory Method 4. Prototype 5. Singleton Suunnittelumallit Proxy et.

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2010

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

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

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

TIES592 Monitavoiteoptimointi ja teollisten prosessien hallinta. Yliassistentti Jussi Hakanen syksy 2010

TIES592 Monitavoiteoptimointi ja teollisten prosessien hallinta. Yliassistentti Jussi Hakanen syksy 2010 TIES592 Monitavoiteoptimointi ja teollisten prosessien hallinta Yliassistentti Jussi Hakanen jussi.hakanen@jyu.fi syksy 2010 Evoluutiopohjainen monitavoiteoptimointi MCDM ja EMO Monitavoiteoptimointi kuuluu

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

Geneettiset algoritmit

Geneettiset algoritmit Geneettiset algoritmit Evoluution piirteitä laskennassa Optimoinnin perusteet - Kevät 2002 / 1 Sisältö Geneettisten algoritmien sovelluskenttä Peruskäsitteitä Esimerkkejä funktion ääriarvon etsintä vangin

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

Ohjelmistojen suunnittelu

Ohjelmistojen 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

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

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

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

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2010

Ohjelmistojen mallintaminen, kesä 2010 582104 Ohjelmistojen mallintaminen, kesä 2010 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

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

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2009

Ohjelmistojen mallintaminen, kesä 2009 582104 Ohjelmistojen mallintaminen, kesä 2009 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen 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ätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

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

Lisätiedot

T SEPA - päiväkirja: Design Patterns. ETL työkalu

T SEPA - päiväkirja: Design Patterns. ETL työkalu T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty

Lisätiedot

Ohjelmistotekniikan menetelmät, kesä 2008

Ohjelmistotekniikan menetelmät, kesä 2008 582101 - Ohjelmistotekniikan menetelmät, kesä 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön

Lisätiedot

Rajapinta (interface)

Rajapinta (interface) 1 Rajapinta (interface) Mikä rajapinta on? Rajapinta ja siitä toteutettu luokka Monimuotoisuus ja dynaaminen sidonta Rajapinta vs periytyminen 1 Mikä rajapinta on? Rajapintoja käytetään, kun halutaan määritellä

Lisätiedot

Yllä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 Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari

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

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

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

Lisätiedot

AS Automaation signaalinkäsittelymenetelmät. Tehtävä 1. Käynnistä fuzzy-toolboxi matlabin komentoikkunasta käskyllä fuzzy.

AS Automaation signaalinkäsittelymenetelmät. Tehtävä 1. Käynnistä fuzzy-toolboxi matlabin komentoikkunasta käskyllä fuzzy. AS-84.161 Automaation signaalinkäsittelymenetelmät Tehtävä 1. Käynnistä fuzzy-toolboxi matlabin komentoikkunasta käskyllä fuzzy. Tämän jälkeen täytyy: 1. Lisätä uusi sisääntulo edit->add input 2. nimetä

Lisätiedot

Avainsanojen poimiminen Eeva Ahonen

Avainsanojen poimiminen Eeva Ahonen Avainsanojen poimiminen 5.10.2004 Eeva Ahonen Sisältö Avainsanat Menetelmät C4.5 päätöspuut GenEx algoritmi Bayes malli Testit Tulokset Avainsanat Tiivistä tietoa dokumentin sisällöstä ihmislukijalle hakukoneelle

Lisätiedot

SEPA - Design Patterns

SEPA - Design Patterns SEPA - Design Patterns Kimmo Karlsson, 51066R & Antti Pirinen, 51406N 15. maaliskuuta 2005 1 Sisältö 1. Sisältö 2. Johdanto 3. Käyttöönotto 4. Käyttökokemukset 2 Johdanto Valitsemamme ohjelmistonkehityskäytäntö

Lisätiedot

T Henkilökohtainen harjoitus: FASTAXON

T Henkilökohtainen harjoitus: FASTAXON T-76.115 Henkilökohtainen harjoitus: FASTAXON Suunnittelumallit Group: Muuntaja Pentti Vänskä 52572W 2 1. Toteutus Tämä henkilökohtainen harjoitustyö käsitteli suunnittelumallien (Design Patterns) käyttöä

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

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

Lisätiedot

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

GA & robot path planning. Janne Haapsaari AUTO Geneettiset algoritmit

GA & robot path planning. Janne Haapsaari AUTO Geneettiset algoritmit GA & robot path planning Janne Haapsaari AUTO3070 - Geneettiset algoritmit GA robotiikassa Sovelluksia liikkeen optimoinnissa: * eri vapausasteisten robottien liikeratojen optimointi * autonomisten robottien

Lisätiedot

Olio-ohjelmointi Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton. 1. Proxy (Edustaja)

Olio-ohjelmointi Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton. 1. Proxy (Edustaja) Olio-ohjelmointi Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton Tässä osassa tutustutaan yhteen rakennemalliin (Proxy) ja kolmeen luontimalliin (Factory Method, ) teoksen [Gam] pohjalta.

Lisätiedot

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VII Suunnittelumallit Adapter ja Composite

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VII Suunnittelumallit Adapter ja Composite 2015 syksy 2. vsk VII Suunnittelumallit Adapter ja Composite Sisältö 1. Johdanto rakennemalleihin 2. Adapter (Sovitin) 3. Composite (Rekursiokooste) Suunnittelumallit Adapter ja Composite 2 VII.1 Johdanto

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

Sisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.

Sisä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ätiedot

Hirviö. Design Patterns

Hirviö. 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ätiedot

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

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

Lisätiedot

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VIII Suunnittelumallit Observer ja State

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VIII Suunnittelumallit Observer ja State 2015 syksy 2. vsk VIII Suunnittelumallit Observer ja State Sisältö 1. Johdanto käyttäytymismalleihin 2. Observer 3. State Suunnittelumallit Observer ja State 2 VIII.1 Johdanto käyttäytymismalleihin Päätarkoitus

Lisätiedot

Rajapinnasta ei voida muodostaa olioita. Voidaan käyttää tunnuksen tyyppinä. Rajapinta on kuitenkin abstraktia luokkaa selvästi abstraktimpi tyyppi.

Rajapinnasta ei voida muodostaa olioita. Voidaan käyttää tunnuksen tyyppinä. Rajapinta on kuitenkin abstraktia luokkaa selvästi abstraktimpi tyyppi. 11. Rajapinnat 11.1 Sisällys Johdanto. Abstrakti luokka vai rajapinta? Rajapintojen hyötyjä. Kuinka rajapinnat määritellään ja otetaan käyttöön? Eläin, nisäkäs, kissa ja rajapinta. Moniperiytyminen rajapintojen

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

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

Olioiden yhteistyön mallintaminen

Olioiden yhteistyön mallintaminen Olioiden yhteistyön mallintaminen Luokkakaaviosta käy hyvin esille ohjelman rakenne minkälaisia luokkia on olemassa miten luokat liittyvät toisiinsa Entä ohjelman toiminta? Luokkakaaviossa voi olla metodien

Lisätiedot

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

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

Lisätiedot

Toiminnot eli käyttäytyminen. Tieto eli rakenteelliset ominaisuudet

Toiminnot eli käyttäytyminen. Tieto eli rakenteelliset ominaisuudet Toiminnot eli käyttäytyminen Tieto eli rakenteelliset ominaisuudet Olio (ks. määritelmä): rajattavissa ja yksilöitävissä oleva asia tai käsite, joka on merkityksellinen käsillä olevan tarkastelun kannalta

Lisätiedot

Olio-ohjelmointi Johdanto suunnittelumalleihin. 1. Yleistä

Olio-ohjelmointi Johdanto suunnittelumalleihin. 1. Yleistä Olio-ohjelmointi Johdanto suunnittelumalleihin Hyvin toimivan olio-ohjelmointiparadigmaa noudattavan ohjelman suunnitteleminen ei ole helppo tehtävä. On löydettävä sopiva luokkarakenne kuvaamaan ratkaistavaa

Lisätiedot

Algoritmit 2. Luento 12 Ke Timo Männikkö

Algoritmit 2. Luento 12 Ke Timo Männikkö Algoritmit 2 Luento 12 Ke 26.4.2017 Timo Männikkö Luento 12 Rajoitehaku Kauppamatkustajan ongelma Lyhin virittävä puu Paikallinen etsintä Vaihtoalgoritmit Geneettiset algoritmit Simuloitu jäähdytys Algoritmit

Lisätiedot

S Laskennallinen systeemibiologia

S Laskennallinen systeemibiologia S-114.2510 Laskennallinen systeemibiologia 3. Harjoitus 1. Koska tilanne on Hardy-Weinbergin tasapainossa luonnonvalintaa lukuunottamatta, saadaan alleeleista muodostuvien eri tsygoottien genotyyppifrekvenssit

Lisätiedot

Käyttötapausanalyysi ja testaus tsoft

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

Lisätiedot

A215 Tietorakenteet. Tietojenkäsittelytieteiden laitos Tampereen yliopisto. Periodit I-II, syksy 2007

A215 Tietorakenteet. Tietojenkäsittelytieteiden laitos Tampereen yliopisto. Periodit I-II, syksy 2007 Kurssiesittely Tietojenkäsittelytieteiden laitos Tampereen yliopisto A215 Tietorakenteet Periodit I-II, syksy 2007 Luennot/vastuuhenkilö: Heikki Hyyrö Sähköposti: heikki.hyyro@cs.uta.fi Kurssin kotisivu:

Lisätiedot

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Arkkitehtuuri- ja suunnittelumalli

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Arkkitehtuuri- ja suunnittelumalli T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Arkkitehtuuri- ja suunnittelumalli Lasse Lindqvist Lasse Lopperi llindqvi@cc.hut.fi lmlopper@cc.hut.fi

Lisätiedot

Poikkeusinfo XML-rajapinnan kuvaus, rajapinnan versio 2 Seasam Group

Poikkeusinfo XML-rajapinnan kuvaus, rajapinnan versio 2 Seasam Group 1.10.2010 1(15) Poikkeusinfo XML-rajapinnan kuvaus, rajapinnan versio 2 Seasam Group Graanintie 7 Tel. + 358 15 338 800 FIN-50190 MIKKELI Fax + 358 15 338 810 VERSIOHISTORIA Versio Pvm Tekijä Selite 1.0

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

Mainosankkuri.fi-palvelun käyttöohjeita

Mainosankkuri.fi-palvelun käyttöohjeita Mainosankkuri.fi-palvelun käyttöohjeita Sisällys 1. Johdanto... 1 2. Sisäänkirjautuminen... 1 3. Palvelussa navigointi... 2 4. Laitteet... 2 5. Sisällönhallinta... 4 6. Soittolistat... 7 7. Aikataulut...

Lisätiedot

Hakemistojen sisällöt säilötään linkitetyille listalle.

Hakemistojen sisällöt säilötään linkitetyille listalle. Harjoitustyö 1 Harjoitustyö Tehtävä: ohjelmoi Java-kielellä komentoikkunaa (komentotulkkia, komentoriviä) simuloiva olioperustainen ohjelma. Hakemistojen sisällöt säilötään linkitetyille listalle. Työ

Lisätiedot

Toinen harjoitustyö. ASCII-grafiikkaa

Toinen harjoitustyö. ASCII-grafiikkaa Toinen harjoitustyö ASCII-grafiikkaa Yleistä Tehtävä: tee Javalla ASCII-merkkeinä esitettyä grafiikkaa käsittelevä ASCIIArt-ohjelma omia operaatioita ja taulukoita käyttäen. Työ tehdään pääosin itse. Ideoita

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

Sisällys. 11. Rajapinnat. Johdanto. Johdanto

Sisällys. 11. Rajapinnat. Johdanto. Johdanto Sisällys 11. ajapinnat. bstrakti luokka vai rajapinta? ajapintojen hyötyjä. Kuinka rajapinnat määritellään ja otetaan käyttöön? Eläin, nisäkäs, kissa ja rajapinta. Moniperiytyminen rajapintojen avulla.

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

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

11. Javan toistorakenteet 11.1

11. Javan toistorakenteet 11.1 11. Javan toistorakenteet 11.1 Sisällys Laskuri- ja lippumuuttujat. Sisäkkäiset silmukat. Tyypillisiä ohjelmointivirheitä: Silmukan rajat asetettu kierroksen verran väärin. Ikuinen silmukka. Silmukoinnin

Lisätiedot

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

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

Lisätiedot

Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä

Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä 1 Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä Kai Koskimies Tampereen teknillinen yliopisto Taustaa: Sulake projekti 2008-2009 2 Osallistujat Areva T&D John Deere Kone Sandvik

Lisätiedot

P e d a c o d e ohjelmointikoulutus verkossa

P e d a c o d e ohjelmointikoulutus verkossa P e d a c o d e ohjelmointikoulutus verkossa Java-kielen perusteet Teoria ja ohjelmointitehtävät Java-kielen perusteet 3 YLEISKATSAUS KURSSIN SISÄLTÖIHIN 10 JAVA-KIELEN PERUSTEET 10 OPISKELUN ALOITTAMINEN

Lisätiedot

Ohjelmistotekniikan menetelmät, koe 2.5.2014

Ohjelmistotekniikan menetelmät, koe 2.5.2014 Ohjelmistotekniikan menetelmät, koe 2.5.2014 Vastaa tehtävään 3 erilliselle konseptille. Tehtävät 1 ja 2 saavat olla samalla konseptilla. Kirjoita jokaiseen palauttamaasi konseptiin kurssin nimi, kokeen

Lisätiedot

TIE-20200 Ohjelmistojen suunnittelu

TIE-20200 Ohjelmistojen suunnittelu TIE-20200 Ohjelmistojen suunnittelu Luento 1: Virtuaalifunktiot, Template method 1 Yleistä asiaa Muistakaa harkkatyöilmoittautuminen 23 ryhmää (mm. lihansyöjäkirahvi), vajaita ryhmiäkin on 44 henkeä vielä

Lisätiedot

Palveluperustaiset arkkitehtuurityylit

Palveluperustaiset arkkitehtuurityylit Palveluperustaiset arkkitehtuurityylit Mukana palvelun tarjoajia ja palvelun käyttäjiä Perusajatuksena tyypillisesti tarjota johonkin resurssiin liittyviä palveluita 1 Asiakas-palvelin -arkkitehtuurit

Lisätiedot

OPI-Maksut - Käyttötapaukset

OPI-Maksut - Käyttötapaukset OPIMaksut Käyttötapaukset Toiminnallisuudet ja käyttötapaukset: maksupalvelutoiminnot Toimeksiannon lisääminen Palveluväylä toiminto: Toimeksiannon lisääminen Yleiskuvaus Palveluväylään sallitut asiointisovellukset

Lisätiedot

A ja B pelaavat sarjan pelejä. Sarjan voittaja on se, joka ensin voittaa n peliä.

A ja B pelaavat sarjan pelejä. Sarjan voittaja on se, joka ensin voittaa n peliä. Esimerkki otteluvoiton todennäköisyys A ja B pelaavat sarjan pelejä. Sarjan voittaja on se, joka ensin voittaa n peliä. Yksittäisessä pelissä A voittaa todennäköisyydellä p ja B todennäköisyydellä q =

Lisätiedot

815338A Ohjelmointikielten periaatteet Harjoitus 6 Vastaukset

815338A Ohjelmointikielten periaatteet Harjoitus 6 Vastaukset 815338A Ohjelmointikielten periaatteet 2015-2016. Harjoitus 6 Vastaukset Harjoituksen aiheena on funktionaalinen ohjelmointi Scheme- ja Haskell-kielillä. Voit suorittaa ohjelmat osoitteessa https://ideone.com/

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

10. Painotetut graafit

10. Painotetut graafit 10. Painotetut graafit Esiintyy monesti sovelluksia, joita on kätevä esittää graafeina. Tällaisia ovat esim. tietoverkko tai maantieverkko. Näihin liittyy erinäisiä tekijöitä. Tietoverkkoja käytettäessä

Lisätiedot

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa: Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,

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

UML:n yleiskatsaus. UML:n osat:

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

Lisätiedot

Ohjelmoinnin peruskurssien laaja oppimäärä, kevät

Ohjelmoinnin peruskurssien laaja oppimäärä, kevät Ohjelmoinnin peruskurssien laaja oppimäärä, kevät Luento 2: Ohjelman suunnittelua, miten oliot toimivat Riku Saikkonen (osa kalvoista on suoraan ei-laajan kurssin luennoista) 21. 1. 2013 Sisältö 1 Suunnittelua:

Lisätiedot

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Kä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ätiedot

Määrittelydokumentti

Määrittelydokumentti Määrittelydokumentti Aineopintojen harjoitustyö: Tietorakenteet ja algoritmit (alkukesä) Sami Korhonen 014021868 sami.korhonen@helsinki. Tietojenkäsittelytieteen laitos Helsingin yliopisto 23. kesäkuuta

Lisätiedot

Viestinvälitysarkkitehtuurit Lähtökohta:

Viestinvä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ätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

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

Lisätiedot

805324A (805679S) Aikasarja-analyysi Harjoitus 4 (2016)

805324A (805679S) Aikasarja-analyysi Harjoitus 4 (2016) 805324A (805679S) Aikasarja-analyysi Harjoitus 4 (2016) Tavoitteet (teoria): Hallita autokovarianssifunktion ominaisuuksien tarkastelu. Osata laskea autokovarianssifunktion spektriiheysfunktio. Tavoitteet

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

Bosch-malli. Kolme vaihetta. Termistöä. Ohjelm!toarkkitehtuu"n

Bosch-malli. Kolme vaihetta. Termistöä. Ohjelm!toarkkitehtuun Bosch-malli Ohjelm!toarkkitehtuu"n suunni#elu 2$6 Quality Attribute-oriented Software Architecture Design method Toiminnallisista vaatimuksista laadittu arkkitehtuurimalli kehitetään arvioimalla sitä laadullisten

Lisätiedot

Ohjelmistotekniikan menetelmät, suunnittelumalleja

Ohjelmistotekniikan menetelmät, suunnittelumalleja 582101 - Ohjelmistotekniikan menetelmät, suunnittelumalleja 1 Suunnittelumallit (design patterns) Kuvaus sellaisesta luokkarakenteesta & olioiden vuorovaikutuksesta, joka ratkaisee tietyn yleisen ongelman

Lisätiedot

Webforum. Version 15.3 uudet ominaisuudet. Päivitetty: 2015-09-21

Webforum. Version 15.3 uudet ominaisuudet. Päivitetty: 2015-09-21 Webforum Version 15.3 uudet ominaisuudet Päivitetty: 2015-09-21 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Alustan otsikointi... 5 Alustan otsikoinnin uusi ryhmittely käyttäjän kuvalla... 5 Aloita

Lisätiedot

811120P Diskreetit rakenteet

811120P Diskreetit rakenteet 811120P Diskreetit rakenteet 2016-2017 1. Algoritmeista 1.1 Algoritmin käsite Algoritmi keskeinen laskennassa Määrittelee prosessin, joka suorittaa annetun tehtävän Esimerkiksi Nimien järjestäminen aakkosjärjestykseen

Lisätiedot

Ohjelmistojen mallintaminen kertausta Harri Laine 1

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

Avoimen ja yhteisen rajapinnan hallintamalli

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

Lisätiedot

Visma Fivaldi -käsikirja Tehtävienhallinta- ohje käyttäjälle

Visma Fivaldi -käsikirja Tehtävienhallinta- ohje käyttäjälle Visma Fivaldi -käsikirja Tehtävienhallinta- ohje käyttäjälle 2 Sisällys 1 Palvelunhallinta... 3 1.1 Käyttäjäryhmän luominen... 3 2 Tehtävienhallinta- perustiedot... 4 2.1 Yhtiön perustiedot... 4 2.2 Tehtävä-/

Lisätiedot

f(n) = Ω(g(n)) jos ja vain jos g(n) = O(f(n))

f(n) = Ω(g(n)) jos ja vain jos g(n) = O(f(n)) Määritelmä: on O(g(n)), jos on olemassa vakioarvot n 0 > 0 ja c > 0 siten, että c g(n) kun n > n 0 O eli iso-o tai ordo ilmaisee asymptoottisen ylärajan resurssivaatimusten kasvun suuruusluokalle Samankaltaisia

Lisätiedot

Ohjelmistoarkkitehtuuri

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

Lisätiedot