Ohjelmistoarkkitehtuurin suunnittelu

Transkriptio

1 Ohjelmistoarkkitehtuurin suunnittelu Luento Ohjelmistoarkkitehtuurit 1

2 Oppimistavoitteet Rationaalinen ja empiirinen suunnittelumenetelmä Frank Buschmannin versio Walking skeleton projektipatternista Mallien käyttö suunnittelussa Ohjelmistoarkkitehtuurit 2

3 Miten suunnittelijat suunnittelevat? RATIONAALINEN JA EMPIIRINEN SUUNNITTELUMENETELMÄ Ohjelmistoarkkitehtuurit 3

4 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, Buschmann, F.: Learning from Failure, Part 2: Featuritis, Performitis, and Other Diseases. Software, IEEE, vol.27, no.1, pp.10,11, Jan.-Feb Ohjelmistoarkkitehtuurit 4

5 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 Ohjelmistoarkkitehtuurit 5

6 Herätyskellon osittainen päätöspuu Clock Visibility Alarm vaihtoehtoisia Luminous dial Plain dial sound. setting control Electric light Phosp. light Ohjelmistoarkkitehtuurit 6

7 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 Ohjelmistoarkkitehtuurit 7

8 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 Ohjelmistoarkkitehtuurit 8

9 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, Ohjelmistoarkkitehtuurit 9

10 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ä Ohjelmistoarkkitehtuurit 10

11 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): Ohjelmistoarkkitehtuurit 11

12 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 Ohjelmistoarkkitehtuurit 12

13 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) Ohjelmistoarkkitehtuurit 13

14 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ä Ohjelmistoarkkitehtuurit 14

15 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 Ohjelmistoarkkitehtuurit 15

16 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ä Ohjelmistoarkkitehtuurit 16

17 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 Ohjelmistoarkkitehtuurit 17

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

19 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] Ohjelmistoarkkitehtuurit 19

20 joka kävelee Ketterässä kehityksessä luuranko on suoritettavaa koodia eli se kävelee Empirismi Testaus Ominaisuuksien mittaus Vaatimusten validointi Ohjelmistoarkkitehtuurit 20

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

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

23 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) Ohjelmistoarkkitehtuurit 23

24 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) Ohjelmistoarkkitehtuurit 24

25 Ohjelmistoarkkitehtuurin mallintaminen MIHIN MALLEJA TARVITAAN? Ohjelmistoarkkitehtuurit 25

26 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 Ohjelmistoarkkitehtuurit 26

27 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 Ohjelmistoarkkitehtuurit 27

28 Kommutatiivinen kaavio Abstrakti ongelma Abstrakti ratkaisu Reaalimaailman ongelma Reaalimaailman ratkaisu Ohjelmistoarkkitehtuurit 28

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

30 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 Ohjelmistoarkkitehtuurit 30

31 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ä Ohjelmistoarkkitehtuurit 31

32 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ä) Ohjelmistoarkkitehtuurit 32

33 Web-palvelimen malliluonnos Kun edellisen mallin suoritusajoille annetaan arviot (esim 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ä Ohjelmistoarkkitehtuurit 33

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

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

36 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 Ohjelmistoarkkitehtuurit 36

37 OHJELMISTOARKKITEHTUURIN MALLIT JA NIIDEN RAKENNE Ohjelmistoarkkitehtuurit 37

38 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 Ohjelmistoarkkitehtuurit 38

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

40 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! Ohjelmistoarkkitehtuurit 40

41 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 Ohjelmistoarkkitehtuurit 41

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

43 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ä Ohjelmistoarkkitehtuurit 43

44 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ä Ohjelmistoarkkitehtuurit 44

45 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ää) Ohjelmistoarkkitehtuurit 45

46 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! Ohjelmistoarkkitehtuurit 46

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

48 Fairbanks G.: Just Enough Software Architecture, pp Ohjelmistoarkkitehtuurit 48

49 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 Ohjelmistoarkkitehtuurit 49

50 Vastaavuussuhde Fairbanks G.: Just Enough Software Architecture, pp Ohjelmistoarkkitehtuurit 50

51 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 Ohjelmistoarkkitehtuurit 51

52 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) Ohjelmistoarkkitehtuurit 52

53 Tarkennussuhde Fairbanks G.: Just Enough Software Architecture, pp Ohjelmistoarkkitehtuurit 53

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

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

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

57 Master model Fairbanks G.: Just Enough Software Architecture, pp Ohjelmistoarkkitehtuurit 57

58 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 Ohjelmistoarkkitehtuurit 58

59 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 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 - 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): PlantUML - helppokäyttöinen tekstipohjainen UML-työkalu, ei tukea UML 2.0:n arkkitehtuuritason rakennekaavioille (composite structure diagram) Verkossa toimivia piirtovälineitä (ominaisuuksiltaan rajoittuneempia) (luokka- ja käyttötapauskaavioihin) (sekvenssikaavioihin) Laitoksen Linux-koneilta löytyy Umbrello, joka ei kuitenkaan tue UML 2.0:n rakennekaavioita (komponenttikaavioita voi piirtää) Ohjelmistoarkkitehtuurit 59