Ohjelmistoarkkitehtuurin suunnittelu · 2017. 9. 26. · – Kaikki mahdolliset (sisäisesti...

Ohjelmistoarkkitehtuurinsuunnittelu

Luento 4

26.9.2017 1581358 Ohjelmistoarkkitehtuurit

Oppimistavoitteet

• Rationaalinen ja empiirinensuunnittelumenetelmä

• Frank Buschmannin versio ”Walking skeleton”–projektipatternista

• Mallien käyttö suunnittelussa


RATIONAALINEN JA EMPIIRINENSUUNNITTELUMENETELMÄ

Miten suunnittelijat suunnittelevat?

26.9.2017 581358 Ohjelmistoarkkitehtuurit 3

Suunnittelusta• Tarkastellaan ohjelmistoarkkitehtuurin

suunnittelumenetelmiä eli metodologioita– Miten asiantuntija ratkoo suunnitteluongelmia?– Millaisia suunnittelutekniikoita tai -strategioita hän käyttää

ajattelutyössään?– Miten työ etenee ongelman määrittelystä sen ratkaisuun?

• Tämä osuus perustuu pääasiassa seuraaviin lähteisiinBrooks, F. P. JR.: The Design of Design. Addison Wesley,

Pearson Education, 2010.Buschmann, F.: Learning from Failure, Part 2: Featuritis,

Performitis, and Other Diseases. Software, IEEE , vol.27,no.1, pp.10,11, Jan.-Feb. 2010


Suunnittelun rationaalinen menetelmä

• Lähtökohtana on oletus, että suunnitteluongelma ja ongelmanratkaisun vaatimukset, tavoitteet ja rajoitteet voidaan määritelläriittävän tarkasti etukäteen

• Itse suunnittelutyö on etsintää, jossa järjestelmällisesti1) generoidaan mahdollisia ratkaisuja2) evaluoidaan ratkaisut (ratkaisun ’arvo’ voitava määrittää)3) valitaan paras

• Ratkaisu kuvataan puumaisena rakenteena (design tree), jossa– kukin solmu vastaa jotain tiettyä asiaa koskevaa suunnittelupäätöstä– Jokainen päätös kiinnittää jonkin ratkaisun piirteen, ja päätösten

tekojärjestyksellä on väliä (yksi päätös voi sulkea joukon muita pois)– Päätökset voivat olla keskenään vaihtoehtoisia– … mutta niiden välillä voi olla monimutkaisempiakin riippuvuuksia– Kaikki mahdolliset (sisäisesti ristiriidattomat) päätöspuut muodostavat

yhdessä ratkaisuavaruuden, josta optimaalinen ratkaisu (puu) etsitään


Herätyskellon osittainen päätöspuu


Electriclight

Phosp.light

Clock

AlarmVisibility

controlsound setting

…. …

Luminousdial

Plaindial

vaihtoehtoisia

Rationaalinen suunnittelumetodi• Goal (primääritavoite)• Desiderata (sekundääriset tavoitteet)• Utility function (ratkaisun hyödyllisyyden ja hyvyyden mittaava arvofunktio)• Constraints (budget, resource allocations)• Design tree decisions

– UNTIL (”good enough”) or (time runs out)• DO another design (to improve utility function)

– UNTIL design is complete // design == tree)» WHILE design remains feasible, make another design decision // constraints» END WHILE» Backtrack up design tree» Explore a path not searched before

– END UNTIL• END DO• Take best design

– END UNTIL


Rationaalinen menetelmä

• Rationalisti uskoo, että saatuaan oikeankoulutuksen, kasvattavaa kokemusta jatekemällä riittävän paljon tarpeeksi huolellistaajatustyötä, suunnittelija voi tehdävirheettömän ja riittävän hyvän suunnitelman

• Suunnittelumetodi tähtää virheettömyydensaavuttamiseen suunnitteluvaiheessa


Rationaalisen menetelmän kritiikkiä1

• Tavoitteet ja vaatimukset ovat harvoin riittäväntarkasti selvillä etukäteen ja ne muuttuvat– ”We don’t really know the goal when we start”

