1 / 37

Pakkanen * * * S ovellustuotannon menetelmäpilotti

Pakkanen * * * S ovellustuotannon menetelmäpilotti. Komponenttien ja sovellusarkkitehtuurin määrittely. PlugIT-seminaari D-työpaja __________________________________________________________ Annamari Riekkinen ja Kirsi Karvinen PlugIT

noreen
Download Presentation

Pakkanen * * * S ovellustuotannon menetelmäpilotti

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Pakkanen* * * Sovellustuotannon menetelmäpilotti Komponenttien ja sovellusarkkitehtuurin määrittely PlugIT-seminaari D-työpaja __________________________________________________________ Annamari Riekkinen ja Kirsi Karvinen PlugIT Kuopion yliopisto / Tietotekniikkakeskus /HIS-tutkimusyksikkö

  2. Esityksen sisältö • Komponenttimäärittelyn rooli koko prosessissa • Menetelmän esittely: käsitteitä ja prosessi • Menetelmän läpikäynti: komponenttien tunnistus • Menetelmän läpikäynti: komponenttien vuorovaikutus • Menetelmän läpikäynti: komponenttien määrittely • Miten onnistuttiin • Miten tästä eteenpäin – yleisesti ja tästä hetkestä

  3. Komponentti- ja arkkitehtuuri-määrittely sovellusprosessissa • Toimintaa tukeva vaatimusmäärittely • Vaatimukset konkretisoituvat käyttöliittymätasolla (näyttökuvat) • Määrittelyssä vaatimukset siirretään sovellukseen. • Huolellinen määrittely: • suoraviivaistaa toteutusta • helpottaa ylläpitoa • parantaa käytettävyyttä

  4. Vaikutteet menetelmän valintaan • Ohjelmistotuotannon kaikki vaiheet ja näkökulmat perustuvat komponentteihin: Komponentti- ja palvelulähestymistavan näkökulma: sovellus määritellään joukkona komponentteja, jotka tarjoavat käyttäjilleen palveluja rajapintojensa (eli liittymiensä) kautta.  komponenttien ja sovelluksen palvelupohjaista arkkitehtuuria tukeva määrittelymenetelmä. • Helposti opittavissa oleva ja käyttöönotettava menetelmä. Tavoite: • Miten menetelmän avulla saadaan kehitysprosessia tukevat tuotokset: arkkitehtuurimäärittely, komponenttimäärittelyt ja rajapintamäärittelyt.

  5. Menetelmän esittely: käsitteitä Arkkitehtuuri koostuu komponenteista. Komponentti toteuttaa rajapinnan(t). Rajapinta koostuu operaatioista. Operaatioista muodostuu toiminnallisuus.

  6. Menetelmän esittely: prosessi Käsitemalli Rajapintamäärittelyt Käyttötapauskuvaus Komponentit ja arkkitehtuuri

  7. Komponenttien ja arkkitehtuurin määrittely Prosessin periaate: • Komponenttien tunnistus: rakenteellinen perusta • komponenttiarkkitehtuuri • komponentit ja rajapinnat • liittymät muihin järjestelmiin ja ympäristöön • Komponenttien vuorovaikutuksen määrittely: toiminnallisuus ja tiedot (logiikka) • rajapintojen operaatiot • määrittelyjen tarkennukset • Komponenttien määrittely: dokumentointi • komponenttiarkkitehtuurin viimeistely • komponentti- ja rajapintamäärittelyiden viimeistely

  8. 1. Komponenttien tunnistusvaihe ICreateUser

  9. Komponenttien tunnistusvaihe Miten käsitemallista ja käyttötapauskuvauksesta johdetaan alustavat rajapintamäärittelyt ja sovellusarkkitehtuuri? Toimintalogiikkarajapintojen tunnistus: • Luo käsitemallin pohjalta tietomalli: Kopioi käsitemalli ja siitä määrittele sen avulla tiedot, jotka sisältyvät tulevaan sovellukseen. Esim. • - Henkilö: sovellukseen ei tallenneta henkilön tietoja, ainoastaan viittaus henkilösovelluksen henkilöön. • - Asiakas: nimetään Käyttäjäksi • - Käyttäjätunnus: Käyttäjän ominaisuus (lisätään Käyttäjä-luokkaan attribuutiksi) • - Palvelinkone ja käyttäjäryhmä: tiedot ylläpidetään sovelluksessa • - Muuta: normalisointi, toiminnan rajoitukset ja säännöt

  10. Komponenttien tunnistusvaihe Käsitemallista  Tietomalli

  11. Komponenttien tunnistusvaihe Toimintalogiikkarajapintojen tunnistus: • Tietomallista johdetaan toimintalogiikkarajapintojen vastuukaavio s.e. sovellukseen sisältyvät käsitteet erotellaan • ydinkäsitteiksi (core type): käyttäjä, palvelinkone, käyttäjäryhmä • käsitteiksi (type), jotka täydentävät ydinkäsitteitä. Ydinkäsitteille nimetään toimintalogiikkarajapinnat. Muiden käsitteiden osalta päätetään, minka rajapinnan kautta niihin liittyvä tieto tallennetaan ja haetaan. Määritellään vastuu eri rajapintoihin sisältyvien käsitteiden välisen viitteen tallentamisesta.

  12. Komponenttien tunnistusvaihe Tietomallista  Vastuukaavio

  13. Komponenttien tunnistusvaihe Järjestelmärajapintojen tunnistus (Cheesman): • Nimetään kukin käyttötapauskuvaus omaksi rajapinnakseen. Käyttötapauksittain käydään läpi kuvausten askelet ja arvioidaan samalla liittyykö niihin toiminnallisuutta, joka on sovelluksen vastuulla  alustavat operaatiomäärittelyt (tarkoitus kuvattuna).

  14. Komponenttien tunnistusvaihe Järjestelmärajapintojen tunnistus (Pakkanen): • Nimeä kukin käyttötapauskuvaus omaksi rajapinnakseen. Käy käyttötapauksittain läpi sovelluksen näyttökuvat ja arvioi samalla liittyykö niihin toiminnallisuutta, joka on sovelluksen vastuulla  alustavat operaatiomäärittelyt (tarkoitus kuvattuna). Lisäksi näyttökuvissa voi olla mukana käyttötapauksessa tarvittavaa tietoa (tietosisältö), joten operaatioiden parametreja voidaan myös lisätä kuvauksiin. Esimerkki käyttöliittymä paperiprotona if (käyttäjätunnus =””) then getPersonUserDetails(in pid, out PersonDetails, outUserDetails); generateUsername(in name:string);

  15. Hakuoperaation palauttamaa: sukunimi, etunimi, henkilötunnus, käyttäjätunnus (jos on) if else operaatioita

  16. Komponenttien tunnistusvaihe Komponenttimäärittelyiden ja arkkitehtuurin luonti • Järjestelmäkomponentit: esimerkkitapauksessa yksi komponenttimäärittely käyttötapaukselle ”Luo käyttäjätunnus” (huomioi, että yksi komponenttimäärittely voi sisältää useita rajapintoja). Toimintalogiikkakomponentit: jokaiselle toimintalogiikkarajapinnalle luodaan oma komponenttimäärittely.

  17. Komponenttien tunnistusvaihe Komponenttimäärittelyiden ja arkkitehtuurin luonti Komponenttimäärittelyt kootaan arkkitehtuuriksi miettimällä miten ne kommunikoivat keskenään.

  18. 2. Komponenttien vuorovaikutus

  19. Komponenttien vuorovaikutus Miten alustavat määrittelyt täsmentyvät prosessin aikana. Toimintalogiikkatason rajapintaoperaatioiden tunnistus: • Luodaan rajapinta- ja komponenttimäärittelyt sekvenssikaavioon. • Käydään läpi kukin järjestelmärajapinnan tunnistettu operaatio yksi kerrallaan ja mietitään, miten vastuu tietojen käsittelystä jakautuu operaatioiksi toimintalogiikkatasolla. • Esimerkkinä operaatiokuvaus findUser(): Operaation tarkoitus on tarjota järjestelmän käyttäjälle lista henkilöistä, joista käyttäjä voi valita. Sen sijaan, että operaatio näyttäisi kaikki järjestelmään tallennetut henkilöt, käyttäjän on annettava hakuarvona merkkijono, joka ainakin osittain vastaa henkilön nimeä tai syntymäaikaa. Järjestelmä palauttaa vain niiden henkilöiden tiedot, jotka sopivat annettuun hakuarvoon.

  20. Komponenttien vuorovaikutus Rajapintojen ja operaatioiden muokkaus: Edellisessä vaiheessa siis riittää, että tunnistetaan (eli nimetään) toimintalogiikkatason rajapintaoperaatiot, mutta jos järjestelmätason operaatioihin on määritelty parametrit, myös ne kannattaa lisätä samalla kertaa tai sitten se tehdään seuraavaksi: ”Käyttäjän on annettava hakuarvona merkkijono, joka ainakin osittain vastaa henkilön nimeä tai syntymäaikaa”. • findPersonUserByPersonData (in match:string) ”Järjestelmä palauttaa vain niiden henkilöiden tiedot, jotka sopivat annettuun hakuarvoon”. • findPersonUserByPersonData (in match:string) :PersonUser[] (lähde: olemassa oleva järjestelmä, vastuukaavio, mutu (tuntuma), käyttöliittymäprotot ym.)

  21. Komponenttien vuorovaikutus Rajapintojen ja operaatioiden muokkaus: Henkilö- ja käyttäjätiedot eri järjestelmissä, joten on mietittävä, miten tietojen haku jakautuu toimintalogiikkarajapinnoille: Henkilötietojen haku henkilötiedoista hakuparametrin perusteella ja osajoukon palautus tuntuu loogiselta vaihtoehdolta: • findPersonsByPersonData(in match:String) :PersonDetails[] Käyttäjätiedoista haetaan ed. operaatiossa palautetuille henkilöille käyttäjätunnukset:  findPersonUsersByPid(in personID[]): UserDetails[] Tietojen yhdistys järjestelmäkomponentissa ja palautus dialogitasolle.

  22. Komponenttien vuorovaikutus

  23. Komponenttien vuorovaikutus:Inkrementaalinen suunnittelu Inkrementaalinen suunnittelu: tavallisesti uusien operaatioiden ja käyttötapausten myötä vaatimukset operaatioiden parametreille muuttuvat (esitellään uusia parametreja, rakenteisten tietotyyppien tietosisällöt lisääntyvät jne.). On päätettävä tehdäänkö yleisiä, kaikille yhteisiä operaatio- ja tietotyyppimäärityksiä vai tehdäänkö samoihin tietoihin erilaisia näkymiä operaatioiden ja tietotyyppien avulla: Esimerkkinä operaatiot: findPersonUserByLastname(in lNamematch) findPersonUserByBirthDate(in bDatematch) findPersonUserByPersonalData(in lNamematch, in bDatematch) findPersonUser(in lNamematch, in bDatematch, in userName)

  24. Komponenttien vuorovaikutus:Inkrementaalinen suunnittelu Esimerkkinä tietotyypit: findPersonUsersByPid(in personID[]): UserDetails[] getPersonUserDetails(in personID): UserDetails Pakkasessa: vain pieniä eroja  kaikille yhteiset Vuorovaikutusta tutkimalla löydetään operaatioita ja niiden vastuita tietojen käsittelyssä. Muita suunnittelunäkökulmia ovat esimerkiksi kutsujen minimointi, sykliset riippuvuudet, operaatioiden ja rajapintojen normalisointi tai olemassa olevien suunnittelumallien käyttö. Hyvä suunnitteluperiaate on se, että pyritään tekemään yksi asia kerrallaan.

  25. Luo käyttäjätunnus ICreateUser ICloseUsername <<comp spec>> UsernameManagementSystem Sulje käyttäjätunnus Komponenttien vuorovaikutus:Operaatioiden normalisointi Määrittelyiden muokkaus: Mitä enemmän operaatioita käsitellään, sitä enemmän voidaan tunnistaa yleisiä, eri toiminnoissa tarvittavia yhteisiä operaatioita, jotka voidaan sijoittaa rajapintoihin eri tavoin. Esim: findPersonUserByPersonData (in match:string):PersonUser[] 1. Uusi toiminnallisuus  uusi rajapinta, jossa operaatio on myös mukana: ei normalisointia

  26. <<comp spec>> UsernameManagementSystem IFindUser ICreateUser ICloseUsername Komponenttien vuorovaikutus:Operaatioiden normalisointi 2. Uusi toiminnallisuus  yhteinen operaatio määritellään omaan rajapintaansa: Luo käyttäjätunnus Sulje käyttäjätunnus findPersonUserByPersonData (in match:string):PersonUser[]

  27. Luo käyttäjätunnus Sulje käyttäjätunnus <<comp spec>> UsernameManagementSystem IFindUser IGetUserData ISetUserData Komponenttien vuorovaikutus:Operaatioiden normalisointi 3. Uusi toiminnallisuus  operaatiot ryhmitellään rajapinnoiksi esimerkiksi käyttöoikeuksien perusteella:

  28. 3. Komponenttien määrittely

  29. Komponenttien määrittely Rajapintojen dokumentointi: Rajapintatietomallien luonti ja rajapintamääritysten kokoaminen. Toimintalogiikkarajapintojen vastuukaavio kopioidaan jokaiselle rajapinnalle erikseen. Vastuukaavio sisältää valmiiksi kaikki järjestelmään kuuluvat tietotyypit, joten kunkin rajapinnan tietomalli tulee sisältämään ainakin osajoukon vastuukaavion tietotyypeistä. Kunkin rajapinnan osalta käydään läpi operaatiomäärittelyihin sisältyvät rakenteiset ja ei-rakenteiset tietotyypit ja muokataan niiden perusteella tietomallin tietotyyppien attribuutteja – lähinnä poistetaan tarpeettomat attribuutit. Tietomalli laajennetaan rajapintamäärittelyksi siten, että kuvauksen rajapintaan lisätään tunnistetut operaatiot ja operaatiosijoitukset (parametrit ja paluuarvot) sekä operaatioiden rakenteiset tietotyypit.

  30. Komponenttien määrittely Esimerkki: ICreateUser-järjestelmärajapinta Vastuukaavio 

  31. Datatypes Komponenttien määrittely ICreateUser-rajapintaoperaatioiden tietotyypit:

  32. Komponenttien määrittely Operaatioiden esi- ja jälkiehtojen määrittely Esi- ja jälkiehtojen avulla määritellään operaation käyttäytyminen ja operaatiosuorituksen mahdollisesti aiheuttama tilamuutos. Esiehto: ehto, jonka on oltava voimassa ennen kuin operaatiota voidaan suorittaa, esim. hakuparametri ”match” ei saa olla tyhjä ( muutoin virheilmoitus). Jälkiehto: komponentin tila tai muu ehto, joka on voimassa kun operaatio on suoritettu (mikäli esiehto on ollut tosi). Alku- ja loppuehtojen määrittely voidaan siirtää toteuksen yhteyteen.

  33. Komponenttien määrittely Rajapintojen välisten rajoitusten määrittely Toiminta asettaa sovellukselle sääntöjä ja rajoituksia. Kuvataan esimerkiksi • käsitteiden välisten yhteyksien lukumääräsuhteena (multiplicity) • attribuutteina Kaikkea ei voida kuvata graafisesti, vaan osa esitetään kuvauksissa invariantteina eli ehtoina, jotka ovat aina voimassa. Rajoitusten määrittelyssä tärkeä on miettiä sijoitus. Esimerkkinä ehto ”Henkilön tiedot täytyy olla henkilötietojärjestelmässä ennen kuin tunnusta voidaan luoda”. Jos sääntö sijoitetaan toimintalogiikkatasolle, se on voimassa kaikissa järjestelmissä, jotka käyttävät tätä henkilörajapintaa. Sen sijaan jos sääntö sijoitetaan järjestelmätasolle, rajoitus on voimassa vain tuotettavassa sovelluksessa.

  34. Komponenttien määrittely Teknisen suunnittelun näkökulmia: • Parametrien välitys (tyyppi, laatu (in,out,inout,return) ja viittaussäännöt) • Virheiden- ja poikkeustenkäsittelymekanismit (filosofia) • Rajapintojen periytyvyys ja rajapintatuki • Rajapintojen ominaisuudet (properties) • Ilmentyminen (olioiden, objects) luontimekanismit • Tapahtumien aiheuttaminen/aikaansaaminen • Toimitettavan komponentin rakeisuus  tehdään toteutuksen suunnittelun yhteydessä.

  35. Komponenttien määrittely Määrittelyjen kokoaminen komponenttien ja sovellusten toteuttajille Komponenttiarkkitehtuurikuvaus: toteuttaja tunnistaa tarvittavat komponentit sekä niiden väliset suhteet ja riippuvuudet. Sekvenssikaavio(t): vuorovaikutus, toteuttaja tietää, mitä komponentin on tehtävä kun se vastaanottaa operaatiokutsun. Rajapintamäärittely(t): 1. operaatiomäärittely (operaatiot parametreineen ja paluuarvoineen, esi- ja jälkiehdot, invariantit): operaatioiden käyttäytyminen ja vastuut tietojen välityksessä. 2. tietomalli: rajapinnan vastuut tietojen tallennuksessa ja hakemisessa. 3. rakenteiset tietotyypit: operaatioissa välitettävä tieto.

  36. Menetelmän arviointia Menetelmän sudenkuoppa: suunnitellaan liian tarkasti paperilla  kannattaa muistaa: Määrittelyvaiheen tulokset ovat vasta määrittelyjä, joita joudutaan todennäköisesti tarkentamaan vielä seuraavassa vaiheessa, kun suunnittelun tulokset sijoitetaan toteutusarkkitehtuuriin ja toteutustekniikoihin ja sitä kautta siirrytään varsinaiseen toteutukseen. Suhteellisen helposti käyttöönotettavissa ja etenee suoraviivaisesti: • käsitemallin pohjalta alustava arkkitehtuuri sekä toimintalogiikarajapinnat • käyttötapausten pohjalta järjestelmärajapinnat ja vuorovaikutuksen määrittely • Rakenne ja toiminnallisuus Rajapintojen välisen vuorovaikutuksen määrittelyyn kehittämisideoita: apuna käyttöliittymäkuvaus, kuvautapana UML-sekvenssikaavio  suoraviivaistaa työvaihetta.

  37. Miten jatketaan Kevään aikana: • Menetelmän analysointi suhteessa koko sovelluskehitysprosessiin: tehtävien keskinäisten suhteiden sijoittuminen, esimerkiksi: • testaus • tietokantasuunnittelu • käyttöliittymäsuunnittelu ja toteutus. • Menetelmäkuvaus: ”keittokirjaresepti” menetelmän soveltamisesta sovelluskehitysprojektissa. Seuraavaksi: • Suunnitelmien sijoitus toteutustekniikoihin ja tekniset ratkaisut demon avulla. Kiitos!

More Related