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

OHJ-3100 Ohjelmien ylläpito ja evoluutio Harjoitustyö 2011 Sisällys 1. Johdanto... 2 1.1 Yleisesittely... 2 1.2 Geneettiset algoritmit... 2 1.3 Ohjelmistoarkkitehtuurit... 3 1.3.1 Perusasioita... 3 1.3.2 Arkkitehtuurityylit ja suunnittelumallit... 4 1.3.3 Arkkitehtuurin arviointi ja skenaariot... 7 1.4 Darwin-työkalu... 8 1.4.1 Yleiskuvaus... 8 1.4.2 GA-moottorin kuvaus... 10 1.4.3 Työkalun käyttö... 12 1.5 Lähteitä... 12 2. Tehtävänanto... 13 2.1 Yleiskuvaus... 13 2.2 Skenaarion määrittely... 13 2.3 Käyttöliittymä... 14 2.4 Skenaarioiden tulkinta... 14 2.5 Fitness-arvon laskeminen... 14 2.6 Output... 18 2.7 Arvioitu työjakauma... 19 2.8 Dokumentti... 20 3. Arvostelu ja palautus... 20

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.

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 1.3.1 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ä,

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. 1.3.2 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ä

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.

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

(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. 1.3.3 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

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

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.

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

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

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, 1995. M. Shaw, D. Garlan: Software Architecture, Perspectives on an Emerging Discipline, Prentice Hall, 1996. P. Clements, R. Kazman, M. Klein: Evaluating Software Architectures, Addison-Wesley, 2002. 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: http://www.uta.fi/sis/tkt/tutkielmat/lis.html Darwinin taustalla olevasta geneettisiin algoritmeihin pohjautuvasta arkkitehtuurisynteesistä on tehty useita julkaisuja, kts. http://practise.cs.tut.fi/project.php?project=darwin&page=publications Julkaisuja voi pyytää tarvittaessa harjoitustyön ohjaajalta.

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.

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.

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

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

Tapaus 5: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa ja käyttävät viestinvälittäjää kommunikointiin: tehokkuusrankaisu: -1-2-1 = -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

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 -1-1 -1-2 = -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.

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ä

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 2.2-2.6). 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 9-15.30 välisenä aikana. Harjoitustyö on palautettava viimeistään 9.12. 2011. 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