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

Samankaltaiset tiedostot
OA:n kanoninen malli I

Ohjelmistoarkkitehtuurit

Sovellusalue- ja suunnittelumallit Domain Model, Design Model

Ohjelmistoarkkitehtuurit, syksy

Ohjelmistojen suunnittelu

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistotekniikan menetelmät, UML

Koodimalli Code Model

OA:n kanoninen malli II

Luokka- ja oliokaaviot

Oppimistavoitteet. Suunnittelumalli Design Model. Suunnittelumalli. Suunnittelumalli. Suunnittelumalli SUUNNITTELUMALLI.

UML- mallinnus: Tilakaavio

Ohjelmistojen mallintaminen Unified Modeling Language (UML)

Ohjelmistojen mallintaminen kertausta Harri Laine 1

2. Olio-ohjelmoinnin perusteita 2.1

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

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

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

13/20: Kierrätys kannattaa koodaamisessakin

Arkkitehtuurin mallintaminen

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät

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

Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

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

UML-kielen formalisointi Object-Z:lla

Ohjelmistotekniikan menetelmät, kesä 2008

Sisällys. 11. Rajapinnat. Johdanto. Johdanto

UML:n yleiskatsaus. UML:n osat:

ohjelman arkkitehtuurista.

Ohjelmistotekniikan menetelmät, kevät 2008

Arkkitehtuurin mallintaminen

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

Uudelleenkäytön jako kahteen

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

Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä

3. Komponentit ja rajapinnat

Ohjelmistojen mallintaminen, kesä 2009

Ohjelmistojen mallintaminen, kesä 2010

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

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

2. Olio-ohjelmoinnin perusteita 2.1

OA:n kanoninen malli III

Järjestelmäarkkitehtuuri (TK081702)

Tietojärjestelmän osat

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Ohjelmistojen mallinnus Ohjelmistoarkkitehtuuri Harri Laine 1

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

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

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

Yhteydelle voi antaa nimen kumpaankin suuntaan Sille ei tarvise antaa lainkaan nimeä Yhteysnimen asemasta tai lisäksi voidaan käyttää roolinimiä

Ohjelmistotekniikan menetelmät Luokkamallit ohjelmiston mallintamisessa Harri Laine 1

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

Malliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki

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

Suunnitteluvaihe prosessissa

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Paikkatietojen tietotuotemäärittely

Yhteentoimivuusvälineistö

Suunnittelumallien käyttö ohjelmistosuunnittelussa

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Arkkitehtuuripankki. Mallintamisen metamalli ja notaatiot

Paikkatietojen tietotuotemäärittely

Korkeakoulujen yhteentoimivuusmalli

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

3. Käsiteanalyysi ja käsitekaavio

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Kertaus: yleistys-erikoistus ja perintä

Johdatus sovellussuunnitteluun, s99, osa3 Helsingin yliopisto;/tktl Harri Laine 1. Olioiden väliset yhteydet. Olioiden väliset yhteydet

Valppaan asennus- ja käyttöohje

Johdatus sovellussuunnitteluun, s99, osa3 Helsingin yliopisto;/tktl Harri Laine 1. Olioiden väliset yhteydet. Olioiden väliset yhteydet

Palveluperustaiset arkkitehtuurityylit

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä

Sisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.

The OWL-S are not what they seem

Kurssin aihepiiri: ohjelmistotuotannon alkeita

Johtamisen haaste kokonaisarkkitehtuuri menestyksen mahdollistajako?

Sisällys. JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta. Abstraktin luokan idea. Abstrakti luokka ja metodi. Esimerkki

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

812341A Olio-ohjelmointi Peruskäsitteet jatkoa

Ohjelmistojen mallintaminen

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

Unified Modeling Language

Ohjelmistojen mallintaminen viikon 4 laskareiden mallivastauksia

Ohjelmistojen mallintaminen Olioiden yhteistyö Harri Laine 1

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

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Rajapinnat ja sisäluokat

Yhteentoimivuusalusta ja sen hyödyntäminen kuntien/maakuntien taloushallinnossa Petri Tenhunen, VRK

