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

Koko: px
Aloita esitys sivulta:

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

Transkriptio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lisätiedot

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

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

Ohjelmistoarkkitehtuurit. Syksy 2008

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

Lisätiedot

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

ohjelman arkkitehtuurista.

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

Lisätiedot

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

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

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

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

Lisätiedot

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari

Lisätiedot

Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari Korhonen

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

Lisätiedot

Tietorakenteet ja algoritmit - syksy 2015 1

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

Lisätiedot

Rajapinta (interface)

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

Lisätiedot

9. Muunneltavuuden hallinta

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

Lisätiedot

Kertaus: yleistys-erikoistus ja perintä

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

Lisätiedot

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

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

Lisätiedot

Poikkeusinfo XML-rajapinnan kuvaus, rajapinnan versio 2 Seasam Group

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

Lisätiedot

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

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

Lisätiedot

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

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

Lisätiedot

Hirviö. Design Patterns

Hirviö. Design Patterns Hirviö SEPA-päiväkirja Design Patterns Anssi Kalliolahti Liia Sarjakoski 15. maaliskuuta 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

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

P e d a c o d e ohjelmointikoulutus verkossa

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

Lisätiedot

Viestinvälitysarkkitehtuurit

Viestinvälitysarkkitehtuurit Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti hajautettuja Komponenttien palveluja ei tiedetä tarkasti etukäteen Komponentteja ja

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

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

Lisätiedot

OPI-Maksut - Käyttötapaukset

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

Lisätiedot

Ohjelmistotekniikan menetelmät, koe 2.5.2014

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

Lisätiedot

Lomalista-sovelluksen määrittely

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

Lisätiedot

Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä

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

Lisätiedot

Palveluperustaiset arkkitehtuurityylit

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

Lisätiedot

10. Painotetut graafit

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

Lisätiedot

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

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

Lisätiedot

Viestinvälitysarkkitehtuurit Lähtökohta:

Viestinvälitysarkkitehtuurit Lähtökohta: Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti

Lisätiedot

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit

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

Lisätiedot

Ohjelmistoarkkitehtuuri

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

Lisätiedot

Uudelleenkäytön jako kahteen

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

Lisätiedot

UML- mallinnus: Tilakaavio

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

Lisätiedot

Visual Case 2. Miika Kasnio (C9767) 23.4.2008

Visual Case 2. Miika Kasnio (C9767) 23.4.2008 Visual Case 2 Miika Kasnio (C9767) 23.4.2008 Työn tarkasti: Jouni Huotari 24.4.2008 1 SISÄLTÖ 1. TYÖN LÄHTÖKOHDAT... 2 2. PERUSTIEDOT... 2 3. ASENTAMINEN... 2 4. OMINAISUUDET... 3 4.1. UML-kaaviot... 4

Lisätiedot

Webforum. Version 15.1 uudet ominaisuudet. Päivitetty: 2015-03-28

Webforum. Version 15.1 uudet ominaisuudet. Päivitetty: 2015-03-28 Webforum Version 15.1 uudet ominaisuudet Päivitetty: 2015-03-28 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Dokumentit... 5 Uudet versiot dokumenttien katseluohjelmista ipadille... 5 Dokumenttien

Lisätiedot

1. Tarkastellaan seuraavaa kaaviota

1. Tarkastellaan seuraavaa kaaviota HELSINGIN YLIOPISTO TIETOJENKÄSITTELYTIETEEN LAITOS JOHDATUS SOVELLUSSUUNNITTELUUN (JSS) 19.12.2001 (H.Laine) 1. Tarkastellaan seuraavaa kaaviota Mitkä seuraavista väitteistä ovat kaavion mukaisia t.s.

Lisätiedot

Avaa ohjelma ja tarvittaessa Tiedosto -> Uusi kilpailutiedosto

