Ohjelmistotekniikan menetelmät, arkkitehtuuria ja rajapintoja

Transkriptio

1 Ohjelmistotekniikan menetelmät, arkkitehtuuria ja rajapintoja 1

2 Arkkitehtuurisuunnittelu Ohjelmistoarkkitehtuurin määritelmä & arkkitehtuurisuunnittelun lähtökohta ja tavoitteet Kerrosarkkitehtuuri ohjelmiston jaottelun perusmallina Arkkitehtuurin osien kuvaaminen UML-pakkauksilla Järjestelmän osien välisten riippuvuuksien hallinta Pakkausten ja luokkien väliset riippuvuudet Rajapinnat Tapahtumankäsittely Esimerkki: MVC-arkkitehtuuri 2

3 Ohjelmistoarkkitehtuuri Ohjelmiston yleisrakenne, jonka on tarkoitus palvella ohjelmiston ymmärrettävyyttä ylläpidettävyyttä laajennettavuutta skaalautuvuutta tuettavuus (supportability) 3

4 Ohjelmistoarkkitehtuurin tehtävä Ohjelmiston jaottelu moduuleiksi esim. luokiksi, paketeiksi, komponenteiksi, toiminnallisuuden sijoittelu moduuleihin moduulien ja olioiden välisten riippuvuuksien hallinta Arkkitehtuurimallien (architectural pattern) ja arkkitehtonisten periaatteiden kiinnittäminen Perusta, jonka varaan kaikki myöhemmät suunnittelu- ja toteutusratkaisut rakennetaan Arkkitehtuurikuvaus toimii järjestelmän yleisrakenteen dokumentaationa 4

5 Arkkitehtuurisuunnittelu Joukko valintoja ja päätöksiä, joilla pyritään toimivaan ohjelmistoarkkitehtuuriin Huom! Päätösten perustelut pitää kirjata! Erityispiirteitä järjestelmänlaajuiset perusratkaisut järjestelmän ositus ja riippuvuuksien hallinta ohjelmiston ei-toiminnalliset ominaisuudet vaihtoehtoisten ratkaisutapojen evaluointi 5

6 Arkkitehtuurisuunnittelun tavoitteet Ohjelmiston hierarkkisen kerrosrakenteen määrittely auttaa hallitsemaan järjestelmän monimutkaisuutta ymmärtämään moduulien välisiä riippuvuuksia, sillä suora olioiden välinen vuorovaikutus on sallittu vain vierekkäisten kerrosten välillä Moduulien välisten riippuvuuksien esittäminen eksplisiittisesti käännösaikaisina rakenteina pelkästään suoritusaikana näkyvien, löyhien ja epämääräisten riippuvuuksien estäminen/ kieltäminen 6

7 Kerrosarkkitehtuuri ohjelmiston jaottelun perusmallina Useimmat järjestelmät voidaan jakaa kerroksiin, esim. Käyttöliittymäkerros, jossa käyttöliittymäoliot järjestelmän ulospäin näkyvä osa, esim. ikkunat, valikot, käyttäjän ja sisältöolioiden välinen yhteys: esitetään tietoja ja vastaanotetaan käyttäjän ohjausta Sovelluslogiikkakerros, jossa sisältöoliot toteuttaa reaalimaailman simulointimallin sisältöoliot tarjoavat omaan tietosisältöönsä perustuvia sovelluskohtaisia palveluja Tietojensäilytyskerros, jossa tietokantaoliot esim. tiedostot, tietokannan taulut, säilyttävät sisältöolioiden tiloja 7

8 Arkkitehtuurin osien kuvaaminen UMLpakkauksilla UML:ssä pakkauksella voidaan koota yhteen nimetty joukko mallinnuselementtejä Pakkaus voi sisältää muita (ali)pakkauksia Pakkaus omistaa sisältönsä pakkauksen poistaminen poistaa myös sen sisällön esim. luokka kuuluu yleensä vain yhteen pakkaukseen Pakkaus voi viitata (import) muihin pakkauksiin merkitään riippuvuutena pakkausten välillä tällöin pakkauksen elementit (esim. luokat) voivat viitata kohdepakkaukseen tai sen elementteihin 8

9 Pakkausnotaatioita 9

10 Plusympyrä-esimerkki 10

11 Plusympyrä-esimerkki 11

