– Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja

Esitys aiheesta: "– Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja"— Esityksen transkriptio:

1 582104 – Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja

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 Esimerkki: MVC-arkkitehtuuri

3 Ohjelmiston suunnittelu
Suunnitteluvaiheessa tarkoituksena on löytää sellaiset oliot, jotka pystyvät yhteistoiminnallaan toteuttamaan edellisessä luvussa listatut järjestelmältä vaadittavat operaatiot Suunnittelu jakautuu karkeasti ottaen kahteen vaiheeseen: Arkkitehtuurisuunnittelu Oliosuunnittelu

4 Arkkitehtuurisuunnittelu ja oliosuunnittelu
Arkkitehtuurisuunnittelussa hahmotellaan järjestelmän rakenne karkeammalla tasolla Oliosuunnittelussa suunnitellaan oliot, jotka ottavat vastuulleen järjestelmältä vaaditun toiminnallisuuden toteuttamisen Yksittäiset oliot eivät yleensä toteutta suurtakaan järjestelmän toiminnallisuudesta Erityisesti oliosuunnitteluvaiheessa tärkeäksi seikaksi nouseekin olioiden välinen yhteistyö, eli se vuorovaikutus, jolla oliot saavat aikaan halutun toiminnallisuuden

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

6 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

7 Komponenttijaottelusta
Komponentilla tarkoitetaan yleensä kokoelmaa toisiinsa liittyviä olioita/luokkia, jotka suorittavat jotain ohjelmassa tehtäväkokonaisuutta Käyttöliittymän voitaisiin ajatella olevan yksi komponentti Suuri komponentti voi muodostua useista alikomponenteista kirjastojärjestelmän sovelluslogiikkakomponetti voisi sisältää komponentin, joka huolehtii sovelluksen alustamisesta ja yhden komponentin kutakin järjestelmän toimintokokonaisuutta varten Komponenttijako voi perustua myös tietosisältöihin kirjastojärjestelmässä voisi olla omat komponentit lainaajia, lainoja ja kirjakokoelmaa varten

8 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

9 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

10 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

11 Arkkitehtuurin osien kuvaaminen UML-pakkauksilla
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

12 Pakkausnotaatioita

13 Plusympyrä-esimerkki

14 Plusympyrä-esimerkki

15 Kerrosarkkitehtuuri pakkauskaaviona
Jokainen komponentti on kuvattu omana pakkauksena, eli isona laatikkona, jonka vasempaan ylälaitaan liittyy pieni laatikko Laatikoiden välillä on riippuvuuksia Käyttöliittymä riippuu sovelluslogiikasta Sovelluslogiikka riippuu tallennuspalveluista Järjestelmä perustuu kerrosarkkitehtuuriin (engl. layered architecture)

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

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

18 Kerrosten väliset riippuvuudet
«layer» Layer 2 Layer 1 Package A Package B Package C Package D Package E 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ä

19 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

20 Kerrosarkkitehtuuri Kirjastojärjestelmän rakenne perustuu siis kerrosarkkitehtuuriin Kerrosarkkitehtuuri yksi hyvin tunnettu arkkitehtuurimalli (engl. architecture pattern), eli periaate, jonka mukaan tietynlaisia ohjelmia kannattaa pyrkiä rakentamaan Olemassa myös muita arkkitehtuurimalleja, joita ei nyt kuitenkaan käsitellä Kerros on kokoelma toisiinsa liittyviä olioita tai alikomponentteja, jotka muodostavat esim. toiminnallisuuden suhteen loogisen kokonaisuuden ohjelmistosta

21 Kolmikerrosarkkitehtuuri
Kerrosarkkitehtuurissa on pyrkimyksenä järjestellä komponentit siten, että ylempänä oleva kerros käyttää ainoastaan alempana olevien kerroksien tarjoamia palveluita Ylimpänä kerroksista on käyttöliittymäkerros sen alapuolella sovelluslogiikka alimpana tallennuspalveluiden kerros, eli esim. tietokanta, jonne sovelluksen olioita voidaan tarvittaessa tallentaa. Palaamme kerrosarkkitehtuurin hyötyihin pian, ensin hieman lisää pakkauskaavioista

22 Pakkauskaavio Pakkauskaaviossa yksi komponentti kuvataan pakkaussymbolilla Pakkauksen nimi joko keskellä symbolia tai ylänurkan laatikossa Pakkausten välillä olevat riippuvuudet ilmaistaan katkoviivanuolena, joka suuntautuu pakkaukseen, johon riippuvuus kohdistuu Kerrosarkkitehtuurissa siis pyrkimyksenä, että riippuvuuksia on ainoastaan alapuolella oleviin kerroksiin. Kirjastojärjestelmän käyttöliittymäkerros riippuu sovelluslogiikkakerroksesta Tyypillinen käännösaikainen riippuvuus on tilanne jossa, käyttöliittymän oliot kutsuvat sovelluslogiikan olioiden metodeja Sovelluslogiikkakerros taas on riippuvainen tallennuspalvelukerroksesta Pakkauksen sisältö on mahdollista piirtää pakkaussymbolin sisään kuten seuraavalla sivulla olevassa tarkennetussa kirjastojärjestelmän arkkitehtuurikuvauksessa Pakkauksen sisällä voi olla alipakkauksia tai esim. luokkia Riippuvuudet voivat olla myös alipakkausten välisiä

