Yleistä

Sovi aiheesta kurssin vastuuhenkilön kanssa, ennen kuin aloitat työn tekemisen. Alla olevien valmiiden aiheiden (1 - 3) lisäksi voit ehdottaa myös omaa aihetta (katso Aihe 4).

Harjoitustyössä tuotetaan raportti, jonka odotettu pituus on 10 - 15 sivua. Palauta työsi mieluiten pdf:nä, mutta laitoksen koneilla avattavissa olevat OpenOffice- ja MS Word-dokumentitkin käyvät. Mahdolliset ohjelmakoodit voi palauttaa erillisenä pakettina (zip) tai tulostaa varsinaisen raportin liitteiksi. Raportille ei ole yksityiskohtaisia ulkoasuvaatimuksia, mutta raportti täytyy otsikoida ja jäsennellä lukuihin ja alilukuihin selkeästi. Kaikkien aihekuvauksissa mainittujen osioiden on löydyttävä raportista vaivattomasti. Voit halutessasi käyttää esimerkiksi kandidaatintutkielma-kurssin valmiita dokumenttipohjia (tiivistelmäsivua ei kuitenkaan tarvita). Työssä käytettyjen lähteiden on käytävä ilmi raportista, ja niihin on viitattava tekstissä. Kieliasun ja esitystavan odotetaan olevaan normaaleja eli selkeää ja vaivattomasti luettavaa asiatekstiä. UML:ää suositellaan käytettäväksi arkkitehtuurikaavioissa, mutta vapaamuotoisiakin piirroksia voi käyttää, kunhan käytettyjen symbolien merkitys käy ilmi piirroksen selostuksesta.

Raportti kirjoitetaan suomeksi (tai ruotsiksi) - vain poikkeustapauksissa englanniksi (esimerkiksi työnantajalle tehtävä oma aihe), mistä on myös erikseen sovittava vastuuhenkilön kanssa ennen työn aloitusta.

Muista merkitä nimesi ja opiskelijanumerosi raportin kansilehdelle. Plagiointi (myös itseltä eli seminaariesitelmien tai muiden vastaavien dokumenttien sellaisenaan "kierrättäminen") on luonnollisesti kielletty.

Aihe 2016-17 / 1: <Jokin> web sovelluskehys

Työn kohteena <jokin> web sovelluskehys. Sovelluskehys voi olla varsinaisen web-applikaation toteuttamista tukeva palvelinpuolen kehys tai asiakaspuolen kehys (esim. JavaScript-kehys selaimessa suoritettavan asiakasliittymän toteuttamiseksi). Työssä kuvataan kehyksen ohjelmistoratkaisun pohjana oleva arkkitehtuurityyli tai -ideat, dokumentoidaan kehyksen perusrakenne ja toimintaperiaate, kuvataan erikoistamisperiaate ja variaatiopisteet ja sekä analysoidaan kehyksen  avulla tuotettujen sovellusten vahvuuksia ja heikkouksia.
 
Työn tuloksena tuotetaan dokumentti, joka koostuu kolmesta osasta. Ensimmäisessä osassa kuvataan kehyksessä sovellettavien arkkitehtuurityylien perusideat ja niiden kehyksestä johdettavien sovellusten komponenteille määrittelemä roolijako.
 
Toisessa osassa dokumentoidaan kehyksen yleisarkkitehtuuri ja keskeisimmät variaatiopisteet. Tavoitteena on antaa yleiskuva kehysrakenteesta ja siitä miten kehystä erikoistetaan sovelluskohtaisesti. Apuna voi käyttää jotain lähteistä löytyvää tai omaa esimerkkisovellusta. Kuvaustekniikkoina tulevat kyseeseen esimerkiksi luokkakaavio selventämään rakennetta ja sekvenssikaaviot kuvaamaan toiminnan kulun pääpiirteitä. Kaavioihin merkitään esimerkiksi stereotyypeillä, mitkä osat arkkitehtuurista kuuluvat kehyksen puolelle ja mitkä osat puolestaan ovat sovelluskohtaisia. Konfiguraatiotiedostot ovat usein merkittävässä osassa web-sovelluskehysten rakenteessa, joten ne on syytä huomioida kuvauksessa. Sovelluskehykset pohjautuvat johonkin arkkitehtuurityyliin ja toteuttavat yleensä useita ohjelmistotason suunnittelumalleja. Rakenteen ymmärtämisen kannalta tärkeät keskeiset suunnittelumallit tulisi tunnistaa.
Kuvauksen tulee olla arkkitehtuuritasoinen ja välttää liiallisia yksityiskohtia. Kehyksestä kannattaa kuvata vain sovelluksen tekijän kannalta kiinnostavat luokat ja esimerkkisovelluksen luokista yksi tai muutama edustaja kutakin (ali)luokkaryhmää kohti. Toiminnan kulun ymmärtämiseksi riittää kuvata 1-2 periaatteet esille tuovaa tapausta. Web sovelluksen kannalta keskeisiä asioita ovat esimerkiksi käyttäjän syötteisiin reagointi, sovelluksen tilan ja kontrollin kulun hallinta, käyttäjille näytettävien sivujen tuottaminen ja yhteydet tietosisältöön.
 
