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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

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

Lisätiedot

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

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

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

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

How to Support Decision Analysis with Software Case Förbifart Stockholm

How to Support Decision Analysis with Software Case Förbifart Stockholm How to Support Decision Analysis with Software Case Förbifart Stockholm (Valmiin työn esittely) 13.9.2010 Ohjaaja: Prof. Mats Danielson Valvoja: Prof. Ahti Salo Tausta -Tukholman ohikulkutien suunnittelu

Lisätiedot

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op FT Ari Viinikainen Tietokoneen rakenne Keskusyksikkö, CPU Keskusmuisti Aritmeettislooginen yksikkö I/O-laitteet Kontrolliyksikkö Tyypillinen Von Neumann

Lisätiedot

12. Javan toistorakenteet 12.1

12. Javan toistorakenteet 12.1 12. Javan toistorakenteet 12.1 Sisällys Yleistä toistorakenteista. Laskurimuuttujat. While-, do-while- ja for-lauseet. Laskuri- ja lippumuuttujat. Tyypillisiä ohjelmointivirheitä. Silmukan rajat asetettu

Lisätiedot

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

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

Lisätiedot

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

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

Lisätiedot

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

etunimi, sukunimi ja opiskelijanumero ja näillä

etunimi, sukunimi ja opiskelijanumero ja näillä Sisällys 1. Algoritmi Algoritmin määritelmä. Aiheen pariin johdatteleva esimerkki. ja operaatiot (sijoitus, aritmetiikka ja vertailu). Algoritmista ohjelmaksi. 1.1 1.2 Algoritmin määritelmä Ohjelmointi

Lisätiedot

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

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

Lisätiedot

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

Ohjelmoinnin peruskurssi Y1

Ohjelmoinnin peruskurssi Y1 Ohjelmoinnin peruskurssi Y1 CSE-A1111 30.9.2015 CSE-A1111 Ohjelmoinnin peruskurssi Y1 30.9.2015 1 / 27 Mahdollisuus antaa luentopalautetta Goblinissa vasemmassa reunassa olevassa valikossa on valinta Luentopalaute.

Lisätiedot

ATK tähtitieteessä. Osa 3 - IDL proseduurit ja rakenteet. 18. syyskuuta 2014

ATK tähtitieteessä. Osa 3 - IDL proseduurit ja rakenteet. 18. syyskuuta 2014 18. syyskuuta 2014 IDL - proseduurit Viimeksi käsiteltiin IDL:n interaktiivista käyttöä, mutta tämä on hyvin kömpelöä monimutkaisempia asioita tehtäessä. IDL:llä on mahdollista tehdä ns. proseduuri-tiedostoja,

Lisätiedot

Luku 8. Aluekyselyt. 8.1 Summataulukko

Luku 8. Aluekyselyt. 8.1 Summataulukko Luku 8 Aluekyselyt Aluekysely on tiettyä taulukon väliä koskeva kysely. Tyypillisiä aluekyselyitä ovat, mikä on taulukon välin lukujen summa tai pienin luku välillä. Esimerkiksi seuraavassa taulukossa

Lisätiedot

Testiautomaatio tietovarastossa. Automaattisen regressiotestauksen periaate ja hyödyt

Testiautomaatio tietovarastossa. Automaattisen regressiotestauksen periaate ja hyödyt Testiautomaatio tietovarastossa Automaattisen regressiotestauksen periaate ja hyödyt Sisältö 2 Testaus kiinteänä osana DW-toteutusta Regressiotestauksen merkitys Robot Framework Automatisoitu DW:n regressiotestaus:

Lisätiedot

Arcada yrkeshögskola Hållbar utveckling v 0.5 > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

Arcada yrkeshögskola Hållbar utveckling v 0.5 > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Arcada yrkeshögskola Hållbar utveckling v 0.5 > 80 % 80 60 % 60 50 % < 50 % Arviointialue Ominaisuuksien Arviointialue

Lisätiedot

Tentti erilaiset kysymystyypit

Tentti erilaiset kysymystyypit Tentti erilaiset kysymystyypit Kysymystyyppien kanssa kannatta huomioida, että ne ovat yhteydessä tentin asetuksiin ja erityisesti Kysymysten toimintatapa-kohtaan, jossa määritellään arvioidaanko kysymykset

