Etukäteistehtävää

Transkriptio

1 ATAM-ohjeistusta

2 Etukäteistehtävää Valmistautukaa huolella, tutustukaa materiaaliin etukäteen. Miettikää kysymyksiä arkkitehtuurista. Valitkaa roolit, arvioijaporukassa kirjuriksi kaveri, joka keskittyy muistiinpanojen tekemiseen ja osaa keskeyttää tarvittaessa keskustelijat, jotta asiat tulee oikeasti kirjattua Tutustukaa dokumenttipohjiin jne. Miettikää miten/millä aiotte kirjata kunkin työvaiheen asiat Arvioitava porukka, kuka esittelee mitäkin/vastaa mistäkin? Pääarkkitehti, bisnespuolen asiat, palvelinpuoli/asiakaspäätteet, Miettikää aikataulu (älkää pelkästään kopioiko esimerkkiä)

3 Tapahtumassa toiminta Iloinen avoin mieli Läppärit kiinni, jos ei liity omaan tehtävään (esim. kirjuri). Facebookin, Iltalehden jne. ihmeelliseen maailmaan pääsee tapahtuman jälkeenkin Puhelin kiinni Jokainen puhuu vuorollaan Ei rinnakkaisia sivukeskusteluja, pysytään asiassa, edetään tehtävissä (päästään ajoissa pois)

4 Esimerkkiaikataulu (4h) klo 1. "ATAM -esitys" 13:00 2. Business-esitys 13:10 3. Arkkitehtuuriesitys 13:25 4. Ratkaisujen tunnistaminen 13:45 Kahvitauko 14:00 5. Laatupuu ja skenaariot 14:15 6. Priorisointi 14:55 7. Analysointi 15:00 jaloittelutauko 15:55 Analysointi jatkuu 16:00 8. Keskustelu / Yhteenveto 16:50

5 Vaiheista tarkemmin Arkkitehtuurilähestymistavat, arkkitehtuuriratkaisujen löytäminen Mitkä ovat järjestelmän tärkeimmät arkkitehtuuripäätökset, tyylit, suunnittelumallit ja yleiset ratkaisut? Miten em. ratkaisut tukevat järjestelmälle asetettuja tärkeimpiä laatuvaatimuksia? Laatupuun rakentaminen Tarkennetaan laatuvaatimukset järjestelmäkohtaisella ryhmittelyllä. Konkretisoidaan tarkennettu laatuvaatimus skenaariolla. Skenaarioiden priorisointi Skenaarioille annetaan sekä haastavuus että tärkeys, tämän jälkeen skenaariot järjestetään tärkeyden ja vaikeuden perusteella (ensisijaisesti tärkeyden, sitten haastavuuden mukaan). Tai priorisoidaan skenaariot jollakin muulla järkevällä tavalla (potentiaalisesti mielenkiintoisimmat, eniten keskustelua herättävät ) Skenaarioiden analysointi Otetaan tärkein analysoimaton skenaario käsittelyyn. Kysytään, mahdollistaako arkkitehtuuri tämän skenaarion? Miten ja miksi? Mitkä asiat arkkitehtuurissa liittyvät kyseiseen skenaarioon? Pyritään tunnistamaan ainakin riskit ja tasapainokohdat. (toistetaan kunnes aika loppuu/skenaariot on analysoitu/kaikki ovat puuduksissa)

6 Esimerkkejä arkkitehtuuripäätöksistä MVC: mahdollistetaan käyttöliittymän päivittäminen ja mallinkäsittelyn vaihtaminen Säikeistys: erilliset säikeet kontrolloitavaa sovelluksen pollausta, puhemoottoria, käyttöliittymää varten Kielen ajoaikainen kontekstipohjainen karsinta: tehdään komentojen tarkastuksia vain niille osille joille tarpeellista Jonotus: yksi puhekomento kerrallaan käsittelyssä, muut jonoon Plugin-arkkitehtuuri: Ohjelmaan saadaan liitettyä helposti uusia ohjattavia sovelluksia, toteutusrajapinta & Vokottimen tarjoama rajapinta Geneerinen ToolAPI: muiden sovellusten ohjaaminen voidaan toteuttaa eri kielillä kuin itse core Wräpätty puheentunnistus: Microsoftin kilut eristetty, sisäisesti käytössä omat tietotyypit Serveriluokat kontrollipisteenä: kontrollin ohjaus, komentojen siirto käsittelijöille näiden pisteiden kautta Puheentunnistuksen seuranta tapahtumia kuuntelemalla: erillinen kuuntelija, joka muuttaa puheentunnistukselta saatuja tapahtumia sisäisten komentojen muotoon Puheen käsittely sisäisesti kokonaisina komentoina: puheentunnistukselta järjestelmään otetaan vain kokonaan tunnistettuja laillisia (ja kontekstin mukaisia) komentoja

