Sovellusalue- ja suunnittelumallit Domain Model, Design Model

Transkriptio

1 Sovellusalue- ja suunnittelumallit Domain Model, Design Model Luento CSM14101 Ohjelmistoarkkitehtuurit 1

2 Oppimistavoitteet Sovellusalueen mallintaminen Tietomalli, invariantit, toiminnalliset skenaariot Suunnittelun mallintamisen perusteet Komponentit, konnektorit, rajapinnat ja portit Suunnittelumalli Rajapintamalli, sisärakennemallit Ohjelmistoarkkitehtuurit 2

3 Esimerkkiohjelmisto Yinzer 1 Yinzer on internetissä toimiva sosiaalisen median palvelu, joka tarjoaa jäsenilleen työhön liittyvää verkostoitumista ja työpaikkailmoittelua Pittsburghin alueella. Jäsenet voivat lisätä toisia palvelun jäseniä kontakteihinsa, julkaista työpaikkailmoituksia, ehdottaa jotain kontaktiaan avoimeen työpaikkaan ja vastaanottaa sähköpostiilmoituksia itselleen sopivista työpaikoista. 1 Yinzer = slanginimitys henkilölle, joka on kotoisin Pittsburghista (PA, U.S.A.) Ohjelmistoarkkitehtuurit 3

4 SOVELLUSALUEMALLI Ohjelmistoarkkitehtuurit 4

5 Sovellusaluemallin käyttö Sovellusaluemallinnuksen tehtävä on varmistaa, että toteutettavan ohjelmiston kannalta oleelliset sovellusalueen piirteet on ymmärretty oikein Tuloksena suppeampi malli kuin koko liiketoiminnan mallinnuksessa (business modelling), jonka tarkoitus on kattavasti kuvata jonkin yrityksen liiketoiminnan tavoitteet ja päätöksentekoprosessit (-> enterprise architecture, kokonaisarkkitehtuuri*) Liiketoimintamallin perusteella voidaan päättää, mitä liiketoiminnan prosesseja automatisoidaan, ja sovellusaluemallin avulla kuvataan automatisoitavan osuuden piirteet * Kokonaisarkkitehtuurista on kurssilla vierailuesitelmä ja Ohjelmistoarkkitehtuurit 5

6 Sovellusaluemallin käyttö Sovellusaluemalli auttaa pitämään ohjelmistototeutukseen liittyvät suunnittelupäätökset erillään sovellusalueen käsitteistä (vastaavuussuhde) Suhteellisen yksinkertaisia sovellusaluemalleja voidaan käyttää kommunikoinnissa sovellusalueen asiantuntijoiden (ja asiakkaiden) kanssa tuloksellisemmin kuin suunnittelumalleja Mallin pohjalta rakentuu yhteinen kieli ohjelmistokehittäjien ja sovellusasiantuntijoiden välille Ohjelmistoarkkitehtuurit 6

7 Sovellusaluemallin käyttö Sovellusaluemalleista on eniten hyötyä järjestelmissä, joiden sovellusalue on suhteellisen monimutkainen ja jota kehittäjät eivät vielä hallitse Esimerkiksi laiteajureiden (device driver) kehittäjillä on tyypillisesti paljon teknisiä haasteita ja hankalia laatuvaatimuksia toteutustyössä, mutta sovellusalue on suhteellisen suppea Sovellusaluemallista on heille vähemmän hyötyä He ovat usein itse alueen parhaita asiantuntijoita Ennen pitkää projektissa kuin projektissa tulee kuitenkin vastaan ongelma, jossa sovellusaluemalli voi auttaa Sovellusalueen puutteellinen ymmärtäminen on monien ITprojektien epäonnistumisen perimmäisiä syitä Ohjelmistoarkkitehtuurit 7

8 Epäilyksiä Sovellusalue on jo tunnettu miksi mallintaa sitä? Näin osittain onkin, ainakin kuumilla uutuusaloilla, mutta tylsät business-jutut voivat olla huonosti ymmärrettyjä, missä piilee riski Sovellusalue on niin simppeli, ettei sitä kannata mallintaa Ymmärtävätkö kehittäjät ja käyttäjät käyttäjien tarpeet varmasti samalla tavalla? Ohjelmistoarkkitehtuurit 8

9 Epäilyksiä Sovellusalue on yhdentekevä arkkitehtuurin suunnitteluratkaisujen kannalta Järjestelmien integroinnissa tulee tilanteita, joissa integroitavien (osa-)järjestelmien erilaiset tulkinnat samoista sovellusalueen käsitteistä johtavat yhteensopivuusongelmiin. Myös arkkitehtuurit ovat tällöin yleensä yhteensopimattomia. On jonkun toisen homma määritellä vaatimukset Ehkä, mutta näillä henkilöillä ei välttämättä ole ymmärrystä, mitkä asiat voivat aiheuttaa ongelmia arkkitehtuurin kannalta, ja heitä joutuu joka tapauksessa muutenkin avustamaan Ohjelmistoarkkitehtuurit 9

10 Epäilyksiä Sovellusalueen oppi parhaiten vähitellen, koodatessa Varmasti näin on, kaikissa tilanteissa tämä ei vain ole mahdollista, esimerkiksi evaluoitaessa valmiita ohjelmistoja integroitavaksi osaksi isompaa järjestelmää Suurissa projekteissa yksittäisten kehittäjien käsitykset sovellusalueesta voivat haitallisesti erkaantua Sovellusaluemallinnus on itseään ruokkiva prosessi, joka ei lopu koskaan (analysis paralysis) Tämä on todellinen riski! Ohjelmistoarkkitehtuurit 10

11 Analysis paralysis Paras lääke tähän tautiin on miettiä ensin, mihin sovellusalueeseen liittyviin kysymyksiin todennäköisesti tarvitaan vastauksia suunnittelu- ja toteutustyön aikana Kun vastaukset on saatu, mallinnus voidaan lopettaa Kysymykset riippuvat projektin riskeistä, tyypillisiä ovat käytettävyyteen ja yhteensopivuuteen (interoperability) liittyvät riskit On nähtävä, milloin mallinnuksen jatkamisesta ei enää saada lisäarvoa verrattuna muihin aktiviteetteihin - esimerkiksi prototyypin tekemiseen Ohjelmistoarkkitehtuurit 11