Tiedonsiirto- ja rajapintastandardit

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Harjoitustehtävät ja ratkaisut viikolle 48

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. II Johdanto olio-ohjelmointiin

Dynaaminen analyysi II

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Ohjelmistoarkkitehtuuri

ELM GROUP 04. Teemu Laakso Henrik Talarmo

Viestinvälitysarkkitehtuurit

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

Ohjelmistoarkkitehtuurit kevät

Transkriptio:

Oppimistavoitteet Sovellusaluemalli Domain Model Luento 8 Sovellusalueen mallintaminen Tietomalli, invariantit, toiminnalliset skenaariot Suunnittelun mallintamisen perusteet Komponentit, konnektorit, rajapinnat ja portit 24.9.2015 581385 Ohjelmistoarkkitehtuurit 1 24.9.2015 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.) 24.9.2015 581385 Ohjelmistoarkkitehtuurit 3 SOVELLUSALUEMALLI 24.9.2015 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) Liiketoimintamallin perusteella voidaan päättää, mitä liiketoiminnan prosesseja automatisoidaan, ja sovellusaluemallin avulla kuvataan automatisoitavan osuuden piirteet 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 5 24.9.2015 581385 Ohjelmistoarkkitehtuurit 6 1

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 kehittäjillä on tyypillisesti paljon teknisiä haasteita ja hankalia laatuominaisuuksia 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ä 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? 24.9.2015 581385 Ohjelmistoarkkitehtuurit 7 24.9.2015 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 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! 24.9.2015 581385 Ohjelmistoarkkitehtuurit 9 24.9.2015 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 Sovellusaluemallin osat Tietomalli (Information model) Invariantit ja rajoitteet (Invariants, constraints) Tilannekuva (snapshot) Toiminnallinen skenaario (functionality scenario) 24.9.2015 581385 Ohjelmistoarkkitehtuurit 11 24.9.2015 581385 Ohjelmistoarkkitehtuurit 12 2

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! Tyyppi Ad (mainos) Company (yhtiö) Contact(kontakti) Employment (työsuhde) Job (työ, toimi) Job Match (rekrytointiehdotus) Person (henkilö) Tekstimuotoinen tietomalli 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 13 24.9.2015 581385 Ohjelmistoarkkitehtuurit 14 Tietomalli UML-kaaviona Tyyppien (luokat) väliset suhteet (assosiaatiot) ja suhteisiin liittyvät määrälliset rajoitukset ovat suoraan näkyvissä 24.9.2015 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 16 Invariantit 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 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 17 24.9.2015 581385 Ohjelmistoarkkitehtuurit 18 3

Tilannekuva 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 Skenaariot kuvaavat tapahtumasarjoja, jotka aiheuttavat muutoksia tilanteista toisiin 24.9.2015 581385 Ohjelmistoarkkitehtuurit 19 24.9.2015 581385 Ohjelmistoarkkitehtuurit 20 Skenaarioesimerkki Skenaarioista Nimi Alkutila Toimijat Owen saa töitä Widgetronista Bradleyon töissä Widgetron -yhtiössä Owen, Bradley, Widgetron Askelet 1. Owen ja Bradleytapaavat ammatillisessa konferenssissa, vaihtavat käyntikortteja ja liittyvät toistensa verkostoon (Contact) 2. Bradleyn työnantaja (Company) Widgetron julkaisee hakuilmoituksen (Ad) sovelluskehittäjän toimeen (Job) 3. Bradley ehdottaa (Job Match) Owenia sopivaksi henkilöksi Widgetronille 4. Widgetron palkkaa (Employment) Owenin sovelluskehittäjäksi 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 21 24.9.2015 581385 Ohjelmistoarkkitehtuurit 22 Skenaarion tilannekuvat - alkutila 1. Askeleen jälkeen 24.9.2015 581385 Ohjelmistoarkkitehtuurit 23 24.9.2015 581385 Ohjelmistoarkkitehtuurit 24 4

