Ohar-ATAM pikaisesti. Ohjelmistoarkkitehtuurit 2009

Transkriptio

1 Ohar-ATAM pikaisesti Ohjelmistoarkkitehtuurit 2009

2 Aikataulu Tämä Ohar-ATAM esittely otsikkotasolla(~5min) Arkkitehtuurin esittely (~40min), arvioiva ryhmä esittää kysymyksiä Arkkitehtuurilähestymistavat, tärkeimpien arkkitehtuuripäätösten nimeäminen ja läpikäynti (arvioiva ryhmä kirjaa näitä ylös arkkitehtuurin esittelyn aikana) arkkitehtuuripäätösten läpikäynti, arvioijat esittelevät, arkkitehti hyväksyy + täydentää tarvittaessa Laatupuun rakentaminen, skenaarioiden löytäminen (~30min) (tärkeys+vaikeus) Skenaarioiden priorisointi (~10min) Lasketaan skenaariosta tärkeys+vaikeus yhteen (poimitaan järjestyksessä ja priorisoidaan tasatilanteessa vaikeutta) Skenaarioiden analysointi: tasapainopisteet, riskit, sanalliset arviot (2+h) Arvioinnin yhteenveto: arvioiva ryhmä esittää yhteenvedon löydöksistä, yksi kalvo. (5+5min) Skenaarioiden viimeistely tilaisuuden jälkeen yms. säätö. Dokumentin kirjoittaminen

3 Vaiheet 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). Skenaarioiden analysointi Otetaan tärkein analysoimaton skenaario käsittelyyn. Kysytään, mahdollistaako arkkitehtuuri tämän skenaarion? Miten ja miksi? Pyritään tunnistamaan ainakin riskit ja tasapainokohdat. (toistetaan kunnes aika loppuu/skenaariot on analysoitu)

4 Sanastoa: peruskäsitteet Skenaario (scenario): arkkitehtuurin testitapaus, tilanne tai tapahtumasarja, joka liittyy jonkin 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, 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.

5 Esimerkkejä arkkitehtuuripäätöksistä MVC: mahdollistetaan käyttöliittymän päivittäminen ja mallinkäsittelyn vaihtaminen Säikeistys: erilliset säikeet sovelluksen pollausta, puhemoottoria, käyttöliittymää varten Tarkistusten 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 Geneerinen ToolAPI: muiden sovellusten ohjaaminen voidaan toteuttaa eri kielillä kuin itse core Wräpätty puheentunnistus: Microsoftin kilut eristetty, mahdollistanee puheohjausmoottorin vaihtamisen Serveriluokat kontrollipisteenä: Ohjaus näiden pisteiden kautta rakenteesta selkeämpi, tapahtumien lähetys näiden kautta

6 Laatupuu, puumaisena laatuominaisuudet Suorituskyky tarkennukset tilausten käsittely skenaariot pystyy käsittelemään 50 pyyntöä sekunnissa (M,L) palaute nappulan painamisesta saadaan alle 0,2 sekunnissa (H,M) Laatu Muunneltavuus Saavutettavuus Vasteaika käyttöliittymän muutokset tietokannan muutokset Laitteistoviat Web-käyttöliittymään siirtyminen käyttäjien kulkuoikeuksien hallinnassa 1 kk:ssa (H,H) Tietokanta vaihdetaan MySQL-pohjaiseksi 6 kk:ssa (L,H) Ryhmäohjaimen hajoamisen jälkeen uusintakäynnistys 5 min:ssa (L,H) Tietoturvallisuus Palvelimen kaatuminen Uudelleenkäynnistys tilastointipalvelimen kaatuessa 5 min:ssa (M,M) salattu yhteys kommunikaatiossa käytetään XYZ-salausta

7 Laatupuu vähemmän puisena Skenaarioissa [Haastavuus, Tärkeys] Suorituskyky Responsiivisuus käyttäjälle [L,H]Käyttäjä puhuu järjestelmälle, vuoden 2004 pöytäkoneelle, järjestelmä reagoi alle 1s. [M,H] Konteksti vaihtuu sovellutuksessa, tähän reagoidaan alle 1s ja uusi sanasto on käytettävissä. Resurssien käyttö [L,M] 500:n luokan malli ladattuna on toimintakykyinen alle 50MB muistilla Muokattavuus Vaihdettavuus [L,H ]Microsoftin puheentunnistusohjelmisto vaihdetaan uudempaan versioon yhdessä työpäivässä. [H,M] ]Microsoftin puheentunnistusohjelmisto OSS Sphinxiin 2 viikkoa. Laajennettavuus [H,M] Lisätään toinen puheentunnistusmoottori rinnalle ja äänestys, implementointi 1kk. [M,L] Puhemakrojen ja äänityksen implementointi kuukaudessa. Joustavuus Yhteensopivuus [M,M] Useamman samankaltaisen sovellutuksen yhteiskäyttö ja copy&paste sovellusten välillä. [H,H] Pitää pystyä ohjaamaan kahta sovellusta joista toista pollataan ja toinen lähettää eventtejä. Tarkkuus Puheohjaus [M,M] Käytetään ilman kouluttamista puhemoottoria, tarkkuus >90%. [H,L] Auki kolme sovellusta, useampi aktiivisena, kontekstin perusteella osaa etsiä oikean kohteen 99,9%. Ylläpidettävyys Uudet työkaluversiot [H,M] Eri koneita ja eri versioita RSM:stä, sama mallilaturi toimii kaikissa ympäristöissä. Siirrettävyys [H,L] Vaihdetaan XP Vista, järjestelmä saadaan käännettyä kun tehdään muutoksia vain yhteen komponenttiin. Jäljitettävyys

8 Skenaariot Skenaario konkretisoi laatuvaatimuksen esimerkillä. Tapahtumasarja, joka liittyy jonkin 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. Voit käyttää myös tarkempaa arkkitehtuuripäätöskohtaista kuvausta ja huomioida turvalliset ratkaisut ja herkkyyspisteet. Erilaisia skenaariotyyppejä: Käyttötapausskenaariot: käyttäjä on vuorovaikutuksessa järjestelmän kanssa Järjestelmän käyttäjä pyytää käyttöasteraportin tietokannasta samalla kun järjestelmässä on käyttöhuippu. Kasvuskenaariot: ennakoituja/odotettavissa olevia muutoksia ja tarpeita tutkivaskenaario : odottamattomat muutokset järjestelmässä/järjestelmään, odottamattomat tilanteen järjestelmän käytön aikana

9 Esimerkki arvioidusta skenaariosta Skenaario #: 3 Skenaario: Microsoftin puheentunnistusmoottori halutaan vaihtaa Open Source sovellukseen (Sphinx) Laatuominaisuus: Muokattavuus Ympäristö: Normaali toiminta Ärsyke: Open source villitys iskee Vaste: onnistuu kahdessa viikossa Arkkitehtuuripäätös: kapselointi wräpätty puheentunnistus Sanaston generointitapa MVC Säikeistys Tasapainopiste T3 T4 Riski R4 R5 R6 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. Jos Sphinxin tunnistusmoottori ja sen antamat ilmoitukset poikkeavat paljon MS:n vastaavista, säikeistykseen saattaa tulla muutoksia. Sanasto generoidaan valmiiksi ja valmista sanastoa aktivoidaan ja deaktivoidaan tarpeen mukaan. Tämä tarkoittaa sitä, että uudelle puhemoottorille joutunee tekemään oman sanastongenerointimokkulansa. Kahden viikon aikataulu on erittäin optimistinen, vaikka vaihtaminen on huomioitu arkkitehtuurissa on työmäärä suuri.