12 Sovellusaluemallin osat Tietomalli (Information model) Invariantit ja rajoitteet (Invariants, constraints) Tilannekuva (snapshot) Toiminnallinen skenaario (functionality scenario) Ohjelmistoarkkitehtuurit 12

13 Tietomalli Helpoimmin tehtävä ja kaikkein hyödyllisin sovellusaluemallin osa, joka määrittelee sovellusalueen asiat ja niiden väliset suhteet Tietomalli voidaan määritellä tekstuaalisesti (ikään kuin sanastona) tai graafisesti UMLkaavioina (käsite- eli luokkakaaviot) UML:n käytössä noudatettava pidättyvyyttä, että myös sovellusalueen asiantuntijat ymmärtäisivät ne (SME = subject matter expert) Tarkoitus on kuvata sovellusaluetta, ei suunnitteluratkaisuja! Ohjelmistoarkkitehtuurit 13

14 Tekstimuotoinen tietomalli Tyyppi Ad (mainos) Company (yhtiö) Contact (kontakti) Employment (työsuhde) Job (työ, toimi) Job Match (rekrytointiehdotus) Person (henkilö) Määritelmä Ilmoitus, jolla haetaan henkilöä (Person) yhtiössä (Company) olevaan avoimeen työpaikkaan (Job) Työnantaja, joka tarjoaa töitä (Job) henkilöille (Person) Kahden henkilön (Person) välinen suhde, joka tarkoittaa, että henkilöt tuntevat toisensa Suhde, joka ilmaisee, että henkilö on tai on ollut töissä (Job) yhtiössä (Company) Yhtiön (Company) toimi tai toimen kuvaus Toimen (Job) ja henkilön (Person) välinen suhde, joka tarkoittaa, että henkilö voi olla sopiva toimeen toisen henkilön mielestä Joku, joka voidaan ottaa työsuhteeseen Ohjelmistoarkkitehtuurit 14

15 Tietomalli UML-kaaviona Tyyppien (luokat) väliset suhteet (assosiaatiot) ja suhteisiin liittyvät määrälliset rajoitukset ovat suoraan näkyvissä Ohjelmistoarkkitehtuurit 15

16 Invariantit ja rajoitteet Tietomalli määrittelee sovellusalueen mallinnuksessa käytettävän sanaston Invariantit eli rajoitteet ilmaisevat väitteitä tai ehtoja (predicate), joiden pitää aina olla tosia Osa rajoitteista voidaan ilmaista suoraan kaavioissa (assosiaatioiden roolien määrälliset rajoitteet) Muu rajoite voidaan liittää UML-kaavioon huomautuksena (note) tai kirjata se johonkin erilliseen dokumenttiin Formaalilla OCL-kielellä voidaan ilmaista täsmällisiä UMLmallia koskevia rajoitteita, assosiaatioketjuja pitkin navigoiden Ohjelmistoarkkitehtuurit 16

17 Invariantit Ohjelmistoarkkitehtuurit 17

18 Tilannekuva Tietomalli kuvaa sovellusalueen asioita tyyppien tasolla, ei konkreettisten olioiden Tilannekuva taas kuvaa jossakin konkreettisessa tilanteessa muodostuvan olioiden eli tyyppien instanssien ja niiden välisten yhteyksien konfiguraation UML:n oliokaaviota (object diagram) käytetään olioiden ja niiden välisten linkkien (suhteiden eli assosiaatioiden instanssien) kuvaamiseen tilannekuvassa Jokainen kaavion olio kuuluu johonkin tyyppiin ja jokainen kaavion linkki on jonkin tyyppien välisen suhteen yksittäinen ilmentymä Tilannekuvia voi käyttää apuna rajoitteita mietittäessä, esimerkiksi voiko henkilö olla oma kontaktinsa Ohjelmistoarkkitehtuurit 18

19 Tilannekuva Ohjelmistoarkkitehtuurit 19

20 Toiminnalliset skenaariot Tilannekuvat näyttävät, minkälaisia olioita ja niiden välisiä linkkejä jollain tietyllä ajan hetkellä on olemassa Tietomalli ja invariantit kuvaavat taas kaikki mahdolliset tilanteet Yksittäisten tilanteiden on oltava tietomallin asettamien rajoitteiden mukaisia (esim. assosiaatioiden kardinaliteetit) Nämä eivät kuitenkaan kuvaa, miten sovellusalueen tila muuttuu ajanhetkestä toiseen Skenaario kuvaavaa tapahtumasarjaa, joka aiheuttaa muutoksen tilannekuvassa Ohjelmistoarkkitehtuurit 20

21 Skenaarioesimerkki Nimi Alkutila Toimijat Owen saa töitä Widgetronista Bradley on töissä Widgetron -yhtiössä Owen, Bradley, Widgetron Askelet 1. Owen ja Bradley tapaavat ammatillisessa konferenssissa, vaihtavat käyntikortteja ja liittyvät toistensa verkostoon (Contact) 2. Bradleyn työnantaja (Company) Widgetron ilmoittaa hakevansa (Ad) uutta sovelluskehittäjää (Job) 3. Bradley ehdottaa (Job Match) Owenia sopivaksi henkilöksi Widgetronille 4. Widgetron palkkaa (Employment) Owenin sovelluskehittäjäksi Ohjelmistoarkkitehtuurit 21

22 Skenaarioista On tärkeää laatia skenaario niin, että jokainen skenaarion askel aiheuttaa tilanteen muuttumisen Auttaa keskittymään tietomallin kuvaamiin asioihin ja jättää turhan yksityiskohdat ja rönsyt pois On hyvä ajatella tilannekuvaa ennen ja jälkeen jokaisen askelen, mikä auttaa kytkemään käyttäytymisen tiukasti tietomalliin Ohjelmistoarkkitehtuurit 22

23 Skenaarion tilannekuvat - alkutila Ohjelmistoarkkitehtuurit 23

24 1. Askeleen jälkeen Ohjelmistoarkkitehtuurit 24

25 2. Askelen jälkeen Ohjelmistoarkkitehtuurit 25

26 3. Askelen jälkeen Ohjelmistoarkkitehtuurit 26

27 4. Askelen jälkeen Kysymys SME:lle : Ovatko Job ja Ad transientteja vai jääkö niistä pysyvä muisto? Ohjelmistoarkkitehtuurit 27