Avaa ohjelma ja tarvittaessa Tiedosto -> Uusi kilpailutiedosto Condess ratamestariohjelman käyttö Aloitus ja alkumäärittelyt Avaa ohjelma ja tarvittaessa Tiedosto -> Uusi kilpailutiedosto Kun kysytään kilpailun nimeä, syötä kuvaava nimi. Samaa nimeä käytetään oletuksena

Lisätiedot

Määrittelydokumentti

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

Lisätiedot

Ohjelmistojen mallintaminen. Luento 10, 3.12.

Ohjelmistojen mallintaminen. Luento 10, 3.12. Ohjelmistojen mallintaminen Luento 10, 3.12. Kertaus Menetelmä: miten edetään ohjelmistoprosessin eri vaiheissa ja mitä apuvälineitä kannattaa missäkin tilanteessa käyttää Käymme läpi erästä olioperustaista

Lisätiedot

ADMIN. Käyttöopas 08Q4

ADMIN. Käyttöopas 08Q4 ADMIN Käyttöopas 08Q4 Sisällysluettelo Uuden käyttäjän lisääminen...3 Käyttäjän poistaminen...3 Oikeudet...4 Käyttäjäasetukset...6 Aktiviteetin määritys...8 Aktiviteetin määrittely...8 Kenttämäärittelyt...9

Lisätiedot

Pauliina Munter / Suvi Junes Tampereen yliopisto/tietohallinto 2013

Pauliina Munter / Suvi Junes Tampereen yliopisto/tietohallinto 2013 Tehtävä 2.2. Tehtävä-työkalun avulla opiskelijat voivat palauttaa tehtäviä Moodleen opettajan arvioitaviksi. Palautettu tehtävä näkyy ainoastaan opettajalle, ei toisille opiskelijoille. Tehtävä-työkalun

Lisätiedot

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Opintojakso TT00AA11 Ohjelmoinnin jatko (Java) Tavoite Opiskelija ymmärtää olio-ohjelmoinnin problematiikan. Opiskelija osaa määritellä ja käyttää itse

Lisätiedot

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

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

Lisätiedot

Ohjelmiston toteutussuunnitelma

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

Lisätiedot

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

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

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

Tällä harjoituskerralla on tarkoituksena harjoitella käyttötapaus-, luokka- ja tapahtumasekvenssikaavioiden luontia.

Tällä harjoituskerralla on tarkoituksena harjoitella käyttötapaus-, luokka- ja tapahtumasekvenssikaavioiden luontia. MagicDraw-pikaohje Tällä harjoituskerralla on tarkoituksena harjoitella käyttötapaus-, luokka- ja tapahtumasekvenssikaavioiden luontia. Alkuvalmistelut Windows (sali TC205) 1) Kirjaudu sisään TTY:n intra-tunnuksella.

Lisätiedot

Ohjelmoinnin jatkokurssi, kurssikoe 28.4.2014

Ohjelmoinnin jatkokurssi, kurssikoe 28.4.2014 Ohjelmoinnin jatkokurssi, kurssikoe 28.4.2014 Kirjoita jokaiseen palauttamaasi konseptiin kurssin nimi, kokeen päivämäärä, oma nimi ja opiskelijanumero. Vastaa kaikkiin tehtäviin omille konsepteilleen.

Lisätiedot

Muutamia peruskäsitteitä

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

Lisätiedot

1 (5) PALVELUKUVAUS JA HINNASTO Requeste palvelut

1 (5) PALVELUKUVAUS JA HINNASTO Requeste palvelut 1 (5) PALVELUKUVAUS JA HINNASTO Requeste palvelut 2 (5) 1. PALVELUKUVAUKSEN TARKOITUS Tässä palvelukuvauksessa kuvataan Sysart Oy:n Requeste tuotteeseen liittyvät maksulliset palvelut. Maksullisia palveluita

Lisätiedot

Metodit. Metodien määrittely. Metodin parametrit ja paluuarvo. Metodien suorittaminen eli kutsuminen. Metodien kuormittaminen