• Koskee erityisesti tuotesuunnittelua• Suunnittelupuun rakenne on ongelmallinen

– Puun rakennetta ei yleensä tunneta etukäteen, vaanse löytyy suunnittelutyön aikana; päätökset avaavatuusia aiemmin tuntemattomia mahdollisuuksia

– Kombinatorinen räjähdys: suunnittelupäätöstenjärjestys voi vaikuttaa radikaalisti puun rakenteeseen;yksittäisillä päätöksillä saattaa riippuvuuksien jasivuvaikutusten kautta olla globaalia vaikutusta

1Brooks, F. P. JR.: The Design of Design. Addison Wesley, Pearson Education, 2010.26.9.2017 9581358 Ohjelmistoarkkitehtuurit

Rationaalisen menetelmän kritiikkiä

• Hyvyysfunktion (utility function)inkrementaalinen evaluointi ei aina olemahdollista– Sen voi evaluoida vasta kun koko päätöspuu on valmis

lehtiä myöten• Suunnittelijat eivät vain tee työtään näin…

– Käytännössä suunnittelutyö näyttää oskilloivan erisuunnitteluongelman alueiden ja niiden (osa-)ratkaisujen välillä sekä osaratkaisujen koostamisenvälillä (top-down & bottom-up vuorotellen)

– Aloittelevalle suunnittelijalle rationaalinen malli voikuitenkin antaa jonkinlaisen lähtöpisteen työhönsä


Empiirinen menetelmä

• Ongelmia ei pystytä määrittelemään täysin etukäteeneikä ratkaisuehdotuksia evaluoimaan ilman konkretiaa– Ihminen ei pysty virheettömän suunnitelman tuottamiseen– suunnittelun viat löydetään kokeellisesti

• Suunnittelu ja toteutus etenevät rinnakkain (iteroiden)*– Ratkaistaan ensin joitakin ongelmia– Testataan ratkaisujen toimivuus– Katsotaan, mihin uusiin avauksiin ja mahdollisuuksiin

tehdyt ratkaisut johtavat• "Design isn't simply selecting from alternatives, but

also realizing their existence"*Katso myös: Basil, V., and Turner, A. "Iterative enhancement: A practical technique for software development.“Software Engineering, IEEE Transactions on 4 (1975): 390-396.26.9.2017 11581358 Ohjelmistoarkkitehtuurit

Empiirisiä menetelmiä

• Co-evoluutio1


määrittely 1 määrittely 2 määrittely 3

Prototyyppi 1 Prototyyppi 2 Prototyyppi 3

Vaatimusmäärittely

Ratkaisun kehittäminen

1 Maher M., Tang H.-H.: Co-evolution as a computational and cognitive model of design.Research in Engineering Design Volume 14, Issue 1, 2003, pp 47-64.

Empiirisiä menetelmiä• Open Source –kehitysmenetelmät (Raymondin

”Bazaar”)– Evolutiivinen, ohjelmiston kasvattamiseen pyrkivä

malli– Kuka tahansa jonkin tarpeen näkevä voi tarjota siihen

ratkaisua– Avoin kilpailu vaihtoehtoisten ratkaisujen välillä (ála

evoluutio)– Joukkotestaus, paremmat bugikorjaukset– Toimii hyvin, kun suunnittelijat ja toteuttajat ovat itse

myös käyttäjiä (vaatimukset, ratkaisujenevaluointikriteerit)


Empiirisiä menetelmiä -Spiraalimalli1

• ”Metaprosessimalli” projektikohtaisen kehitysmenetelmänlöytämiseksi

• Kehitys tapahtuu sykleissä, joissa1. selvitetään projektin menestymisen kannalta kriittisten

sidosryhmien asettamat tavoitteet syklille2. Tunnistetaan riskit ja kehitetään ja evaluoidaan vaihtoehtoisia

ratkaisuja3. Kehitetään ja testataan ratkaisu, jolla tavoitteet saavutetaan4. haetaan sidosryhmien hyväksyntä ja lupa seuraavaan