28 Skenaarioista Skenaario kertoo reaalimaailman asioista, eikä ota kantaa, miten ne ohjelmistossa toteutetaan Skenaario kuvaa yhden mahdollisen tapahtumien ketjun ja siihen liittyvät tilanteet Useimmiten muutama skenaario perustapauksista riittää UML:n tilakaaviot (State diagram) ja aktiviteettikaaviot (Activity diagram) sopivat yleisempiin kuvauksiin, jotka määrittelevät kaikkien mahdollisten tapahtumapolkujen joukon Vaativat myös enemmän työtä Ohjelmistoarkkitehtuurit 28

29 Yhteenveto Sovellusaluemalli auttaa pitämään suunnittelupäätökset erillään sovellusalueen ymmärtämiseen liittyvistä kysymyksistä Sovellusaluemalli määrittelee yhteisen kielen SME:iden ja kehittäjien välille Mallin laajuus ja syvyys on syytä päättää etukäteen miettimällä mihin kysymyksiin sen avulla pitää voida vastata ja minkälaisia erikoistilanteita ja outouksia on käsiteltävä Malli on väistämättä todellisuuden yksinkertaistus mutta sen pitää olla silti täsmällinen Nyrkkisääntö: jos jonkin sovellusalueen piirteen ymmärtämättä jääminen aiheuttaa riskin, se pitää mallintaa, muuten ei Ohjelmistoarkkitehtuurit 29

30 Huomautus Entity-Relationship mallinnus on yleisesti käytetty tietojärjestelmien tietosisällön analysointi ja määrittelyformalismi p_model Menetelmä on erityisesti tarkoitettu relaatiotietokantojen rakenteen suunnittelun apuvälineeksi ja tarjoaa hieman UML:stä poikkeavan semantiikan Kokonaisuutena UML tarjoaa monipuolisemman joukon kaaviotyyppejä sovellusalueen mallinnukseen, mutta ERmalleissa on omat vahvat puolensa (esimerkiksi täsmällisesti määritelty semantiikka!) Ohjelmistoarkkitehtuurit 30

31 SUUNNITTELUMALLIN PERUSELEMENTTEJÄ Ohjelmistoarkkitehtuurit 31

32 Arkkitehtuuriajattelun elementtejä Ennen varsinaista suunnittelumalliin perehtymistä, käydään läpi peruskäsitteitä, joilla on paitsi käytännöllinen myös käsitteellinen rooli arkkitehtuurisuunnittelussa ja arkkitehtuurityökalujen kehityksessä Komponentti Konnektori Portit ja rajapinnat Ohjelmistoarkkitehtuurit 32

33 KOMPONENTTI Ohjelmistoarkkitehtuurit 33

34 Komponentti Komponentti on arkkitehtuurielementti, joka kapseloi osan järjestelmän toiminnallisuutta ja/tai dataa ( musta laatikko ) sellaisenaan käytettäväksi ( looginen, koherentti kokonaisuus) rajoittaa ulkopuolisten pääsyn käyttämään toimintoja/dataa tarkasti määritellyn rajapinnan kautta tapahtuvaksi jolla on eksplisiittisesti määritellyt riippuvuudet suoritusympäristöönsä on sellaisenaan (konfiguroinnin jälkeen) tietokoneessa suoritettava (eli ajon aikainen elementti) Voi olla iso (osajärjestelmä tai koko järjestelmä) tai pieni (yksittäinen operaatio) Voi koostua muista komponenteista, joiden avulla toteuttaa tarjoamansa palvelun (component assembly) Näkyy ulospäin vain rajapintansa kautta = tarjoaa rajapinnan muille elementeille: määrittelee, miten elementin palveluja käytetään, mutta ei niiden toteutusta Rajapinnan toteuttava olio (tai muutama) edustaa komponenttia ulospäin vrt. legopalikka, koneen osa Ohjelmistoarkkitehtuurit 34

35 Komponentti Eksplisiittisesti määritellyt riippuvuudet vaatimukset komponenteille, joiden kanssa toimii yhteistyössä ns. vaadittu rajapinta (required interface) tarvittavat resurssit; esimerkiksi tiedostot tai hakemistot ohjelma-alusta laitteistoalusta Määrittely metadatana, pakettiriippuvuuksina, dokumentteina Komponentit voivat olla Sovellusriippuvia kehitetty tietyn sovelluksen tarpeisiin Sovellusalueriippuvia - uudelleenkäytettävissä sovellusalueen sisällä (domain specific) Yleiskäyttöisiä käytettävissä useilla sovellusalueilla Ohjelmistoarkkitehtuurit 35

36 Komponentti CBD komponentti (CBD = Component Based Development) Aikoinaan tavoiteltiin komponenttimarkkinoita, joilta olisi voitu hankkia tarvittavia ohjelmistojen binäärisiä rakennuspalikoita samaan tapaan kuin elektroniikkakomponentteja - ajatus ei toteutunut Nykyään voi kuitenkin hankkia erilaisia web-apien kautta käytettäviä palveluita (melkein sama asia): tunnistaminen, maksupalvelut jne. Niinpä nykyään useimmat komponentit jaellaan paketteina lähde- tai käännettynä koodina, josta suoritusaikainen komponentin ilmentymä instantioidaan (jonkin standardin määräämällä tavalla) Esim. ladataan pakkauksen sisältämä Java-luokka ja luodaan siitä olio, joka puolestaan luo olioita muista pakkauksen sisältämistä luokista muodostaen näiden kanssa suoritusaikaisen komponentti-instanssin Vaadin komponenttikirjasto Toisaalta - esimerkiksi node.js npm-moduulit ovat käytännössä hyvin lähellä alkuperäistä CBD-ideaa, vaikka ne jaellaankin (tulkittavana ja ajon aikana käännettävänä) lähdekoodina Ohjelmistoarkkitehtuurit 36

37 Komponentit UML 2.0:ssa Ohjelmistoarkkitehtuurit 37

38 KONNEKTORI Ohjelmistoarkkitehtuurit 38

39 Konnektori Konnektori (connector) Arkkitehtuurielementti, jonka tehtävänä on mahdollistaa ja hallita komponenttien vuorovaikutusta Esimerkkejä konnektorityypeistä: proseduurikutsu, etäproseduurikutsu, jaetun datan käyttö, sanomanvälitys, jne Vastuita Kontrollin siirto Tiedon siirto Tuki- ja alustapalvelut (facilities) esim. toiminnon käynnistys, viestinvälitys, transaktiot, persistenssi, jne Ohjelmistoarkkitehtuurit 39

