Ohjelmistojen mallintaminen Ohjelmistoarkkitehtuuri 25.11.2008 Harri Laine 1
Buschmann et al: Software architecture is a description of the subsystems and components of a software system and relations between them. UML: Architecture is the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems 25.11.2008 Harri Laine 2
Clements : Ohjelmistoarkkitehtuuri Software architecture is loosely defined as the organizational structure of a software system including components, connections, constraints, and rationale. Components can be small pieces of code, such as modules, or larger chunks, such a stand-alone programs like database management systems. Connections in an architecture are abstractions for how components interact in a system, e.g., procedure calls, pipes, and remote procedure calls. An architecture has various constraints and rationales associated with it, including the constraints on component selection and the rationale for choosing a specific component in a given situation. Koskimies: Ohjelmistoarkkitehtuuri on ohjelmiston keskeisten osien ja niiden välisten suhteiden kuvaus korkealla abstraktiotasolla 25.11.2008 Harri Laine 3
Kruchten on määritellyt ns. 4+1 näkemyksen (4+1 views) mallin rinnakkaisista arkkitehtuurikuvauksista: Logical view Development view Scenarios Process view Physical view Kruchten P.,B.: The 4+1 View Model of Architecture, IEEE Software, Nov 1995, pp 42-50. (http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=00469759) [laitokselta] 25.11.2008 Harri Laine 4
Logical view (looginen rakenne, sisältömalli) järjestelmän loogiset rakenneosat (esim. luokat ja niiden väliset yhteydet, staattiset rakenteet) Kuvausvälineet: luokkakaavio, oliokaavio, yhteistyökaaviot, tiedonkulku miten saadaan parhaiten välitettyä kuva sisällöstä kokonaisuutena? Process view (toiminnan organisointi) kontrollin kulku, prossessit, taskit, rinnakkaisuus voidaan suhteuttaa sisältömalliin osajärjestelminä samasta osajärjestelmästä (prosessirakenteesta) voi olla useita instansseja (prosesseja) osajärjestelmien kytkennät ja yhteistyö voidaan kuvata esim. Luokka-, olio-, komponentti-, asennus- ja yhteistyökaavioilla 25.11.2008 Harri Laine 5
Development view (ohjelmarakenne, toteutusnäkökulma) paketointi, jako tiedostoihin ohjelmistotekninen rakenne Minkälaisiksi kokonaisuuksiksi ohjelmisto pilkotaan? kirjastot komponentit kehykset kokoamiseen pakkaukset ja alijärjestelmät osien yhteenliittyminen voidaan kuvata luokka- ja oliokaavioilla tai moduulirakenteena, pakkauskaaviot 25.11.2008 Harri Laine 6
Physical view (laitteistosijoittelu, hajautus) ohjelmiston sijoittelu verkkoon, laitteistoon Ohjelmiston ja prosessien sijoittelu UML:ssä erillinen kaavio -riittävyys? Sijoiteltavia: prosessit - prosessisijoittelu ohjelmat - ohjelmasijoittelu esim. WWW-sovelluksissa komponentti (esim java-appletti) voi olla sijoitettu palvelimelle, mutta ajetaan työasemassa Scenarios (skenaariot, käyttönäkökulma) Tyypillisen käytön esimerkkitapauksia kytkennät erityisesti sisältömalliin ja prosessimalliin yhteistyökaaviot keskeisiä 25.11.2008 Harri Laine 7
Näkymät tarkastelevat arkkitehtuuria kukin omasta näkökulmastaan Mikään näkökulma ja kuvaus ei yksinään riitä arkkitehtuurin kuvaamiseen 25.11.2008 Harri Laine 8
Keskeisessä asemassa ohjelmistoarkkitehtuuria määriteltäessä on ohjelmiston jako osiin auttaa hallitsemaan kokonaisuutta mahdollistaa valmiiden osien hyväksikäytön mahdollistaa hajautuksen helpottaa ratkaisun ymmärtämistä mahdollistaa työnjaon toteutuksessa 25.11.2008 Harri Laine 9
Ohjelmiston jako osiin on tyypillisesti hierarkkista (monitasoista) Jakamisessa ei ole yksikäsitteistä "parasta" ratkaisua Jako perustuu johonkin näkökulmaan, jonka mukaan tietyt palvelut ja tiedot kuuluvat samaan kokonaisuuteen, näkökulma ja jakokriteeri voivat vaihtua tasoittain 25.11.2008 Harri Laine 10
Kriteerejä esimerkiksi Yhteiset käyttötapaukset samaan osaan, yhteenkuulumattomat erilleen Yhteiset käyttäjät yhteen Eri käyttäjäryhmät erilleen Yhteinen tietosisältö/toiminnan kohde samaan osajärjestelmään Yhteinen toimintaympäristö tai tekniikka Sama-/eriaikaisuus Yhteinen palvelukokonaisuus Sovittaminen arkkitehtuuritason ratkaisumalliin 25.11.2008 Harri Laine 11
Pakkaukset UML:n tapa kuvata asioiden ryhmittelyä kokonaisuuksiksi Pakkaus voi sisältää muita pakkauksia Pakkauksia voidaan käyttää kokoamaan käyttötapauksia, luokkia, aktiviteetteja Nimi pakkaussymboli 25.11.2008 Harri Laine 12
Pakkausnotaatioita 25.11.2008 Harri Laine 13
Pakkauksen sisältö Pakkaus omistaa sisältönsä 25.11.2008 Harri Laine 14
Vaihtoehtoinen tapa pakkauksen sisällön kuvaamiseen 25.11.2008 Harri Laine 15
Osiinjaon periaatteita Ositus (partitioning) Jako samantasoisiin osiin, joilla kullakin on oma eriytynyt toiminnallinen vastuunsa Osat voivat olla toiminnan vaiheita Ositus voi olla monitasoinen Kerrostus (layering) Jako eri abstraktiotasoja edustaviin kerroksiin Kullakin kerroksella oma käsitteistönsä Ylempi kerros käyttää hyväkseen alemman palveluja Kerroksen sisällä osituspohjaista ryhmittelyä 25.11.2008 Harri Laine 16
Ositus Kokonaisuudesta osiin Pääosat pienemmät osat vielä pienemmät osat jne. Toteutuu puhtaimmillaan ns. top-down jäsentelyssä: asteittaisen tarkentamisen idea Asteittain voi tarkentaa sekä toimintaa että tietoa Sopii hyvin aktiviteettien tarkentamiseen ja sitä kautta olioiden palvelujen määrittelyyn 25.11.2008 Harri Laine 17
Esimerkki / toiminnan asteittainen tarkentaminen juopottele mene viinakauppaan osta kossu mene porttikongiin juo sammu korkkaa ota 1. ryyppy irvistele juo loput laula särje pullo 25.11.2008 Harri Laine 18
Esimerkki/ tiedon asteittainen tarkentaminen sakkolappu nimi osoite henkilötunnus raha katuosoite postiosoite eurot sentit 25.11.2008 Harri Laine 19
Kerrostus toiminta-abstraktiot abstrakti kone ajattelu esim. java-virtuaalikone ylemmän kerroksen palvelut tuotetaan alemman kerroksen palveluiden avulla (vrt. tietoliikenne OSI-malli) kerrokset perustuvat eri käsitteistöihin 25.11.2008 Harri Laine 20
Application Presentation OSI -kerrokset: kukin kerros tarkastelee tietoliikennettä eri abstraktiotasolla Session CORBA Transport Network TCP/IP Data Link Ethernet Physical 25.11.2008 Harri Laine 21
Järjestelmän palvelut jaetaan kerroksiksi. Samalla abstraktiotasolla olevat asiat muodostavat kerroksen Ylempi kerros käyttää alemman kerroksen tarjoamia palveluita Periaatteessa alemman kerroksen ei tarvitse tietää mitään ylemmästä (asiakas - palvelin yhteys) hyvin joustava alempi kerros uudelleenkäytettävissä 25.11.2008 Harri Laine 22
Suljetussa kerrosarkkitehtuurissa ylempi kerros voi käyttää vain välittömästi alemman kerroksen palveluja Avoimessa kerrosarkkitehtuurissa kerroksen ohitukset ovat mahdollisia 25.11.2008 Harri Laine 23
Avoin kerrosarkkitehtuuri Kerros tulee suoraan riippuvaksi monesta alemmasta kerroksesta -joustavuus vähenee 25.11.2008 Harri Laine 24
Yhtenä arkkitehtuuritason suunnittelun tavoitteena on hallita moduulien (osajärjestelmä, luokka, olio, ) välisiä riippuvuuksia Moduuli A riippuu moduulista B, jos muutos B:ssä voi aiheuttaa muutostarpeen A:ssa Riippuvuuksia voivat aiheuttaa luokan attribuutit, luokkahierarkia, parametrityypit, operaatiokutsut, tapahtumat, Tavoitteena on arkkitehtuuri, joka minimoi riippuvuudet 25.11.2008 Harri Laine 25
Ominaisuuksia, joihin on syytä kiinnittää huomiota: modulaarisuus kiinteys (cohesion) kytkentä (coupling) tiedon kätkeminen (information hiding) ylläpidettävyys (maintainability) 25.11.2008 Harri Laine 26
Modulaarisuus Ohjelmisto on jaettu erillisiin nimettyihin (usein erikseen käännettäviin) osiin - moduuleihin, sisältönä tietorakenteita yleensä yksityisiä, käyttö operaatioiden kautta moduuli voi tarjota myös jaetun tietorakenteen operaatioita julkisia tai yksityisiä liittymä julkiset operaatiot, joita muut moduulit voivat kutsua 25.11.2008 Harri Laine 27
Modulaarisuus, perusajatuksena työmäärä(p+q) > työmäärä(p) + työmäärä(q) moduulin koko Moduulien määrän kasvaessa liittymien toteutuskustannukset kasvavat, joten jatkuva pilkkominen pienemmiksi moduuleiksi ei poista kaikkia kustannuksia. 25.11.2008 Harri Laine 28
Kiinteys (cohesion) moduuli on kiinteä, jos sen osat kytkeytyvät toisiinsa ja palvelevat yhtä ainoaa tehtäväkokonaisuutta moduuli ei ole kiinteä, jos se sisältää heikosti toisiinsa liittyviä osia kiinteys parantaa moduulin ylläpidettävyyttä ja lisää mahdollisuuksia uuskäyttöön 25.11.2008 Harri Laine 29
kiinteyden asteet huonosta hyvään: moduulissa satunnaisesti yhdistettyjä osia moduuliin koottu loogisesti samantyyppisiä tehtäviä (esim. tulostukset) moduuliin koottu samaan aikaan tarvittavia osia (esim. alustukset) moduuliin on koottu kontrollin etenemisjärjestyksessä peräkkäisiä osia moduulin koottu yhteisiä tietorakenteita käyttäviä operaatioita (oliot?) moduulin osat muokkaavat toistensa tuloksia, toisen tuote on toisen syöte toimintakokonaisuuteen perustuva yhdistäminen, jokainen osa tarpeen moduulin vastuulla olevan toimintakokonaisuuden kannalta 25.11.2008 Harri Laine 30
Kytkentä (coupling) kuvaa vuorovaikutuksia eri moduulien välillä löyhästi kytkettyjä moduuleja on helpompi ylläpitää, koska muutokset eivät vaikuta muihin moduuleihin kiinteästi kytketyillä on voimakkaita riippuvuuksia 25.11.2008 Harri Laine 31
Kytkentä löyhästä vahvaan: ei vuorovaikutusta moduulien välillä kytkennät yksinkertaisten rajapintojen kautta kytkennät monimutkaisten rakenteisten rajapintojen kautta ohjaustiedon välittäminen yhteiskäyttöiset ulkoiset laitteet yhteiskäyttöinen tietorakenne sisäisten rakenteiden hyväksikäyttö 25.11.2008 Harri Laine 32
Tiedon kätkeminen (information hiding) moduulia ajatellaan mustana laatikkona vain liittymät näkyvät ulospäin: syötteet tulosteet moduulin sisältämien toimintojen määrittely ulos eivät näy: moduulin sisäiset tietorakenteet toimintojen toteutustapa toteutus, testaus ja ylläpito paikallista suojaus tehostuu Luokilla liittymämetodit (accessories), pakkauksilla rajapintaluokat 25.11.2008 Harri Laine 33
Moduuli A riippuu moduulista B, jos muutos B:ssä voi aiheuttaa muutostarpeen A:ssa Operaatioiden ja attribuuttien väliset riippuvuudet aiheuttavat luokkien väliset riippuvuudet Vastaavasti luokkien väliset riippuvuudet aiheuttavat pakettien välisiä riippuvuuksia ja pakettien väliset kerrosten välisiä riippuvuuksia 25.11.2008 Harri Laine 34
Package A <<layer>> Layer 1 Package B P ac ka ge A depends on P ac ka ge B bec ause Cl as s X depends on ClassY Class X Class Y Layer 1 depends on Layer 2 because Class X depends on Class Z Package C <<layer>> Layer 2 P acka ge D Class Z Package E 25.11.2008 Harri Laine 35
Package A Package A1 Package B Package B Erityisen ongelmallisina pidetään syklisiä riippuvuuksia. Ne voidaan usein purkaa eristämällä riippuvuuden aiheuttava osa omaksi pakkauksekseen Package A2 ne elementit, joista B riippuu on eristetty paketiksi A2 25.11.2008 Harri Laine 36
Kerrosarkkitehtuurissa ylempi kerros riippuu alemmasta löyhästi kytketyt kerrokset tarjoavat palvelut rajapinnan kautta vain rajapinta näky ulospäin vahva kytkentä kerrosten välillä kerrosten kytkentä rajapinnan kautta 25.11.2008 Harri Laine 37
kerros Palvelurajapinta = funktiot tai metodit, joita voi kutsua ulkoa (service interface) Toteutusrajapinta = (required interface) funktiot tai metodit, joiden toteutuksen alempi taso tarjoaa = alemman tason palvelurajapinta 25.11.2008 Harri Laine 38
tarjottu rajapinta = palvelurajapinta A C vaadittu rajapinta = toteutusrajapinta B <<interface>> A C Bimp <<interface>> B 25.11.2008 Harri Laine 39