Ohjelmistoarkkitehtuurit harjoitustyö Johdanto. 2 Harjoitustyön käytännönjärjestelyt ja aikataulu. Versio

Transkriptio

1 Versio Ohjelmistoarkkitehtuurit harjoitustyö Johdanto Harjoitustyön aiheena on suunnitella musiikinkuuntelupalvelu TUTifyn ohjelmistoarkkitehtuuri. Jokainen yksittäinen harjoitustyöryhmä suunnittelee arkkitehtuurin ja lisäksi jokaisella ryhmällä on yhteistyöryhmä, joka suorittaa arkkitehtuurin arvioinnin. Ryhmät toimivat itsenäisesti, mutta kommunikoivat tarpeen vaatiessa keskenään arviointiin liittyvissä asioissa. Harjoitustyössä suunnitellaan musiikinkuuntelupalvelu TUTifyn ohjelmistoarkkitehtuuri riittävän tarkalla tasolla. Eli toisin sanoen: - Dokumentoikaa mielestänne tärkeät asiat TUTify servicestä - Perustelkaa miksi valitsitte juuri ne kohdat, jotka valitsitte. Huomatkaa, että dokumentin rakenne on yksi arvosteluperuste. - Clientin rajapinta tulee dokumentoida sillä tasolla, että alihankkija osaa sitä käyttää (voisit itse kuvitella koodaavasi softan sen perusteella) Suunnittelun lisäksi harjoitustyön tavoitteena on tutustua arkkitehtuurien arviointiin käytännössä. Arviointiin käytetään ATAM- ja DCAR-menetelmiä, siten että ryhmä tulee arvioiduksi ATAM:lla ja arvioivat DCAR:lla tai toisinpäin. Näin kukin ryhmä ja heidän yhteistyöryhmänsä näkevät molemmat menetelmät käytännössä. Tarkoitus on, että arviointisessiossa arvioidaan mahdollisimman valmis arkkitehtuuri, mutta toisaalta arvioinnin jälkeen arkkitehtuuria on vielä mahdollista parantaa ATAM/DCAR-sessiossa löytyneiden riskien ja puutteiden perusteella. Tätä voikin ajatella iteratiivisena prosessina parhaan mahdollisen lopputuloksen saamiseksi. 2 Harjoitustyön käytännönjärjestelyt ja aikataulu Olkaa yhteydessä yhteistyöryhmäänne (TTY:llä ryhmien tiedot löytyvät IDLE:stä) jo harjoitustyön alkuvaiheessa. Jos kommunikoinnin kanssa on ongelmia, ottakaa yhteyttä omaan assariinne. Harjoitustyön tekeminen koostuu kahdesta päävaiheesta: 1. Suunnittelu a) Välipalautus b) Arvioitavan version palautus c) Korjatun arkkitehtuurisuunnitelman palautus assarille + miten ATAM/DCAR -löydöksiin on reagoitu 2. Arkkitehtuurin arviointi a) Arviointitilaisuuteen valmistautuminen, arkkitehtuuriesityksen valmistelu jne. b) Varsinainen arviointitilaisuus, jossa molemmat ryhmät ovat läsnä c) Arviointiraportin palautus assarille ja yhteistyöryhmälle