40 Konnektorien tehtäviä Tyypillisiä palveluita Kommunikointi tiedonsiirto (communication) esim. sanomanvälitys Koordinointi kontrollin siirto (coordination) esim. yksinkertainen proseduurikutsu - monimutkainen kuormantasauslliittymä Konversio komponenttien vuorovaikutustapojen yhteensovitus (conversion) esim. tietomuotokonversiot, kääreet (wrappers) Toiminnan mahdollistaminen tukitoiminta (facilitation) esim. ajastus, samanaikaisuuden hallinta Ohjelmistoarkkitehtuurit 40

41 Konnektorityyppejä Konnektorityypit Proseduurikutsu (procedure call) Tapahtuma (event) Tietokytkös (data access) Linkitys (linkage) Tietovuo (stream) Välittäjä (arbitrator) Sovitin (adaptor) Välityspalvelu (distributor) Ohjelmistoarkkitehtuurit 41

42 Konnektorin toteutus Komponentit sovelluskohtaisia palveluita, konnektorit sovellusriippumattomia vuorovaikutustapoja Ohjelmistojen toteutuksessa konnektoreilla Ei usein ole omaa koodia eikä identiteettiä Ei käännösyksikkövastaavuutta Toteutus on hajautettu useaan moduuliin ja useaan vuorovaikutusmekanismiin Vrt. Java Message Service Ohjelmistoarkkitehtuurit 42

43 Konnektorit ja arkkitehtuurityylit Käsitteellisellä tasolla Keskeisiä identiteetin omaavia arkkitehtuurielementtejä Kuvaavat kaiken vuorovaikutuksen komponenttien välillä Tarvitsevat omat määritykset Konnektoreilla on usein tärkeä rooli arkkitehtuurityyleissä ja ratkaisumalleissa Vaatteet tekevät henkilön ja konnektori tyylin Mahdollistavat sovellusriippuvan toiminnallisuuden eriyttämisen komponentteihin Ohjelmistoarkkitehtuurit 43

44 RAJAPINNAT JA PORTIT Ohjelmistoarkkitehtuurit 44

45 Komponenttien rajapinnoista Ohjelmistorakennetta voidaan tarkastella komponentteina Komponentti muodostaa toiminnallisen kokonaisuuden, joka tarjoaa joukon loogisesti toisiinsa liittyviä palveluja Palvelut käyttävät samoja tietorakenteita Palveluja käytetään tyypillisesti samassa yhteydessä Toiminnallisuus peruste komponentin olemassaololle Komponentti on työnjaon perusyksikkö kaikissa kehitystyön vaiheissa Ohjelmistoarkkitehtuurit 45

46 Komponenttien rajapinnoista Yleinen ohjelmistosuunnittelun periaate: erotetaan se mitä halutaan tehdä siitä miten toiminta toteutetaan Komponentin ei pitäisi riippua tietyistä toisista komponenteista, vaan joukosta (abstrakteja) palveluja, joita muut komponentit tarjoavat Abstrakti palvelu määritellään rajapintana (interface) Vrt. palvelut (services) Java 9 moduuleissa Ohjelmistoarkkitehtuurit 46

47 Komponenttien rajapinnoista Rajapinnat määräävät tavat, joilla komponentit kommunikoivat keskenään Myös suurin osa arkkitehtuurityyleistä ja suunnittelumalleista perustuu rajapintojen käyttämiseen Huolellinen rajapintasuunnittelu edellytys Työn järkevälle jakamiselle Ohjelmiston keskeisten laatuominaisuuksien, kuten testattavuuden, ylläpidettävyyden ja muunneltavuuden varmistamiselle Rajapintasuunnittelu alkaa tyypillisesti heti keskeisten arkkitehtuuriratkaisujen tekemisen (esim. arkkitehtuurityylien valitsemisen) jälkeen Ohjelmistoarkkitehtuurit 47

48 Rajapinnan suunnittelu How to Design a Good API and Why it Matters Joshua Bloch, Google rch.google.com/en//pubs/archive/32713.pdf Ohjelmistoarkkitehtuurit 48

49 Komponenttien rajapinnoista Komponentti voi joko tarjota (eli toteuttaa) tai vaatia rajapinnan -> tarjotut ja vaaditut rajapinnat (provided and required interfaces) Tietty nimetty rajapinta on yleensä toisen komponentin vaatima ja toisen tarjoama Ohjelmointikielet, kuten Java tai C++, eivät tarjoa välineitä vaadittujen ja tarjottujen rajapintojen eksplisiittiseen kuvaamiseen komponenttien (pakkausten) tasolla (pitää kuvata ei-formaalilla dokumentaatiolla) Huom: Java 9 Moduulit lisäävät tämän Java-kieleen! Eräät komponenttiarkkitehtuurit ja sovelluskehykset taas tukevat riippuvuuksien konfigurointia ja automaattista instantiointia komponentteihin liitetyn metadatan perusteella Javan annotaatiotia voi käyttää riippuvuuksien injektointia varten (kieli ei määrittele kuitenkaan injektointimekanismia) Ohjelmistoarkkitehtuurit 49

50 Vaadittu ja tarjottu rajapinta Collection Indexer ItemList Vaadittu rajapinta (required interface) Tarjottu rajapinta (provided interface) Ohjelmistoarkkitehtuurit 50

51 Portti Portti Liitoskohta, jonka kautta komponentti on yhteydessä ulospäin Mekanismi, jolla voidaan koota yhteen rajapintoja liittämällä ne samaan porttiin, esim. roolirajapinnoiksi eri käyttäjäryhmiä varten Samaan porttiin ei kuitenkaan kannata koota selvästi yhteenkuulumattomia rajapintoja/paveluita (-> SRP) Portteja ei välttämättä tarvitse käyttää mallinnuksessa jokaisella rajapinnalla implisiittisesti oma porttinsa Porttiin voi liittyä oma protokollansa ja tilakoneensa Esimerkiksi käyttäjäistuntojen (session) hallinta Riippuu porttiin kytketyistä konnektoreista ja rajapintojen semantiikasta Käytännössä portti == rajapinta Portit liittyvät yrityksiin luoda formaalia semantiikkaa arkkitehtuurin määrittelyyn, minkä vuoksi niille voi olla vaikea nähdä vastinetta nykyohjelmointikielissä Ohjelmistoarkkitehtuurit 51