kierroksen (syklin) käynnistämiseen• Projekti voi yhdistellä osia eri kehitysmenetelmistä sillä

perusteella, miten ne sopivat projektin riskien voittamiseen– Eri sykleissä voidaan noudattaa eri menetelmiä


1http://en.wikipedia.org/wiki/Spiral_model

Empiirisiä menetelmiä -Spiraalimalli

• Life Cycle Architecture –kontrollipiste(myöhempi lisäys alkuperäiseen malliin)

– Onko olemassa riittävän hyvin määritelty ja kaikkiensidosryhmien tavoitteet täyttävä ratkaisu ja onkokaikki riskit eliminoitu tai minimoitu?

– “’Hazardous spiral look-alikes’ that violate thisinvariant include evolutionary and incrementalprocesses that commit significant resources toimplementing a solution with a poorly definedarchitecture.”1


1http://en.wikipedia.org/wiki/Spiral_model

Suunnittelua tiimityönä?• Brooks korostaa käsitteellisen eheyden (conceptual

integrity) merkitystä– Sama asia tehdään vain yhdellä ja samalla tavalla eri puolilla

järjestelmää• Hänen mukaansa yhteistoiminnallinen reaaliaikainen

(kollaboratiivinen) suunnittelu ei toimi, muttaparityöskentelyssä on taikaa– Suunnittelu vaatii itsenäistä miettimistä ja keskittymistä– Reaaliaikainen kollaboraatio toimii suunnitelmien

katselmoinnissa, mutta ei itse suunnittelussa• Jossain määrin ongelmallinen asia emergenssiä korostaville

ketterille menetelmille– Ei yleensä erillistä arkkitehdin roolia, mutta tarvitaan kuitenkin

vahvoja, suunnittelupäätöksiin kykeneviä yksilöitä tiimissä


Esimerkki - ”Walking skeletons”

• Frank Buschmann selostaa empiirisenkoulukunnan näkemyksiä noudattavanlähestymistavan ohjelmistoarkkitehtuurinsuunnitteluun Pragmatic Architectkolumnissaan1

– Tavoitteena erityisesti arkkitehtuurintarkoituksenmukaisuus ja eräiden ei-toivottujenilmiöiden välttäminen

– Ei mene suunnitteluprosessin yksityiskohtiin,mutta antaa suuntaviivat


1Buschmann, F.: Learning from Failure, Part 2: Featuritis, Performitis, and OtherDiseases. Software, IEEE , vol.27, no.1, pp.10,11, Jan.-Feb. 2010

Vältettäviä asioita

• Featuritis – toiminnallisuuden toteuttamisenkorostaminen laatuominaisuuksien kustannuksella

• Flexibilitis – arkkitehtuurin kuormittaminentarpeettoman laajoilla laajennos-, sovitus- jakonfigurointimekanismeilla

• Performitis – projektin loppusuoralla suorituskykyhavaitaan huonoksi, mikä johtaa laajamittaiseenpaikalliseen optimointiin ja häkkäykseen globaalinstrategian puuttuessa– ongelmien perimmäisenä syynä usein kaksi edellistä

”tautia”


Luuranko

• Walking skeleton1 – ohjelmistonperusarkkitehtuuri (baseline), joka tukee– Tärkeimpien arvoa tuottavien toiminnallisuuksien

toteuttamista (business case)– Haastavimpien laatuvaatimusten toteuttamista– Ohjelmistotuoteperheen rakentamista (variability)

• Yllä mainittuun kolmeen ryhmään kuuluvatvaatimukset ovat arkkitehtuurin kannaltamerkittävimpiä vaatimuksia (ArchitecturallySignificant Requirements)


[1] http://alistair.cockburn.us/Walking+skeleton

…joka kävelee

• Ketterässä kehityksessä luuranko onsuoritettavaa koodia eli se ”kävelee”

• Empirismi– Testaus– Ominaisuuksien mittaus– Vaatimusten validointi


Sovellusalueen merkitys