2 2.1 Aikataulu Välipalautusversion ja välipalautuksen ajanvarauksen deadline harjoitustyön välipalautukset Arviointitilaisuudessa esiteltävän materiaalin (=kalvot, arkkitehtuuridokumentaatio) palauttaminen mennessä ja arviointitilaisuuden ajanvarauksen deadline Arviointisessiot Arviointidokumenttien palautus (myös yhteistyöryhmälle) 8.5. Arkkitehtuuriarvioinnin perusteella muunnellun/kommentoidun suunnitteludokumentin palautus (katso myös kohta 6.2) Annetut päivämäärät ovat viimeisiä mahdollisia päiviä, palautuksen saa ja kannattaa tehdä ennen viimeistä päivää. 2.2 Arviointitilaisuuteen valmistautuminen - Tee menetelmän esittelykalvot (kts. kalvopohjat kurssin kotisivuilta). - Tutustu menetelmän eri vaiheisiin mitä tehdään missäkin vaiheessa. - Varmista, että ryhmälläsi on käytettävissä tietokone arviointitilaisuudessa. Jos ryhmällä ei ole kannettavaa tietokonetta, niin kysy assarilta ETUKÄTEEN lainaläppäriä. Varmista myös läppärin toiminta videotykillä, esim. Applen VGA-adapteri, läppärin laturi jne. on mukana. - Tarvittavat dokumenttipohjat tulee ottaa mukaan läppärillä ja niiden käyttöön on syytä tutustua etukäteen, jotta tilaisuus sujuu mahdollisimman sujuvasti, eikä aika kulu tietoteknisten ongelmien selvittelyyn. - Sopikaa arvioinnin suorittavan ryhmän roolitus ennen tilaisuutta: kuka on kirjuri, kuka puheenjohtaja, kyseenalaistaja, prosessin tarkkailija, jne. Arvioitava ryhmä sopii kuka edustaa business näkemystä ja kuka esittää pääarkkitehtia. Lisäksi DCAR menetelmässä tulee edellä mainittujen roolien lisäksi valita forcejen kerääjä. - DCAR:ssa arviointiryhmän on hyvä varautua siihen, että arkkitehtuurin tehnyt ryhmä saattaa tarvita läppäriä lainaksi. Tässä on hyvä myös neuvotella arvioitavan ryhmän kanssa, josko he voisivat ottaa myös omia tietokoneitaan mukaan. 2.3 Arviointitilaisuus - Arviointitilaisuus etenee menetelmän vaiheiden mukaisesti. Tutustukaa niihin etukäteen. Molemmissa tilaisuus alkaa menetelmän lyhyellä esittelyllä. Tämän esityksen pitää arvioiva ryhmä - Seuraavaksi molemmissa menetelmissä on business- ja arkkitehtuuriesitykset. Harjoitustyössä nämä esitykset on yhdistetty yhdeksi esitykseksi, joka sisältävät molemmat asiat. Tämän esityksen pitää arkkitehtuurin suunnitellut ryhmä. - Seuraavat vaiheet riippuvat menetelmästä: - ATAM o ATAMissa arvioiva ryhmä johtaa tilaisuutta ja kyselee tärkeät laatuominaisuudet. Tämän hoitaa puheenjohtaja, kirjuri kirjaa tiedot ylös. o Puheenjohtaja johtaa myös skenaarioiden keräämistä laatupuuhun, esimerkiksi joko kyselemällä tai käyttämällä jotain ideointimenetelmää. o Skenaariot priorisoidaan H/M/L asteikolla. Arkkitehti päättää skenaarion vaikeuden arkkitehtuurin kannalta. Domain /business -asiantuntija tärkeyden liiketoiminnan kannalta (arvioitavasta ryhmästä). o Analyysivaiheessa kyseenalaistaja koittaa tuomita arkkitehtuurin vääränä ja arkkitehti puolustautuu (arvioinnin perusperiaate: arkkitehti on syyllinen kunnes toisin todistaa ).

