Ohjelmistojen mallintaminen Ohjelmistoarkkitehtuuri Harri Laine 1

Transkriptio

1 Ohjelmistojen mallintaminen Ohjelmistoarkkitehtuuri Harri Laine 1

2 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 Harri Laine 2

3 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 Harri Laine 3

4 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 ( [laitokselta] Harri Laine 4

5 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 Harri Laine 5

6 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 Harri Laine 6

7 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ä Harri Laine 7

8 Näkymät tarkastelevat arkkitehtuuria kukin omasta näkökulmastaan Mikään näkökulma ja kuvaus ei yksinään riitä arkkitehtuurin kuvaamiseen Harri Laine 8

9 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 Harri Laine 9

10 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 Harri Laine 10

11 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 Harri Laine 11

12 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 Harri Laine 12

13 Pakkausnotaatioita Harri Laine 13

14 Pakkauksen sisältö Pakkaus omistaa sisältönsä Harri Laine 14

15 Vaihtoehtoinen tapa pakkauksen sisällön kuvaamiseen Harri Laine 15

16 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ä Harri Laine 16

17 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 Harri Laine 17

18 Esimerkki / toiminnan asteittainen tarkentaminen juopottele mene viinakauppaan osta kossu mene porttikongiin juo sammu korkkaa ota 1. ryyppy irvistele juo loput laula särje pullo Harri Laine 18

19 Esimerkki/ tiedon asteittainen tarkentaminen sakkolappu nimi osoite henkilötunnus raha katuosoite postiosoite eurot sentit Harri Laine 19

20 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 Harri Laine 20

21 Application Presentation OSI -kerrokset: kukin kerros tarkastelee tietoliikennettä eri abstraktiotasolla Session CORBA Transport Network TCP/IP Data Link Ethernet Physical Harri Laine 21

22 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ä Harri Laine 22

23 Suljetussa kerrosarkkitehtuurissa ylempi kerros voi käyttää vain välittömästi alemman kerroksen palveluja Avoimessa kerrosarkkitehtuurissa kerroksen ohitukset ovat mahdollisia Harri Laine 23

24 Avoin kerrosarkkitehtuuri Kerros tulee suoraan riippuvaksi monesta alemmasta kerroksesta -joustavuus vähenee Harri Laine 24

25 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 Harri Laine 25

26 Ominaisuuksia, joihin on syytä kiinnittää huomiota: modulaarisuus kiinteys (cohesion) kytkentä (coupling) tiedon kätkeminen (information hiding) ylläpidettävyys (maintainability) Harri Laine 26

27 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 Harri Laine 27

28 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 Harri Laine 28

29 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 Harri Laine 29

30 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 Harri Laine 30

31 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 Harri Laine 31

32 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ö Harri Laine 32

33 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 Harri Laine 33

34 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 Harri Laine 34

35 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 Harri Laine 35

36 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 A Harri Laine 36

37 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 Harri Laine 37

38 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 Harri Laine 38

39 tarjottu rajapinta = palvelurajapinta A C vaadittu rajapinta = toteutusrajapinta B <<interface>> A C Bimp <<interface>> B Harri Laine 39