• Sovellusalueen käsitteet ja ilmiöt ohjaavatmerkittävällä tavalla perusarkkitehtuurinsuunnittelua– Arkkitehtuurissa suunniteltujen komponenttien

vastuiden ja yhteistoiminnan pitää heijastaasovellusalueen käsitteitä, olioita ja prosesseja

• Tämä mahdollistaa vaaditun toiminnallisuudenjärkevän toteuttamisen (esim. riittävät tietomallit)– Sovellusalueen paikalliset muutokset jäävät

todennäköisemmin paikallisiksi myös ohjelmistossa*


*Vrt. Bob Martinin ”Clean Architecture”

Käyttötapaukset

• Koko ohjelmiston ”läpi menevät” (end-2-end)käyttötapaukset ja skenaariot ohjaavatperusarkkitehtuurin suunnittelua kattamaansovellusalueen eri osat– Suppea mutta edustava joukko tärkeimmät

suunnitteluhaasteet esiin tuovia käyttötapauksia– Laatuvaatimusten tulisi tulla esille skenaarioissa

• Sovellustoiminnallisuuden suhde laatuvaatimuksettoteuttavaan infrastruktuuriin


Suunnittelutyön kulku• Suunnittelu lähtee liikkeelle arkkitehtuuristen vaatimusten

(ASR) kannalta relevanttien käyttötapausten peruskuluista(main success & failure scenarios)

• Vasta kun peruskulut toteuttava arkkitehtuuri on vakaa jase toimii, aletaan ottaa harkiten mukaan näiden variaatioitaja laajennoksia seuraavissa iteraatioissa– Piirremalleja voidaan käyttää apuna (myöhemmin kurssilla)

• Luurangon ympärille kasvatetaan lihaksia, ei läskiä

• Sama perusajattelu on nähtävissä RUP-prosessikehyksessä1,jossa elaboration -vaihe tuottaa ”suoritettavanarkkitehtuurin”, eli järjestelmän todistettavasti toimivanluurangon (tosin se voi olla vain malli)


1https://en.wikipedia.org/wiki/Rational_Unified_Process

Yhteenveto suunnittelumenetelmistä

• Rationaalinen malli ei käytännössä yleensä toimi– Voi soveltua kuitenkin rajattuihin, matemaattisessa

mielessä hyvin määriteltyihin ongelmiin• Empiiriset menetelmät (iteroivat ja evolutiiviset)

sopivat paremmin reaalimaailman projekteihin,joissa erehtyväiset ihmiset toimivatepätäydellisen tiedon varassa– Vuorottelu ongelma- ja ratkaisuavaruuden välillä,

prototyypit ja validointi– Ratkaisujen rakentaminen mahdollista sekä top-down

(osittamalla, divide & conquer) että bottom-up(osaratkaisuista kokoamalla)


MIHIN MALLEJA TARVITAAN?Ohjelmistoarkkitehtuurin mallintaminen


Malleista ja niiden käytöstä

• 1Malli =esine, kuva, kuvio, kaava tms., jonka mukaan

tehdään jtak t. josta havainnoidaan jtak. […]Erik.

[…]• b. jtak kuviona, kaaviona tm. havainnollistava esitys.

Molekyylin kolmiulotteinen malli. Atomiytimen malli.Väestön kehitystä kuvaava matemaattinen malli.

[…]


1MOT Sanakirja

Malleista ja niiden käytöstä

• Yksinkertaiset ongelmat voidaan ratkaistasuoraan (ratkaisu on ilmeinen)

• Monimutkaiset reaalimaailman ongelmat vaativatasian kuvaamista abstraktina mallina (jokapelkistää ongelman ytimen) ja sen ratkaisemistaensin mallissa, minkä jälkeen ratkaisu siirretäänreaalimaailman implementaatioksi– Esimerkiksi matemaattisten mallien käyttö

rakenteiden lujuuslaskennassa jne.– 3D-mallien käyttö rakennusten suunnittelun apuna


Kommutatiivinen kaavio