52 Portti Konnektori (connector) Portti (port) Ohjelmistoarkkitehtuurit 52

53 SUUNNITTELUMALLI Ohjelmistoarkkitehtuurit 53

54 Suunnittelumalli Suunnittelumalli sisältää arkkitehtuurin suunnittelun ja analysoinnin kannalta oleelliset suunnittelupäätökset Käsitteellisellä tasolla se on täydellinen sisältäen kaikki oleelliset suunnittelupäätökset (Master-malli) Jos laadittaisiin konkreettinen täydellinen suunnittelumalli, siitä tulisi hyvin laaja ja siksi epäkäytännöllinen Ymmärrettävyys, ylläpidettävyys Ohjelmistoarkkitehtuurit 54

55 Suunnittelumalli Täydellinen suunnittelumalli jääköön siis suunnittelijoiden mieleen, mutta siitä on silti pystyttävä laatimaan konkreettisia kuvauksia, joita voidaan efektiivisesti käyttää päätelmien tekoon arkkitehtuurista Seuraavia tekniikoita käytetään efektiivisten suunnittelumallien laadinnassa Näytetään vain ne yksityiskohdat, joita tarvitaan suunnitteluongelmien ratkomiseen Ohjelmistoarkkitehtuurit 55

56 Suunnittelumalli Näkymä (View) Projektio, joka poimii tietyn näkökulman mukaisen joukon yksityiskohtia täydellisestä Master-mallista konkreettiseksi kuvaukseksi Kapselointi (Encapsulation) Arkkitehtuurielementin malli jaetaan rajapintamalliin (boundary model) ja sisärakennemalliin (internals model) Erotetaan elementin julkisesti muille elementeille näkyvä osa (rajapinta, palvelut) sen toteutuksesta Ohjelmistoarkkitehtuurit 56

57 Suunnittelumalli Sisäkkäisyys (Nesting) Useimmilla mallin elementeillä on hienorakenne (sub-structure) Sisärakennemalli kuvaa hienorakenteen, joka esitetään sisältyvien komponenttien rajapintamallin avulla Sisältyvillä elementeillä on taas oma sisäinen rakenteensa Näin syntyy puumainen elementtihierarkia Ohjelmistoarkkitehtuurit 57

58 Yinzer Top-Level Design Model Ohjelmistoarkkitehtuurit 58

59 Yinzer-palvelun suunnittelumalli Seuraavassa käydään läpi Yinzer SoMepalvelun suunnittelumalli Ylimmän tason rajapintamalli, joka kuvaa koko järjestelmän rajapinnan muuhun maailmaan Käyttötapaukset ja toiminnalliset skenaariot, systeemikonteksti, ulos näkyvät koodimoduulit, sijoittelu laitteistoon, laatuskenaariot Ylimmän tason sisärakennemalli, joka kuvaa koko järjestelmän sisäistä suunnittelua Komponenttikokoonpano, sisäkkäiset rakennemallit Ohjelmistoarkkitehtuurit 59

60 YLIMMÄN TASON RAJAPINTAMALLI Ohjelmistoarkkitehtuurit 60

61 Ylimmän tason rajapintamalli KÄYTTÖTAPAUKSET Ohjelmistoarkkitehtuurit 61

62 Rajapintamalli Käyttötapaukset ja skenaariot UML:n käyttötapauskaaviot (use case diagram) tarjoavat kompaktin graafisen yhteenvedon Järjestelmän toiminnallisuudesta Toimijoista (Actor) ja muista järjestelmistä, joiden kanssa SUD 1 on vuorovaikutuksessa Kaavion käyttötapaukset kuvaavat järjestelmän toiminnallisuuden yleisellä tasolla, eivät mitään tiettyä yhtä skenaariota eivätkä käyttötapausten keskinäisiä riippuvuuksia (esim. suoritusjärjestys) 1 SUD = system under design, suunnitteilla oleva järjestelmä Ohjelmistoarkkitehtuurit 62

63 Käyttötapauskaavio Ohjelmistoarkkitehtuurit 63

64 Ylimmän tason rajapintamalli TOIMINNALLISET SKENAARIOT Ohjelmistoarkkitehtuurit 64

65 Toiminnalliset skenaariot Skenaariot kuvaavat täydellisiä tapahtumakulkuja, joissa SUD on vuorovaikutuksessa ulkopuolisten toimijoiden (actor) kanssa Erona sovellusaluemallin skenaarioihin nyt voidaan jo puhua Yintzer-järjestelmästä ja siihen kuuluvista jäsenistä (member) erotuksena muista ihmisistä Skenaarion kulussa voidaan jo ottaa kantaa myös suunnitteluratkaisuihin, eli miten järjestelmän toiminta näkyy järjestelmän rajapinnalla ja vuorovaikutuksessa ulkop. toimijoiden kanssa ei kuvata siis SUD:n sisäistä toiminnan kulkua Ohjelmistoarkkitehtuurit 65

66 Skenaarioesimerkki Nimi Alkutila Toimijat Kevin saa töitä Widgetron-yhtiöstä Alan ja Owen ovat jäseniä Yinzerissä; Kevin ei ole jäsen. Alan on töissä Widgetronissa Alan, Kevin, Owen, Widgetron Askelet 1. Alan kutsuu Kevinin kontaktikseen (Contact) omaan verkostoonsa (Network). / Järjestelmä lähettää Kevinille kutsun sähköpostissa. 2. Kevin klikkaa sähköpostiviestissä olevaa linkkiä, liittyy jäseneksi Yinzeriin ja hyväksyy Alanin kutsuun liittyvän kontaktipyynnön. 3. Widgetron julkaisee ilmoituksen (Ad) avoimesta ohjelmistokehittäjän toimesta (Job). / Järjestelmä automaattisesti ehdottaa Owenia rekrytoitavaksi ja lähettää hänelle sähköpostin. 4. Alan näkee ilmoituksen ja ehdottaa Keviniä toimeen. / Järjestelmä lähettää Kevinille sähköpostin. 5. Kevin saa työpaikan ja hän päivittää Yinzer-profiiliinsa uuden työnsä Widgetron-yhtiössä Ohjelmistoarkkitehtuurit 66