Metodit. Metodien määrittely. Metodin parametrit ja paluuarvo. Metodien suorittaminen eli kutsuminen. Metodien kuormittaminen Metodit Metodien määrittely Metodin parametrit ja paluuarvo Metodien suorittaminen eli kutsuminen Metodien kuormittaminen 1 Mikä on metodi? Metodi on luokan sisällä oleva yhteenkuuluvien toimintojen kokonaisuus

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

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

Lisätiedot

Tietokannan luominen:

Tietokannan luominen: Moodle 2 Tietokanta: Tietokanta on työkalu, jolla opettaja ja opiskelijat voivat julkaista tiedostoja, tekstejä, kuvia, linkkejä alueella. Opettaja määrittelee lomakkeen muotoon kentät, joiden kautta opiskelijat,

Lisätiedot

Webforum. Version 14.4 uudet ominaisuudet. Viimeisin päivitys: 2014-12-6

Webforum. Version 14.4 uudet ominaisuudet. Viimeisin päivitys: 2014-12-6 Webforum Version 14.4 uudet ominaisuudet Viimeisin päivitys: 2014-12-6 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Yleistä & hallinnointi... 5 Dokumentit... 5 Perättäinen tarkistus- ja hyväksymisprosessi...

Lisätiedot

Tik-76.612 Harjoitustyö

Tik-76.612 Harjoitustyö Tik-76.612 Harjoitustyö Harjoitustyö Tehdään 2-3 hengen ryhmissä Koostuu etapeista joiden aikana simuloidaan ohjelmistoprojektin läpivientiä On nivottu osaksi kurssin luentoja On pakollinen 2 Harjoitustyön

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

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

Lisätiedot

Ohjelmisto on selainpohjaisen käyttöliittymän tarjoava tietokantajärjestelmä merikotkien seurantaan WWF:n Merikotka-työryhmän tarpeisiin.

Ohjelmisto on selainpohjaisen käyttöliittymän tarjoava tietokantajärjestelmä merikotkien seurantaan WWF:n Merikotka-työryhmän tarpeisiin. TIETOKANTA MERIKOTKIEN SEURANTAAN Käyttöohje Versiohistoria: Versio Päivämäärä Kuvaus Tekijä 1.0 11.12.2007 Ensimmäinen luonnos Janne Piippo 2.0 13.12.2007 Virallinen verio Janne Piippo HELSINGIN YLIOPISTO

Lisätiedot

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa 1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä

Lisätiedot

Eclipse ja JUnit-ohjelmoijatestit

Eclipse ja JUnit-ohjelmoijatestit Eclipse ja JUnit-ohjelmoijatestit Tarkoitus on tutustua Eclipsen käyttöön vähän lähemmin ja varsinkin JUnit-ohjelmoijatesteihin (ohjelmoijatesti on vanhalta nimeltä yksikkötesti). Ohjelmoijatestit ovat

Lisätiedot

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

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

Lisätiedot

TIE-20200 Ohjelmistojen suunnittelu

TIE-20200 Ohjelmistojen suunnittelu TIE-20200 Ohjelmistojen suunnittelu Luento 1: Virtuaalifunktiot, Template method 1 Seuraavaksi tarjolla: Otekn-asiaa vähän pintaa syvemmältä Virtuaalifunktiot ja erikoistaminen, olioiden kopiointi ja elinaika

Lisätiedot

UML Luokkakaavio 14:41

UML Luokkakaavio 14:41 UML Luokkakaavio UML Olio-ohjelman luokkien pääpiirteet voidaan kätevähkösti esittää ns. UML-luokkakaaviona. Näin usein tehdäänkin esim. suunniteltaessa, millaisia luokkia ohjelmaan on tarkoitus laatia,

Lisätiedot

Ohjelmistotuotanto. Luento 9 23.4.2012

Ohjelmistotuotanto. Luento 9 23.4.2012 Ohjelmistotuotanto Luento 9 23.4.2012 Lisää suunnittelumalleja Olion rikastaminen dekoraattorilla Joskus eteen tulee tarve lisätä olioon jotain ekstraominaisuuksia, pitäen kuitenkin olio sellaisena että