Reaalimaailmanongelma

Reaalimaailmanratkaisu

Abstraktiongelma

Abstraktiratkaisu

Mallien käyttö

• Ongelman laajuus ja monimutkaisuus vaatiiabstrahointia (eli yksityiskohtien karsimista)– On nähtävä metsä puilta– Yksittäistä luokkaa, moduulia tai suunnittelumallin

ilmentymää laajempien kokonaisuuksienhahmottaminen ja niiden roolin ymmärtäminen

– Suuren ohjelmiston koodin lukeminen rivi riviltäsen arkkitehtuurin ymmärtämiseksi onkäytännössä mahdotonta


Mallien käyttö

• Abstraktiot pelkistävät ongelmia ja tarjoavatmahdollisuuden kehittää työkaluja– Oikein laadittu abstraktio vangitsee reaalimaailman

ongelman oleelliset piirteet, jotka vaikuttavathyväksyttävän ratkaisun muodostamiseen

• ’Turhat’ yksityiskohdat karsitaan pois– Abstraktiin malliin voidaan käyttää erityisiä työkaluja

ongelmien ratkaisemiseksi• Esim moduulien/luokkien uudelleensijoittelu

kirjastoihin/pakkauksiin haitallisiksi havaittujenriippuvuuksien karsimiseksi ja heijastusvaikutustenvähentämiseksi


Mallien käyttö

• Mallit helpottavat päätelmien tekemistäjärjestelmän ominaisuuksista– Malli auttaa päättämään, mitkä yksityiskohdat ja

suunnittelupäätökset ovat tärkeitälaatuominaisuuksien ja niiden toteutumisenarvioinnin kannalta

– Malli voi olla luonnosmainen ja/tai pelkästäänanalysoijan mielessä


Web-palvelimen malliluonnos


Client(s) Server(s) Database(s)

Asiakkaan yksi web-sivun pyyntövoi aiheuttaa monia tietokantahakuja

Asiakkaan kokema viive pyyntöön vastaamisessa =Viestinvälitykseen kuluva aika + palvelimen pyynnön prosessointiaika +(tietokantahakuun kuluva aika x hakujen lukumäärä)

Web-palvelimen malliluonnos• Kun edellisen mallin suoritusajoille annetaan

arviot (esim. 10 + 10 + n x 25ms), niin mallinperusteella on helppo nähdä, ettätietokantakyselyihin kuluva aika dominoiasiakkaan kokemaa viivettä– Normalisoitu, hierarkinen relaatiotietokanta vs.

normalisoimaton ”flat” –tietomalli• -> Tietokantahakujen määrässä voi olla kertaluokan ero

• Malli jättää monia yksityiskohtia huomiotta(cache:t, jonotus*), mutta tällaisenaankin se onhyödyllinen analyysin kannalta


*) samanaikaisten pyyntöjen aiheuttaman jonotuksen ja resurssikilpailun mallintaminenei ole sekään erityisen vaikeaa oikeilla työkaluilla ja matem. mallinnusmenetelmillä

Mallien käyttö

• Mallit karsivat ongelman ratkaisussakäsiteltäviä yksityiskohtia– Malli valikoi ongelman ratkaisemisen kannalta

oleelliset asiat ja jättää muut pois– Malli on aina jossain mielessä epätäydellinen,

mutta reaalimaailman ”täydellinen malli” olisi liiansuuri ja hankala käsiteltäväksi ja käsitettäväksi

– ”Essentially, all models are wrong but some areuseful.”


Mallien käyttö

• Mallit tehostavat päätelmien ja arviointientekemistä– Suunnittelija voi keskittyä vain pieneen joukkoon

suunnittelupäätöksiä/yksityiskohtia kerrallaan(=työmuisti ja kognitio)

– Käsitteellinen tai konkreettinen malli auttaasuhteuttamaan ratkaisun eri yksityiskohtiatoisiinsa ja havaitsemaan ja analysoimaan niidenvälisiä riippuvuuksia ja rajoitteita


Mallien käyttö