7 Laatupuu puumaisena Tilausten käsittely Järjestelmä pystyy käsittelemään 100 tilausta 5 sekunnin aikana, vasteaika jokaisella maksimissaan 0,5s suorituskyky hakukuormitus Järjestelmässä tehdään 5000 tuotehakua 3 sekunnin aikana, jokaiseen vastataan sekunnin kuluessa. laatu muunneltavuus Käyttöliittymän muutokset Weppikäyttöliittymän rinnalle toteutetaan dedikoitu Android käyttöliittymä yhdessä henkilötyökuukaudessa. Tietokannan päivittäminen Siirrytään käyttämään MySQLtietokantaa omalla tietokantapalvelimella. Toteutus yhden henkilötyökuukauden aikana. luotettavuus Turvallisuus Saavutettavuus Käyttäjätietojen varmentaminen Tietojen salaus Pääjärjestelmän vikaantuessa varajärjestelmä on käytössä maksimissaan 10 sekunnin viiveellä. Tietoja ei ole kadotettu

8 Vähemmän puumainen laatupuu

9 Skenaariot Skenaario (scenario): arkkitehtuurin testitapaus, tilanne tai tapahtumasarja, joka liittyy johonkin laatuvaatimukseen. Laatupuu (utility tree): kohdejärjestelmän laatuvaatimusten asteittainen tarkennus skenaarioiksi Herkkyyspiste (sensitivity point):muutokset tämän arkkitehtuuripäätöksen suhteen voivat aiheuttaa merkittäviä muutoksia johonkin laatuominaisuuteen Tasapainopiste (tradeoff): Arkkitehtuuripäätös, joka vaikuttaa useampaan laatuominaisuuteen (eri suuntiin), moninkertainen herkkyyspiste. Riski (risk): Arkkitehtuuripäätös, joka saattaa aiheuttaa ongelmia tulevaisuudessa jonkun laatuattribuutin näkökulmasta. Turvallinen ratkaisu/ei-riski (no-risk): Arkkitehtuuripäätös, joka voi edesauttaa laatuominaisuuden toteutumisessa / jolla on tiedossa vain hyviä laatuseuraamuksia.

10 Skenaarioista lisää Skenaario konkretisoi laatuvaatimuksen esimerkillä. Tapahtuma sarja, joka liittyy johonkin laatuvaatimukseen. Skenaarion on oltava riittävän on täsmällinen (jotta arkkitehtuuria voidaan arvioida sitä vasten) Kirjaa skenaarioista ainakin tasapainopisteet ja riskit sekä anna koko skenaarion tarkempi selitys. Käytä myös tarkempaa arkkitehtuuripäätöskohtaista kuvausta ja huomioi mahdolliset turvalliset ratkaisut ja herkkyyspisteet. Erilaisia skenaariotyyppejä: Käyttötapausskenaariot: käyttäjä on vuorovaikutuksessa järjestelmän kanssa Kasvuskenaariot: ennakoituja/odotettavissa olevia muutoksia ja tarpeita tutkiva skenaario : odottamattomat muutokset järjestelmässä/järjestelmään, odottamattomat tilanteen järjestelmän käytön aikana

11 Skenaarion rakenneesimerkki Skenaarion rakenne: Ärsyke - Ympäristö Vaste Käyttötapausskenaario: Etäkäyttäjä hakee tietokantaraportin web-käyttöliittymästä suurimman kuormahuipun aikana ja saa sen 5s kuluessa. Kasvuskenaario: Järjestelmään lisätään uusi datapalvelin latenssin vähentämiseksi 2,5s, työ tehdään 1 henkilötyöviikossa. Tutkiva skenaario: Puolet palvelimista kaatuu normaalissa käyttötilanteessa, tämä ei vaikuta järjestelmän saavutettavuuteen

