Sovellusalue- ja suunnittelumallit Domain Model, Design Model

Samankaltaiset tiedostot
Oppimistavoitteet. Suunnittelumalli Design Model. Suunnittelumalli. Suunnittelumalli. Suunnittelumalli SUUNNITTELUMALLI.

OA:n kanoninen malli II

OA:n kanoninen malli I

Oppimistavoitteet. Sovellusaluemalli Domain Model. Esimerkkiohjelmisto Yinzer 1. Sovellusaluemallin käyttö. Sovellusaluemallin käyttö 24.9.

Ohjelmistoarkkitehtuurit

Ohjelmistojen suunnittelu

Ohjelmistotekniikan menetelmät, UML

Arkkitehtuurin mallintaminen

Ohjelmistojen mallintaminen, mallintaminen ja UML

Koodimalli Code Model

UML:n yleiskatsaus. UML:n osat:

UML- mallinnus: Tilakaavio

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Ohjelmistojen mallintaminen Unified Modeling Language (UML)

Arkkitehtuurin mallintaminen

OA:n kanoninen malli III

Oppimistavoitteet. Arkkitehtuurin mallintaminen. Malleista ja niiden käytöstä. Malleista ja niiden käytöstä. Kommutatiivinen kaavio 22.9.

2. Olio-ohjelmoinnin perusteita 2.1

Ohjelmistojen mallintaminen, kesä 2009

Ohjelmistotekniikan menetelmät, kesä 2008

Ohjelmistoarkkitehtuurit, syksy

Oppimistavoitteet. Koodimalli Code Model. Näkymätyypit. Näkymätyypit Yksi arkkitehtuuri monta näkymää NÄKYMÄTYYPIT

Luokka- ja oliokaaviot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Ohjelmistotekniikan menetelmät, kevät 2008

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Ohjelmistojen mallintaminen kertausta Harri Laine 1

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Järjestelmäarkkitehtuuri (TK081702)

Uudelleenkäytön jako kahteen

Yhteentoimivuusalusta: Miten saadaan ihmiset ja koneet ymmärtämään toisiaan paremmin?

Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita.

Ohjelmistojen mallintaminen, kesä 2010

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

HELIA 1 (14) Outi Virkki Käyttöliittymät ja ohjlmiston suunnittelu

UML-kielen formalisointi Object-Z:lla

Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa Harri Laine 1

TIE Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely

13/20: Kierrätys kannattaa koodaamisessakin

Tietojärjestelmän osat

Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja

Dynaaminen analyysi II

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Rajapinnasta ei voida muodostaa olioita. Voidaan käyttää tunnuksen tyyppinä. Rajapinta on kuitenkin abstraktia luokkaa selvästi abstraktimpi tyyppi.

2. Olio-ohjelmoinnin perusteita 2.1

Ohjelmiston toteutussuunnitelma

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

3. Käsiteanalyysi ja käsitekaavio

Ohjelmistojen mallintaminen Tietovuokaaviot Harri Laine 1

Hieman lisää malleista ja niiden hyödyntämisestä

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus

Unified Modeling Language

UML - unified modeling language

The OWL-S are not what they seem

Valppaan asennus- ja käyttöohje

Tilakaaviot, sekvenssikaaviot (Haikala, Märijärvi ss , )

Yhteentoimivuusvälineistö

Lomalista-sovelluksen määrittely

SUD SUD. Haasteet. Haasteet Esimerkki riskilähtöisestä arkkitehtuurityöstä ja mallinnuksesta. Esimerkkitapauksen rajaukset ja oletukset

Suunnitteluvaihe prosessissa

Analyysi on tulkkaamista

Käyttötapausanalyysi ja testaus tsoft

Sisällys. 11. Rajapinnat. Johdanto. Johdanto

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

2 Ohjelmistoarkkitehtuurien kuvaus

Ohjelmistojen mallintaminen Olioiden yhteistyö Harri Laine 1

ohjelman arkkitehtuurista.

Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä

Palveluperustaiset arkkitehtuurityylit

Concurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo

ELM GROUP 04. Teemu Laakso Henrik Talarmo

Muutamia peruskäsitteitä

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

Ohjelmistojen mallinnus Ohjelmistoarkkitehtuuri Harri Laine 1

Ohjelmistojen mallintaminen olioiden elinkaaret - tilakaavio Harri Laine 1

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta.

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Arkkitehtuuripankki. Mallintamisen metamalli ja notaatiot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Olioiden yhteistyön mallintaminen

käyttötapaukset mod. testaus

Malliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki

Tiedonsiirto- ja rajapintastandardit

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Tietokantojen suunnittelu, relaatiokantojen perusteita

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Kiertokysely. Sulautetut järjestelmät Luku 2 Sivu 1 (??)

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen

Viestinvälitysarkkitehtuurit

Ohjelmistojen mallintaminen

Yhteentoimiva.suomi.fi - palvelukokonaisuuden ja työkalujen esittely

TUTKI OMAT TIETOTURVA-AUKKOSI. ENNEN KUIN JOKU MUU TEKEE SEN PUOLESTASI. F-Secure Radar Ville Korhonen

Ohjelmistoarkkitehtuuri

SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

Transkriptio:

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

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

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.) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 3