Lisätiedot

KORJAUSVELAN LASKENTAMALLI KÄYTTÖÖN

KORJAUSVELAN LASKENTAMALLI KÄYTTÖÖN KORJAUSVELAN LASKENTAMALLI KÄYTTÖÖN KEHTO-foorumi Seinäjoki 23.10.2014 TAUSTAA Korjausvelan määrityshanke vuonna 2012-2013 Katujen ja viheralueiden korjausvelan periaatteita ei ollut aiemmin määritelty

Lisätiedot

Tietojärjestelmän osat

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

Lisätiedot

SUOMEN KUNTALIITTO RY

SUOMEN KUNTALIITTO RY Karttaliittymä Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen tausta... 2 1.2 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Lyhenteet...

Lisätiedot

Ohjelmistojen mallintaminen Olioiden yhteistyö. 18.11.2008 Harri Laine 1

Ohjelmistojen mallintaminen Olioiden yhteistyö. 18.11.2008 Harri Laine 1 Ohjelmistojen mallintaminen Olioiden yhteistyö 18.11.2008 Harri Laine 1 Olioiden yhteistyö Oliokeskeisen ohjelmistonäkemyksen mukaan ohjelmiston palvelut tuotetaan olioiden yhteistyön tuloksena. Ohjelmisto

Lisätiedot

Implementation of Selected Metaheuristics to the Travelling Salesman Problem (valmiin työn esittely)

Implementation of Selected Metaheuristics to the Travelling Salesman Problem (valmiin työn esittely) Implementation of Selected Metaheuristics to the Travelling Salesman Problem (valmiin työn esittely) Jari Hast xx.12.2013 Ohjaaja: Harri Ehtamo Valvoja: Hari Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston

Lisätiedot

Olio-ohjelmointi: Luokkien toteuttaminen. Jukka Juslin

Olio-ohjelmointi: Luokkien toteuttaminen. Jukka Juslin Olio-ohjelmointi: Luokkien toteuttaminen Jukka Juslin Luokkien kirjoittaminen Tähän mennessä on käytetty valmiiksi määritettyjä luokkia. Nyt opimme kirjoittamaan omia luokkia olioiden kuvaamiseksi Seuraavaksi

Lisätiedot

1. ASIAKKAAN OHJEET... 2. 1.1 Varauksen tekeminen... 2. 1.2 Käyttäjätunnuksen luominen... 4. 1.3 Varauksen peruminen... 4

1. ASIAKKAAN OHJEET... 2. 1.1 Varauksen tekeminen... 2. 1.2 Käyttäjätunnuksen luominen... 4. 1.3 Varauksen peruminen... 4 1. ASIAKKAAN OHJEET... 2 1.1 Varauksen tekeminen... 2 1.2 Käyttäjätunnuksen luominen... 4 1.3 Varauksen peruminen... 4 1.4 Omien tietojen muokkaaminen... 5 1.5 Salasanan muuttaminen... 5 2. TYÖNTEKIJÄN

Lisätiedot

Suomen virtuaaliammattikorkeakoulu Tietojohtaminen rakennus prosesseissa > 80 % 80 60 % 60 50 % < 50 % Suhteellinen osuus maksimiarvosta (%)

Suomen virtuaaliammattikorkeakoulu Tietojohtaminen rakennus prosesseissa > 80 % 80 60 % 60 50 % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Suomen virtuaaliammattikorkeakoulu Tietojohtaminen rakennus prosesseissa > 80 % 80 60 % 60 50 % < 50 % Arviointialue

Lisätiedot

Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä

Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä Agenda Tehtävänanto Johdanto Näkökulma Ohjelmistotuotantoprosessit Testaus & arviointimenetelmät Menetelmien yhdistäminen, onnistuuko?

Lisätiedot

Aalto Yliopisto T-106.2001 Informaatioverkostot: Studio 1. Oliot ja luokat Javaohjelmoinnissa