Kolmannessa osassa arvioidaan kehystä ja sen avulla toteutetun sovelluksen arkkitehtuuria. Arviossa tuodaan esiin hyviä ja huonoja puolia (esim lähdekirjallisuudessa mainittuja). Yleisarvioinnin lisäksi laaditaan pienehkö joukko (laatu-) skenaarioita jonkin laatuominaisuuden testaamiseksi - sekä odotettavissa olevia että järjestelmän rajoja määritteleviä (katso luentokurssin materiaalit arkkitehtuurin arvioinnista ja ATAM:sta) . Testattava laatuominaisuus  voisi olla saatavuus ja luotettavuus tai muunneltavuus ja uudelleenkäytettävyys. Skenaarioissa kuvattujen tavoitteiden toteutumismahdollisuuksia kuvataan lyhyellä sanallisella kuvauksella. Vaativuudesta ja työmäärästä esitetään karkea arvio asteikolla L(ow) / M(edium) / H(igh) (vrt. ATAM) .
 

<Jokin> voidaan valita seuraavista:

• Struts 2 (http://struts.apache.org/2.x/)  [Java]
• Spring (rajattuna web sovelluksiin) (http://www.springsource.org/documentation) [Java]
• Zend framework (http://framework.zend.com/) [PHP]
• Ruby on Rails (http://rubyonrails.org/)
• AngularJS (asiakaskehys, https://angularjs.org/)
• Express (http://expressjs.com/)
• joku muu, josta sovitaan erikseen

Aihe 2016-17 / 2: Ristisana- ja ruudukkopelejä tukeva sovelluskehys

Tehtävänä on suunnitella ristisana- ja ruudukkopelien toteuttamista tukeva sovelluskehys Java-ym­päristöön. Lisäksi ana­ly­soidaan kehyksen odotettua uudelleenkäytettävyyttä.
 
Kehyksen on tarkoitus helpottaa kirjaimia tai numeroja sisältävien ruudukoiden täyttämiseen pe­rus­tu­vi­en pelisovellusten laatimista. Esimerkkejä tällaisista peleistä ovat esimerkiksi sudokut (ks. http://www.websudoku.com), ristisanatehtävät (ks. http://www.crossword-puzzles.co.uk) ja laskutehtävät (ks. http://www.edhelper.com/puzzles.htm). Yhteistä näille pe­leil­le on riveistä ja sarakkeista muodostuva pelialue, jolla sijaitsevista ruuduista kukin voi si­säl­tää joko pelin ratkaisemiseen tarvittavaa vihjetietoa (numeroita, kirjaimia, tekstiä tai kuvia) tai sitten ruutu voi olla tyhjä paikka käyttäjän syötteelle. Käyttäjä täyttää ruudukon vapaita syö­te­ruu­tu­ja yksi kerrallaan, ja peliohjelma tarkistaa, että täyttäminen sujuu pelin sääntöjen mu­kaan. Kun kaikki syöteruudut on täytetty sääntöjen mukaan, peli (tai tehtävä) on ratkaistu. Oi­ke­as­ta ratkaisusta lasketaan pelikohtaisten sääntöjen mukainen tulos, joka voi olla esi­mer­kik­si ratkaisuun kuluneen ajan ja pelin aikana syötteisiin tehtyjen korjausten lukumäärän pe­rus­teel­la laskettu pistemäärä. Pelit toteutetaan Java-sovelluksina J2SE-ympäristössä.
 
Kehykseltä vaaditaan seuraavat ominaisuudet ja palvelut:
Työn ensimmäisessä osassa tehtävänä on suunnitella kehykselle luokista ja ra­ja­pin­nois­ta sekä nii­den julkisista omi­nai­suuk­sis­ta (metodeista ja tietokentistä) koostuva Java API. Kuvaa API luokkakaavion ja siihen liittyvien sanallisten selvitysten avulla. Kuvaa ohjelmarakenteen lisäksi toiminnan kulku pääpiirteissään. Kuvaa myös kehyksen variaatiopisteet ja miten kehys on tarkoitettu erikoistettavaksi (erityisesti  miten hoidetaan pelikohtainen alkutilanteen ja oikean ratkaisun käsittely, miten määritellään pelikohtaiset syötetarkistukset ja pistelasku, …). Selosta myös kaikki kehyksen luokat ja rajapinnat, so­vel­le­tut suun­nit­te­lu­mal­lit ja ark­ki­teh­tuu­ri­tyy­li. Liitä kehyksen dokumentaatioon lyhyt kuvaus siitä, miten yksinkertainen sudoku-peli olisi johdettavissa kehyksestä. Kuvaa toiminnan eteneminen parin keskeisen skenaarion avulla, esimerkiksi  tapaukset (a) käyttäjä antaa yhden vir­heel­lisen syötteen johonkin ruutuun ja kun (b) käyttäjä saa tehtävän valmiiksi ja pe­li­so­vel­lus tarkistaa ratkaisun ja laskee sitä vastaavat tulospisteet.

Työn toisessa osassa tehtävänäsi on arvioida kehyksen arkkitehtuuria.  Keskity ana­lyy­sis­sä muunneltavuuteen ja uu­del­leen­käy­tet­tä­vyy­teen. Tarkastele seuraavia skenaarioita

1. Kehyksen avulla toteutetaan yksinkertainen sanaristikkopeli.
2. Kehyksellä toteutetaan sudoku-pelistä versio, johon halutaan pelikohtaisesti määritelty käyt­töliittymä ja graafinen ulkoasu.
3. Kehyksellä toteutetaan sudoku-pelistä versio, jolla voi tallettaa pelitilanteen koska ta­han­sa kesken pelin ja jatkaa siitä myöhemmin.
4. Kehystä halutaan käyttää apuna tuotettaessa pelitilanteita tai ongelmia generoivia so­vel­luk­sia (esim. sudokun- tai sanaristikonlaatimissovellus).

Analysoi kutakin skenaariota sanallisesti ja arvioi toteutuksen vaikeutta karkeasti ATAM tyyliin, eli esitä vaativuudesta ja työmäärästä karkea arvio asteikolla L(ow) / M(edium) / H(igh).

Aihe 2016-17 / 3:  Ohjelmistokehys grafiikkaeditoreille

Työn kohteena on jokin ohjelmistokehys (esim. Eclipseen liittyvä GEF). Työssä kuvataan kehyksen ohjelmistoratkaisun pohjana oleva arkkitehtuurityyli, dokumentoidaan kehyksen perusrakenne ja toimintaperiaate, kuvataan erikoistamisperiaate ja variaatiopisteet sekä analysoidaan kehyksen avulla tuotettujen sovellusten vahvuuksia ja heikkouksia.
 
Työn tuloksena tuotetaan dokumentti, joka koostuu kolmesta osasta. Ensimmäisessä osassa kuvataan kehyksessä sovellettavien arkkitehtuurityylien perusideat ja niiden kehyksestä johdettavien sovellusten komponenteille määrittelemä roolijako.
 
Toisessa osassa dokumentoidaan kehyksen yleisarkkitehtuuri ja keskeisimmät variaatiopisteet. Tavoitteena on antaa yleiskuva kehysrakenteesta ja siitä miten kehystä erikoistetaan sovelluskohtaisesti. Apuna voi käyttää jotain lähteistä löytyvää esimerkkisovellusta. Kuvaustekniikkoina tulevat kyseeseen esimerkiksi luokkakaavio selventämään rakennetta ja sekvenssikaaviot kuvaamaan toiminnan kulun pääpiirteitä. 
Kaavioihin merkitään esimerkiksi stereotyypeillä, mitkä osat arkkitehtuurista kuuluvat kehyksen puolelle ja mitkä osat puolestaan ovat sovelluskohtaisia. Sovelluskehykset pohjautuvat johonkin arkkitehtuurityyliin ja toteuttavat yleensä useita ohjelmistotason suunnittelumalleja. Rakenteen ymmärtämisen kannalta tärkeät keskeiset suunnittelumallit tulisi tunnistaa. Kuvauksen tulee olla arkkitehtuuritasoinen ja välttää liiallisia yksityiskohtia. Kehyksestä kannattaa kuvata vain sovelluksen tekijän kannalta kiinnostavat luokat ja esimerkkisovelluksen luokista yksi tai muutama edustaja kutakin (ali)luokkaryhmää kohti. Toiminnan kulun ymmärtämiseksi riittää kuvata 1-2 periaatteet esille tuovaa tapausta

Kolmannessa osassa arvioidaan kehystä ja sen avulla toteutetun sovelluksen arkkitehtuuria. Arviossa tuodaan esiin hyviä ja huonoja puolia. Yleisarvioinnin lisäksi laaditaan pienehkö joukko (laatu-) skenaarioita jonkin laatuominaisuuden testaamiseksi - sekä odotettavissa olevia että järjestelmän rajoja määritteleviä (katso luentokurssin materiaalit arkkitehtuurin arvioinnista ja ATAM:sta) . Testattava laatuominaisuus  voisi olla saatavuus ja luotettavuus tai muunneltavuus ja uudelleenkäytettävyys. Skenaarioissa kuvattujen tavoitteiden toteutumismahdollisuuksia kuvataan lyhyellä sanallisella kuvauksella. Vaativuudesta ja työmäärästä esitetään karkea arvio asteikolla L(ow) / M(edium) / H(igh) (vrt. ATAM) .
 

Aihe 2016-17 / 4: <Oma aihe>

Aiheena voi olla esimerkiksi jonkin itseä kiinnostavan ohjelmistokehyksen (framework) tai alustan (platform) arkkitehtuurin osa-alueen kuvaus. Aihe kannattaa rajata niin, että sen pystyy järkevästi käsittelemään 10-15 sivun raportissa. Aihetta pitää käsitellä nimenomaan arkkitehtuurinäkökulmasta, eli tunnistaa käytetyt arkkitehtuurityylit ja -patternit, erikoistamispisteet ja-periatteet (kehyksistä), sekä evaluoida arkkitehtuuriratkaisuja laatuskenaarioita käyttäen. Aiheen 1 jäsentelyä voi käyttää lähtökohtana raportille.

On myös mahdollista tehdä työ, jossa sovelletaan ja syvennetään jotain muuta kurssin teemaa, esimerkiksi arkkitehtuurin mallintamista. Voit esimerkiksi analysoida ja selostaa esimerkkien avulla, miten soveltaisit kurssilla läpikäytyä ohjelmistoarkkitehtuurin kanonista mallia jonkin konkreettisen ohjelmiston arkkitehtuuriin.

Voit laatia myös kokemusperäisen raportin arkkitehtuurityön roolista/merkityksestä/saavutuksista/vaikeuksista oman työkokemuksesi perusteella. Viimeksimainitussa on oleellista reflektoida kurssilla esitettyjä asioita käytännön kokemuksiin ja arvioida kriittisesti arkkitehtuurityön merkitystä. Voit myös poimia joitain tiettyjä rajatumpia aihealueita kurssin aihepiiristä, joita käsittelet konkreettisten esimerkkien kautta. Huomaa kuitenkin, että esimerkiksi työnantajan luottamukselliseksi määrittelemiä asioita ei saa ilman työnantajan lupaa selostaa (harjoitustöitä ei julkaista, mutta mitään luottamuksellisuussopimusta [Non-Disclosure Agreement, NDA] kurssin vastuuhenkilö ei allekirjoita).

Omasta aiheesta pitää siis sopia kurssin vastuuhenkilön kanssa ennen työn aloittamista. Toimita sähköpostitse aiheesi kuvaus sekä loppuraportin alustava jäsentely kurssin vastuuhenkilölle aiheen sopimista varten.