67 Skenaarioesimerkki Jokainen edellä olevan skenaarion erillinen askel vastaa yhtä käyttötapausmallin käyttötapausta Käyttötapausmalli kuvaa mahdolliset tapaukset, mutta skenaario kuvaa jonkin tietyn ketjun käyttötapausten suorituksia Skenaarioiden ei tarvitse käyttää kaikkia käyttötapauksia; tämä oli vain yksi esimerkki Jos käyttötapausten keskinäiset riippuvuudet ovat tärkeitä (esim suoritusjärjestys), UML:n aktiviteettikaaviot sopivat kaikkien mahdollisten laillisten polkujen (skenaarioiden) määrittelyyn yleisen (tila-)mallin avulla Ohjelmistoarkkitehtuurit 67

68 Skenaarioesimerkki Skenaariossa ei kuvattu järjestelmän käyttöliittymän yksityiskohtia Käyttöliittymää koskevat suunnittelupäätökset on tällä tasolla syytä jättää avoimiksi selkeyden vuoksi Toiminnallisissa skenaarioissa ei ole toisaalta syytäkään vielä kiinnittää käyttöliittymän suunnittelua, vaan mahdollistaa monia toteutuksia (vaihtoehtoja on!) Käytettävyydellä ja käyttöliittymän vaatimuksilla on kuitenkin usein vaikutusta arkkitehtuuriin, joten niitäkin pitää projektin aikaisessa vaiheessa alkaa miettiä Käytettävyyten ja vuorovaikutukseen liittyviä asioida voidaan käsitellä esimerkiksi laatuattribuutteina (myöh.) Ohjelmistoarkkitehtuurit 68

69 Ylimmän tason rajapintamalli SYSTEEMIKONTEKSTI Ohjelmistoarkkitehtuurit 69

70 Systeemikonteksti Kuten käyttötapauskaavio, systeemikontekstikaavio (system context diagram) näyttää SUD:n kanssa vuorovaikutuksessa olevat ulkoiset järjestelmät / toimijat Mallinnetaan komponentteina Erona toiminnallisuuteen keskittyvään käyttötapauskaavioon systeemikonteksti näyttää järjestelmiä yhdistävät kommunikaatiokanavat eli konnektorit Portit, joiden kautta kommunikaatio tapahtuu ja jotka kokoavat loogisesti yhteen kuuluvat rajapinnat samaan yhteyspisteeseen Ohjelmistoarkkitehtuurit 70

71 Yinzer - systeemikontekstikaavio Ohjelmistoarkkitehtuurit 71

72 Systeemikonteksti Systeemikontekstikaavio ottaa kantaa konkreettisiin vuorovaikutusmekanismeihin Konnektorit ja portit Käyttötapauskaavio näyttää Yinzer -jäsenen kommunikoivan suoraan järjestelmän kanssa, mutta systeemikonteksti näyttää sen tapahtuvan web-selaimen välityksellä kahden teknisesti samanlaisen mutta loogisesti erillisen kanavan ja portin kautta Lisäksi näytetään sähköpostiliikenteen kulku sähköpostipalvelimen ja sen asiakkaiden kautta Porttien tukemat käyttötapaukset määrittävät porttien roolit Käyttötapausten ja skenaarioiden kuvaamat vuorovaikutukset ulkoisten järjestelmien ja toimijoiden kanssa pitää pystyä selittämään systeemikontekstin kuvaamien kommunikaatioväylien avulla Jokaiselle käyttötapaukselle pitää olla sen mahdollistava portti / portit Ohjelmistoarkkitehtuurit 72

73 Systeemikonteksti Huomaa, että systeemikontekstikaavio näyttää komponentti-instansseja, eli ajonaikaisen tilanteen Järjestelmätason komponentti-instansseja on usein vain yksi (esim. SUD eli Yinzer), mutta asiakaskomponentteja voi olla useita näitten eri roolien havainnollistamiseksi (Yinzer-jäsenet ja ei-jäsenet) Mitä isommasta komponentista on kysymys, sitä todennäköisempää on, että siitä on olemassa vain yksi tai korkeintaan muutama instanssi järjestelmän käytössä ollessa Systeemikontekstikaavio on vain yksi esimerkki kaikista mahdollisista ajonaikaisista konfiguraatioista Asiakkaiden ja s-postipalvelimien määrä vaihtelee järjestelmän elinkaaren aikana paljonkin Ohjelmistoarkkitehtuurit 73

74 Systeemikonteksti Neuvo: Komponenttien kaikki portit ja niitä yhdistävät konnektorit pitäisi aina näyttää, kun komponentteja piirretään kaavioihin Näin on todennäköisempää, että kaavioiden avulla todella voi ymmärtää järjestelmän toimintaa Ohjelmistoarkkitehtuurit 74

75 Ylimmän tason rajapintamalli MODUULIT Ohjelmistoarkkitehtuurit 75

76 Moduulit Moduulimalli kuvaa järjestelmän ulospäin näkyviksi tarkoitetut koodimoduulit (pakkaukset) Nämä liittyvät järjestelmän porttien toteutukseen Moduulit sisältävät ne määrittelyt (luokat, rajapinnat, tietotyyypit ja niiden käyttöön vaadittavan implementaation) joita tarvitaan porttien/rajapintojen käyttöön ulkoisista ohjelmistoista Yleisempänä pyrkimyksenä on noudattaa ohjelmointityyliä, joka tekee arkkitehtuurin näkyväksi myös implementaation tasolla (eli koodimallissa) Ohjelmistoarkkitehtuurit 76

77 Moduulimalli Ohjelmistoarkkitehtuurit 77

78 Ylimmän tason rajapintamalli SIJOITTELU SUORITUSYMPÄRISTÖÖN Ohjelmistoarkkitehtuurit 78

79 Sijoittelumalli Yinzer-järjestelmän suoritusympäristö (laitteisto, tietoliikenneyhteydet) vaikuttaa merkittävästi järjestelmän suoriutumiseen tehtävistään Sijoittelukaavio (deployment diagram) kuvaa, miten järjestelmän komponenttien instanssit on allokoitu suoritusympäristön laitteistoon (palvelimet, verkot, erilaiset päätelaitteet) ja mitä kommunikaatiokanavia ne käyttävät Laiteympäristöelementit = environmental element, node Ohjelmistoarkkitehtuurit 79

80 Yinzer-sijoittelukaavio Ohjelmistoarkkitehtuurit 80

