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 Johdanto Skenaarioiden määrittely Käyttöliittymä Skenaarioiden tulkinta Fitness-arvon Output Arvioitu työjakauma Dokumentti Arvostelu Palautus 3 4 Yleisesittely Geneettiset algoritmit Toteutetaan Darwin-työkalun laajennus Darwin tuottaa automaattisesti ohjelmistoarkkitehtuurisuunnitelmia Darwin lähtee nolla-arkkitehtuurista ja kehittää arkkitehtuuria käyttämällä suunnittelutyylejä ja malleja Arkkitehtuurin laatua arvioidaan muunneltavuuden, tehokkuuden ja ymmärrettävyyden suhteen Laadukasta arkkitehtuuria etsitään geneettisellä algoritmilla Laajennuksessa mahdollistetaan tehokkuusskenaarioiden määrittely ja tulkinta Työssä oletetaan tuntemusta Eclipse-rajapinnoista ja Javaohjelmointikielestä Geneettiset algoritmit kuuluvat meta-heuristisiin etsintäalgoritmeihin Etsintä on epädeterminististä Käytetään, kun ratkaisujoukko on suuri, ja determinististä algoritmia ei voida toteuttaa Geneettiset algoritmit pohjautuvat darwinistiseen teoriaan evoluutiosta Yksilöt katsotaan sitä laadukkaammiksi, mitä paremmin ne ovat sopeutuneet ympäristöönsä, ja mitä paremmat mahdollisuudet niillä on tuottaa laadukkaita jälkeläisiä Luonnonvalinta korjaa huonot yksilöt pois, jotta populaation koko pysyy hallinnassa 5 6 Geneettiset algoritmit - peruskäsitteitä Geneettiset algoritmit - prosessi Geneettiset algoritmit nojautuvat biologisiin käsitteisiin. Populaatio = ratkaisujoukko tietyllä ajanhetkellä Sukupolvi = ajanhetki, n. sukupolvi ilmaisee, että on tehty n iteraatiota, puhutaan n. sukupolven populaatio == n. populaatio Yksilö = ratkaisu Kromosomi = ratkaisun mallinnos Geeni = kromosomin (ratkaisun) muunneltava osa Alleeli = geenin saama arvo, osan eri variaatiot Mutaatio = geeniin (ratkaisun osaan) kohdistuva muutos Risteytys = kahden yksilön (ratkaisun) eri ominaisuuksien yhdistäminen Fitness-funktio = hyvyysfunktio = laatufunktio, laskee yksilön hyvyyden. Mitä parempi hyvyysarvo, sitä todennäköisemmin yksilö selviää luonnonvalinnasta ja osallistuu risteytyksiin Input: ratkaisun formalisointi kromosomimuodossa Luo populaatio Mutatoi kromosomeja Risteytä kromosomeja Laske hyvyysarvo yksilöille Suorita luonnonvalinta 1
Geneettiset algoritmit esimerkki 7 8 Esimerkki: repuntäyttöongelma. Reppuun mahtuu 9 tilavuusyksikön verran tavaraa. Tarkoitus on saada reppu mahdollisimman täyteen niin, että reppu painaa mahdollisimman paljon, mutta tilavuus ei ylitä repun tilavuutta. Reppuun yritetään saada mahtumaan seuraavat esineet: Tiili Cokis Kirja Läppäri Kengät Paino 5 1 3 4 2 Tilavuus 1 2 3 4 5 Geneettiset algoritmit esimerkki 9 10 Mallinnus: Validi ratkaisu on joukko esineitä, jotka eivät yhteensä ylitä repun tilavuutta. Ratkaisu voidaan mallintaa bittivektorilla, jossa 0 tarkoittaa, että kyseisen indeksin määrittämää esinettä ei pakata reppuun ja 1 tarkoittaa, että kyseinen esine pakataan. Nyt vektori on kromosomi, vektorin kentät ovat geenejä ja bitit ovat alleeleja. Esimerkki: Oletetaan, että esineet mallinnetaan samassa järjestyksessä kuin edelle, eli: Tiili cokis kirja läppäri kengät 0 1 0 0 0 Tässä ratkaisussa vain cokis on otettu reppuun mukaan, ja näin ollen reppu painaa 1 yksikön ja sen tilavuudesta on käytetty 2 yksikköä. Ratkaisu on validi, sillä tilavuusrajoite ei ylity, mutta ratkaisu ei varmasti ole optimaalinen. Mutaatio muuttaa ratkaisua. Mutaatio kohdistuu yleensä yhteen geeniin, mutta voi kohdistua myös koko kromosomiin. Mutaatio riippuu aina valitusta mallinnuksesta, sillä se vaihtaa geenin alleelin toiseen. Bittivektorin tapauksessa mutaatio on selkeä: 0 vaihtuu 1:ksi tai toisinpäin. Esimerkki: mutaatio 0 1 0 0 0 0 1 1 0 0 Nyt reppuun on pakattu cokiksen lisäksi kirja, ja reppu painaa 4 yksikköä. Tilavuudesta viedään 5 yksikköä, joten ratkaisu on validi. 11 12 isä lapsi 1 Risteytys yhdistää eri ratkaisuja. Yksinkertaisimmillaan risteytyskohta arvotaan, ja ratkaisun puoliskat yhdistetään, jolloin tuloksena on kaksi uutta ratkaisua. Risteytykseen osallistuvia ratkaisuja sanotaan vanhemmiksi, ja tuotettuja ratkaisuja jälkeläisiksi. Esimerkki: 0 1 1 0 0 1 0 0 0 1 äiti lapsi 2 0 1 0 0 1 1 0 1 0 0 Fitness-arvolla mitataan ratkaisun hyvyyttä. Reppuesimerkissä fitness-arvo on suoraviivaisesti laskettavissa: mikäli tilavuutta ei ole ylitetty, ratkaisu on sitä parempi mitä painavampi se on. Yleensä fitness-arvon ei ole yhtä suoraviivaista, eikä arvojen perusteella voida tehdä vertailua, ts. jos ratkaisu A saa fitness-arvon 1 ja ratkaisu B arvon 10, todennäköisesti B ei kuitenkaan ole 10 kertaa parempi kuin A. Fitness-arvoilla voidaan kuitenkin järjestää ratkaisut. Edellisen kalvon ratkaisuille voidaan laskea hyvyysarvot: Isä-ratkaisu sisältää cokiksen ja kirjan 1 + 3 = 4 Äiti-ratkaisu sisältää tiilen ja kengät 5 + 2 = 7 Lapsi 1 sisältää cokiksen ja kengät 1 + 2 = 3 Lapsi 2 sisältää tiilen ja kirjan 5 + 3 = 8 yksikköä 2
13 Ohjelmistoarkkitehtuurit 14 Luonnonvalinta toteutetaan karsimalla huonot yksilöt pois. Helpoimmillaan pidetään vain populaation parhaat yksilöt, eliitti, ja karsitaan suoraan huonoimmat pois. Tällöin kuitenkin on riski, että algoritmi konvergoituu liian nopeasti. Jotta populaatiossa olisi riittävästi hajontaa, toteutetaan valinta todennäköisyyksiin perustuvalla valinnalla. Yleensä tähän yhdistetään elitismi. Esimerkki: Tarkistetaan, ovatko ratkaisut valideja: Isä-ratkaisu sisältää cokiksen ja kirjan 2 + 3 = 5 Äiti-ratkaisu sisältää tiilen ja kengät 1 + 5 = 6 Lapsi 1 sisältää cokiksen ja kengät 2 + 5 = 7 Lapsi 2 sisältää tiilen ja kirjan 1 + 3 = 4 Kaikki tilavuudet ovat alle sallitun (9). Lapsi 2 on paras yksilö (fitness-arvo 8); valitaan se eliittinä suoraan seuraavalle kierrokselle. Lopuille (isä, äiti, lapsi1) määrätään todennäköisyydet niiden fitness-arvojen perusteella. 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ä Ohjelmistoarkkitehtuurit 15 Ohjelmistoarkkitehtuurit 16 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 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 Darwinissa on käytössä kaksi arkkitehtuurityyliä (viestinvälittäjä ja asiakas-palvelin) sekä viisi suunnittelumallia (Mediator, Façade, Strategy, Adapter, Template Method) 17 18 Viestinvälittäjä Asiakas-palvelin (Client-server) 3
19 20 Façade Mediaattori 21 22 Strategia Adapteri 23 Ohjelmistoarkkitehtuurit - arviointi 24 Template Method Arkkitehtuurille ei voida antaa yksikäsitteistä laatuarvosanaa Yksi tunnetuimpia arkkitehtuurien arviointimekanismeja on ATAM. Eri sidosryhmät esittävät laatuvaatimuksia omasta näkökannastaan Vaatimukset ovat usein ristiriitaisia Laatuvaatimukset esitetään ATAM-arvioinnissa skenaarioiden avulla Skenaario kuvaa todennäköistä tilannetta jonkin tietyn laatuattribuutin suhteen Skenaarioille annetaan prioriteetti ja muutosskenaarioiden kohdalla arvioitu todennäköisyys 4
25 26 Darwin Darwin Tarjoaa käyttöliittymän työkalun taustalla olevalle GA-moottorille. GA-moottori toteuttaa geneettisen algoritmin ja kehittää arkkitehtuurin. Darwinissa puolestaan on toteutettu rajapinnat GA-moottoriin sekä käyttöliittymä. Evolution MODEL VIEW Generation Architecture 1..* FitnessValue 1..* Period Scenario MutationProbabilities 1..* Weights * Settings CONTROLLER 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ä. Evolution Explorer Evolution Controls Generation View Mutations View Settings View Weights View Scenarios View 27 28 Darwin Darwin GA -moottori Use case diagram Evolution controls Class diagram Family tree Settings view Evolution explorer Menu group Mutations view Scenarios view Weights view Generation view 29 30 Tehtävänanto - johdanto Tehtävänanto skenaarion määrittely Darwin-työkalua laajennetaan siten, että tehokkuutta voidaan arvioida skenaarioiden kautta Tehokkuusskenaarioina käytetään käyttötapauksia. Skenaarion katsotaan toteutuvan sitä paremmin, mitä nopeammin käyttötapauksesta suoriudutaan Jokaisesta käyttötapauksesta suoriudutaan tehokkaimmin nollaarkkitehtuurivaiheessa. Kun arkkitehtuuria parannellaan muunneltavuuden suhteen, sen tehokkuus laskee Tehokkuusskenaarioiden avulla arkkitehtuurisuunnittelua voidaan ohjailla arvottamalla tehokkuuskriittiset käyttötapaukset muita korkeammiksi Jotta tehokkuusskenaarioita voidaan käyttää, tulee toteuttaa niiden määrittely, tarvittavat muutokset käyttöliittymään, skenaarioiden tulkinta, skenaariofitness-arvon ja fitness-arvon näyttäminen käyttäjälle 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äjä määrittelee skenaariot antamalla tarvittavat sekvenssikaaviot, joissa yksi sekvenssikaavio kuvaa yhden käyttötapauksen eli skenaarion. Käyttötapaus 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. 5
Tehtävänanto skenaarioiden määrittely 31 Tehtävänanto - käyttöliittymä 32 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 käyttötapausten pohjalta käyttämällä samoja kutsusekvenssejä tai niiden osia. Skenaariot syötetään erillisinä sekvenssikaavioina. Annetut skenaariot tulee voida tallentaa (esim. XML-muodossa tai sekvenssikaaviomuodossa) ja jälleen ladata Scenarios-näkymää tulee laajentaa siten, että nykyisten muunneltavuusskenaarioiden lisäksi se listaa myös tuotetut/annetut tehokkuusskenaariot ja mahdollistaa tehokkuusskenaarioiden lataamisen ja rangaistuskertoimien antamisen Listassa jokaiselle skenaariolle tulee olla nimi sekä sekvenssikaavion kutsujen määrä Weights-näkymään tulee lisätä kohta tehokkuusskenaarioille, ts. tehokkuusskenaariolle tulee voida antaa oma painonsa Tehtävänanto skenaarion tulkinta 33 34 Kun skenaariot on annettu sekvenssikaavioina, ne tulee koodata muotoon, jonka GA ymmärtää Fitness-funktioon lisätään uusi osafitness-funktio tehokkuusskenaarioiden fitness-arvon laskemiseen. GA:n käsittelemää koodattua muotoa käytetään tehokkuuslaskennassa Skenaariofitness-arvon käyttöönottoa säädellään painolla; mikäli paino on 0, osafunktiota ei luonnollisesti tule laskea mukaan. Olemassa olevaa koodausta ja tulkintaa muunneltavuusskenaarioille voi käyttää pohjana, mutta on huomioitava, että tehokkuusskenaariot ovat luonteeltaan hyvin erilaisia Muissa tapauksissa (paino > 0) tehokkuusskenaariofitness käyttäytyy kuten muutkin osafitness-funktiot, eli se lasketaan osaksi kokonaisfitness-arvoa. Valitun koodaus/tulkintatavan tulisi olla joustava ja ottaa huomioon, että vastaisuudessa voidaan haluta lisätä erityyppisiä tehokkuusskenaarioita. Tehokkuusseknaariofitness-arvot tulee rekisteröidä erikseen, jotta arvon kehitystä voidaan tarkastella ajon jälkeen. 35 36 Tehokkuutta heikentäviä ratkaisuja rankaistaan seuraavasti: Jokaisesta luokkien välisestä kutsusta tulee rankaisu -1 Jokaisesta serverikutsusta lisärankaisu -s Jokaisesta viestinvälittäjän (dispatcher) käytöstä lisärankaisu -d Serveri- ja viestinvälittäjärankaisut tulee voida asettaa niin, että niitä voidaan joustavasti vaihtaa! Lähtökohtaisesti s ja d > 1. Huomaa, että kutsu luokasta rajapintaan katsotaan yhtäläiseksi suoran kutsun (luokasta luokkaan) kanssa. Ts. jos a b, ja b on eri luokassa kuin a, on skenaarion kannalta yhdentekevää, toteuttaako b jonkin rajapinnan vai ei. Esimerkki: Asetetaan s = 2 ja d = 2. 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 6
37 38 Tapaus 2: keitäkahvia ja laitakahvikonepäälle ovat luokissa A ja B, luokkien välillä on suora kutsu tai keitäkahvia kutsuu B-luokan rajapintaa (jonka laitakahvikonepäälle toteuttaa): tehokkuusrankaisu -1 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. 39 40 Tapaus 4: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa, ja laitakahvikonepäälle luokka on merkattu serveriksi: tehokkuusrankaisu: -1-2 = -3 Tapaus 5: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa ja käyttävät viestinvälittäjää kommunikointiin: tehokkuusrankaisu: -1-2-1 = -4 41 42 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 -1-1 -2 = -4 Tapaus 7: keitäkahvia ja laitakahvikonepäälle ovat eri luokissa, ja kommunikoivat viestinvälittäjän kautta. Lisäksi laitakahvikonepäälleoperaatiota tulisi käyttää Adapterin kautta: tehokkuusrankaisu -1-1 -1-2 = -5 7
43 Tehtävänanto - output 44 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 esitetyllä tavalla, ja kokonaisrankaisu on näiden summa Ratkaisun (arkkitehtuurin) tehokkuusskenaariofitness-arvo on luonnollisesti kaikkien yksittäisten käyttötapaustehokkuuksien summa. Työkalu näyttää reaaliajassa, miten arkkitehtuurien (yhteis)fitness-arvojen keskiarvo kehittyy Lisäksi on mahdollista erotella eri osafitness-funktioiden fitnesskäyrät, kun tulos on valmistunut Tehokkuusskenaarioiden erillistä fitness-käyrää tulee voida tarkastella vastaavasti kuin muitakin osafitness-funktioiden käyriä nykyisessä toteutuksessa Tehokkuusskenaariofitness tulee olla mukana yhteisfitnessin laskennassa 45 46 Tehtävänanto arvioitu työjakauma Tehtävänanto - dokumentti Darwin: Syötteen antamisen toteutus, n. 20h Sekvenssikaaviot (antaminen, tallentaminen, lataaminen) Skenaario- ja painonäkymät Syötteen koodaus Frankenstein: Skenaariototeutus GA:lle n. 30h Koodaus ja sen tulkinta Fitness-funktion toteutus Koodin ymmärtäminen (Cromosome-tietorakenne) Darwin: Tulosteen antaminen n. 10h Fitness-käyrä 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 skenaarioiden määrittelystä tulosteeseen. 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> */ 47 48 Arvostelu - minimivaatimukset Arvostelu - minimivaatimukset Hyväksytystä harjoitustyöstä saa 3p. 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. Skenaariot voi ladata työkaluun. Käyttöliittymässä Skenaarionäkymä on päivitetty niin, että syötetyt skenaariot voidaan nähdä listana. Skenaariofitnessin laskenta on toteutettu toimivasti Fitness-käyrään päivittyy myös tehokkuusskenaarioarvo ja tehokkuusskenaario-fitnessin saa tarvittaessa näkymään omana käyränään Weights-näkymä on päivitetty (tehokkuusskenaarioille oma kenttä) Serveri- ja viestinvälittäjäkertoimet voidaan antaa Skenaarionäkymässä. Skenaarioiden koodaus ja tulkinta on toteutettu toimivasti 8
Arvostelu - täydellisesti toteutettu tehtävänanto 49 Arvostelu lisäpisteet/kompensoinnit 50 Harjoitustyöstä voi saada maksimissaan 6 pistettä. Pakollisen osuuden lisäksi voi toteuttaa valinnaisia osuuksia, joilla voi nostaa pistemäärää. Tehokkuusskenaarioiden antaminen tehtävänannon mukaisesti sekvenssikaavioilla, ja skenaariot pystytään tallentamaan ja jälleen lataamaan (2 p) Käyttöliittymässä Skenaarionäkymä on päivitetty niin, että syötetyt skenaariot voidaan nähdä listana (1p) HUOM! Skenaarionäkymän listatoteutus on PAKOLLINEN, jos skenaarioiden syöttö muuten kuin sekvenssikaavioilla. Listatoteutus VALINNAINEN (saa lisäpisteen), jos syöttö sekvenssikaavioilla. Lisätehtäviä, joilla voi korvata valinnaisia toteutuksia tai kompensoida puutteita. (HUOM! Pisteitä voi saada MAX 6p, eli lisätehtävillä EI VOI nostaa kokonaispistemäärää yli 6 pisteen.): Skenaarioiden priorisoinnin toteuttaminen (priorisointi käyttöliittymän kautta, loogisinta käyttää Skenaario-näkymää) ja priorisoinnin ottaminen huomioon fitness-funktiossa(1p) Frankensteinia (eli GA-moottoria) voi käyttää myös komentorivin kautta. Tällöin loppuratkaisu eli luokkakaavio piirretään Frankensteinin UMLGenerator luokassa. Luokan koodi on kamalaa. Lisätehtävä: UML-kaavioluokan (UMLGenerator) siistiminen (1.5p) 51 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 ladata joko 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 9