• Kysy ensin mitä haluat tietää ja laadi malli vastasitten– Ei malleja mallinnuksen vuoksi– Samasta asiasta voidaan laatia erilaisia malleja eri

käyttötarkoituksiin (suorituskyky, turvallisuus,riippuvuuksien hallinta jne.) !

• Arkkitehtuurityössä malleista on hyötyä ja ne ovatusein jopa välttämättömiä, mutta konkreettisiamalleja pitäisi laativa vain todelliseen tarpeeseen,ei varmuuden vuoksi


OHJELMISTOARKKITEHTUURINMALLIT JA NIIDEN RAKENNE


Ohjelmistoarkkitehtuurinmallintaminen

• Fairbanks esittää kanonisen1 rakenteenohjelmistoarkkitehtuurin malleille– Määrittelee minkälaisia asioita

ohjelmistoarkkitehtuurin mallin pitäisi yleisestiottaen kuvata

• metamalli tai mallinnusstandardi

– Kattaa koko arkkitehtuuriratkaisun ainasovellusalueen käsitteistä toteutuksen koodiin jalaitteistosijoitteluun asti


1) Ohjeellinen, esikuvallinen - MOT Kielitoimiston sanakirja


• Kanoninen rakenne antaa myös käsitteellisen kehyksen(conceptual model) ohjelmistoarkkitehtuurille– Kehys tukee OA:n suunnittelua ohjaamalla

suunnittelutyötä tietynlaisten kysymysten ja rakenteidenpohtimiseen

– Ohjaa jakamaan ohjelmistoa koskevien faktojen käsittelynsopivalle abstraktiotasolle

• Ei ole kuitenkaan tarkoitus, että jokaisestaohjelmistoprojektista laaditaan kanonisen rakenteenmukainen kattava kuvaus– Projektit valikoivat todellisen tarpeen mukaan, mitä osia

arkkitehtuurista mallinnetaan kanonisen metamallinsääntöjä noudattaen



• Harhakäsityksiä– Jokaisen projektin pitää dokumentoida

arkkitehtuurinsa: väärin. Arkkitehtuurimalleja jadokumentteja kannattaa laatia vain kun ne auttavatpienentämään (projekti- ja tuote-) riskejä

– Arkkitehtuurin dokumentaation pitää olla ainakattava: väärin. Mallinnuksen pitäisi kohdistuariskipitoisimpiin ratkaisun osa-alueisiin(laatuominaisuuksiin).

• Laaja dokumentaatiokin saattaa joskus olla tarpeen,esimerkiksi erityisen kommunikointitarpeen tyydyttämiseksi!



– Suunnittelun pitäisi aina edellyttää koodausta:väärin. Projektin aikaisessa vaiheessa tehtyratkaisun osittainen toteutus ja prototypointivoivat auttaa tunnistamaan hankalimmatongelmat.

• Vrt. Walking Skeleton


Kanonisen rakenteen perusideat

• Arkkitehtuurin malli (jatkossa a-malli) jakautuukolmeen osamalliin1. Sovellusaluemalli (domain model)2. Suunnittelumalli (design model)3. Koodimalli (code model)

• Sovellusaluemalli on abstraktein ja koodimallikonkreettisin (lähimpänä toteutusta)

– Vastaavuus- ja tarkennussuhteet (designation andrefinement) kytkevät osamallit toisiinsa


Kanoninen rakenteen perusideat

• Osamallit voivat periaatteessa olla hyvinlaajoja, mutta näkymillä (view) voidaansuodattaa ja poimia esiin vain tietynnäkökulman kannalta mielenkiintoisia faktoja– Käytännössä a-mallin fyysinen ilmentymä

(kaaviokokoelma, dokumentti) koostuu aina tietyinperustein valituista näkymistä

– ”Täydellinen” malli voi olla olemassa vainsuunnittelijoiden mielissä


Kanoninen rakenteen perusideat

• Malli jakaa erilaiset faktat toteutettavastaohjelmistosta omiin osamalleihinsa– ”Laskutusjakso on 30 vuorokautta”– ”Ladatut fonttiresurssit pitää aina eksplisiittisesti