81 Sijoittelumalli Ohjelmistojen asennukseen, varmistukseen, päivitykseen ja migraatioon liittyy monenlaisia teknisiä haasteita Näistä kannattaa laatia toiminnallisia skenaarioita, jotka kuvaavat esimerkiksi ohjelmistoversion päivitykseen tai varmuuskopiointiin liittyvät työvaiheet ja järjestelmän tilan Ohjelmistoarkkitehtuurit 81

82 Ylimmän tason rajapintamalli LAATUATTRIBUUTIT Ohjelmistoarkkitehtuurit 82

83 Laatuattribuutit ja arkkitehtuuriajurit Järjestelmän laatuominaisuudet on syytä priorisoida toimivan teknisen ratkaisun löytämiseksi Priorisointi on tehtävä näkyväksi kaikille kehittäjille Laatuvaatimukset voidaan kuvata eksplisiittisemmin myös laatuattribuuttiskenaarioita käyttäen (quality attribute scenarios) Ohjelmistoarkkitehtuurit 83

84 Laatuattribuuttiskenaarioesimerkki Skenaario Lähde Heräte Ympäristö Artefakti Vastaus Mittari Koko skenaarion kulku #<tunniste> Yinzer -jäsen Web-sivun pyyntö Yinzer-palvelimelta Normaali toiminta Koko järjestelmä Palvelin palauttaa pyydetyn web-sivun Yinzer-järjestelmä lähettää vastauksen yhden (1) sekunnin kuluessa Yinzer-jäsen klikkaa linkkiä web-selaimessa; selain lähettää sivupyynnön Yinzer-palvelimelle, joka lähettää vastauksena websivun yhden sekunnin kuluessa Ohjelmistoarkkitehtuurit 84

85 Laatuattribuuttiskenaariot Todella merkittäviä laatuattribuuttiskenaarioita on yleensä vain kourallinen järjestelmää kohden Tulisi siis valita oikeasti tärkeimmät laatuominaisuudet ja niihin liittyvät konkreettiset vaatimukset skenaarioihin Laatuskenaarion määrittely on helppoa, jos attribuutilla on selkeä ja suoraviivaisesti laskettava ja mitattava mittari Esimerkiksi ylläpidettävyyteen liittyvien mittarien määrittely voi olla huomattavan hankalaa Ohjelmistoarkkitehtuurit 85

86 Arkkitehtuuriajurit Laatuattribuuttiskenaariot voidaan priorisoida 1 niiden suhteellisen tärkeyden ja toisaalta niiden toteuttamisen vaikeuden perusteella Sekä hyvin tärkeät että vaikeasti toteutettavat laatuskenaariot vaativat aivan erityistä huomiota suunnittelussa ja toteutuksessa Tämän takia niitä kutsutaan arkkitehtuuriajureiksi (architectural driver) Suunnittelupäätösten ja valintojen kelpoisuus arvioidaan niitä vasten 1 Tähän palataan kurssilla arkkitehtuurin arvioinnin yhteydessä Ohjelmistoarkkitehtuurit 86

87 Laatuominaisuuksien tasapainottelu Järjestelmän suunnittelussa jostakin laatuominaisuudesta täytyy yleensä tinkiä jonkin toisen hyväksi (trade-off) Esimerkiksi Yinzer lähettää ei-jäsenille sähköpostitse kontaktiksi -kutsun yhteydessä linkin sivulle, joka sisältää joitakin henkilökohtaisia tietoja kutsujasta Sähköpostin saaja voi klikata linkkiä ja nähdä sivun suoraan sivu ei vaadi lataajan tunnistamista. Toisaalta linkin URI:iin sisältyy suuri satunnaisluku, jonka arvaaminen ilman linkkiä on aika epätodennäköistä. Turvallisemmat ratkaisut, joissa linkin klikkaaja jollain luotettavalla tavalla tunnistettaisiin, vaikuttaisivat heikentävästi käytettävyyteen lisäämällä uusia askeleita käyttötapaukseen. Tämä voisi vähentää myös potentiaalisen jäsenen halua tulla mukaan. Nyt käyttäjä näkee hyvin nopeasti, mistä kutsussa on oikein kysymys ja voi päättää, haluaako mukaan palveluun vai ei Ohjelmistoarkkitehtuurit 87

88 Rajapintamallin yhteenveto Suunittelumallin ylimmän tason rajapintamalli (boundary model) sisältää siis seuraavat osat jotka kuvaavat järjestelmän ulospäin näkyviä piirteitä Käyttötapaukset ja toiminnalliset skenaariot Systeemikonteksti Portteihin liittyvät moduulit Sijoittelu laitteistoon Laatuominaisuudet ja laatuskenaariot Ohjelmistoarkkitehtuurit 88

89 SISÄRAKENNEMALLI Ohjelmistoarkkitehtuurit 89

90 Sisärakennemalli Komponenttikokoonpano (Component Assembly) näyttää joukon komponentti-instansseja ja niitä porttien kautta yhdistävät konnektorit Yinzer systeemikontekstikaavio on esimerkki tällaisesta konfiguraatiosta Sisärakennemalleissa komponenttikokoonpanoilla määritellään rajapintamalleissa esiteltyjen komponenttien sisäinen suunnittelu, joka piilotettiin rajapintamalleissa Ohjelmistoarkkitehtuurit 90

91 Yinzer systeemin ylimmän tason sisärakenne Ohjelmistoarkkitehtuurit 91

92 Yinzer systeemin sisärakenne Sisärakennemallissa näytetään kaikki rajapintamallissa määritellyt portit sekä komponentit, jotka loogisesti ovat systeemi-komponentin sisällä ja muodostavat sen kokoonpanon Kokoonpano näyttää, kuinka Yinzer-systeemin portit delegoivat toimintansa sisärakenteen komponenttien portteihin Ulompi portti ei itse asiassa tee mitään, vaan delegaatti hoitaa kaiken työn Porttien on oltava vähintään yhteensopivia, joskin sisempi portti voi tarjota enemmän operaatioita, jotka eivät ole näkyvissä ulommassa portissa Ohjelmistoarkkitehtuurit 92

93 Sisäkkäiset rakenteet Rajapinta- ja sisärakennemallit muodostavat rekursiivisen rakenteen Yinzer-järjestelmän rajapintamallin systeemikontekstikaavio näytti Yinzer-systeemin yhtenä komponenttina, joka oli porttiensa ja niihin kytkettyjen konnektorien kautta yhteydessä ulkoisiin toimijoihin Ylimmän tason sisärakennemalli näyttää systeemikomponentin välittömän komponenttikokoonpanon Tämä kaavio toimii samalla rajapintamallina kokoonpanon komponenteille Niillä voi olla kullakin oma sisärakennemallinsa, joka näyttää rekursion seuraavan tason kokoonpanon Ohjelmistoarkkitehtuurit 93