SOVELLUSALUEMALLI 10.10.2017 581385 Ohjelmistoarkkitehtuurit 4

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ä 10.10. ja 17.10. 10.10.2017 581385 Ohjelmistoarkkitehtuurit 5

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 6

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ä 10.10.2017 581385 Ohjelmistoarkkitehtuurit 7

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? 10.10.2017 581385 Ohjelmistoarkkitehtuurit 8

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 9

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! 10.10.2017 581385 Ohjelmistoarkkitehtuurit 10

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 11

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

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! 10.10.2017 581385 Ohjelmistoarkkitehtuurit 13

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 14

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

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 16

Invariantit 10.10.2017 581385 Ohjelmistoarkkitehtuurit 17

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 18

Tilannekuva 10.10.2017 581385 Ohjelmistoarkkitehtuurit 19

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 20

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 21

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 22

Skenaarion tilannekuvat - alkutila 10.10.2017 581385 Ohjelmistoarkkitehtuurit 23

1. Askeleen jälkeen 10.10.2017 581385 Ohjelmistoarkkitehtuurit 24

2. Askelen jälkeen 10.10.2017 581385 Ohjelmistoarkkitehtuurit 25

3. Askelen jälkeen 10.10.2017 581385 Ohjelmistoarkkitehtuurit 26

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

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ä 10.10.2017 581385 Ohjelmistoarkkitehtuurit 28

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 29

Huomautus Entity-Relationship mallinnus on yleisesti käytetty tietojärjestelmien tietosisällön analysointi ja määrittelyformalismi http://en.wikipedia.org/wiki/entity%e2%80%93relationshi 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!) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 30

SUUNNITTELUMALLIN PERUSELEMENTTEJÄ 10.10.2017 581385 Ohjelmistoarkkitehtuurit 31

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 32

KOMPONENTTI 10.10.2017 581385 Ohjelmistoarkkitehtuurit 33

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 34

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 35

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 https://vaadin.com/directory#!browse 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 https://www.npmjs.com/ 10.10.2017 581385 Ohjelmistoarkkitehtuurit 36

Komponentit UML 2.0:ssa 10.10.2017 581385 Ohjelmistoarkkitehtuurit 37

KONNEKTORI 10.10.2017 581385 Ohjelmistoarkkitehtuurit 38

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 39

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 40

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

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 42

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 43

RAJAPINNAT JA PORTIT 10.10.2017 581385 Ohjelmistoarkkitehtuurit 44

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 45

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 46

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 47

Rajapinnan suunnittelu How to Design a Good API and Why it Matters Joshua Bloch, Google http://static.googleusercontent.com/media/resea rch.google.com/en//pubs/archive/32713.pdf 10.10.2017 581385 Ohjelmistoarkkitehtuurit 48

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) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 49

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

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ä 10.10.2017 581385 Ohjelmistoarkkitehtuurit 51

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

SUUNNITTELUMALLI 10.10.2017 581385 Ohjelmistoarkkitehtuurit 53

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 54

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 55

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 56

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 57

Yinzer Top-Level Design Model 10.10.2017 581385 Ohjelmistoarkkitehtuurit 58

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 59

YLIMMÄN TASON RAJAPINTAMALLI 10.10.2017 581385 Ohjelmistoarkkitehtuurit 60

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

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ä 10.10.2017 581385 Ohjelmistoarkkitehtuurit 62

Käyttötapauskaavio 10.10.2017 581385 Ohjelmistoarkkitehtuurit 63

Ylimmän tason rajapintamalli TOIMINNALLISET SKENAARIOT 10.10.2017 581385 Ohjelmistoarkkitehtuurit 64

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 65

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ä. 10.10.2017 581385 Ohjelmistoarkkitehtuurit 66

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 67

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.) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 68

Ylimmän tason rajapintamalli SYSTEEMIKONTEKSTI 10.10.2017 581385 Ohjelmistoarkkitehtuurit 69

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 70

Yinzer - systeemikontekstikaavio 10.10.2017 581385 Ohjelmistoarkkitehtuurit 71

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 72

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 73

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 74

Ylimmän tason rajapintamalli MODUULIT 10.10.2017 581385 Ohjelmistoarkkitehtuurit 75

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) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 76

Moduulimalli 10.10.2017 581385 Ohjelmistoarkkitehtuurit 77

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

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 79

Yinzer-sijoittelukaavio 10.10.2017 581385 Ohjelmistoarkkitehtuurit 80

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 81

Ylimmän tason rajapintamalli LAATUATTRIBUUTIT 10.10.2017 581385 Ohjelmistoarkkitehtuurit 82

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) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 83

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 84

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 85

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ä 10.10.2017 581385 Ohjelmistoarkkitehtuurit 86

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. 10.10.2017 581385 Ohjelmistoarkkitehtuurit 87

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 88

SISÄRAKENNEMALLI 10.10.2017 581385 Ohjelmistoarkkitehtuurit 89

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 90

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

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 92

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 93

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) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 94

Sisärakennemalli TOIMINNALLISET SKENAARIOT 10.10.2017 581385 Ohjelmistoarkkitehtuurit 95

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ä 10.10.2017 581385 Ohjelmistoarkkitehtuurit 96

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ää Email-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. 10.10.2017 581385 Ohjelmistoarkkitehtuurit 97

Sisärakennemalli KOMPONENTTIEN VASTUUT, SUUNNITTELURAJOITTEET 10.10.2017 581385 Ohjelmistoarkkitehtuurit 98

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 99

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ä 10.10.2017 581385 Ohjelmistoarkkitehtuurit 100

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 Email-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) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 101

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 10.10.2017 581385 Ohjelmistoarkkitehtuurit 102

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) 10.10.2017 581385 Ohjelmistoarkkitehtuurit 103

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