Ohjelmistoarkkitehtuurin suunnittelu Luento 4 26.9.2017 581358 Ohjelmistoarkkitehtuurit 1
Oppimistavoitteet Rationaalinen ja empiirinen suunnittelumenetelmä Frank Buschmannin versio Walking skeleton projektipatternista Mallien käyttö suunnittelussa 26.9.2017 581358 Ohjelmistoarkkitehtuurit 2
Miten suunnittelijat suunnittelevat? RATIONAALINEN JA EMPIIRINEN SUUNNITTELUMENETELMÄ 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ähteisiin Brooks, 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 26.9.2017 581358 Ohjelmistoarkkitehtuurit 4
Suunnittelun rationaalinen menetelmä Lähtökohtana on oletus, että suunnitteluongelma ja ongelman ratkaisun vaatimukset, tavoitteet ja rajoitteet voidaan määritellä riittävän tarkasti etukäteen Itse suunnittelutyö on etsintää, jossa järjestelmällisesti 1) generoidaan mahdollisia ratkaisuja 2) 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 26.9.2017 581358 Ohjelmistoarkkitehtuurit 5
Herätyskellon osittainen päätöspuu Clock Visibility Alarm vaihtoehtoisia Luminous dial Plain dial sound. setting control Electric light Phosp. light 26.9.2017 581358 Ohjelmistoarkkitehtuurit 6
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 26.9.2017 581358 Ohjelmistoarkkitehtuurit 7
Rationaalinen menetelmä Rationalisti uskoo, että saatuaan oikean koulutuksen, kasvattavaa kokemusta ja tekemällä riittävän paljon tarpeeksi huolellista ajatustyötä, suunnittelija voi tehdä virheettömän ja riittävän hyvän suunnitelman Suunnittelumetodi tähtää virheettömyyden saavuttamiseen suunnitteluvaiheessa 26.9.2017 581358 Ohjelmistoarkkitehtuurit 8
Rationaalisen menetelmän kritiikkiä 1 Tavoitteet ja vaatimukset ovat harvoin riittävän tarkasti 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, vaan se löytyy suunnittelutyön aikana; päätökset avaavat uusia aiemmin tuntemattomia mahdollisuuksia Kombinatorinen räjähdys: suunnittelupäätösten järjestys voi vaikuttaa radikaalisti puun rakenteeseen; yksittäisillä päätöksillä saattaa riippuvuuksien ja sivuvaikutusten kautta olla globaalia vaikutusta 1 Brooks, F. P. JR.: The Design of Design. Addison Wesley, Pearson Education, 2010. 26.9.2017 581358 Ohjelmistoarkkitehtuurit 9
Rationaalisen menetelmän kritiikkiä Hyvyysfunktion (utility function) inkrementaalinen evaluointi ei aina ole mahdollista 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 eri suunnitteluongelman alueiden ja niiden (osa-) ratkaisujen välillä sekä osaratkaisujen koostamisen välillä (top-down & bottom-up vuorotellen) Aloittelevalle suunnittelijalle rationaalinen malli voi kuitenkin antaa jonkinlaisen lähtöpisteen työhönsä 26.9.2017 581358 Ohjelmistoarkkitehtuurit 10
Empiirinen menetelmä Ongelmia ei pystytä määrittelemään täysin etukäteen eikä 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 581358 Ohjelmistoarkkitehtuurit 11
Empiirisiä menetelmiä Co-evoluutio 1 Vaatimusmäärittely määrittely 1 määrittely 2 määrittely 3 Prototyyppi 1 Prototyyppi 2 Prototyyppi 3 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. 26.9.2017 581358 Ohjelmistoarkkitehtuurit 12
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, ratkaisujen evaluointikriteerit) 26.9.2017 581358 Ohjelmistoarkkitehtuurit 13
Empiirisiä menetelmiä - Spiraalimalli 1 Metaprosessimalli projektikohtaisen kehitysmenetelmän löytämiseksi Kehitys tapahtuu sykleissä, joissa 1. selvitetään projektin menestymisen kannalta kriittisten sidosryhmien asettamat tavoitteet syklille 2. Tunnistetaan riskit ja kehitetään ja evaluoidaan vaihtoehtoisia ratkaisuja 3. Kehitetään ja testataan ratkaisu, jolla tavoitteet saavutetaan 4. 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ä 1 http://en.wikipedia.org/wiki/spiral_model 26.9.2017 581358 Ohjelmistoarkkitehtuurit 14
Empiirisiä menetelmiä - Spiraalimalli Life Cycle Architecture kontrollipiste (myöhempi lisäys alkuperäiseen malliin) Onko olemassa riittävän hyvin määritelty ja kaikkien sidosryhmien tavoitteet täyttävä ratkaisu ja onko kaikki riskit eliminoitu tai minimoitu? Hazardous spiral look-alikes that violate this invariant include evolutionary and incremental processes that commit significant resources to implementing a solution with a poorly defined architecture. 1 1 http://en.wikipedia.org/wiki/spiral_model 26.9.2017 581358 Ohjelmistoarkkitehtuurit 15
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, mutta parityö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ä 26.9.2017 581358 Ohjelmistoarkkitehtuurit 16
Esimerkki - Walking skeletons Frank Buschmann selostaa empiirisen koulukunnan näkemyksiä noudattavan lähestymistavan ohjelmistoarkkitehtuurin suunnitteluun Pragmatic Architect kolumnissaan 1 Tavoitteena erityisesti arkkitehtuurin tarkoituksenmukaisuus ja eräiden ei-toivottujen ilmiöiden välttäminen Ei mene suunnitteluprosessin yksityiskohtiin, mutta antaa suuntaviivat 1 Buschmann, F.: Learning from Failure, Part 2: Featuritis, Performitis, and Other Diseases. Software, IEEE, vol.27, no.1, pp.10,11, Jan.-Feb. 2010 26.9.2017 581358 Ohjelmistoarkkitehtuurit 17
Vältettäviä asioita Featuritis toiminnallisuuden toteuttamisen korostaminen laatuominaisuuksien kustannuksella Flexibilitis arkkitehtuurin kuormittaminen tarpeettoman laajoilla laajennos-, sovitus- ja konfigurointimekanismeilla Performitis projektin loppusuoralla suorituskyky havaitaan huonoksi, mikä johtaa laajamittaiseen paikalliseen optimointiin ja häkkäykseen globaalin strategian puuttuessa ongelmien perimmäisenä syynä usein kaksi edellistä tautia 26.9.2017 581358 Ohjelmistoarkkitehtuurit 18
Luuranko Walking skeleton 1 ohjelmiston perusarkkitehtuuri (baseline), joka tukee Tärkeimpien arvoa tuottavien toiminnallisuuksien toteuttamista (business case) Haastavimpien laatuvaatimusten toteuttamista Ohjelmistotuoteperheen rakentamista (variability) Yllä mainittuun kolmeen ryhmään kuuluvat vaatimukset ovat arkkitehtuurin kannalta merkittävimpiä vaatimuksia (Architecturally Significant Requirements) [1] http://alistair.cockburn.us/walking+skeleton 26.9.2017 581358 Ohjelmistoarkkitehtuurit 19
joka kävelee Ketterässä kehityksessä luuranko on suoritettavaa koodia eli se kävelee Empirismi Testaus Ominaisuuksien mittaus Vaatimusten validointi 26.9.2017 581358 Ohjelmistoarkkitehtuurit 20
Sovellusalueen merkitys Sovellusalueen käsitteet ja ilmiöt ohjaavat merkittävällä tavalla perusarkkitehtuurin suunnittelua Arkkitehtuurissa suunniteltujen komponenttien vastuiden ja yhteistoiminnan pitää heijastaa sovellusalueen käsitteitä, olioita ja prosesseja Tämä mahdollistaa vaaditun toiminnallisuuden jä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 26.9.2017 581358 Ohjelmistoarkkitehtuurit 21
Käyttötapaukset Koko ohjelmiston läpi menevät (end-2-end) käyttötapaukset ja skenaariot ohjaavat perusarkkitehtuurin suunnittelua kattamaan sovellusalueen eri osat Suppea mutta edustava joukko tärkeimmät suunnitteluhaasteet esiin tuovia käyttötapauksia Laatuvaatimusten tulisi tulla esille skenaarioissa Sovellustoiminnallisuuden suhde laatuvaatimukset toteuttavaan infrastruktuuriin 26.9.2017 581358 Ohjelmistoarkkitehtuurit 22
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 ja se toimii, aletaan ottaa harkiten mukaan näiden variaatioita ja 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 suoritettavan arkkitehtuurin, eli järjestelmän todistettavasti toimivan luurangon (tosin se voi olla vain malli) 1 https://en.wikipedia.org/wiki/rational_unified_process 26.9.2017 581358 Ohjelmistoarkkitehtuurit 23
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 toimivat epä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) 26.9.2017 581358 Ohjelmistoarkkitehtuurit 24
Ohjelmistoarkkitehtuurin mallintaminen MIHIN MALLEJA TARVITAAN? 26.9.2017 581385 Ohjelmistoarkkitehtuurit 25
Malleista ja niiden käytöstä 1 Malli = 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. [ ] 1 MOT Sanakirja 26.9.2017 581385 Ohjelmistoarkkitehtuurit 26
Malleista ja niiden käytöstä Yksinkertaiset ongelmat voidaan ratkaista suoraan (ratkaisu on ilmeinen) Monimutkaiset reaalimaailman ongelmat vaativat asian kuvaamista abstraktina mallina (joka pelkistää ongelman ytimen) ja sen ratkaisemista ensin mallissa, minkä jälkeen ratkaisu siirretään reaalimaailman implementaatioksi Esimerkiksi matemaattisten mallien käyttö rakenteiden lujuuslaskennassa jne. 3D-mallien käyttö rakennusten suunnittelun apuna 26.9.2017 581385 Ohjelmistoarkkitehtuurit 27
Kommutatiivinen kaavio Abstrakti ongelma Abstrakti ratkaisu Reaalimaailman ongelma Reaalimaailman ratkaisu 26.9.2017 581385 Ohjelmistoarkkitehtuurit 28
Mallien käyttö Ongelman laajuus ja monimutkaisuus vaatii abstrahointia (eli yksityiskohtien karsimista) On nähtävä metsä puilta Yksittäistä luokkaa, moduulia tai suunnittelumallin ilmentymää laajempien kokonaisuuksien hahmottaminen ja niiden roolin ymmärtäminen Suuren ohjelmiston koodin lukeminen rivi riviltä sen arkkitehtuurin ymmärtämiseksi on käytännössä mahdotonta 26.9.2017 581385 Ohjelmistoarkkitehtuurit 29
Mallien käyttö Abstraktiot pelkistävät ongelmia ja tarjoavat mahdollisuuden kehittää työkaluja Oikein laadittu abstraktio vangitsee reaalimaailman ongelman oleelliset piirteet, jotka vaikuttavat hyvä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 havaittujen riippuvuuksien karsimiseksi ja heijastusvaikutusten vähentämiseksi 26.9.2017 581385 Ohjelmistoarkkitehtuurit 30
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 toteutumisen arvioinnin kannalta Malli voi olla luonnosmainen ja/tai pelkästään analysoijan mielessä 26.9.2017 581385 Ohjelmistoarkkitehtuurit 31
Web-palvelimen malliluonnos Asiakkaan yksi web-sivun pyyntö voi aiheuttaa monia tietokantahakuja Client(s) Server(s) Database(s) Asiakkaan kokema viive pyyntöön vastaamisessa = Viestinvälitykseen kuluva aika + palvelimen pyynnön prosessointiaika + (tietokantahakuun kuluva aika x hakujen lukumäärä) 26.9.2017 581385 Ohjelmistoarkkitehtuurit 32
Web-palvelimen malliluonnos Kun edellisen mallin suoritusajoille annetaan arviot (esim. 10 + 10 + n x 25ms), niin mallin perusteella on helppo nähdä, että tietokantakyselyihin kuluva aika dominoi asiakkaan 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 on hyödyllinen analyysin kannalta * ) samanaikaisten pyyntöjen aiheuttaman jonotuksen ja resurssikilpailun mallintaminen ei ole sekään erityisen vaikeaa oikeilla työkaluilla ja matem. mallinnusmenetelmillä 26.9.2017 581385 Ohjelmistoarkkitehtuurit 33
Mallien käyttö Mallit karsivat ongelman ratkaisussa kä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 liian suuri ja hankala käsiteltäväksi ja käsitettäväksi Essentially, all models are wrong but some are useful. 26.9.2017 581385 Ohjelmistoarkkitehtuurit 34
Mallien käyttö Mallit tehostavat päätelmien ja arviointien tekemistä Suunnittelija voi keskittyä vain pieneen joukkoon suunnittelupäätöksiä/yksityiskohtia kerrallaan (=työmuisti ja kognitio) Käsitteellinen tai konkreettinen malli auttaa suhteuttamaan ratkaisun eri yksityiskohtia toisiinsa ja havaitsemaan ja analysoimaan niiden välisiä riippuvuuksia ja rajoitteita 26.9.2017 581385 Ohjelmistoarkkitehtuurit 35
Mallien käyttö Kysy ensin mitä haluat tietää ja laadi malli vasta sitten 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 ovat usein jopa välttämättömiä, mutta konkreettisia malleja pitäisi laativa vain todelliseen tarpeeseen, ei varmuuden vuoksi 26.9.2017 581385 Ohjelmistoarkkitehtuurit 36
OHJELMISTOARKKITEHTUURIN MALLIT JA NIIDEN RAKENNE 26.9.2017 581385 Ohjelmistoarkkitehtuurit 37
Ohjelmistoarkkitehtuurin mallintaminen Fairbanks esittää kanonisen 1 rakenteen ohjelmistoarkkitehtuurin malleille Määrittelee minkälaisia asioita ohjelmistoarkkitehtuurin mallin pitäisi yleisesti ottaen kuvata metamalli tai mallinnusstandardi Kattaa koko arkkitehtuuriratkaisun aina sovellusalueen käsitteistä toteutuksen koodiin ja laitteistosijoitteluun asti 1) Ohjeellinen, esikuvallinen - MOT Kielitoimiston sanakirja 26.9.2017 581385 Ohjelmistoarkkitehtuurit 38
Ohjelmistoarkkitehtuurin mallintaminen Kanoninen rakenne antaa myös käsitteellisen kehyksen (conceptual model) ohjelmistoarkkitehtuurille Kehys tukee OA:n suunnittelua ohjaamalla suunnittelutyötä tietynlaisten kysymysten ja rakenteiden pohtimiseen Ohjaa jakamaan ohjelmistoa koskevien faktojen käsittelyn sopivalle abstraktiotasolle Ei ole kuitenkaan tarkoitus, että jokaisesta ohjelmistoprojektista laaditaan kanonisen rakenteen mukainen kattava kuvaus Projektit valikoivat todellisen tarpeen mukaan, mitä osia arkkitehtuurista mallinnetaan kanonisen metamallin sääntöjä noudattaen 26.9.2017 581385 Ohjelmistoarkkitehtuurit 39
Ohjelmistoarkkitehtuurin mallintaminen Harhakäsityksiä Jokaisen projektin pitää dokumentoida arkkitehtuurinsa: väärin. Arkkitehtuurimalleja ja dokumentteja kannattaa laatia vain kun ne auttavat pienentämään (projekti- ja tuote-) riskejä Arkkitehtuurin dokumentaation pitää olla aina kattava: väärin. Mallinnuksen pitäisi kohdistua riskipitoisimpiin ratkaisun osa-alueisiin (laatuominaisuuksiin). Laaja dokumentaatiokin saattaa joskus olla tarpeen, esimerkiksi erityisen kommunikointitarpeen tyydyttämiseksi! 26.9.2017 581385 Ohjelmistoarkkitehtuurit 40
Ohjelmistoarkkitehtuurin mallintaminen Suunnittelun pitäisi aina edellyttää koodausta: väärin. Projektin aikaisessa vaiheessa tehty ratkaisun osittainen toteutus ja prototypointi voivat auttaa tunnistamaan hankalimmat ongelmat. Vrt. Walking Skeleton 26.9.2017 581385 Ohjelmistoarkkitehtuurit 41
Kanonisen rakenteen perusideat Arkkitehtuurin malli (jatkossa a-malli) jakautuu kolmeen osamalliin 1. Sovellusaluemalli (domain model) 2. Suunnittelumalli (design model) 3. Koodimalli (code model) Sovellusaluemalli on abstraktein ja koodimalli konkreettisin (lähimpänä toteutusta) Vastaavuus- ja tarkennussuhteet (designation and refinement) kytkevät osamallit toisiinsa 26.9.2017 581385 Ohjelmistoarkkitehtuurit 42
Kanoninen rakenteen perusideat Osamallit voivat periaatteessa olla hyvin laajoja, mutta näkymillä (view) voidaan suodattaa ja poimia esiin vain tietyn näkökulman kannalta mielenkiintoisia faktoja Käytännössä a-mallin fyysinen ilmentymä (kaaviokokoelma, dokumentti) koostuu aina tietyin perustein valituista näkymistä Täydellinen malli voi olla olemassa vain suunnittelijoiden mielissä 26.9.2017 581385 Ohjelmistoarkkitehtuurit 43
Kanoninen rakenteen perusideat Malli jakaa erilaiset faktat toteutettavasta ohjelmistosta 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ään helpottaen niitten ymmärtämistä ja käsittelemistä 26.9.2017 581385 Ohjelmistoarkkitehtuurit 44
Sovellusaluemalli Ilmaisee reaalimaailman eli ongelma-alueen tosiasioita, jotka ovat relevantteja toteutettavan ohjelmiston kannalta (~ käsitteet jotka esiintyvät toiminnallisissa 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ää) 26.9.2017 581385 Ohjelmistoarkkitehtuurit 45
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! 26.9.2017 581385 Ohjelmistoarkkitehtuurit 46
Koodimalli Koodimalli on toteutetun ohjelmiston lähdekoodi tai jokin muu toteutuksen kanssa ekvivalentti malli Voidaan tuottaa käänteistekniikalla (reverseengineering, code-to-uml) Siinä missä suunnittelumalli jättää joitain suunnittelupäätöksiä avoimiksi, koodimalli on (periaatteessa) riittävän täydellinen suoritettavaksi tietokoneessa 26.9.2017 581385 Ohjelmistoarkkitehtuurit 47
Fairbanks G.: Just Enough Software Architecture, pp. 116 26.9.2017 581385 Ohjelmistoarkkitehtuurit 48
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), mutta se 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 toimivassakaan ohjelmistossa, koska suunnittelussa voidaan tarkoituksella tehdä yksinkertaistuksia sovellusalueen tietotyyppeihin 26.9.2017 581385 Ohjelmistoarkkitehtuurit 49
Vastaavuussuhde Fairbanks G.: Just Enough Software Architecture, pp. 117 26.9.2017 581385 Ohjelmistoarkkitehtuurit 50
Tarkennussuhde Tarkennus (refinement) kytkee toisiinsa saman olion vähän yksityiskohtia sisältävän (low-detail) mallin ja yksityiskohtaisen (high-detail) mallin Sitä käytetään kytkemään rajapintamalli sisärakennemalliin, joka siis kuvaa elementin julkisen rajapinnan toteutuksen (suunnittelun tasolla) Tarkennusta voidaan käyttää myös hierarkisesti jakamaan jokin kokonaisuus osiinsa 26.9.2017 581385 Ohjelmistoarkkitehtuurit 51
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) 26.9.2017 581385 Ohjelmistoarkkitehtuurit 52
Tarkennussuhde Fairbanks G.: Just Enough Software Architecture, pp. 118 26.9.2017 581385 Ohjelmistoarkkitehtuurit 53
Näkymät Sovellusalue-, suunnittelu- ja koodimallit ovat täynnä yksityiskohtia (ainakin käsitteellisessä mielessä), joita on hankalaa pitää mielessä yhtä aikaa saati dokumentoida eksplisiittisesti Näkymä eli projektio suodattaa mallista osajoukon yksityiskohtia jotakin tiettyä näkökulmaa (viewpoint) tai tarvetta varten 26.9.2017 581385 Ohjelmistoarkkitehtuurit 54
Näkymät Esimerkiksi kaupungin maa-alue ja sen rakennukset, tiet ym. muodostavat mallin Opaskartta auttaa asukasta löytämään tietyn katuosoitteen kaupungista Reittiopas kertoo julkisten liikennevälineiden reitit kaupungissa Rakentajat ja kaavoittajat tarvitsevat taas aivan erilaisia tietoja omiin karttoihinsa 26.9.2017 581385 Ohjelmistoarkkitehtuurit 55
Näkymät Eri näkymät samaan Master -malliin eivät saisi olla keskenään ristiriitaisia Jos jokin sovellusaluemallin toiminnallinen skenaario viittaa johonkin oliotyyppiin, tyypin pitäisi olla kuvattuna myös mallin tietomallissa Master mallia ei välttämättä koskaan täydellisenä dokumentoida, joten on tärkeää muuten huolehtia, että kaikilla projektiin osallistuvilla on sama master malli mielessään 26.9.2017 581385 Ohjelmistoarkkitehtuurit 56
Master model Fairbanks G.: Just Enough Software Architecture, pp. 119 26.9.2017 581385 Ohjelmistoarkkitehtuurit 57
UML UML 2.0 versioon on lisätty tukea arkkitehtuurien mallinnukselle Kieli on laaja ja sen semantiikka ei ole kovin hyvin määritelty, mutta sille on melko yleinen hyväksyntä ja hyvä, joskin kirjava, työkalutuki Kurssilla ja kurssikirjassa käytetään UML 2.0:aa mallien visualisointiin 26.9.2017 581385 Ohjelmistoarkkitehtuurit 58
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 mutta suhteellisen toimiva väline, jolla onnistuvat myös UML 2.0:n arkkitehtuuritason rakennekaaviot (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:n rakennekaavioita (komponenttikaavioita voi piirtää) 26.9.2017 581385 Ohjelmistoarkkitehtuurit 59