Lisätiedot

Suomen virtuaaliammattikorkeakoulu The XML Dokuments > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

Suomen virtuaaliammattikorkeakoulu The XML Dokuments > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Suomen virtuaaliammattikorkeakoulu The XML Dokuments > 80 % 80 60 % 60 50 % < 50 % Arviointialue Ominaisuuksien

Lisätiedot

Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka templateaihio > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka templateaihio > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka templateaihio > 80 % 80 60 % 60 50 % < 50 % Arviointialue

Lisätiedot

815338A Ohjelmointikielten periaatteet 2014-2015. Harjoitus 7 Vastaukset

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

Lisätiedot

Action Request System

Action Request System Action Request System Manu Karjalainen Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 25.10.2000 Action Request System (ARS) Manu Karjalainen Ohjelmistotuotantovälineet

Lisätiedot

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

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

Lisätiedot

T Testiraportti - järjestelmätestaus

T Testiraportti - järjestelmätestaus T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria

Lisätiedot

Tentti erilaiset kysymystyypit

Tentti erilaiset kysymystyypit Tentti erilaiset kysymystyypit Monivalinta Monivalintatehtävässä opiskelija valitsee vastauksen valmiiden vastausvaihtoehtojen joukosta. Tehtävään voi olla yksi tai useampi oikea vastaus. Varmista, että

Lisätiedot

Harjoitustyön testaus. Juha Taina

Harjoitustyön testaus. Juha Taina Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida

Lisätiedot

Suvi Junes/Pauliina Munter Tietohallinto/Opetusteknologiapalvelut 2014

Suvi Junes/Pauliina Munter Tietohallinto/Opetusteknologiapalvelut 2014 Tietokanta Tietokanta on työkalu, jolla opettaja ja opiskelijat voivat julkaista tiedostoja, tekstejä, kuvia ja linkkejä alueella. Opettaja määrittelee lomakkeen muotoon kentät, joiden kautta opiskelijat

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

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

Lisätiedot

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

805324A (805679S) Aikasarja-analyysi Harjoitus 3 (2016) 805324A (805679S) Aikasarja-analyysi Harjoitus 3 (2016) Tavoitteet (teoria): Hallita multinormaalijakauman määritelmä. Ymmärtää likelihood-funktion ja todennäköisyystiheysfunktion ero. Oppia kirjoittamaan

Lisätiedot

käyttötapaukset mod. testaus

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

Lisätiedot

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

58160 Ohjelmoinnin harjoitustyö

58160 Ohjelmoinnin harjoitustyö 58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista

Lisätiedot

Alkuarvot ja tyyppimuunnokset (1/5) Alkuarvot ja tyyppimuunnokset (2/5) Alkuarvot ja tyyppimuunnokset (3/5)

Alkuarvot ja tyyppimuunnokset (1/5) Alkuarvot ja tyyppimuunnokset (2/5) Alkuarvot ja tyyppimuunnokset (3/5) Alkuarvot ja tyyppimuunnokset (1/5) Aiemmin olemme jo antaneet muuttujille alkuarvoja, esimerkiksi: int luku = 123; Alkuarvon on oltava muuttujan tietotyypin mukainen, esimerkiksi int-muuttujilla kokonaisluku,

Lisätiedot

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( )

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( ) PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma (1.5.2002-31.8.2004) Ydin-osaprojekti: potilastietojen toiminnallisen hallinnan näkökulma Yhteisten ydinkomponenttien määrittely" Ydin-osaprojektin rooli

Lisätiedot

58131 Tietorakenteet ja algoritmit (syksy 2015)

58131 Tietorakenteet ja algoritmit (syksy 2015) 58131 Tietorakenteet ja algoritmit (syksy 2015) Harjoitus 2 (14. 18.9.2015) Huom. Sinun on tehtävä vähintään kaksi tehtävää, jotta voit jatkaa kurssilla. 1. Erään algoritmin suoritus vie 1 ms, kun syötteen

Lisätiedot

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

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

Lisätiedot

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