12 Järjestelmän osien välisten riippuvuuksien hallinta Moduuli (luokka, paketti, olio, ) A riippuu moduulista B, jos muutos B:ssä voi aiheuttaa muutostarpeen A:ssa Riippuvuusmekanismeja luokan attribuutit, luokkahierarkia, parametrityypit, operaatiokutsut, tapahtumat, Tavoitteena arkkitehtuuri, joka minimoi riippuvuudet; erityisesti riippuvuudet eivät saa ulottua naapurikerroksia kauemmas aiheuttaa syklejä (tästä lisää myöhemmin) 12

13 Pakkausten välisten riippuvuussyklien poistaminen Package A Package B Package A1 Package B Package A2 ne elementit, joista B riippuu on eristetty paketiksi A2 13

14 Kerrosten väliset riippuvuudet «layer» Layer 1 Package A «layer» Layer 2 Package C Package E Package B Package D Ylemmät kerrokset riippuvat alemmista Alempien kerrosten oltava (julkisilta osiltaan) vakaita muutos rajapintaan heijastuu ylempään Toisaalta alemman kerroksen voidaan vaihtaa julkisilta osiltaan samanlaiseen (mutta sisäiseltä toteutukseltaan erilaiseen), koska se on riippumaton ylemmästä 14

15 Riippuvuudet eri abstraktiotasoilla Operaatioiden ja attribuuttien väliset riippuvuudet aiheuttavat luokkien väliset riippuvuudet Vastaavasti luokkien väliset aiheuttavat pakettien väliset ja pakettien väliset kerrosten väliset riippuvuudet 15

16 Rajapinnat ja abstraktit luokat Rajapinta (interface) UML:ssä piirteiden (attribuuttien ja operaatioiden) kokoelma, josta ei voi suoraan luoda ilmentymiä rajapinnan toteuttava olio tarjoaa julkisen pääsyn ko. piirteisiin käytetään usein attribuuttien ja parametrien tyyppinä Abstrakti luokka (abstract class) esittelee vähintään yhden operaation, jota ei ole (tai ei voi olla) toteutettu kyseisessä luokassa ei voi suoraan instantioida (luoda ilmentymiä) Javassa rajapinnassa vain vakioattribuutteja ja operaatiosignatuureja luokka voi periä vain yhden (abstraktin tai konkreettisen) luokan, mutta voi toteuttaa useita rajapintoja 16

17 Rajapinnan kuvaaminen UML:ssä 17

18 Toteutusriippuvuus (interface realization, implementation dependency) Luokan Class1 tarjoama rajapinta (provided interface) = Interface1 + Interface2 18

19 Käyttöriippuvuus (usage dependency) Luokan Class1 tarvitsema rajapinta (required interface) = Interface1 19

20 Syklisten riippuvuuksien aiheuttamat haitat ja niiden lieventäminen Moduulien välisten riippuvuussyklien aiheuttamia haittoja ja vaikeuksia moduulien suunnittelu- ja toteutusvastuun jakaminen oikean alustus- ja kutsujärjestyksen määrittely esim. kerrosten riippumattomuus toisistaan (ongelmana ylöspäin suuntautuvat riippuvuudet) Syklejä ei aina voida poistaa, mutta haittoja voidaan lieventää rajapintojen harkitulla käytöllä usein rajapinta ja sen toteuttava luokka eri pakettiin rajapinta samaan pakettiin sen käyttäjän kanssa tai kokonaan erilliseen pakettiin 20

21 Syklin poistaminen rajapinnalla public class PWindow implements ICPresenter { } public void init() { } interface ICPresenter { void init(); } public class CInit { PWindow ICPresenter win; p; public void do() { win.init(); p.init(); } } «layer» presentation PWindow +init() PDialog +dook() ICPresenter +init() CActioner +action() «layer» control «uses» +do() CInit public class PDialog { private CActioner actioner; } public void dook() { actioner.action(); } public class CActioner { public void action() { } } // do something 21

22 Tapahtumakäsittely Synkroninen kommunikointi aiheuttaa operaatioriippuvuuksia moduulien välille Asynkronisessa kommunikoinnissa palvelun käyttäjä on löyhemmin sidottu palvelun tarjoajaan Eräs asynkronisen kommunikoinnin muoto on tapahtumaperustainen kommunikointi voidaan toteuttaa esimerkiksi Observersuunnittelumallin avulla [Gamma et al., 1995] Javassa valmis tuki rajapinnalla java.util.observer ja kantaluokalla java.util.observable 22