23

24 Plusympyrä käytännössä
Jos pakkauksessa on paljon sisältöä, voi sisällön näyttäminen piirtämällä sisältyvät komponentit pakkauksen sisäpuolelle olla ongelmallista Mahdollista piirtää pakkaukseen sisältyvät komponentit ulkopuolelle

25 Pakkaussymboli sovellettavissa kaikkiin mallinnuselementteihin
UML:n pakkaussymbolilla voidaan ryhmitellä mitä tahansa komponentteja: pakkauksia, luokkia, olioita, käyttötapauksia, ... Voitaisiin esim. jakaa kirjastojärjestelmän käyttötapaukset ylläpidon helpottamiseksi tai dokumentoinnin selkeyttämiseksi neljään eri pakkaukseen

26 Kerrosarkkitehtuurin etuja
Kerroksittaisuus helpottaa ylläpitoa Kerroksen sisältöä voi muuttaa vapaasti jos sen palvelurajapinta eli muille kerroksille näkyvät osat säilyvät muuttumattomina Sama pätee tietysti mihin tahansa komponenttiin Jos kerroksen palvelurajapintaan tehdään muutoksia, aiheuttavat muutokset ylläpitotoimenpiteitä ainoastaan ylemmän kerroksen riippuvuuksia omaavin kerroksiin Esim. käyttöliittymän muutokset eivät vaikuta sovelluslogiikkaan tai tallennuspalveluihin

27 Kerrosarkkitehtuurin etuja 2/2
Sovelluslogiikan riippumattomuus käyttöliittymästä helpottaa ohjelman siirtämistä uusille alustoille, esim. toimimaan www-selaimen kautta Alimpien kerroksien palveluja, kuten lokitiedostoon kirjoitusta tai tietokantayhteyksiä voidaan ehkä uusiokäyttää myös muissa sovelluksissa Ylemmät kerrokset voivat toimia korkeammalla abstraktiotasolla Tallennuspalvelukerros kätkee tietokannan käsittelyn muilta kerroksilta: sovelluslogiikan tasolla voidaan ajatella kaikki olioina Kaikkien ohjelmoijien ei tarvitse ymmärtää kaikkia detaljeja, osa voi keskittyä tietokantaan, osa käyttöliittymiin, osa sovelluslogiikkaan

28 Yhtenäisiä pakkauksia
Yksittäisistä pakkauksista kannattaa tehdä mahdollisimman yhtenäisiä toiminnallisuudeltaan eli sellaisia, joiden osat kytkeytyvät tiiviisti toisiinsa ja palvelevat ainoastaan yhtä selkeästi eroteltua tehtäväkokonaisuutta Samalla pyrkimyksenä on, että erilliset pakkaukset ovat mahdollisimman löyhästi kytkettyjä toisiinsa pakkausten välisiä riippuvuuksia pyritään minimoimaan Ohjelman jakautuminen mahdollisimman riippumattomiin pakkauksiin eristää koodiin ja suunnitelmaan tehtävien muutosten vaikutukset mahdollisimman pienelle alueelle, eli ainoastaan riippuvuuden omaaviin pakkauksiin Tämä helpottaa ohjelman ylläpitoa ja tekee sen laajentamisen helpommaksi Selkeä jakautuminen pakkauksiin myös helpottaa työn jakamista suunnittelu- ja ohjelmointivaiheessa

29 Kerroksellisuus ei riitä
Pelkkä kerroksittaisuus ei tee ohjelman arkkitehtuurista automaattisesti hyvää. Alla tilanne, missä kerroksen n+1 kolmella alipaketilla on kullakin paljon riippuvuuksia kerroksen n sisäisiin komponenttiin Esim. muutos kerroksen n luokkaan 1 aiheuttaa nyt muutoksen hyvin moneen ylemmän kerroksen pakkaukseen

30 Kerrosten välille rajapintoja
Yksi tapa toteuttaa rajapinta on luoda kerroksen sisälle erillinen rajapintaolio, jonka kautta ulkoiset yhteydet tapahtuvat Tätä periaatetta sanotaan fasaadimalliksi (engl. facade pattern) Alla luotu rajapintaolio kerrokselle n. Kommunikointi kerroksen kanssa tapahtuu rajapinnan kautta ylemmän kerroksen riippuvuudet kohdistuvat rajapintaolioon muutos esim. luokkaan 1 ei vaikuta kerroksen n+1 komponentteihin ainoat muutokset on tehtävä rajapintaolion sisäiseen toteutukseen

31 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

32 Rajapinnan kuvaaminen UML:ssä

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

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

35 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

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

37 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

38 Model-View-Controller (MVC) -arkkitehtuurimalli
Application View Database & Web Services Model Controller 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

39 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

40 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)