Aalto Yliopisto T-106.2001 Informaatioverkostot: Studio 1. Oliot ja luokat Javaohjelmoinnissa Aalto Yliopisto T-106.2001 Informaatioverkostot: Studio 1 Oliot ja luokat Javaohjelmoinnissa Vesa Laakso 22.9.2012 Sisällysluettelo Sisällysluettelo... 1 Johdanto... 2 1. Luokka... 2 2. Olio... 2 3. Luokan

Lisätiedot

Lahden, Pohjois Karjalan ja Kemi Tornion AMK Effective Reading > 80 % 80 60 % 60 50 % < 50 % Suhteellinen osuus maksimiarvosta (%)

Lahden, Pohjois Karjalan ja Kemi Tornion AMK Effective Reading > 80 % 80 60 % 60 50 % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Lahden, Pohjois Karjalan ja Kemi Tornion AMK Effective Reading > 80 % 80 60 % 60 50 % < 50 % Arviointialue Ominaisuuksien

Lisätiedot

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)

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

Lisätiedot

Tekstinkäsittely ja opinnäytetyö I sisällysluettelo ja sivunumerointi. Word 2007

Tekstinkäsittely ja opinnäytetyö I sisällysluettelo ja sivunumerointi. Word 2007 Tekstinkäsittely ja opinnäytetyö I sisällysluettelo ja sivunumerointi Word 2007 Perttu Suhonen 2008 Sisällysluettelo 1 Sisällysluettelon tekeminen...5 1.1 Monitasoinen numerointi...5 1.2 Otsikkotyylien

Lisätiedot

Oulun ja Pohjois Karjalan ammattikorkeakoulu Virtuaalivasikan kasvatuspeli v. 0.5 > 80 % 80 60 % 60 50 % < 50 % Suhteellinen osuus maksimiarvosta (%)

Oulun ja Pohjois Karjalan ammattikorkeakoulu Virtuaalivasikan kasvatuspeli v. 0.5 > 80 % 80 60 % 60 50 % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Oulun ja Pohjois Karjalan ammattikorkeakoulu Virtuaalivasikan kasvatuspeli v. 0.5 > 80 % 80 60 % 60 50 % < 50

Lisätiedot

Tietokantojen suunnittelu, relaatiokantojen perusteita

Tietokantojen suunnittelu, relaatiokantojen perusteita Tietokantojen suunnittelu, relaatiokantojen perusteita A277, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin

Lisätiedot

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

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

Lisätiedot

811312A Tietorakenteet ja algoritmit 2015-2016. I Johdanto

811312A Tietorakenteet ja algoritmit 2015-2016. I Johdanto 811312A Tietorakenteet ja algoritmit 2015-2016 I Johdanto Sisältö 1. Algoritmeista ja tietorakenteista 2. Algoritmien analyysistä 811312A TRA, Johdanto 2 I.1. Algoritmeista ja tietorakenteista I.1.1. Algoritmien

Lisätiedot

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

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

Lisätiedot

Ohjelmistojen mallintaminen. Luento 2, pe 5.11.

Ohjelmistojen mallintaminen. Luento 2, pe 5.11. Ohjelmistojen mallintaminen Luento 2, pe 5.11. Kertausta Ohjelmistotuotantoprosessin vaiheet: Vaatimusanalyysi- ja määrittely Mitä halutaan? Suunnittelu Miten tehdään? Toteutus Ohjelmointi Testaus Varmistetaan

Lisätiedot

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

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

Lisätiedot

1 Tehtävän kuvaus ja analysointi

1 Tehtävän kuvaus ja analysointi Olio-ohjelmoinnin harjoitustyön dokumentti Jyri Lehtonen (72039) Taneli Tuovinen (67160) 1 Tehtävän kuvaus ja analysointi 1.1 Tehtävänanto Tee luokka, jolla mallinnetaan sarjaan kytkettyjä kondensaattoreita.

Lisätiedot

Moodle-oppimisympäristö