Ohjelmistoarkkitehtuurit harjoitustyö RobotWarGame RobotFW SimulationFW SimulationGUIFW SWT/Java Kuva 1: Esimerkki arkkitehtuurin kerroskuvasta

Ohjelmistoarkkitehtuurit harjoitustyö RobotWarGame RobotFW SimulationFW SimulationGUIFW SWT/Java Kuva 1: Esimerkki arkkitehtuurin kerroskuvasta Ohjelmistoarkkitehtuurit harjoitustyö 2006 1 Johdanto Harjoitustyönä on toteuttaa kerroksittainen sovelluskehys erilaisten simulaatioon perustuvien pelien tekemiseen. Kehyksestä lisäksi erikoistetaan keskenään

Lisätiedot

Tietorakenteet ja algoritmit

Tietorakenteet ja algoritmit Tietorakenteet ja algoritmit Rekursio Rekursion käyttötapauksia Rekursio määritelmissä Rekursio ongelmanratkaisussa ja ohjelmointitekniikkana Esimerkkejä taulukolla Esimerkkejä linkatulla listalla Hanoin

Lisätiedot

Sisällys. 12. Javan toistorakenteet. Yleistä. Laskurimuuttujat

Sisällys. 12. Javan toistorakenteet. Yleistä. Laskurimuuttujat Sisällys 12. Javan toistorakenteet Ylstä toistorakentsta. Laskurimuuttujat. While-, do-while- ja for-lauseet. Laskuri- ja lippumuuttujat. Tyypillisiä ohjelmointivirhtä. Silmukan rajat asetettu kierroksen

Lisätiedot

Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen

Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Vaatimusluettelo versio 0.17 Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Yleiset vaatimukset 1 Koodistopalvelujärjestelmä on selainkäyttöinen 2 Käyttöliittymän tulee

Lisätiedot

Testaussuunnitelma Labra

Testaussuunnitelma Labra Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,

Lisätiedot

Johdatus rakenteisiin dokumentteihin

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

Lisätiedot

pitkittäisaineistoissa

pitkittäisaineistoissa Puuttuvan tiedon käsittelystä p. 1/18 Puuttuvan tiedon käsittelystä pitkittäisaineistoissa Tapio Nummi tan@uta.fi Matematiikan, tilastotieteen ja filosofian laitos Tampereen yliopisto Puuttuvan tiedon

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

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

Lisätiedot

Kurssin hallinta -työväline

Kurssin hallinta -työväline Kurssin hallinta -työväline Kurssin hallinta -työvälineellä muokataan kursseja A&Ooppimisympäristöalustalla Kurssi koostuu - ohjelmasta (linkit työkaluihin& muihin resursseihin), - materiaaleista, - keskusteluryhmästä,

Lisätiedot

Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka: Voima ja sen komponentit > 80 % % % < 50 %

Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka: Voima ja sen komponentit > 80 % % % < 50 % Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka: Voima ja sen komponentit > 80 % 80 60 % 60 50 %

Lisätiedot

HAMK Pähkinäkori > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

HAMK Pähkinäkori > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain HAMK Pähkinäkori > 80 % 80 60 % 60 50 % < 50 % Arviointialue Ominaisuuksien Arviointialue Ominaisuuksien Valmis/

Lisätiedot

812341A Olio-ohjelmointi, IX Olioiden välisistä yhteyksistä

812341A Olio-ohjelmointi, IX Olioiden välisistä yhteyksistä 2016 IX Olioiden välisistä yhteyksistä Sisältö 1. Johdanto 2. Kytkentä 3. Koheesio 4. Näkyvyydestä 2 Johdanto n Ohjelmassa syntyy kytkentöjä olioiden välille Toivottuja ja epätoivottuja n Näkyvyys vaikuttaa

Lisätiedot

SEPA päiväkirja. Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen

SEPA päiväkirja. Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen SEPA päiväkirja Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen 1. Johdanto...3 2. Menetelmän käyttö...4 3. Kokemukset ja muutokset...5 1. Johdanto SEPAn aiheenamme meillä on suunnittelumallit

Lisätiedot

1. Algoritmi 1.1 Sisällys Algoritmin määritelmä. Aiheen pariin johdatteleva esimerkki. Muuttujat ja operaatiot (sijoitus, aritmetiikka ja vertailu). Algoritmista ohjelmaksi. 1.2 Algoritmin määritelmä Ohjelmointi