vapauttaa”– ”Asiakkaan osoite on talletettu varchar(80) –

tyyppiseen kenttään”

• Auttaa pitämään erityyppiset asiat erilläänhelpottaen niitten ymmärtämistä ja käsittelemistä


Sovellusaluemalli• Ilmaisee reaalimaailman eli ongelma-alueen

tosiasioita, jotka ovat relevantteja toteutettavanohjelmiston kannalta (~ käsitteet jotka esiintyvättoiminnallisissa vaatimuksissa)– Ilmiöt ja oliot– Niiden keskinäiset suhteet– Miten yllämainitut kehittyvät ja muuttuvat ajan

kuluessa• Näihin tosiasioihin on suhtauduttava annettuina;

niitä ei voi muuttaa tai tulkita toisin (esim.viikossa on aina seitsemän päivää)


Suunnittelumalli• Ohjelmistototeutuksen (SUD, System Under Design)

suunnittelu taas on täysin ohjelmistoprojektin käsissä• Suunnittelumalli on osajoukko kaikista ohjelmiston

suunnittelupäätöksistä– Osa päätöksistä jää avoimiksi ja koodimallissa ratkaistaviksi

• Se koostuu rekursiivisesti sisäkkäisistä rajapinta-(boundary) ja sisärakennemalleista– Hierarkia, yksityiskohtaisuuden tasot– Rajapintamalli kuvaa elementin julkisen rajapinnan

muuhun ohjelmistoon– Sisärakennemalli kuvaa elementin yksityisen sisäisen

suunnittelun


!

Koodimalli

• Koodimalli on toteutetun ohjelmistonlähdekoodi tai jokin muu toteutuksen kanssaekvivalentti malli– Voidaan tuottaa käänteistekniikalla (reverse-

engineering, code-to-UML)– Siinä missä suunnittelumalli jättää joitain

suunnittelupäätöksiä avoimiksi, koodimalli on(periaatteessa) riittävän täydellinen suoritettavaksitietokoneessa



Fairbanks G.: Just Enough Software Architecture, pp. 116

Vastaavuussuhde• Vastaavuussuhde (designation) linkittää kahden eri mallin

samanlaiset oliot toisiinsa• Sovellusaluemallin käsitteillä ja ilmiöillä on oltava

vastinparinsa suunnittelumallissa (vrt. F. Buschmannin”Walking Skeletons”)

• Vastaavuussuhdetta ei välttämättä määritelläeksplisiittisesti (listaamalla vastaavuuksia, mapping), muttase on voitava aina validoida– Vastaavuuden rikkoutuminen johtaa yleensä ohjelmistovikoihin,

jotka näyttäytyvät vääränä käyttäytymisenä (hyväksyntä-)testauksessa

– Vastaavuus ei välttämättä ole 100% oikein toimivassakaanohjelmistossa, koska suunnittelussa voidaan tarkoituksella tehdäyksinkertaistuksia sovellusalueen tietotyyppeihin


Vastaavuussuhde



Tarkennussuhde

• Tarkennus (refinement) kytkee toisiinsa samanolion vähän yksityiskohtia sisältävän (low-detail)mallin ja yksityiskohtaisen (high-detail) mallin

• Sitä käytetään kytkemään rajapintamallisisärakennemalliin, joka siis kuvaa elementinjulkisen rajapinnan toteutuksen (suunnitteluntasolla)

• Tarkennusta voidaan käyttää myös hierarkisestijakamaan jokin kokonaisuus osiinsa


Tarkennussuhde• Tarkennusta käytetään myös linkittämään

suunnittelumalli koodimalliin• Suunnittelumallin rakenteelliset elementit kuvautuvat

yleensä suoraan koodimallin elementteihin– Moduuli suunnittelumallissa vastaa pakkausta koodissa– Komponentti suunnittelussa vastaa joukkoa luokkia (niiden

ilmentymiä eli olioita) koodissa• Mutta on kuitenkin joukko suunnittelumallin