3 tämä keskustelu pitää kuitenkin käydä skenaarion tarjoamassa kontekstissa kuitenkin, jotta kirjuri pystyy kirjaamaan huomiot ylös. - DCAR o DCARssa esitysten aikana kaikki arvioijat keräävät päätöksiä ja forceja (huom. esim. Google Docs voi helpottaa näiden keräämistä). o Yksi henkilö yhdistää listat (tarvittaessa). Tämä forcejen kerääjä ottaa listan itselleen täydennettäväksi arvioinnin myöhemmissä vaiheissa. o Päätökset priorisoidaan kaksivaiheisesti. Ensin jokainen arkkitehtuurin tehneen ryhmän jäsen valitsee n. 5 päätöstä seuraavalle kierrokselle. Toisella kierroksella jokaisella arkkitehtiryhmän jäsenellä on käytössä 100 pistettä, jotka hän voi jakaa haluamallaan tavalla toiselle kierrokselle mukaan otetuille päätöksille. Pisteitä annetaan yleensä päätöksille, jotka vaikuttavat epäilyttäviltä tai vaativat arviointia osallistujan mielestä. Muistakaa, että arviointiryhmä on paikalla auttamassa teitä tekemään parempaa harjoitustyötä! o Jokainen arkkitehtiryhmän jäsen dokumentoi noin 2-3 päätöstä käyttäen dokumenttipohjaa. o Kirjuri kerää päätökset ja niitä ruvetaan käymään lävitse priorisointijärjestyksessä. o Dokumentoija esittelee päätöksen läsnäolijoille. o Analyysi vaiheessa arviointiryhmä esittää kysymyksiä ja yrittää löytää heikkouksia päätöksestä. Alussa kerättyjä forceja käytetään kysymysten esittämiseen. Esim. Sanoitte, että suorituskyky on tärkeää. Eikös tämä päätös heikennä sitä, koska. o Kirjuri täydentää päätösten kuvaukset sitä mukaan kun analyysiä käydään lävitse. Päätöksen plussat ja miinukset, päätöksen kuvaus, mahdolliset esille tulevat vaihtoehtoiset ratkaisut, jne. o Lopuksi arkkitehtuuriryhmä ilmaisee mielipiteensä päätöksen kelvollisuudesta peukkuäänestyksellä. Kirjuri kirjaa äänestystuloksen ylös. - Assarin rooli: valvoa tilaisuutta Tarvittaessa neuvoa ja kyseenalaistaa, mutta ei kuitenkaan olla puheenjohtaja. 2.4 Arviointitilaisuuden arvosteluperusteet - Tilaisuus etenee arviointiryhmän puheenjohtajan toimesta (ei assarin toimesta) - Kyseenalaistaminen: Arviointiryhmä oikeasti kyseenalaistaa ratkaisuja, eikä vain hyväksy, että hyvältä näyttää. Tarkoitus on auttaa arvioitavaa ryhmää löytämään ongelmia. - Arkkitehtuuriryhmän valmius vastata kysymyksiin ja perustella päätöksiään. Hiljaisuus ei ole tapa vastata. - Tilaisuuteen valmistautuminen: esitykset kunnossa, läppärit mukana, kaikki ajoissa paikalla, jne. - Koko ryhmä osallistuu arviointiin eikä homma ole yhden jäsenen sankaritekojen varassa. 2.5 Yleiset vaatimukset Käyttäkää soveltuvin osin opinnäytetyön pohjaa 1 (doc, docx, Latex ja OpenOffice) ja tehkää palautus pdf-muodossa. Saatte itse päättää dokumenttinne sisällön. Esimerkkejä arkkitehtuuridokumenteista (tai dokumenttipohjista) on esitetty kurssin aikana. Tarkistakaa, että sivunumerointi löytyy ja toimii. Kiinnittäkää erityistä huomioita kuviin ja kaavioihin sekä siihen, että ne on tekstissä selitetty. Dokumentoikaa järjestelmän tärkeimmät rajapinnat riittävän yksityiskohtaisesti. Ennakoikaa ja sopikaa yhteistyöryhmän kanssa arviointiajasta riittävän ajoissa - parhaat ajat menevät ensimmäisenä. 1 TTY:

4 3 Aihealueen esittely Harjoitustyön aiheena on suunnitella musiikin suoratoistopalvelu (music streaming service) TUTifylle arkkitehtuuri. TUTify ohjelman avulla rekisteröityneet käyttäjät voivat kuunnella musiikkia, joko tietokoneella, mobiilipäätelaitteella (älypuhelimet, taulutietokoneet, jne.) tai web-selaimella. Palvelu on käyttäjille ilmainen, mutta ilmaiskäytössä käyttäjille soitetaan mainoksia kappaleiden välissä ja näytetään mainoksia myös ruudulla. Käyttäjät voivat kuukausittain maksaa palvelusta, jolloin käyttäjälle ei soiteta tai näytetä mainoksia. Jatkossa järjestelmää halutaan kehittää niin, että samasta palvelusta käyttäjä voi myös katsella TV-sarjoja ja elokuvia. Tämä laajennos kulkee työnimellä TUTflix. TUTifyn tärkeimpiä ominaisuuksia ovat Hakukenttä, jolla kappaleita voi etsiä soitettavaksi Hakutulosten listaus, joka näyttää haun tuloksen Soittolistat, johon voi kerätä haluamiaan kappaleita soitettavaksi. Näitä listoja voi myös jakaa kavereiden kesken. Suositukset, jotka näytetään soitetun kappaleen jälkeen. Esimerkiksi Reijo Taipaleen jälkeen voidaan kertoa, että muut ovat kuunnelleet myös Jari Sillanpäätä. Kappaleiden tähditys välillä 0-5 tähteä. Facebook-integraatio, jonka avulla TUTify kertoo käyttäjän aikajanalla soitettuja kappaleita. Lisäksi näytetään käyttäjälle Facebook-kavereiden kuuntelemat kappaleet. Radio-tila, jossa soitetaan satunnaisessa järjestyksessä valitun artistin tyylisiä kappaleita. Hittikappaleet -näkymä, jossa näytetään käyttäjälle hänen kotimaansa soitetuimmat musiikkikappaleet. Kokeilujakso-toiminto, jonka avulla uudet käyttäjät voivat kokeilla TUTifyä 30 päivän ajan ilmaiseksi ilman mainoksia. 4 TUTifyn arkkitehtuuri TUTify-järjestelmän perusrakenne on kuvattu kuvassa 1. Järjestelmässä on erilaisia asiakassovelluksia (client) ja keskitetty palvelu (TUTify service), johon otetaan yhteys. Harjoitustyössä on tarkoitus suunnitella TUTify palvelun arkkitehtuuri ja yksi esimerkkiasiakassovellus. Loput asiakassovellukset teetetään alihankkijalla. Niinpä palvelun käyttöön liittyvät rajapinnat tulee dokumentoida sillä tarkkuudella, että alihankkija kykenee käyttämään niitä ja toteuttamaan asiakassovelluksen ilman TUTifyn arkkitehtien apua.

5 Kuva 1 Järjestelmän perusrakenne 4.1 Järjestelmän osat TUTify koostuu seuraavista osista: Käyttäjän tietojen hallinta Levy-yhtiöiltä tulevan materiaalin kääntäminen musiikkipalvelun ymmärtämään muotoon ja metadatan tulkinta Käyttäjän soittolistojen hallinta Musiikkikappaleiden tallennus Musiikkikappaleiden selaus ja halutun kappaleen etsintä eri kriteerien perusteella Erilaisten raporttien muodostaminen yhteyslokien perusteella TUTify käyttää omaa, salattua protokollaa. Kaikki yhteydet kulkevat yhden palvelun kautta, joka purkaa salauksen ja varmistaa, että asiakkaalla on oikeus haluttuun toimintoon. 4.2 Vaatimuksia Ohjelmalle on vaatimusanalyysin perusteella löydetty seuraavia vaatimuksia: - Musiikin soitto ei saa pätkiä, vaikka verkossa olisikin pientä viivettä - Radiosoitto-moodin kappaleen valinta algoritmi pitää olla helposti vaihdettavissa - Kapasiteettia on jatkossa pystyttävä nostamaan helposti (uudet kappaleet, mainokset ja videoiden striimaus) (TUTflix) - Tulevaisuudessa mahdollista integroida muuallekin kuin Facebookiin, esim. Twitter, LinkedIn tai Tutter - Käyttäjän luottokorttitiedot talletetaan palveluun, jotta ostaminen on helppoa. Nämä tiedot eivät saa missään olosuhteissa vuotaa - Jatkossa halutaan myös mahdollisuus lisätä maksutapoja, esim. PayPal, paikallisten pankkien verkkopalvelut, jne - Erilaisia asiakassovelluksia tulee jatkossa lisää

