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