2. Askelen jälkeen 3. Askelen jälkeen 24.9.2015 581385 Ohjelmistoarkkitehtuurit 25 24.9.2015 581385 Ohjelmistoarkkitehtuurit 26 4. Askelen jälkeen Kysymys SME:lle : Ovatko Job ja Ad transientteja vai jääkö niistä pysyvämpi muisto sovellusalueelle? Skenaarioista Skenaario kertoo reaalimaailman asioista, eikä ota kantaa, miten ne ohjelmistossa toteutetaan Skenaario kuvaa yhden mahdollisen tapahtumien polun 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 polkujen joukon Vaativat myös enemmän työtä 24.9.2015 581385 Ohjelmistoarkkitehtuurit 27 24.9.2015 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 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%93relatio nship_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 ER-malleissa on omat vahvat puolensa 24.9.2015 581385 Ohjelmistoarkkitehtuurit 29 24.9.2015 581385 Ohjelmistoarkkitehtuurit 30 5

Arkkitehtuuriajattelun elementtejä SUUNNITTELUMALLIN PERUSELEMENTTEJÄ Ennen varsinaista suunnittelumalliin perehtymistä, käydään läpi peruskäsitteitä, joilla on merkittävä käytännöllinen ja myös käsitteellinen rooli arkkitehtuurisuunnittelussa Komponentti Konnektori Portit ja rajapinnat 24.9.2015 581385 Ohjelmistoarkkitehtuurit 31 24.9.2015 581385 Ohjelmistoarkkitehtuurit 32 Komponentti KOMPONENTTI Komponentti on arkkitehtuurielementti, joka kapseloi osan järjestelmän toiminnallisuutta ja/tai dataa rajoittaa pääsyn tähän osaan tarkoin määritellyn rajapinnan kautta tapahtuvaksi ja jolla on eksplisiittisesti määritellyt riippuvuudet suoritusympäristöönsä. 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 33 24.9.2015 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 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ähdetai 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 35 24.9.2015 581385 Ohjelmistoarkkitehtuurit 36 6

Komponentit UML 2.0:ssa KONNEKTORI 24.9.2015 581385 Ohjelmistoarkkitehtuurit 37 24.9.2015 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 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 39 24.9.2015 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) 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 24.9.2015 581385 Ohjelmistoarkkitehtuurit 41 24.9.2015 581385 Ohjelmistoarkkitehtuurit 42 7

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 RAJAPINNAT JA PORTIT 24.9.2015 581385 Ohjelmistoarkkitehtuurit 43 24.9.2015 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 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) Minimaalinen rajapintamäärittely: palveluiden kutsumuodot (signatures) kutsu voi olla muutakin kuin paikallinen tai etäproseduurikutsu Esim. viesti-/tapahtumapohjainen protokolla 24.9.2015 581385 Ohjelmistoarkkitehtuurit 45 24.9.2015 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 Rajapinnan suunnittelu How to Design a Good API and Why it Matters Joshua Bloch, Google http://lcsd05.cs.tamu.edu/slides/keynote.pdf 24.9.2015 581385 Ohjelmistoarkkitehtuurit 47 24.9.2015 581385 Ohjelmistoarkkitehtuurit 48 8

Komponenttien rajapinnoista Vaadittu ja tarjottu rajapinta 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 rajapintojen eksplisiittiseen kuvaamiseen komponenttien (pakkausten) tasolla (pitää kuvata eiformaalilla dokumentaatiolla) 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) Sorter Vaadittu rajapinta (required interface) Collection List Tarjottu rajapinta (provided interface) 24.9.2015 581385 Ohjelmistoarkkitehtuurit 49 24.9.2015 581385 Ohjelmistoarkkitehtuurit 50 Portti Portti Portti Liitoskohta, jonka kautta komponentti on yhteydessä ulospäin Mekanismi, jolla voidaan koota yhteen rajapintoja liittämällä ne samaan porttiin, esim. roolirajapinnaksi Portteja ei välttämättä tarvitse käyttää mallinnuksessa jokaisella rajapinnalla implisiittisesti oma porttinsa Porttiin voi liittyä oma protokollansa ja tilakoneensa Riippuu porttiin kytketyistä konnektoreistaja rajapintojen semantiikasta 24.9.2015 581385 Ohjelmistoarkkitehtuurit 51 Konnektori (connector) Portti (port) 24.9.2015 581385 Ohjelmistoarkkitehtuurit 52 9