12 Esimerkkiskenaario Skenaario #: 3 Skenaario: Microsoftin puheentunnistusmoottori halutaan vaihtaa Open Source sovellukseen (Sphinx) Laatuominaisuus: Muokattavuus Ympäristö: jatkokehitys Ärsyke: Halutaan lisätä rinnakkainen tai korvaava ilmainen puheentunnistusmoottori Vaste: onnistuu kahdessa henkilötyöviikossa Arkkitehtuuripäätös tasapainopiste herkkyyskohta Riski/ ei-riski Kapselointi wräpätty puheentunnistus T3 R4 Sanaston generointi kerralla R5 MVC - Säikeistys T4 R6 Puheentunnistuksen tapahtumakuuntelija R

13 jatkuu Koko skenaarion selitys: Kapseloinnin ansiosta puheentunnistusmoottori on omien rajapintojensa takana ja muualla sovelluksessa käytetään vain sovelluksen omia puheentunnistukseen liittyviä tietotyyppejä. Uuden moottorin käyttöä varten pitää luoda wräppäys/konversiot Vokottimen ja puhemoottorin tietotyyppien välille. Puheentunnistuksen tapahtumakuuntelija pitää toteuttaa Sphinxille. Jos Sphinxin tunnistusmoottorin antamat ilmoitukset poikkeavat paljon MS:n vastaavista, tapahtumankäsittely ei välttämättä toimi samalla tavalla ja myös säikeistykseen saattaa tulla muutoksia. Sanasto generoidaan valmiiksi ja valmista sanastoa poistetaan käytöstä ja otetaan käyttöön tarpeen mukaan. Tämä tarkoittaa sitä, että uudelle puhemoottorille joutuu (joutunee) tekemään oman sanastongenerointimokkulansa. Kahden viikon aikataulu on erittäin optimistinen, vaikka vaihtaminen on huomioitu arkkitehtuurissa, on työmäärä erittäin suuri varattuun aikaan nähden. Ratkaisujen analysointi: kapselointi wräpätty puheentunnistus: Kapselointi eristää puheentunnistusmoottorin muusta järjestelmästä, mutta toisaalta hidastaa suoritusta [T3]. Uusi moottori voi poiketa paljon nykyisestä moottorista, jolloin tarvitaan muutoksia myös säikeistykseen [R4]. Sanaston generointitapa: Sanaston eri osia otetaan käyttöön ja poistetaan käytöstä eri osien tunnisteiden avulla. Jos lause- ja sääntökohtaista aktivointia ja käytöstä poistoa ei ole käytössä, joudutaan koko ohjelman rakenteeseen tekemään muutoksia (tai tyytymään siihen, että koko sanasto on jatkuvasti käytössä kontekstista riippumatta). [R5] Mallin pohjalta tuotettavan sanaston toteutuksessa voinee hyödyntää osin MS:n puheentunnistussanaston tuottotapaa, sillä malli käydään läpi samaan tapaan. Puheentunnistuksen tapahtumankuuntelija: Puheentunnistusmoottorilta kuunnellaan hyväksyttyjä tunnistettuja tapahtumia ja nämä lähetetään eteenpäin tunnistettu komento viesteinä. (myös sanakohtaisesta tunnistusta ja hylättyjen komentojen ja vaihtoehtoisten komentojen tapahtumia voidaan kuunnella). Jos uuden moottorin puheentunnistustapahtumat poikkeavat paljon nykyisestä, voi tapahtumien kuunteluun perustuva lähestyminen olla mahdotonta (toteutettava esimerkiksi oma erillinen pollaukseen perustuva komentojen koostaja). Jos käyttöliittymään haluttaisiin mahdollisuus valita käytössä oleva puheentunnistusmoottori, pitäisi myös tänne tehdä muutoksia ja välittää valintatiedot muihin ohjelman osiin. (viestinvälitys, viestien käsittelijät)