6 - Kappalesuosituksia annetaan käyttäjän historiatietojen hyödyntävän algoritmin avulla. Tämä algoritmi pitää olla vaihdettavissa - Jatkossa voitaisiin lisätä ominaisuus, että tiedostoja voidaan tallettaa paikallisesti offlinesoittoa varten. - Jatkossa mahdollisesti kuormaa halutaan jakaa toimimalla P2P-topologian mukaisesti, eli clientit saattavat striimata musiikkia toisilleen - Palvelu tulee olla aina saavutettavissa, 99,99% - Musiikin tekijänoikeuksia pitää pystyä vahtimaan. Käyttäjät eivät voi tallettaa kappaleita omalle koneelleen ilmaiseksi. - Jatkossa halutaan lisätä mahdollisuus ostaa musiikkia itselle. - Järjestelmä pitää kirjaa kaikkien kappaleiden toistokerroista ja jyvittää maksut artisteille vastaavasti. Järjestelmä lähettää maksutiedot suoraan tekijänoikeuksista vastaavalle taholle. - Järjestelmä pitää kirjaa myös käyttäjän kuuntelemista kappaleista. Jatkossa laskutus voidaan vaihtaa kuuntelukertaperustaiseksi. 5 Vaadittava dokumentaatio 5.1 Välipalautus Seuraavat asiat pitää dokumentoida välipalaukseen palautettavassa dokumentissa: Arkkitehtuuridokumentin lopullinen rakenne (sisällysluettelo) Yleinen kuvaus järjestelmästä ja sen arkkitehtuurisesti merkittävistä vaatimuksista Mahdollisia käyttöskenaarioita Muunneltavuusvaatimukset eli minkälaiseen muunteluun toteutettavan järjestelmän tulee varautua Korkean tason arkkitehtuuri. Muista käyttää eri näkymiä (4+1) ja kaaviotyyppejä. Käytetyt arkkitehtuurityylit ja suunnittelumallit 5.2 Lopullinen palautus Korjattu/päivitetty versio välipalautuksessa annetusta dokumentista, johon on täydennetty loputkin sisällysluettelonne kohdat. Tärkeää on myös kertoa, mitä muutoksia arkkitehtuuriarviointi aiheutti ryhmän järjestelmään. Esittäkää muutokset omana lukuna dokumentissanne. Lisäksi ryhmän on kerrottava raportissaan ryhmän järjestelmälle suoritetusta arkkitehtuuriarvioinnista riippuen joko ATAM-arvioinnissa löytyneiden riskien vakavuus (High= suuria ja työläitä muutoksia, Medium= aiheuttaa joitain muutoksia, Low= ei suurempia vaikutuksia ), tai DCAR-arvioinnin perusteella löytyneiden riskien aiheuttama korjaustarpeen vaikeus (esim. kuinka vaikeaa olisi vaihtaa viestinvälityskomponentti toiseen). 5.3 ATAM/DCAR ATAM/DCAR-arviointitilaisuutta varten tehty materiaali (esitykset yms.) ATAM/DCAR-raportti. 6 Alustavat arvosteluperusteet Arvostelussa kiinnitetään erityisesti huomiota seuraaviin asioihin: Järjestelmän arkkitehtuuri Arkkitehtuurityylit Suunnittelumallit Ratkaisujen perustelut Laajennettavuus ja ylläpidettävyys

7 Dokumentaation yleinen laatu Clientin rajapinnan kuvaus Harjoitustyö arvostellaan seuraavasti: Välipalautus: hyväksytty/hylätty Suunnittelu: 0-10p (sisältäen alkuperäisen suunnittelun + arkkitehtuuriarviointiin reagoinnin) ATAM/DCAR arviointitilaisuus: + / 0 / - ATAM/DCAR arviointiraportti: 0-5p. Arviointitilaisuuden arvosana vaikuttaa kokonaispistemäärään pyöristävästi. Eli esim. jos assari miettii, että olisiko arvosana 3 tai neljä niin + pyöristää arvosanan ylöspäin ja alaspäin. 7 Palauttaminen 7.1 Välipalautus Välipalautuksessa palautetaan alustava versio dokumentaatiosta yliopistokohtaisten käytäntöjen mukaisesti. Kiinnittäkää huomiota asioihin, joita haluatte kuvata dokumentissa ja dokumentin yleiseen rakenteeseen. 7.2 Lopullinen palautus Palautuspaketit nimetään seuraavan mallin mukaisesti: ohar_2013-group<ryhmän numero>-<vaihe>-tutify.pdf eli esim. ohar_2013-group1-välipalautus-tutify.pdf Ryhmänumeron saat IDLE:stä (TTY) tai assariltasi.