23 Tapahtumankäsittelyn toteutus Tapahtuman lähettäjä (event originator, publisher) luo tyypillisesti tapahtumaolion (event object), joka kuvaa tapahtumaan liittyvää informaatiota (esim. ButtonEvent: mikä painike) Tapahtuman käsittelijät (event listener, observer, subscriber) ovat aiemmin ilmoittautuneet halukkaiksi tulemaan informoiduksi kyseisenlaisista tapahtumista tapahtumaolio välitetään niille kaikille käsiteltäväksi sopivasti Laajoissa järjestelmissä voi olla erillinen rekisteröijä (registrator object), jolle tapahtuman käsittelijät ilmoittautuvat ja joka huolehtii lähettäjien ja käsittelijöiden välisestä kättelystä 23

24 Tapahtumankäsittelyn aiheuttamat riippuvuudet Tapahtuman lähettäjä ei tiedä (eikä haluakaan tietää), kuinka käsittelijä tulee tapahtumaan reagoimaan lähettäjä riippuu käsittelijästä vain hyvin löyhästi käytännössä se yleensä tuntee vain joukon tietyn kuuntelijarajapinnan toteuttavia olioita Käsittelijän ja lähettäjän välinen kättely aiheuttaa vahvemman riippuvuuden jos käytetään erillistä rekisteröijäoliota, se riippuu sekä tapahtuman lähettäjästä että käsittelijästä jos käsittelijä rekisteröityy suoraan lähettäjälle, se riippuu lähettäjästä rajapintojen käytöllä voidaan löyhentää riippuvuuksia 24

25 PDialogEvent PDialog +adddialoglistener() -firedialogevent() +dook() Kuuntelijarajapinnan käyttäminen tapahtumankäsittelyssä «layer» presentation «uses» PWindow +init() IPDialogListener +processdialogevent() «layer» control ICPresenter +init() CActioner CInit «uses» +processdialogevent() public class PDialog { private CActioner IPDialogListener act; lst; private PDialogEvent evt; public class CActioner { public void adddialoglistener(ipdialoglistener adddialoglistener(cactioner a) { l) act { lst = = a; l; }} public void processdialogevent( private void firedialogevent() { PDialogEvent evt) { if (evt!= null) evt = new PDlgEvent(); // do something with evt if (act (lst!= null) lst.processdialogevent(evt); act.processdialogevent(evt); } } } 25/26 public void dook() { firedialogevent(); } } 25 }

26 Käyttöliittymäolioiden ja sisältöolioiden suhde Yksi keskeisiä haasteita ohjelmiston arkkitehtuuria suunniteltaessa Yleisesti: sisältöolioiden tulisi tarjota käyttöliittymästä riippumattomia palveluja sisällön käsittelyyn Usein käyttöliittymäolioiden ja sisältöolioiden välillä käytetään erityisiä kontrolliolioita tätä kutsutaan Model-View-Controller malliksi 26

27 Model-View-Controller (MVC) - arkkitehtuurimalli Application View Controller Model Database & Web Services Mallioliot (model) esittävät kohdealueen käsitteitä, liiketoimintasääntöjä ja sovelluslogiikkaa Näkymäoliot (view) esittävät käyttöliittymän osia Kontrollioliot esittävät syötelaitteiden (hiiri, näppäimistö) tuottamia tapahtumia ja niiden käsittelylogiikkaa 27

28 Käyttöliittymäolioiden toiminta eli käyttöliittymän kuuntelu Kontrolliolio asettuu kuuntelemaan tiettyyn käyttöliittymäolioon liittyviä tapahtumia (Observer) Dynaamisen sidonnan ansiosta käyttöliittymäolion ei tarvitse tietää kontrolliolion konkreettista luokkaa, ainoastaan rajapinta Käyttöliittymäoliolle (esim. painike) suoritetusta toiminnosta (esim. painikkeen painallus) välitetään käsittelypyyntö kaikille kuuntelijoille, myös ko. kontrollioliolle 28

29 MVC:n etuja Erilaiset käyttöliittymät eri tarpeisiin (esim. GUI vs. eräajokäyttö) ja myös samanaikaisesti erilaiset näkymät samaan tietosisältöön Käyttöliittymän päivittäminen tai käyttöliittymätyypin vaihtaminen ei vaikuta sisältöluokkiin Käyttöliittymän reagointitapaa voidaan vaihtaa muuttamatta ulos näkyviä käyttöliittymäkomponentteja Tietosisällön muotoa ja talletustapaa voidaan vaihtaa muuttamatta käyttöliittymää Tietosisältöä voidaan käsitellä ilman käyttöliittymää (esim. ohjelmallinen käsittely, skriptaus) 29