Lisätiedot

VirtuaaliAMK Opinnäytetyön ohjausprosessi > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

VirtuaaliAMK Opinnäytetyön ohjausprosessi > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain VirtuaaliAMK Opinnäytetyön ohjausprosessi > 80 % 80 60 % 60 50 % < 50 % Arviointialue Ominaisuuksien Arviointialue

Lisätiedot

Luku 6. Dynaaminen ohjelmointi. 6.1 Funktion muisti

Luku 6. Dynaaminen ohjelmointi. 6.1 Funktion muisti Luku 6 Dynaaminen ohjelmointi Dynaamisessa ohjelmoinnissa on ideana jakaa ongelman ratkaisu pienempiin osaongelmiin, jotka voidaan ratkaista toisistaan riippumattomasti. Jokaisen osaongelman ratkaisu tallennetaan

Lisätiedot

Specifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki

Specifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Specifying user requirements for corporate intranet with user centered design methods Espoo 29.9.2016 Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Sisältö Työn tausta Ongelman asettelu Metodiikka Kehitysprojekti

Lisätiedot

Sisällys. 11. Javan toistorakenteet. Laskurimuuttujat. Yleistä

Sisällys. 11. Javan toistorakenteet. Laskurimuuttujat. Yleistä Sisällys 11. Javan toistorakenteet Laskuri- ja lippumuuttujat.. Tyypillisiä ohjelmointivirheitä: Silmukan rajat asetettu kierroksen verran väärin. Ikuinen silmukka. Silmukoinnin lopettaminen break-lauseella.

Lisätiedot

Lausekielinen ohjelmointi II Ensimmäinen harjoitustyö

Lausekielinen ohjelmointi II Ensimmäinen harjoitustyö Lausekielinen ohjelmointi II Ensimmäinen harjoitustyö Yleistä Tehtävä: Tee Javalla LineBreaker-ohjelma tekstirivin sovittamiseen tekstialueelle riviä katkomalla. Lausekielinen ohjelmointi II -kurssin pakollinen

Lisätiedot

Suomen virtuaaliammattikorkeakoulu Teknillinen mekanikka fem tutorials > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

Suomen virtuaaliammattikorkeakoulu Teknillinen mekanikka fem tutorials > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Suomen virtuaaliammattikorkeakoulu Teknillinen mekanikka fem tutorials > 80 % 80 60 % 60 50 % < 50 % Arviointialue

Lisätiedot

Suomen virtuaaliammattikorkeakoulu VPN peli > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

Suomen virtuaaliammattikorkeakoulu VPN peli > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Suomen virtuaaliammattikorkeakoulu VPN peli > 80 % 80 60 % 60 50 % < 50 % Arviointialue Ominaisuuksien Arviointialue

Lisätiedot

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. Assembly ja konekieli

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. Assembly ja konekieli TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op Assembly ja konekieli Tietokoneen ja ohjelmiston rakenne Loogisilla piireillä ja komponenteilla rakennetaan prosessori ja muistit Prosessorin rakenne

Lisätiedot

Lukujonon raja-arvo 1/7 Sisältö ESITIEDOT: lukujonot

Lukujonon raja-arvo 1/7 Sisältö ESITIEDOT: lukujonot Lukujonon raja-arvo 1/7 Sisältö Esimerkki lukujonon raja-arvosta Lukujonossa a 1,a 2,a 3,... (jossa on äärettömän monta termiä) voivat luvut lähestyä jotakin arvoa, kun jonossa edetään yhä pidemmälle.

Lisätiedot

Sisällys. 6. Metodit. Oliot viestivät metodeja kutsuen. Oliot viestivät metodeja kutsuen

Sisällys. 6. Metodit. Oliot viestivät metodeja kutsuen. Oliot viestivät metodeja kutsuen Sisällys 6. Metodit Oliot viestivät metodeja kutsuen. Kuormittaminen. Luokkametodit (ja -attribuutit).. Metodien ja muun luokan sisällön järjestäminen. 6.1 6.2 Oliot viestivät metodeja kutsuen Oliot viestivät

Lisätiedot