94 Sisäkkäiset rakenteet Sisärakenteen tarkentamista (refinement) kannattaa jatkaa vain tiettyyn rajaan asti (itse päätettävä) Jollekin tarkennustasolle tultaessa on yleensä jo järkevämpää siirtyä suoraan varsinaiseen implementaatioon (koodiin) Ohjelmistoarkkitehtuurit 94

95 Sisärakennemalli TOIMINNALLISET SKENAARIOT Ohjelmistoarkkitehtuurit 95

96 Toiminnalliset skenaariot, osa II Toiminnallisia skenaarioita voi käyttää sisärakennemallissa kuten rajapintamallissakin toiminnallisuuden kuvaamiseen Nyt skenaarion askeleisiin voi kuitenkin sisällyttää kuvauksen, mitä järjestelmän sisäiset komponentit tekevät niiden yhteydessä Ohjelmistoarkkitehtuurit 96

97 Toiminnalliset skenaariot, osa II Nimi Alkutila Toimijat Kevin saa töitä Widgetron-yhtiöstä Alan ja Owen ovat jäseniä Yinzerissä; Kevin ei ole jäsen. Alan on töissä Widgetronissa Alan, Kevin, Owen, Widgetron Askelet 1. Alan kutsuu Kevinin kontaktikseen (Contact) omaan verkostoonsa (Network). / Järjestelmä lähettää Kevinille kutsun sähköpostissa. a) Contacts-komponentti etsii Kevinin sähköpostiosoitetta Users-komponentin palveluja käyttäen. Keviniä ei löydy Yinzer-käyttäjien joukosta. b) Contacts-komponentti muodostaa sähköpostiviestin Kevinille kutsuen hänet jäseneksi Yinzeriin ja Alanin verkostoon. Contacts pyytää -komponenttia lähettämään viestin 2. Kevin klikkaa sähköpostiviestissä olevaa linkkiä, liittyy jäseneksi Yinzeriin ja hyväksyy Alanin kutsun kontaktipyynnön Ohjelmistoarkkitehtuurit 97

98 Sisärakennemalli KOMPONENTTIEN VASTUUT, SUUNNITTELURAJOITTEET Ohjelmistoarkkitehtuurit 98

99 Arkkitehtuurielementtien vastuut Mallit käyttävät lyhyitä nimiä kuvaamaan kompleksisia asioita (esim. komponentin tai portin nimi) On kuitenkin erittäin tärkeätä ymmärtää elementtien vastuut 1 (resposibility) väärinkäsitysten ja väärien oletusten välttämiseksi Mitä komponentti tietää? Mitä komponentti tekee? Mikä on sen rooli mikä ei toimisi järjestelmässä tai jäisi tekemättä, jos komponenttia ei olisi? Mikä on sen salaisuus? Vastuiden kirjaaminen on helppo ja halpa tapa lisätä mallin ymmärrettävyyttä ja käyttökelpoisuutta 1 Katso esim. Reponsibility-driven design, CRC -cards Ohjelmistoarkkitehtuurit 99

100 Rajoitteiden ohjausvaikutus Rajoitteiden (constraints) tarkoitus on ohjata (guiderails) suunnittelua ja toteutusta tunnistettujen riskien minimoimiseksi ja laatuvaatimusten saavuttamiseksi Esimerkiksi Pyritään rajoittamaan mitä käyttöjärjestelmän palveluja ohjelma saa käyttää, jotta sen siirtäminen eri käyttöjärjestelmän päälle olisi helpompaa Asetetaan komponenttien RAM-muistin käytölle yläraja, jotta ohjelma voi toimia sulautetussa järjestelmässä, jossa on vain vähän muistia käytössä Kielletään joitain komponentteja luomasta omia suoritussäikeitään (thread), koska k:n suoritusympäristö (kehys, containeri) huolehtii tästä Ohjelmistoarkkitehtuurit 100

101 Rajoitteet Yinzer-järjestelmän suunnittelussa laatuskenaario antaa tiukan rajoitteen web-sivupyynnön vastausajalle ( 1s) Yksi osa ratkaisua on vaatia asynkronisen konnektorin käyttöä web-pyyntöjä käsittelevien komponenttien ja -komponentin välillä, koska sähköpostin lähettäminen saattaa kestää arvaamattoman pitkään Rajoite on kehittäjän ystävä, ei riesa Rajoitteet on syytä dokumentoida ja automatisoida niiden valvonta (jos vain mahdollista) Ohjelmistoarkkitehtuurit 101

102 Yhteenveto Sisärakennemalli Sisäkkäisten rakennemallien muodostama puumainen hierarkia, jonka juurena on koko järjestelmäkomponentin sisärakenne komponenttikokoonpanona ja alahaaroina näitten komponenttien rakennemallit Rajapintamallin toiminnallisia skenaarioita voidaan tarkentaa komponenttien toimintojen ja yhteistyön kuvauksella Komponenttien vastuut kannattaa selittää Rajoitteet ohjaavat suunnittelua ja toteutusta laatuvaatimusten saavuttamiseksi ja riskien minimoimiseksi Ohjelmistoarkkitehtuurit 102

103 Yinzer suunnittelumallin rakenne Ylimmän tason rajapintamalli Käyttötapaukset ja toiminnalliset skenaariot Systeemikonteksti ulos näkyvät koodimoduulit sijoittelu laitteistoon laatuskenaariot Ylimmän tason sisärakennemalli Komponenttikokoonpano Tarkennetut toiminnalliset skenaariot, jotka selostavat komponenttien yhteistoiminnan Contacts -komponentin malli Komponenttikokoonpano Toiminnalliset skenaariot tarkennettuna tälle tasolle. (muitten komponenttien mallit) Ohjelmistoarkkitehtuurit 103

104 Katso myös Kurssikirjan 4. luvussa on yksityiskohtaisempi esimerkki arkkitehtuurimallien käytöstä osana riskien hallinnan perustalta lähtevää arkkitehtuurityötä (risk-driven approach) Ohjelmistoarkkitehtuurit 104