elementtejä, joilla ei ole suoraa vastinetta koodissa– Invariantit, rajoitteet, arkkitehtuurityylit ja ratkaisumallit– Koodissa voi pyrkiä noudattamaan niitä, mutta niitä ei voi

suoraan ilmaista ohjelmointikielellä (kieli ei määrittele)


Tarkennussuhde



Näkymät

• Sovellusalue-, suunnittelu- ja koodimallit ovattäynnä yksityiskohtia (ainakin käsitteellisessämielessä), joita on hankalaa pitää mielessäyhtä aikaa saati dokumentoida eksplisiittisesti

• Näkymä eli projektio suodattaa mallistaosajoukon yksityiskohtia jotakin tiettyänäkökulmaa (viewpoint) tai tarvetta varten


Näkymät

• Esimerkiksi kaupungin maa-alue ja senrakennukset, tiet ym. muodostavat mallin– Opaskartta auttaa asukasta löytämään tietyn katu-

osoitteen kaupungista– Reittiopas kertoo julkisten liikennevälineiden reitit

kaupungissa– Rakentajat ja kaavoittajat tarvitsevat taas aivan

erilaisia tietoja omiin karttoihinsa


Näkymät

• Eri näkymät samaan ”Master” -malliin eivätsaisi olla keskenään ristiriitaisia– Jos jokin sovellusaluemallin toiminnallinen

skenaario viittaa johonkin oliotyyppiin, tyypinpitäisi olla kuvattuna myös mallin tietomallissa

• ”Master” –mallia ei välttämättä koskaantäydellisenä dokumentoida, joten on tärkeäämuuten huolehtia, että kaikilla projektiinosallistuvilla on sama ”master” –mallimielessään


”Master model”



UML

• UML 2.0 –versioon on lisätty tukeaarkkitehtuurien mallinnukselle

• Kieli on laaja ja sen semantiikka ei ole kovinhyvin määritelty, mutta sille on melko yleinenhyväksyntä ja hyvä, joskin kirjava, työkalutuki

• Kurssilla ja kurssikirjassa käytetään UML 2.0:aamallien visualisointiin


UML -työkalut• Täysveriset UML-työkalut ovat isoja ja raskaskäyttöisiä (ja usein myös kalliita)

ohjelmistoja– Tukevat täydellisten mallien laatimista ja esim. automaattista koodin generointia

• Kevyempiä välineitä tämän kurssin tarpeisiin– Draw.io https://www.draw.io/ varsin monipuolinen ilmainen piirrrosväline, joka ei aivan täysin

tue UML 2.0:n rakennekaavioiden (composite structure diagram) piirtämistä, mutta pienelläsäätämisellä nekin onnistuvat

– UMLet http://www.umlet.com/ - osin tekstipohjainen, osin graafinen, askeettinen muttasuhteellisen toimiva väline, jolla onnistuvat myös UML 2.0:n arkkitehtuuritasonrakennekaaviot (composite structure diagram); tästä on myös on-line versio (UMLetino):http://www.umlet.com/umletino/umletino.html

– PlantUML http://plantuml.sourceforge.net/ - helppokäyttöinen tekstipohjainen UML-työkalu,ei tukea UML 2.0:n arkkitehtuuritason rakennekaavioille (composite structure diagram)

• Verkossa toimivia piirtovälineitä (ominaisuuksiltaan rajoittuneempia)– http://yuml.me/ (luokka- ja käyttötapauskaavioihin)– https://www.websequencediagrams.com/ (sekvenssikaavioihin)

• Laitoksen Linux-koneilta löytyy Umbrello, joka ei kuitenkaan tue UML 2.0:nrakennekaavioita (komponenttikaavioita voi piirtää)


Ohjelmistoarkkitehtuurin suunnittelu · 2017. 9. 26. · – Kaikki mahdolliset (sisäisesti...

Documents

Transcript of Ohjelmistoarkkitehtuurin suunnittelu · 2017. 9. 26. · – Kaikki mahdolliset (sisäisesti...