Alla on muutama aihekuvaus. Voit ehdottaa myös omaa aihetta. Syksyn 2012 Ohjelmistoarkkitehtuurit -kurssin kuluessa aiheita tullee jokunen lisää.

Aihe 2012/1: <Jokin> web sovelluskehys

Työn kohteena <jokin> web sovellustokehys. Työssä kuvataan kehyksen ohjelmistoratkaisun pohjana oleva arkkitehtuurityyli, 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 skenaarioita jonkin laatuominaisuuden testaamiseksi sekä odotettavissa olevia että järjestelmän rajoja määritteleviä. Testattava laatuominaisuus  voisi olla saatavuus ja luotettavuus tai muunneltavuus ja uudelleenkäytettävyys. Skenaarion totutusmahdollisuuksia kuvataan lyhyellä sanallisella kuvauksella. Vaativuudesta ja työmäärästä esitetään karkea arvio (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]
• joku muu, josta sovitaan erikseen

Aihe 2012/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.

Aihe 2012/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 (esim. lähdekirjallisuudessa mainittuja). Yleisarvioinnin lisäksi laaditaan pienehkö joukko skenaarioita jonkin laatuominaisuuden testaamiseksi sekä odotettavissa olevia että rajoja määritteleviä. Testattava laatuominaisuus  voisi olla saatavuus ja luotettavuus tai muunneltavuus ja uudelleenkäytettävyys. Skenaarion totutusmahdollisuuksia kuvataan lyhyellä sanallisella kuvauksella. Vaativuudesta ja työmäärästä esitetään karkea arvio (vrt. ATAM).