Moodle-oppimisympäristö k5kcaptivate Moodle-oppimisympäristö Opiskelijan opas Sisältö 1. Mikä on Moodle? 2. Mistä löydän Moodlen? 3. Kuinka muokkaan käyttäjätietojani? 4. Kuinka ilmoittaudun kurssille? 5. Kuinka käytän Moodlen

Lisätiedot

DOORSin Spreadsheet export/import

DOORSin Spreadsheet export/import DOORSin Spreadsheet export/import 17.10.2006 SoftQA Oy http/www.softqa.fi/ Pekka Mäkinen Pekka.Makinen@softqa.fi Tietojen siirto DOORSista ja DOORSiin Yhteistyökumppaneilla ei välttämättä ole käytössä

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

Päivitetty 17.1.2014. JETI pikaohje. Ennakkosuunnitelman luonti

Päivitetty 17.1.2014. JETI pikaohje. Ennakkosuunnitelman luonti Päivitetty 17.1.2014 JETI pikaohje Ennakkosuunnitelman luonti 1/5 Uuden ennakkosuunnitelman luonti Voit luoda uuden ennakkosuunnitelman kahdella tavalla: 1. Joko luomalla uuden ennakkosuunnitelman tyhjältä

Lisätiedot

Sisällys Clerica Web-sovellusten käytön aloittaminen 2

Sisällys Clerica Web-sovellusten käytön aloittaminen 2 Sisällys Clerica Web-sovellusten käytön aloittaminen 2 Kirjautuminen järjestelmään 2 Myyntilaskut 2 Ostolaskujen käsittely 4 Uuden laskun syöttö 6 Palkkailmoituslomake 8 Palkkailmoituksesta kopio 9 Henkilötietojen

Lisätiedot

Tietokoneohjelmien käyttö laadullisen aineiston analyysin apuna

Tietokoneohjelmien käyttö laadullisen aineiston analyysin apuna Tietokoneohjelmien käyttö laadullisen aineiston analyysin apuna Laadullinen, verbaalinen, tulkinnallinen aineisto kootaan esimerkiksi haastattelemalla, videoimalla, ääneenpuhumalla nauhalle, yms. keinoin.

Lisätiedot

OHJ-7400 Graafisen käyttöliittymän ohjelmointi 4/6 op

OHJ-7400 Graafisen käyttöliittymän ohjelmointi 4/6 op OHJ-7400 Graafisen käyttöliittymän ohjelmointi 4/6 op Syksy 2007, periodit 1-2 Harjoitustyö Yleistä Harjoitustyö tehdään 2 hengen ryhmissä. Yhden hengen ryhmistä tulee sopia kurssiassistentin kanssa erikseen

Lisätiedot

Toiminnallisen määrittelyn tarina. Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä.

Toiminnallisen määrittelyn tarina. Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä. Toiminnallisen määrittelyn tarina Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä. Toimitusjohtajan pulma Tässä on toimitusjohtaja Roope, jonka tavoitteena on pyörittää Rengasmaster Oy:tä

Lisätiedot

1.1. MITEN ITSEARVIOINTIVÄLINETTÄ KÄYTETÄÄN. Väline kattaa kolmen osan kolme tärkeintä prosessia: hakijoiden valinta (laskentataulukon työkirja 1)

1.1. MITEN ITSEARVIOINTIVÄLINETTÄ KÄYTETÄÄN. Väline kattaa kolmen osan kolme tärkeintä prosessia: hakijoiden valinta (laskentataulukon työkirja 1) Liite 1 1.1. MITEN ITSEARVIOINTIVÄLINETTÄ KÄYTETÄÄN Väline kattaa kolmen osan kolme tärkeintä prosessia: hakijoiden valinta (laskentataulukon työkirja 1) hankkeiden toteuttaminen tuensaajien toimesta,

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Vaatimusmäärittely Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Versio Päiväys Tekijä Kuvaus 0.1 12.10.01 Pekka Koskinen Ensimmäinen luonnos 0.2 17.10.01 Pekka Koskinen Lisätty vaatimuksia

Lisätiedot