Cad-ohjelmistotuoteperheen komponenttikirjastojen modernisointi

CAD-OHJELMISTOTUOTEPERHEEN KOMPONENTTIKIRJASTOJEN MODERNISOINTI

Diplomityö, 42 sivua Informaatioteknologian ja viestinnän tiedekunta Tarkastaja: Prof. Hannu-Matti Järvinen Kesäkuu 2021

TIIVISTELMÄ

Matias Ala-Sunila: CAD-ohjelmistotuoteperheen komponenttikirjastojen modernisointi Diplomityö, 42 sivua

Tampereen yliopisto Tietotekniikka Kesäkuu 2021

Teknologioiden kehittyminen luo aivan uusia vaatimuksia ohjelmistoille. Olemassa olevien oh- jelmistojen kohdalla se tarkoittaa ohjelmiston vanhentumista. Monesti vanha ohjelmisto on kriit- tinen yritykselle, joten siitä ei voida luopua. Vaihtoehdoksi jää siis vain modernisoida ohjelmisto vastaamaan nykypäivän tarpeisiin.

Tässä työssä modernisoidaan CAD-ohjelmiston komponenttikirjastojen arkkitehtuuri. Erityi- sesti tekniset vaatimukset olivat muuttuneet merkittävästi ohjelmiston elinkaaren aikana. Kirjas- tojen ylläpito ja päivittäminen olivat myös käyneet hankaliksi. Modernisoinnin lisäksi arvioidaan arkkitehtuuria käyttäen Decision-centric architechture review -arviointimallia.

Ohjelmistoarkkitehtuuri suunniteltiin uusiksi ja lopputuloksena syntyi selkeä, joustava ja hel- posti ylläpidettävä arkkitehtuuri. Erityisesti ohjelmiston eri osien vastuiden täsmällisessä ja sel- keässä jaossa onnistui hyvin. Lisäksi uuden arkkitehtuurin myötä ohjelmisto täyttää uudet tekniset vaatimukset. Tärkein näistä oli pilvipalveluiden käytön mahdollistaminen.

Tarpeiden täyttymisen lisäksi diplomityön teon aikana yritykseen saatiin käyttöön uusi tapa ar- vioida ohjelmistoa. Arkkitehtuurin arviointi koettiin mielekkääksi ja sen avulla saatiin aikaan oleel- lisia arkkitehtuuripäätöksiä. Kaiken kaikkiaan modernisointi oli erittäin onnistunut. Sen vuoksi to- teutetun arkkitehtuurin kehitystä jatketaankin eteenpäin.

Avainsanat: Modernisointi, Uudistaminen, Ohjelmistoarkkitehtuuri, CAD, DCAR Tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck -ohjelmalla.

ABSTRACT

Matias Ala-Sunila: Modernization of component libraries in CAD software product family Master of Science Thesis, 42 pages

Tampere University Information technology June 2021

Development of technologies has created brand new demands on software. That means exist- ing software turns to be legacy. However in many cases existing software is critical for corporation so it cannot be thrown away. Only solution is modernization to make software fulfil today’s require- ments.

In this thesis CAD sofware component libraries will be modernized. Especially technical re- quirements has been changed significantly during software life cycle. Maintaining and updating libraries has become also very difficult. Besides modernization architecture will be evaluated by using Decision-centric architecture review -method.

Software architecture has been redesigned and the result was clear, flexible and easily main- tained architecture. Specially responsibilities of different software parts became very precise and clear. In addition with new architecture software now fulfils new technical requirements. The most important one was making possible to use cloud services.

In addition to fulfil requirements new way to evaluate software was introduced to company.

Architecture evaluation felt meaningful and with it many important architecture decisions were made. Overall modernization was very successful. Because of that development of implemented architecture will continue.

Keywords: Modernization, Re-engineer, Software architecture, CAD, DCAR

The originality of this thesis has been checked using the Turnitin OriginalityCheck service.

ALKUSANAT

Tämä työ toteutettu Vertex Systems Oy:lle, jota haluan kiittää mielenkiintoisesta diplo- mityön aiheesta. Aiheen lisäksi on ollut mahtavaa huomata työn olevan myös yritykselle erittäin tärkeä. Erityisesti haluan kiittää ohjaajiani professori Hannu-Matti Järvistä ja Ju- ha Huhdankoskea työn ohjauksesta ja hyvästä palautteesta työn aikana. Lisäksi haluan vielä antaa kiitokset läheisilleni tuesta ja kannustuksesta.

Tampereella, 28. kesäkuuta 2021

Matias Ala-Sunila

SISÄLLYSLUETTELO

1 Johdanto . . . 1

2 Ohjelmistoarkkitehtuurin arviointi . . . 3

2.1 Arvioinnin kehitys . . . 3

2.2 ATAM . . . 4

2.3 DCAR . . . 6

3 Ohjelmistoarkkitehtuurin modernisointi . . . 10

3.1 Ohjelmistojen modernisointi . . . 10

3.2 Arkkitehtuuriset tyylit . . . 12

3.2.1 Komponenttipohjainen arkkitehtuuri . . . 13

3.2.2 Tietovuoarkkitehtuuri . . . 14

3.2.3 Monoliittiarkkitehtuuri . . . 15

3.2.4 Kerrosarkkitehtuuri . . . 16

4 Taustaympäristö . . . 18

4.1 Vertex tuoteperhe . . . 18

4.2 Komponenttikirjastojen uudistamistarpeet . . . 19

5 Vertex BD ja komponenttikirjastot . . . 21

5.1 Vertex BD . . . 21

5.2 Komponenttikirjastot . . . 22

5.3 Komponentit ja niiden rakenne . . . 23

6 Arkkitehtuuri . . . 25

6.1 Kokonaisuus . . . 25

6.2 Moduuli . . . 26

6.3 Kirjasto . . . 28

6.4 Datan käsittelijä ja komponentti . . . 29

7 Arviointi ja jatkokehitys . . . 31

7.1 Arkkitehtuurin arviointi . . . 31

7.2 Toiminnallisuuden arviointi . . . 35

7.3 Jatkokehitys . . . 37

8 Yhteenveto . . . 39

Lähteet . . . 41

KUVALUETTELO

2.1 Esimerkki laatuattribuuttipuusta. . . 5

2.2 Arkkitehtuurisen päätöksen documentointipohja [10]. . . 8

3.1 Legacy-ohjelmiston päätösmatriisi . . . 10

3.2 Yleinen malli ohjelmistojen uudelleensuunnitteluun . . . 11

3.3 Tietovuoarkkitehtuuri . . . 14

3.4 Kerrosarkkitehtuuri . . . 16

4.1 Vertex CAD-tuoteperhe . . . 18

4.2 Kuvankaappaus Vertex G4 sovelluksesta . . . 19

5.1 BD-mallin sisältämät tiedot. Keskellä runko- ja arkkitehtimallin ulkoasu. [26] 21 5.2 Kuvankaappaus Vertex BD kirjaston sovelluksesta . . . 22

5.3 Kuvankaappaus Vertex BD sovelluksesta palkkien liitoksista . . . 23

5.4 Kuvankaappaus Vertex BD sovelluksesta seinäelementin puurungosta . . 24

6.1 Yleiskuva koko arkkitehtuurista . . . 25

6.2 Luokkakaavio moduulikerroksesta . . . 27

6.3 Luokkakaavio kirjastokerroksesta . . . 28

6.4 Luokkakaavio komponentista ja datan käsittelystä vastaavista luokista . . 29

7.1 Dokumentoitu arkkitehtuuripäätös itsenäisistä moduuleista . . . 32

7.2 Dokumentoitu arkkitehtuuripäätös muokattavista moduuleista . . . 33

7.3 Dokumentoitu arkkitehtuuripäätös muokkaamattomista moduuleista . . . . 34

7.4 Kuvankaappaus Vertex BD uudesta komponentin valintaselaimesta . . . . 36

LYHENTEET JA MERKINNÄT

BIM Rakennuksen tietomalli (engl. Building information modeling) CAD Tietokoneavusteinen suunnittelu (engl. Computer-aided design) ISO Kansainvälinen standardointiorganisaatio

1 JOHDANTO

Ohjelmistokehityksen menetelmät ja tekniikat kehittyvät jatkuvasti ja ovat viimeisen vuo- sikymmenten aikana merkittävästi muuttuneet. Erityisesti tekniikoiden kehityksestä joh- tuen vanhentuneiden ohjelmistojen määrä kasvaa vauhdilla. Vanhat ohjelmat eivät enää pysty täyttämään nykypäivän vaatimuksia. Nykyisillä tekniikoilla voidaan tehdä asioita, joihin vanhat tekniikat eivät pystyneet. Yksi merkittävimmistä tällaisista kehitysaskelista tekniikoiden osalta on ollut pilvipalveluiden kehittyminen. Varsinkin verkkoyhteyksien saa- tavuuden ja nopeuden kasvamisen myötä pilvipalveluja on voitu laajemmin hyödyntää eri palveluiden toteutuksissa.

Menetelmien osalta jopa merkittävintä muutosta ovat tuoneet ketterät ohjelmistotuotan- non menetelmät. Ketterät menetelmät ovat tehostaneet ohjelmistojen kehitystä ja lisän- neet erityisesti ohjelmistotuotannon joustavuutta. Kehitys on kuitenkin tuonut haasteensa vanhojen menetelmien käytössä. Erityisesti arvioinnin tuominen mukaan nopeaan oh- jelmistotuotantoon on ollut ongelmia. Ketterässä kehityksessä ajanjaksot ovat paljon ly- hyemmät, joten kattavien kymmenien henkilötyöpäivien arviointien sisältäminen niihin on ongelmallista.

Tässä työssä käsitellään vanhan CAD-ohjelmiston uudistamista ja arviointia. Uudistuk- sessa tärkeänä tavoitteena on pilvipalveluiden käytön mahdollistaminen. Ohjelmiston osa oli toteutettu ennen kuin pilvipalveluiden käyttö on ollut edes mahdollista, siksi arkkiteh- tuurissa ei ole otettu pilvipalveluita lainkaan huomioon. Lisäksi tärkeänä tavoitteena on myös ohjelmiston ylläpidon vähentäminen. Samalla uudistamistyön aikana myös arvioi- daan arkkitehtuuria. Arvioinnissa käytetään ketterään kehitykseen sopivaa arkkitehtuurin arviointimenetelmää Decision-centric architecture review.

Ensimmäiseksi tässä työssä käydäänkin läpi luvussa 2 arkkitehtuurin arviointia. Siinä käydään ensin läpi arviointia itsessään ja sen jälkeen työn kannalta oleellisimmat ark- kitehtuurin arvioinnin mallit. Luvussa 3 käydään läpi vanhan ohjelmiston arkkitehtuurin uudistamista eli ohjelmistoarkkitehtuurin modernisointia. Modernisointi on ohjelmistotuo- tantoa, koska siinä pohjimmiltaan on kyse uuden ohjelmiston kehittämisestä. Ohjelmisto- tuotannon ominaisuuksien lisäksi modernisointiin liittyy paljon omia erityispiirteitään, joita luvussa 3 myös käydään läpi. Lisäksi modernisointiin kuuluvat oleellisena osana erilaiset arkkitehtuuriset tyylit.

Luvuissa 4 ja 5 käydään lyhyesti läpi taustaympäristöä ja uudistettavaa ohjelmaa läpi.

Luvussa 6 taas esitetään kattavasti toteutettu arkkitehtuuri. Lukuun 7 on koottu yhteen arvioinnin tulokset ja siinä myös pohditaan jatkokehitystä. Lopuksi on yhteenveto, jossa käydään läpi lopputulos ja opitut asiat.

2 OHJELMISTOARKKITEHTUURIN ARVIOINTI

2.1 Arvioinnin kehitys

Ohjelmistoarkkitehtuurille ei ole tarkkaa määritelmää mikä johtuu suurimmaksi osaksi sii- tä, että aikojen kuluessa sen merkitys on muuttunut ohjelmistojen kehittyessä. Aluksi oh- jelmistoarkkitehtuurista puhuttaessa sillä tarkoitettiin lähinnä tietokoneen fyysistä raken- netta [1]. Vasta 90-luvun alkupuolella se alkoi saada nykyisen merkityksensä kuvaamaan kokonaisuutta, johon kuuluu ohjelmiston rakenne, toimintaympäristö ja perustelut tehdyille valinnoille. Tähän pohjautuen ISO-standardi täsmentää ohjelmistoarkkitehtuurin tarkoitta- van perusymmärrystä systeemistä ympäristössään, johon kuuluu sen rakentavat elemen- tit, niiden väliset suhteet toisiinsa ja ympäristöön sekä systeemin suunnittelua ja kehitystä ohjaavat periaatteet [2].

Nopeasti 90-luvun uuden määritelmän jälkeen ohjelmistoarkkitehtuuri alkoi kehittyä mer- kittäväksi tieteenalaksi vauhdilla saaden paljon panostuksia teollisuudesta ja akateemi- sesta maailmasta [1]. Tukea annettiin helpommin kuin aiemmin, sillä hyvän arkkitehtuurin merkitys korostui ohjelmistojen koon ja sidosryhmien määrän kasvaessa huomattavas- ti. Ohjelmistoarkkitehtuurin tärkeys myös korostui johdon silmissä, sillä alettiin vähitellen huomaamaan ylläpitokulujen kasvavan. Vertailuna nykyään selkeästi suurin osa ohjel- mistoprojektin kuluista tulee ylläpidosta [3]. Ylläpitokuluihin vaikuttaa oleellisesti ohjelmis- toarkkitehtuuri, sillä teollisuudessa tehdyn tutkimuksen [4, s. 121] tuloksena Knodel et al.

toteavat arkkitehtuuristen päätösten näkyvän vuosienkin päähän. Näin ollen huonot pää- tökset vaikeuttavat tulevaisuudessa vielä ylläpidossakin ja päinvastoin hyvä arkkitehtuu- ri helpottottaa ylläpitoa. Hyviä keinoja ylläpitokulujen vähentämiseksi ohjelmistoprojektin alussa onkin arkkitehtuurin selkeä kuvaaminen ja riittävä arviointi.

Merkittäviä saavutuksia 90-luvulla olivatkin ohjelmistoarkkitehtuuria arvioivat arviointimal- lit sekä sitä kuvaavat suunnittelumallit, kuten 4+1 menetelmä sekä Siemens 4 näkymää (Siemens’ four views). Näistä 4+1 näkymän suunnittelumallissa on keskiössä skenaariot, jotka pyrkivät kuvaamaan käyttötapauksia ja tärkeimpiä vaatimuksia [5]. Skenaarioiden pohjalta kehittyi suunnittelumallien lisäksi ensimmäinen skenaarioihin pohjautuva arvioin- timalli software architecture analysis method (SAAM) [6].

SAAM arvioi arkkitehtuuria valittuja laatukriteerejä vasten. Laatukriteerit lähinnä testa-

sivat järjestelmän teknisiä ominaisuuksia. Näiden laatukriteerien täyttymistä arvioidaan käyttäen priorisoituja skenaarioita. SAAM tarvitsee tarkan arkkitehtikuvauksen arvioita- vasta järjestelmästä, mutta se myös tuottaa hyvän arvion järjestelmän teknisestä kyvyk- kyydestä. Lisäksi syntyy hyödyllistä dokumentaatiota arkkitehtuurista sekä tapahtuu infor- maation jakamista sidosryhmien välillä. Monesti ei kuitenkaan olla täysin kiinnostuneita teknisten ominaisuuksien optimoinnista vaan kiinnostavampaa on esimerkiksi se, millai- sia kompromisseja ja riskejä arkkitehtuuriset valinnat aiheuttavat. SAAM kuitenkin toimi hyvänä pohjana siitä kehitetylle ja sittemmin arkkitehtuurin arvioinnin epäviralliseksi stan- dardiksi muodostuneelle ATAM:lle.

2.2 ATAM

Architecture tradeoff analysis method -arviointimallin eli ATAM:n tarkoitus on tarkastella tarkastella arkkitehtuuristen valintojen seurauksia toisin kuin edeltäjänsä SAAM, joka ta- voitteli laatuominaisuuksien maksimointia. Toinen suuri ero arviointimallien välillä on se, että ATAM ei pyri ennustamaan lopputulosta, vaan keskittyy lisäämään arkkitehtuurista tietoisuutta ja dokumentaatiota [7, s. 3]. Rakenteeltaan ATAM on suhteellisen raskas, sil- lä se vaatii vähintään kolme henkilöä ja kestää vähintään kolme päivää mikä tarkoittaa 9 henkilötyöpäivää [7, s. 41–43]. Kuitenkin käytännössä 9 henkilötyöpäivää on aivan liian vähän ja 20-30 henkilötyöpäivää on huomattavasti realistisempi arvio [8].

Taulukko 2.1.ATAM arvioinnin vaiheet [41 7, muokattu]

Vaihe Sisältö Sidosryhmät

1 ATAM:n esittely

2 Liiketoimintaan vaikuttavien tekijöiden esittely

3 Arkkitehtuurin esittely 4 Arkkitehtuuristen

lähestymistapojen tunnistus 5 Laatuattribuuttipuun teko 6 Arkkitehtuuristen

lähestymistapojen analysointi

Arvioijat, asiakkaan edustajat ja arkkitehdit

7 Aivoriihi ja skenaarioiden

priorisointi Kaikki

8 Arkkitehtuuristen

lähestymistapojen analysointi

Arvioijat, asiakkaan edustajat ja arkkitehdit

9 Tulosten esittely Kaikki

ATAM sisältää 9 vaihetta, jotka on listattu taulukkoon 2.1 ¹. Ensimmäisten kolmen vai- heen tarkoitus on esitellä arviointiprosessi, liiketoiminnalliset tarpeet ja tavoitteet sekä arkkitehtuuri. Kattavien esittelyjen jälkeen alkaa analysointi, joka alkaa arkkitehtuuristen lähestymistapojen tunnistamisella. Arkkitehti pyrkii tunnistamaan arkkitehtuuriset lähes- tymistavat eli arkkitehtuuriset päätökset, sillä arkkitehtuuriset tyylit eivät välttämättä ole tarpeeksi tuttuja tunnistettavaksi arkkitehtuurista [7, s. 29]. Tässä vaiheessa arkkitehtuu- riset lähestymistavat vain tunnistetaan. Itse arviointi ja analysointi tapahtuu kuudennessa vaiheessa.

Kuva 2.1.Esimerkki laatuattribuuttipuusta

Seuraavaksi muodostetaan laatuattribuuttipuu, jonka pohjalta arkkitehtuurisia päätöksiä arvioidaan. Laatuattribuuttipuussa on nimensä mukaisesti haaroina laatuattribuutit ja nii- den jaottelu tarkempiin alikohtiin (Kuva 2.1). Puun lehtinä toimivat skenaariot, jotka tes- taavat laatuattribuuttien alikohtia. Alikohdat ovat yleensä muotoiltu käyttäjätarinoiksi ko- rostaen tutkittavaa laatuattribuuttia. Skenaarioita priorisoidaan tyypillisesti antamalla ar- vio skenaarion tärkeydestä ja sen toteuttamisen hankaluudesta. Alkuperäisen artikkelin tapaan [7] priorisoinnissa arvio tehdään yleensä karkealla asteikolla, jossa arvot ovat ma-

1”Kaikki” pitää sisällään kehittäjät, ylläpitäjät, operaattorit, käyttäjät, testaajat jne.

tala, keskitaso ja korkea.

Laatuattribuuttipuun laatimisen jälkeen aiemmin tunnistettuja arkkitehtuurisia lähestymis- tapoja arvioidaan. Tarkoitus on uusien lähestymistapojen tunnistamisen lisäksi löytää ar- vioitavan järjestelmän riskitekijöitä, herkkyyskohtia ja kompromisseja. Kaiken analysoin- nin jälkeen pidetään aivoriihi, jossa kaikkien sidosryhmien edustajat pyrkivät laajenta- maan skenaarioiden joukkoa. Aivoriihen tuotoksena syntynyt laajempi skenaariojoukko priorisoidaan. Korkeimmalla prioriteettitasolla olevia skenaarioita käytetään arkkitehtuu- risten lähestymistapojen uudelleenarviointiin ja -analysointiin. Tässä vaiheessa erona vai- heeseen kuusi on se, että arvioinnin lisäksi riskitekijät, herkkyyskohdat ja kompromissit dokumentoidaan. Aivan lopuksi tulokset esitellään kaikille sidosryhmille.

Nykyaikaiseen ketterään ohjelmistokehitykseen tällainen raskas tarkka suunnittelu ennal- ta ei sovi kovin hyvin. Kuitenkin halu tuoda arviointi kiinteästi mukaan ohjelmistokehityk- seen usein löytyy, mutta kuten Knodel et al. tutkittuaan arviointeja [4, s. 123] toteavat, että käytännössä arviointi usein jätetään kiireen alla pois. Syitä arvioinnin poisjättöön ovat pääasiassa suuri päivittäinen työmäärä ja se, että ongelmien juurisyyn selvittämisen sijaan vain ongelmien aiheuttamat seuraukset korjataan. Arviointi kuitenkin kannattaisi tehdä, sillä samassa tutkimuksessa [4] todetaan pelkkien diagrammien olevan riittämät- tömiä, korostetaan arkkitehtuuristen ongelmien löytämisen tärkeyttä ja kannustetaan heti toimimaan ongelmien korjaamiseksi, jotta myöhemmin taisteluun niitä vastaan ei kuluisi paljon aikaa.

2.3 DCAR

Decision-centric architecture review -arviointimallin (DCAR) tarkoitus on tarjota edeltä- jänsä ATAM:n hyvät puolet ja olla samalla huomattavasti kevyempi tapa arvioida arkkiteh- tuuria. ATAM:n hyvillä puolilla tarkoitetaan erityisesti dokumentaation lisäämistä ja tiedon välitystä osallistujien kesken. ATAM:sta poiketen DCAR tarkastelee arkkitehtuuria ja sen ongelmia laajemmassa mittakaavassa sekä korostaa ongelmien keskinäisiä suhteita yk- sittäisten laatuominaisuuksien sijaan.

DCAR:ssa käytetään voima-käsitettä (eng. force), jota hyödynnetään ongelmakentän ym- märtämisessä. Voima pitää sisällään kaikki arkkitehtuurisiin päätöksiin vaikuttavat tekijät.

Näitä on laatuvaatimusten kuten suorituskyvyn ja ylläpidettävyyden lisäksi suunnitteluun vaikuttavat reunaehdot kuten aikataulu ja budjetti. Näiden lisäksi DCAR listaa voimiksi myös hiljaiset tiedot kuten arkkitehdin mielipiteet ja yrityksen vahvuudet. Erityisesti hil- jaisten tietojen löytäminen nostaa merkittävästi päätösten läpinäkyvyyttä.

DCAR sisältää 9 vaihetta, jotka on listattu taulukkoon 2.2. Toisin kuin ATAM:ssa kaikki mukana olevat henkilöt osallistuvat jokaiseen vaiheeseen. Lisäksi isona erona on se, että DCAR:ssa on korostettu valmistelua nostamalla se erikseen omaksi vaiheekseen. Val-

mistelua lukuunottamatta arvioinnin vaiheissa on hyvin paljon yhteneväisyyksiä ATAM:n vaiheisiin. Valmistelu eroaa myös paljon muista vaiheista. Se on nimittäin ainoa vaihe, jo- ka tapahtuu erillään muista vaiheista. Siinä käydään ennalta läpi materiaalit ja pyritään jo valmiiksi tunnistamaan osa arkkitehtuuriin vaikuttavia voimia ja päätöksiä. Seuraavak- si esitellään loput vaiheet lyhyesti samalla tavalla kuin alkuperäisessä DCAR-julkaisussa [9].

Taulukko 2.2.DCAR arvioinnin vaiheet [72 9, muokattu]

Vaihe Sisältö

1 Valmistelu 2 DCAR:n esittely

3 Hallinnon/Asiakkaan esitelmä 4 Arkkitehtuurin esittely

5 Voimien ja päätösten viimeistely 6 Päätösten priorisointi

7 Päätösten dokumentointi 8 Päätösten arviointi

9 Retrospektiivi ja raportointi

Ensimmäiseksi käydään nopeasti läpi DCAR:n vaiheet ja päivän aikataulu. Tarkoitus on lähinnä kerrata DCAR läpi ja tarjota aikaa selvittää epäselvät kohdat. Seuraavaksi on projektista riippuen asiakkaan tai hallinnon esityksen vuoro. Esityksen aikana arviointitii- min tehtävänä on löytää erityisesti liiketoimintaan liittyviä voimia ja kirjata ne ylös. Tästä eteenpäin asiakkaan tai hallinnon edustajan ei välttämättä tarvitse olla läsnä, mutta hän voi tuoda jatkossa esille tärkeitä liiketoimintaan liittyviä oivalluksia.

Seuraavaksi käydään läpi arkkitehtuuri. Nyt voimien lisäksi tärkeää on pyrkiä täydentä- mään valmistelun aikana löydettyjen arkkitehtuurisien päätöksien listaa. Esityksen lopuk- si olisi hyvä tehdä graafi, joka kuvaa arkkitehtuuristen päätösten välisiä suhteita. Samalla käydään vielä yhdessä läpi täydentäen löydetyt voimat. Esitysten ja viimeistelyn jälkeiset kolme vaihdetta käsittelevät löydettyjä päätöksiä ja tarkastelevat niitä löydettyjä voimia vasten. Kyseiset vaiheet voidaan halutessa toistaa tarpeen vaatiessa iteratiivisesti.

Yleensä esitysten jälkeisen viimeistelyn tuloksena päätöksiä on liikaa arvioitavaksi. Puo- lessa päivässä ehtii käydä läpi perusteellisesti noin 7-10 päätöstä [9, s. 74]. Mikäli pää- töksiä on reilusti liikaa, niin tällöin voidaan käyttää kaksivaiheista priorisointia. Siinä osal- listujat ensin valitsevat 3-5 päätöstä, jotka haluavat arvioitavan. Tämän jälkeen vain ää- niä saaneet päätökset priorisoidaan halutulla tavalla. Heesch et al. ehdottavat pisteisiin perustuvaa priorisointia, jossa osallistujat jakavat 100 pistettä haluamallaan tavalla. Ää- nestyksen jälkeen pisteet summataan yhteen ja eniten pisteitä saanut päätös arvioidaan ensin ja vähiten pisteitä lopuksi.

Valitut päätökset jaetaan osallistujien kesken dokumentoitavaksi niin, että jokainen osal- listuja saisi hänelle mahdollisimman tuttuja päätöksiä. Dokumentoinnin jälkeen arvioidaan päätökset prioriteettijärjestyksessä. Ensin päätöksen dokumentoinut henkilö esittelee sen muille ja siihen pyritään löytämään lisää argumentteja sekä puolesta että vastaan. Eten- kin tähdätään haastamaan kyseistä päätöstä, jotta riskejä ei jäisi ennen lopullista arvio- ta huomiotta. Tähän on apuna lista voimista, joka käydään vielä uudelleen läpi. Uusien löydösten jälkeen täydennetyn dokumentaation pohjalta äänestetään päätöksestä. Yksin- kertaisuuden nimissä arvosteluluokkia kannattaa olla kolme. Tällöin voidaan käyttää do- kumentaatiossa liikennevaloja visualisoimaan valittuja arvosteluluokkia, kuten kuvan 2.2 esimerkkipohjassa.

Lopuksi pidetään nopea retrospektiivi ja myöhemmin, mielellään mahdollisimman pian DCAR-tilaisuuden jälkeen, kirjoitetaan tilaisuudesta raportti. Raporttiin kannattaa lisätä tarkemmin argumenttien perusteluja ja mahdollisesti muita esille nousseita asioita, kuin mitä arkkitehtuuristen päätösten dokumenteista löytyy. Tähän auttaa huomattavasti se, että DCAR-arviointipäivän tapahtumat ovat vielä hyvin muistissa.

Kuva 2.2.Arkkitehtuurisen päätöksen documentointipohja [10].

Kokonaisuudessaan sovellettuna DCAR on suhteellisen kevyt tapa arvioida arkkitehtuu- ria tarkasti. Keveyden ja tarkkuden lisäksi etuna on, että DCAR ei tuota mitään turhaa dokumentaatiota vaan kaikkea dokumentaatiota voidaan sellaisenaan käyttää arkkiteh-

tuurin dokumentaationa. Merkittävä hyöty erityisesti DCAR:n kohdalla on myös päätös- ten läpinäkyvyyden lisääminen. Tämä hyöty saavutetaan panostamalla arkkitehtuuristen voimien tunnistamiseen, sillä pelkästään niitä käyttämällä saavutetaan huomattava kasvu päätösten läpinäkyvyydessä [11]. Näiden hyötyjen lisäksi DCAR:n kevyt rakenne alentaa kynnystä arkkitehtuurisen arvioinnin tuomiseksi kiinteästi mukaan ketterään ohjelmisto- kehitykseen.

3 OHJELMISTOARKKITEHTUURIN MODERNISOINTI

3.1 Ohjelmistojen modernisointi

Ohjelmistojen modernisoinnilla tarkoitetaan erityisesti legacy-ohjelmistojen uudistamista.

Legacy-ohjelmistolla tarkoitetaan vanhaa ohjelmistoa, joka on kriittinen osa yrityksen toi- mintaa ja hankalasti muokattavissa [12]. Pääosin juuri huono muokattavuus itsessään ja sen aiheuttamat suuret ylläpitokulut nousivat ohjelmistoalan asiantuntijoiden keskuudes- sa merkittävimmiksi syiksi modernisoida vanha ohjelmisto [13]. Modernisointi nähdään myös yrityksen talouden näkökulmasta usein tärkeänä, sillä ylläpitokuluja karsimalla saa- daan aikaan merkittäviä säästöjä. Tämä johtuu siitä, että ohjelmiston iästä ja koosta riip- puen ylläpitokulut kattavat vähintään kaksi kolmasosaa koko ohjelmiston elinkaaren ku- luista [3][12][14]. Ylläpitokuluja kasvattaa erityisesti se, että vikojen korjaamiseen menevä aika, raha ja työmäärä kasvavat hyvin nopeasti ajan kuluessa [15]. Suurimmat menot oh- jelmiston elinkaaressa syntyy siis ylläpidossa, joten niiden karsimisella saadaan helposti laskettua kokonaiskustannuksia.

Kuva 3.1.Legacy-ohjelmiston päätösmatriisi [12]

Täytyy kuitenkin muistaa, että modernisointiin liittyy myös riskejä. Modernisointiin liittyvät riskit voidaan jakaa käyttäjätyytyväisyyteen, kuluihin, takaisinmallinnukseen, uudelleen- suunnitteluun, suorituskykyyn ja ylläpitoon liittyviin riskeihin [16]. Erityisesti kannattaa eri- tyisesti kiinnittää huomiota käyttäjäystävällisyyteen ja kuluihin liittyviin riskeihin [16]. Ris- keistä huolimatta vaara sille, että vanha järjestelmä pettää kokonaan tai sen ylläpitokulut kasvavat liikaa ovat usein isommat kuin riskit epäonnistua modernisoinnissa.

Vanhan ohjelmiston ylläpitokulujen karsimisessa lähdetään liikkeelle siitä, että ensin ar- vioidaan nykyisen ohjelmiston tila. Kuvassa 3.1 on esitetty yksinkertainen päätösmatrii- si, jolla pystytään aluksi nopeasti kartoittamaan ohjelmiston nykytilaa. Heikon liikearvon ohjelmistot pääsääntöisesti poistetaan käytöstä, ellei niillä ole korkeaa teknistä laatua ja niiden ylläpito ei ole kallista. Käytännössä useimmiten kuitenkin vanhoilla käytössä ole- villa ohjelmilla on korkea liikearvo, mutta niiden tekninen laatu vaihtelee. Näille korkean liikearvon ohjelmistoille on kaksi jatkosuunnitelmaa. Korkean teknisen laadun omaavien ohjelmistojen ylläpitoa jatketaan ja heikon laadun ohjelmistoille tehdään modernisointia.

Modernisoinnille taas on olemassa kolme erilaista vaihtoehtoa [12][17]. Näistä radikaalein vaihtoehto on ohjelmiston korvaaminentoisella ohjelmistolla. Ohjelmiston korvaaminen tehdään ilman mitään uudelleenkäyttöä. Uuden ohjelmiston hankinta voidaan toteuttaa monella eri tavalla. Vanhat toiminnot voidaan siirtää toisen järjestelmän toteutettavaksi tai tehdä vastaava palvelu alusta alkaen. Alusta alkaen tehtäessä uusi ohjelma voidaan tehdä itse tai mahdollisesti ostaa palvelu alihankintana.

Kuva 3.2.Yleinen malli ohjelmistojen uudelleensuunnitteluun [16, s. 6]

Korvaamista hieman maltillisempi tapa modernisoida on tehdä uudelleensuunnittelu (engl.re-engineer). Uudelleensuunnittelu on hyvin laaja käsite. Se voi olla mitä vain koo- din siistimisen ja täydellisen uudelleentoteutuksen väliltä. Tärkeimpänä yhteisenä tekijä-

nä ja isona erona korvaamiseen kuitenkin on se, että uudelleensuunnittelussa pyritään käyttämään hyväksi vanhoja sovelluksen osia. Kuvassa 3.2 on esitetty miten ohjelmiston eri abstraktiotasot uudistetaan käyttäen hyväksi olemassa olevaa järjestelmää.

Takaisinmallinnus lähtee liikkeelle siitä, että olemassa olevasta järjestelmästä pyritään nykyisestä järjestelmästä erottamaan eri abstaktiotasot. Pyrkimys on päästä mahdollisim- man korkealle abstraktiotasolle, jotta voidaan hyödyntää perinteisiä ohjelmistotuotannon menetelmiä uudistamisvaiheessa. Abstaktiotasojen sisältöjä kutsutaan toisinaan artefak- teiksi ja tästä syystä takaisinmallinnusprosessia onkin verrattu arkeologiaan [18]. Analo- gia on hyvä, sillä takaisinmallinnuksessa pyritään arkeologian tavoin ymmärtämään ny- kyisen tilanteen historia. Historian ymmärtäminen on tärkeää, sillä se auttaa tunnista- maan ohjelmistosta oleelliset ajan saatossa hukkuneet käsitteet ja vaatimukset. Käsitteet ja vaatimukset ovat tärkeimmät artefaktit, sillä ne ovat kaiken perusta uudistamisvaihees- sa.

Viimeinen modernisoinnin vaihtoehto on nykyisen järjestelmän ylläpidon jatkaminen.

Tätä vaihtoehtoa käytetään, kun alkuperäisen ohjelmiston tekninen laatu on riittävän kor- kea ja nykyinen järjestelmä sisältää riittävät ominaisuudet. Lisäksi verrattuna muihin vaih- toehtoihin tämä on halvin vaihtoehto lyhyellä aikavälillä. Ylläpitoa pyritään jatkamaan te- kemättä isoja muutoksia.

Modernisoinnin vaihtoehdoista siis korvaaminen ja uudelleensuunnittelu ovat yleensä pi- demmän aikavälin ratkaisuja ja ylläpidon jatko lyhyen aikavälin ratkaisu. Tämän työn ta- pauksessa uudistettavalla ohjelmistolla on liiketoiminnan kannalta suuri arvo. Ohjelmiston laatu on keskitasoa, mutta sen voidaan silti ajatella olevan tekniseltä laadultaan heikkoa.

Tämä johtuu siitä, että ohjelmasta puuttuu nykypäivänä tärkeitä ominaisuuksia. Näiden ominaisuuksien kannalta tarkasteltuna tekninen laatu ei ole riittävällä tasolla. Erityisesti ohjelmiston suunnitteluratkaisut eivät tue uusien ominaisuuksien toteuttamista nykyiseen järjestelmään. Tämän takia päädyttiin suunnittelemaan uudelleen komponenttikirjastot ja kiinnittämään erityistä huomiota ohjelmiston arkkitehtuurin uudistamiseen.

3.2 Arkkitehtuuriset tyylit

Ohjelmiston elinkaaren alkuvaiheessa ongelman tunnistamisen ja vaatimusmäärittely- jen jälkeen luodaan suunnitelma ohjelmiston arkkitehtuurista. Arkkitehtuurin suunnitte- lussa pyritään ymmärtämään laajempi kokonaisuus, johon suunniteltava ohjelmisto kuu- luu. Päämääränä on kuvata kehitettävä ohjelmisto korkealla abstraktiotasolla. Korkealla abstraktiotasolla työskennellessä kohdattavat ongelmat useimmiten toistuvat myöhem- min projektista toiseen. Toistuvia suunnitteluongelmia varten arkkitehtuurin suunnittelus- sa käytetään arkkitehtuurisia tyylejä. Arkkitehtuurinen tyyli on joukko arkkitehtuurisia pää- töksiä, joita voidaan soveltaa toistuvan suunnitteluongelman ratkaisuun ja joka ottaa huo- mioon erilaiset ohjelmistokehityksen ympäristöt, jossa ongelma esiintyy [19].

Arkkitehtuuriset tyylit yleensä jaotellaan kategorioihin siten, että samantyylisen ongelman ratkaisevat tyylit kuuluvat samaan kategoriaan. Ongelmatyypin mukaisesti myös Sharma et al. kokoavat katsauksessaan [20] yhteen tärkeimmät arkkitehtuuriset tyylit. Listatuis- ta arkkitehtuurisista tyyleistä käydään läpi rakenteelliset arkkitehtuurityylit, sillä ne ovat diplomityön kannalta oleellisimmat tyylit. Komponenttikirjastojen uudistamisessa on kyse pääasiassa rakenteen uudistamisesta. Rakenteellisia arkkitehtuurityylejä ovat:

• komponenttipohjainen arkkitehtuuri

• tietovuoarkkitehtuuri (engl. Pipes and filters architecture)

• monoliittiarkkitehtuuri

• kerrosarkkitehtuuri (engl. Layered architecture).

Arkkitehtuurisia tyylejä vertailtaessa on hyvä muistaa, että ne eivät sulje pois toisiaan. Lä- hes aina lopullinen arkkitehtuuri sisältää monta arkkitehtuurista tyyliä. Esimerkiksi hyvin korkealla tasolla voidaan hyödyntää yleisesti yhtä arkkitehtuuria, mutta kyseisen arkkiteh- tuurin komponenteissa voidaan käyttää useaa muuta arkkitehtuuria. Lisäksi harvoin ark- kitehtuurista tyyliä voidaan soveltaa sellaisenaan lopulliseen järjestelmään, vaan usein joudutaan tekemään kompromisseja.

3.2.1 Komponenttipohjainen arkkitehtuuri

Komponenttipohjaisessa arkkitehtuurissa järjestelmä koostetaan yhteen komponenteis- ta. Komponentti on itsenäinen yksikkö, jonka käyttö tapahtuu sen tarjoaman rajapinnan avulla. Tavoitteena on, että komponentit ovat mahdollisimman itsenäisiä. Useimmiten kui- tenkin komponentti tietää joitain asioita järjestelmästä, johon se on liitetty. Lisäksi kom- ponentti voi olla riippuvainen muista komponenteista. Tällaisesta tilanteesta, jossa kom- ponentti on riippuvainen muista rajapinnoista käytetään termiä vaadittu rajapinta (engl.

required interface). Ideaalisessa tilanteessa tällaisia rajapintoja ei ole, mutta sellaisen jär- jestelmän suunnittelu on hyvin vaikeaa ja jossain tilanteissa mahdotonta.

Riippuvuuksien lisäksi voidaan tarkastella komponenttien pätevyyttä eli komponenttien kykyä vastata järjestelmän vaatimuksiin. Parhaiten järjestelmän vaatimukset täyttää sel- lainen komponentti, jonka voi suoraan liittää osaksi järjestelmää käyttäen hyväksi olemas- sa olevia rajapintoja. Käytännössä tällaisia tilanteita on harvoin ja useimmiten komponent- tia tarvitsee muokata. Komponentteja voidaan jaotella kolmeen ryhmään sen mukaan, kuinka paljon komponentin sisäistä tilaa voidaan muokata [21]. Nämä kolme ryhmää ovat:

musta, harmaa ja valkoinen laatikko. Mustaa laatikkoa ei voida ollenkaan muokata. Tyy- pillinen esimerkki mustista laatikoista ovat binääritiedostot, joita vain suoritetaan järjes- telmässä. Harmaista laatikoista voi muokata ainoastaan rajapintaa. Rajapinnan muok- kaus tehdään usein käyttäen sovittimia (engl. wrapper/adapter). Tällaisia tilanteita esiin- tyy usein silloin, kun komponentteja päivitetään ja uusi rajapinta halutaan ottaa käyttöön

muokkaamatta järjestelmää. Valkoisten laatikoiden sisäinen rakenne on avointa tietoa ja ne ovat täysin muokattavissa.

Komponenttien itsenäisyydellä ja pätevyydellä pyritään saavuttamaan helposti uudelleen- käytettäviä ohjelman osia. Lisäksi itsenäiset komponentit mahdollistavat järjestelmän ta- solla loistavan skaalautuvuuden ja siirrettävyyden. Nämä hyödyt tulevat siitä, että ohjel- masta on helppo vaihtaa tiettyjä haluttuja osia toisiksi. Tosin hyötyjen saavuttamiseksi mo- nesti komponenttipohjainen järjestelmä on hankalampi suunnitella kuin muut myöhemmin esiteltävät arkkitehtuurityylit. Haasteet liittyvät erityisesti uudelleen käytettävien rajapinto- jen suunnitteluun. Suppeahko ja yleinen rajapinta on mahdollista käyttää helposti uudel- leen, mutta sen hyödyntäminen täysin on usein hankalaa. Toisaalta hyvin tarkasti tiettyyn tehtävään suunnattua komponenttia voi olla vaikea käyttää uudelleen. Uudelleenkäyttö haastaa komponentteja käyttävää järjestelmää vaadittujen rajapintojen suhteen, sillä ra- japinnan tulee olla hyvin suljettu muutoksilta.

Komponenttipohjainen arkkitehtuuri sopii parhaiten toistuvien samankaltaisten ohjelmien tekoon. Ensimmäinen ohjelma vie enemmän aikaa tehdä, mutta sitä seuraavat ohjelmat ovat huomattavasti nopeampia tehdä. Lisäksi yleensä saavutetaan myös helpommin yl- läpidettävä joukko ohjelmia kuin sillä, että jokainen ohjelma olisi suunniteltu erikseen.

Testauksen kannalta komponentit helpottavat yksikkötestausta, mutta lisäävät integraa- tiotestauksen määrää.

3.2.2 Tietovuoarkkitehtuuri

Kuva 3.3.Tietovuoarkkitehtuuri [22, s. 132]

Tietovuoarkkitehtuuri koostuu itsenäisistä komponenteista (engl. filter) ja niitä yhdistävistä väylistä (engl. pipe), joissa tieto kulkee komponentista toiseen komponenttiin (kuva 3.3).

Komponentit toimivat funktioiden lailla eli lopputulos riippuu ainoastaan syötteestä. Kom- ponenteilla ei siis ole yhteistä jaettua tilatietoa. Lisäksi prosessoinnin tulisi tapahtua yh- dessä vaiheessa kerralla siten, että syötetiedon prosessointi ei saa riippua toisen kompo- nentin prosessoinnin tuloksesta [22]. Rakenne saa haarautua, kuten kuvassa 3.3, kunhan rakenteeseen ei synny silmukoita. Käytännössä kuitenkin yleisin käytetty tietovuorakenne on liukuhihna-arkkitehtuuri. Siinä tieto kulkee systeemin läpi haarautumatta kertaakaan.

Liukuhihna-arkkitehtuuria käytetään esimerkiksi kuvan käsittelyssä, koneoppimisessa ja kääntäjissä.

Tietovuoarkkitehtuurin suurimpia etuja ovat komponenttien helppo uudelleenkäytettävyys ja koko järjestelmän joustava muokkaus. Tietovuoarkkitehtuuria on helppo muokata, sillä jokainen komponentti on hyvin itsenäinen ja niitä on helppo vaihtaa toisiin komponenttei- hin. Komponenttien riippumattomuuden ansiosta komponentteja on muokkaamisen lisäk- si helppo lisätä. Riippumattomuus mahdollistaa myös sen, että vaikea tehtävä voidaan pilkkoa pieniin osiin. Lisäksi oleellinen tietovuoarkkitehtuurin hyvä puoli on hyvä tuki rin- nakkaiselle sekä samanaikaiselle laskennalle.

Suurimpana heikkoutena taas on soveltumattomuus interaktiivisiin järjestelmiin. Ongel- mana on erityisesti se, että hyvin harvoin komponenttien tuottamat välivaiheet ovat käyt- täjän kannalta mielekkäitä. Interaktiivisen järjestelmän ohella tietovuoarkkitehtuurin heik- koutena on myös heikko virhetilanteiden sietokyky. Tiedon välittäminen komponenttien välillä saattaa joskus johtaa suorituskyvyn heikkenemiseen [22]. Putkissa liikkuvan tie- don muodosta riippuen kukin komponentti voi joutua jäsentämään syötetiedon käsittelyä varten ja sen jälkeen muuttamaan lopputuloksen takaisin alkuperäiseen muotoon. Kai- ken kaikkiaan tietovuoarkkitehtuuri on loistava vaihtoehto ei-interaktiivisen järjestelmän arkkitehtuuriksi. Toisaalta interaktiivisen järjestelmän osa voi olla toteutettu hyödyntäen tietovuoarkkitehtuuria

3.2.3 Monoliittiarkkitehtuuri

Monoliittiarkkitehtuuri edustaa perinteistä tyyliä tuottaa ohjelmia. Perusajatuksena on pi- tää kaikki palvelut lähellä toisiaan yhdessä paikassa. Tuloksena on yksi sovellus, joka sisältää kaikki rajapinnat. Tämä tapa on erittäin luonnollinen tapa tehdä ohjelmia, mut- ta usein se ei ole kannattavin tapa. Esimerkiksi verkkosovellus usein tehdään niin, että se jaetaan kolmeen osaan: käyttöliittymään, tietokantaan ja palvelinpuolen sovellukseen.

Tyypillisesti palvelinpuolen sovellus on suunniteltu monoliittisella arkkitehtuurilla [23]. Yh- den sovelluksen asentaminen ja ajaminen palvelimella tai kehittäjän omalla koneella tes- tattaessa on helppoa. Lisäksi sovelluksen skaalaaminen ylöspäin on helppoa, sillä sama sovellus voidaan nopeasti kopioida toiselle palvelimelle ajettavaksi.

Ongelmia taas monoliittisissa ohjelmissa alkaa syntymään ajan kuluessa, kun koodin määrä kasvaa, vaatimukset muuttuvat ja ihmiset vaihtuvat projektissa. Iso yhtenäinen koodikanta aiheuttaa sen, että pienenkin muutoksen teko vaatii koko sovelluksen raken- tamisen ja ajamisen. Lisäksi iso koodikanta hankaloittaa uuden henkilön liittymistä pro- jektiin, sillä tehdäkseen muutoksia kehittäjän on usein ymmärrettävä koko usein moni- mutkaisen sovelluksen toiminta [24]. Monoliittinen arkkitehtuuri on myös haavoittuvainen virhetilanteille, koska vika yksittäisessä moduulissa voi kaataa koko sovelluksen [24].

Monoliittinen ratkaisu sopii yksinkertaisuutensa vuoksi käytettäväksi nopeiden prototyyp- pien ja konseptien toimivuuden todentamiseen (engl. proof of concept). Monesti on hyö- dyllistä projektin aluksi tehdä monoliittinen ratkaisu, jotta saadaan nopeasti kasvatettua ymmärrystä suunniteltavasta ohjelmistosta. Kuitenkin nykypäivänä lopulliseksi kokonais- ratkaisuksi monoliittinen arkkitehtuuri ei enää sovi tai lähes aina löytyy kannattavampi vaihtoehto sille.

3.2.4 Kerrosarkkitehtuuri

Kerrosarkkitehtuurissa järjestelmä jaetaan abstraktiotasoihin eli kerroksiin. Perusideana on, että jokainen kerros käyttää ainoastaan välittömästi alempana olevan kerroksen pal- veluita. Kuitenkin käytännössä näin ideaaliin tilanteeseen päädytään erittäin harvoin. Ylei- sin ja hyväksytyin poikkeama on tehdä kutsuja syvemmällä oleville tasoille. Tällaista alem- man kerroksen ohittamista ei ole iso rikkomus arkkitehtuurista tyyliä vastaan, mutta usein toistettuna ei enää saavuteta kerrosarkkitehtuurin hyötyjä. Syynä kerrosten ohittamiseen useimmiten on tehokkuus, sillä usein palvelu on tehokkainta kutsua suoraan alemmilta tasoilta [22]. Joskus voi myös olla niin, että palvelua ei ole tarjolla välittömästi alemmalla kerroksella.

Huomattavasti vakavampi rikkomus on tehdä kutsuja alemmasta kerroksesta ylempään kerrokseen. Joskus kuitenkin joudutaan tekemään kutsuja ylöspäin. Näissä tilanteissa kutsut toteutetaan käyttäen takaisinkutsua (engl callback). Takaisinkutsujen avulla sy- vempi kerros ei tule riippuvaiseksi alemmasta kerroksesta. Kuvassa 3.4 on esitetty yleisin ja yksinkertaisin tapa kuvata kerrosarkkitehtuuria, siinä jokainen komponentti esitetään omana suorakulmionaan. Tässä visualisointitavassa korostuvat ohitetut komponentit, jot- ka lasketaan kuuluvan osaksi ohituksen tekevää komponenttia.

Kuva 3.4.Kaksi erilaista kerrosarkkitehtuuria (muokattu [22])

Kerrosarkkitehtuurin käytöllä ei ole rajoituksia, vaan sitä voidaan soveltaa melkein aina.

Lisäksi kerrosarkkitehtuurin etuina on modulaarisuuden ja uudelleenkäytön lisääntymi- nen. Kerrosarkkitehtuurin avulla järjestelmästä tulee selkeämpi ja se luonnostaan oh-

jaa vähentämään riippuvuuksia komponenttien välillä. Kerrosarkkitehtuurin intuitiivisuu- den ja yksinkertaisen rakenteen ansiosta sen avulla tehdystä järjestelmästä on helpompi keskustella myös niiden kanssa, jotka eivät ymmärrä ohjelmistokehityksestä tarpeeksi.

Kerrosarkkitehtuurin suurimpana heikkoutena on aiemmin ohitusten yhteydessä mainit- tu suorituskyky, joka voi heiketä kerrosten takia. Suorituskyvyn ohella kerrosarkkitehtuuri voi tehdä hankalaksi poikkeusten käsittelyn. Poikkeuksen käsittelijä ja poikkeuksen lä- hettäjän välillä voi olla monta kerrosta. Tällaisessa tilanteessa poikkeuksen käsittelijä ei välttämättä osaa reagoida poikkeukseen.

4 TAUSTAYMPÄRISTÖ

4.1 Vertex tuoteperhe

Vertex tarjoaa suunnittelun ja tiedonhallinnan ohjelmistoratkaisuja. Tämän työn kannalta oleellisimmat tuotteet ovat CAD-suunnitteluohjelmistot (ks. kuva 4.1). Tuotteita on mon- ta erilaista, ja ne vastaavat hyvin erilaisiin tarpeisiin. HD-, ED- ja InD-ohjelmat on tar- kimmin kohdennettu tietylle toimialalle, kun taas G4- ja G4Plant-ohjelmilla on suhteelli- sen laaja asiakaskunta eri toimialoilla. Kun ajatellaan kokonaisuudessaan tuoteperheen tarpeita komponenttikirjastojen näkökulmasta, täytyy kuitenkin muistaa, että suunnittelua voidaan jakaa eri ohjelmistojen kesken. Esimerkiksi InD-suunnitteluohjelmistolla suun- nitellessa kalusteita ja keittiöitä monet yksittäiset mallit on usein voitu tehdä käyttäen G4-ohjelmaa. G4:llä tuotettuja malleja käytetäänkin myös paljon muissa tuotteissa. Tuot- teiden yhteiskäyttö on tavallisinta G4Plant-ohjelmalla suunniteltaessa. G4:llä tuotettujen mallien lisäksi G4Plant-mallissa voidaan käyttää usein suunnittelun tukena prosessi- ja instrumenttikaavioita (G4PI).

Kuva 4.1.Vertex:n erilaiset CAD suunnitteluohjelmistot [25]

4.2 Komponenttikirjastojen uudistamistarpeet

CAD-ohjelmistotuoteperheen tuotteet poikkeavat hyvin paljon toisistaan. Eroavaisuuksis- ta huolimatta tahto uudistaa niiden komponenttikirjastoja on kuitenkin yhteinen. Suurin yhteinen huolenaihe on nykyinen ylläpidon tilanne. Siihen liittyy olennaisesti koko jär- jestelmän rakenne, jossa Vertexin toimittamat oletuskomponentit voi korvata lisäämällä asiakkaan puolelle vastaavat muokatut tiedostot. Näin asiakkaan on helppo mukauttaa ohjelmisto omiin tarpeisiin sopivaksi. Vertexin näkökulmasta ylikirjoittaminen tekee tie- dostojen päivittämisestä hankalaa, sillä muutosten siirtäminen asiakkaalle vaatii lisätyö- tä. Monet järjestelmän mukana tulevat tiedostot ovat kuitenkin luonteeltaan sellaisia, että niitä on harvoin tarve päivittää. Kuitenkin kirjastojen kohdalla usein uusia ominaisuuksia lisättäessä on tarve lisätä uusia parametrejä kirjastoon. Lisäksi kirjastoja halutaan laajen- taa ajan mittaan, kun esimerkiksi alalle kehitetään uusia materiaaleja tai uuden kokoisia komponentteja. Toinen iso yhteinen tarve on tehdä kirjastojen muokkaamisesta ja luo- misesta helpompaa. Tällä hetkellä uusien kirjastojen teko on vanhan käyttöliittymän ja kirjastojen staattisen rakenteen takia hankalaa.

Kuva 4.2.Komponentin valinta Vertex G4:ssä [25]

Kirjastot halutaan myös tarjota ladattaviksi verkosta. Nykyinen rakenne ei kuitenkaan mahdollista sitä. Siksi kirjastojen rakenteen uudistaminen olisi tärkeää. Tällöin voitaisiin vähentää kirjastojen määrää itse ohjelman toimittamisen yhteydessä. Kirjastot voitaisiin

ladata tarvittaessa ohjelman käytön aikana. Näin asiakkaalle ei tule kirjastoja, joita hän ei tarvitse, ja lisäksi ohjelman asennus nopeutuu.

Kirjastoja on tarve uudistaa myös tuotekohtaisesti. Mekaniikka- ja laitossuunnittelussa ei ole tällä hetkellä olemassa kirjastoja, vaan tiedostojärjestelmän kansiot ja kansiorakenteet näkyvät sovelluksessa (kuva 4.2). Kun tiedostojen ja kansioiden nimet näkyvät sovelluk- sessa, joudutaan luomaan useita erikielisiä kansioita ja kopioimaan samoja malleja näihin kansioihin. Kirjastojen uudistamisella haetaan myös tuotteiden sisäisen yhtenäisyyden li- säämistä. Erityisesti BD-ohjelmistossa kirjastoja on ollut jo pitkään paljon käytössä. Ajan mittaan erityyppisten kirjastojen rakenteelliset erot ovat kasvaneet isoiksi. Tämän takia kirjastojen uudistamisen ja yhtenäistämisen tarve on suurin BD:ssä ja jatkossa keskity- täänkin erityisesti BD:n kirjastoihin. Samalla toki pyritään myös vähentämään tuotteiden välisiä eroja.

5 VERTEX BD JA KOMPONENTTIKIRJASTOT

5.1 Vertex BD

Vertex BD (Building design) on rakennussuunnitteluohjelmisto, joka perustuu rakennuk- sen tietomalliin (Building information model). Se on suunniteltu tukemaan laajasti teollista rakentamista aina suunnittelusta valmistukseen. Rakennuksen tietomalli tarkoittaa sitä, että ohjelmassa nähtävillä olevan mallin tiedot ovat yhdessä samassa paikassa. Tämä mahdollistaa sen, että mitään ei tarvitse mallintaa kahdesti. Erilaisia näkymiä on myös tällöin helppo tehdä, sillä kaikki tieto tulee yhdestä mallista. Toisaalta pienikin muutos mallissa vaikuttaa moneen eri näkymään. Kuvassa 5.1 on lueteltu tietoja, jotka löytyvät Vertex BD:n tietomallista sekä lisäksi havainnollistettu runko- ja arkkitehtinäkymät.

Kuva 5.1.BD mallin sisältämät tiedot. Keskellä esitetty runko- ja arkkitehtimallin ulkoasu.

[26]

Vertex BD:stä löytyy monta eri aluekohtaista ohjelmiston versiota, joista käytetään jatkos- sa nimitystä ympäristö. Versiosta puhuttaessa tarkoitetaan taas vuosittain julkaistavan saman ympäristön ohjelmistoa. Eri aluekohtaisten ympäristöjen lisäksi teräs- ja puura- kentamiselle on olemassa omat ympäristönsä. Erilaiset räätälöidyt ympäristöt ovat mah-

dollistaneet nopean ja joustavan reagoinnin paikallisten ongelmien ratkomiseksi. Kuiten- kin nyt tarkoituksena on kutistaa ympäristöjen määrää, jotta saavutetaan kokonaisuuden ylläpidettävyyden kannalta eheämpi lopputulos. Lukuisten versioiden ja niiden ympäris- töjen ylläpito on liian työlästä, sillä jokaisessa ympäristössä ylläpidon lisäksi täytetään asiakkaiden yksilöllisiä tarpeita. Ympäristöjen ja samalla niiden ylläpito vähenee, jolloin aikaa jää enemmän asiakaskohtaisten konfigurointien tekoon. Nopea ja joustava reagoin- ti tulee siis silti säilymään, ja vain muokkausten kohde tulee muuttumaan. Jatkossa oh- jelmaan erikseen tuotavien uudistettujen komponenttikirjastojen avulla tullaan hoitamaan aluekohtaiset eroavaisuudet muokkaamatta itse ohjelmaa.

Itsessään suunnittelu Vertex BD:llä etenee tyypillisesti niin, että ensin malliin lisätään ha- lutut komponentit ja sen jälkeen suunnittelija tekee tarvittavat muutokset. Valmiiden osien ja automatiikan avulla saadaan aikaan lähes valmis malli. Useimmiten malli vaatii vain pientä viimeistelyä, ja ainoastaan haastavimmat paikat pitää suunnitella käsin. Aiemmin mainitut valmiit komponentit on lähes kaikki lajiteltu käytön ja laadun mukaan komponent- tikirjastoihin. Kirjastoja löytyy paljon valmiina, ja uusia voi tehdä itse lisää alusta alkaen tai muokata täysin valmiiden kirjastojen pohjalta.

Kuva 5.2.Kirjaston määrittelytiedoston muokkausnäkymä

5.2 Komponenttikirjastot

Komponenttikirjastojen tehtävä on tarjota komponentteja, joiden parametrit ovat valmiiksi määritelty vastaamaan mahdollisimman lähelle käyttötilannetta. Komponenttikirjastot on toteutettu pääosin käyttämällä tietokantoja. Tietokannat pystyvät vastaamaan varsin hy- vin kirjastojen tarpeisiin. Ongelmia kuitenkin aiheuttaa eri ympäristöjen samannimiset kir- jastot. Vertex BD:ssä on kirjastojen hallintaan oma järjestelmä, joka korvaa samannimiset tietokannat toisilla. Nykyinen järjestelmä toimii hyvin asiakkaiden kirjastojen käsittelyssä,

mutta samalla se pakottaa tekemään eri ympäristöille omat tietokannat. Lisäksi saman ympäristön eri versioiden tietokannat voivat poiketa toisistaan. Tämä tekee tietokantojen ylläpidosta työlästä. Tietokannan lisäksi komponenttikirjasto sisältää määrittelytiedoston, joka kertoo muun muassa kirjaston tyypin (kuva 5.2). Kirjaston tyypin avulla sovellus osaa näyttää kirjaston oikeassa käyttötapauksessa.

5.3 Komponentit ja niiden rakenne

Komponentilla tarkoitetaan yleisesti jonkin suuremman kokonaisuuden osaa. Komponent- ti on hyvin abstrakti käsite, joka riippuu paljon siitä mitä ollaan suunnittelemassa ja mis- sä vaiheessa suunnittelua ollaan. Mekaniikkasuunnittelussa käytetään esimerkiksi paljon komponentteina ruuveja, muttereja ja kierteitä, kun taas rakennussuunnittelussa käyte- tään sen sijaan lattioita, seiniä ja kattoja. Komponentit eivät ole muuttumattomia kokonai- suuksia vaan ne voidaan jakaa osiin eli komponenteiksi mikä onkin käytännössä erittäin yleistä.

Komponenttien valikoima ei rajoitu pelkästään fyysisiin osiin vaan myös työstöt, työkalut, kaavat ja 2D-mallit ovat komponentteja. Työstöt ovat erilaisia fyysiseen komponenttiin tulevia muotoiluja. Työstöt eivät useimmiten sisällä itsessään fyysistä komponenttia, vaan ne määrittelevät mittoja ja sääntöjä, miten muotoilu ilmentyy komponentissa, johon työstö on liitetty. Esimerkkinä työstöistä ovat erilaiset palkkien liitokset (kuva 5.3).

Kuva 5.3.Kolme palkkien välistä liitosta

Työkalu taas on ennalta määrätty säännöstö. Se määrittää esimerkiksi, miten joukko komponentteja sijoittuu ja millaisia työstöjä mahdollisesti käytetään. Esimerkkinä Vertex BD:ssä käytetään vaaka- ja pystyrakenteiden elementtien muodostamiseen rakennetyö- kaluja. Elementtiä muodostaessa rakennetyökalu määrittää muun muassa sen, mitä tolp- pia käytetään missäkin kohdassa runkoa. Kuvassa 5.4 ulkoseinästä on rakennetyökalun

avulla muodostettu seinäelementti, josta on piilotettu verhous- ja levytyskerrokset ja jäl- jellä on näkyvillä pelkkä puurunko. Puurungossa näkyy hyvin kuinka aukkojen (ikkunan ja oven) ympärillä tolppien määrä ja sijainti vaihtelevat paljon muuhun runkoon nähden.

Lisäksi työstöistä erottuu alhaalla oleva tukilauta, joka on kiinnitetty pystypalkkeihin lo- veuksella.

Kaavojen (engl. schemes) alle tässä yhteydessä niputetaan kaikki säännöt, jotka eivät suoraan vaikuta 3D-rakenteisiin. Tällaisia ovat muun muassa numerointisäännöt, raportit ja mitoitustaulukot. 2D-mallit voidaan myös ajatella kaavoiksi, sillä esimerkiksi piirustukset sisältävät paljon sääntöjä ja parametreja siitä, miten eri 3D-mallit näytetään kuvissa.

Kuva 5.4.Seinäelementin puurunko ja lista sen sisältämistä komponenteista

Aiemmin esitellyt komponentit on tyypitelty tarkemmin helpottamaan käytännön suunnit- telutyötä. Näin pystytään käyttäjälle näyttämään vain olennaiset komponentit käyttötilan- teen mukaan. Ilman komponenttien tyyppejä ei voida tietää mihin käyttötarkoitukseen komponentti on suunniteltu.

6 ARKKITEHTUURI

6.1 Kokonaisuus

Uudessa arkkitehtuurissa keskeisimpinä tavoitteina oli koodin ja eri ohjelman osien roo- lien selkeyttäminen. Vanhojen luokkien roolit olivat ajan kuluessa sotkeutuneet. Tämä hankaloittaa paljon ylläpitoa, minkä takia roolien selkeyttäminen nostettiin keskeiseksi ta- voitteeksi. Roolien epämääräisyydestä huolimatta luokat yhdessä suurin piirtein noudat- tivat kerrosarkkitehtuuria. Kerrosarkkitehtuuri sopi hyvin edelleen myös uuden arkkiteh- tuurin tyyliksi, sillä komponenttikirjastot ja niihin liittyvät luokat muodostavat hyvin hierar- kisen rakenteen. Tavotteiden kannalta tärkeää on myös, että kerrosarkkitehtuuri ohjaa luonnostaan vähentämään luokkien välisiä riippuvuuksia. Mitä vähemmän luokkien välillä on riippuvuuksiä sitä selkeämpinä luokkien roolit pysyvät.

Kuva 6.1.Yleiskuva koko arkkitehtuurista

Kuvassa 6.1 havainnollistettu hyvin yksinkertaisesti koko arkkitehtuuri kerrosarkkitehtuu- rille tyypillisellä tavalla, jossa käyttäjää lähinnä olevat kerrokset ovat ylhäällä. Käyttäjän sijaan arkkitehtuuri on kuvattu nyt Vertex BD:n kehittäjän näkökulmasta. Kehittäjää lähin- nä on manageri-kerros, joka toimii julkisivuna piilottaen muut luokat taakseen. Manageri toimii yhteisenä rajapintana muille luokille ja sen pääasiallisena tarkoituksena on tarjota muiden luokkien tärkeimmät palvelut helposti käytettäväksi muulle sovellukselle.

Manageri on modernisoitu vanhasta olemassa olevasta luokasta, joka hallinnoi erilaisia tietokantoja ja piti kirjaa tiedostojärjestelmän poluista. Tämä näkyy vielä ylimääräisinä

arkkitehtuurin rikkomuksina. Esimerkiksi kuvassa 6.1 näkyvänä ohituksena, joka ulot- tuu managerista aina datan luvusta huolehtivaan luokkaan asti. Komponentti ja datan käsittely ovat myös modernisoitu vanhoista luokista. Loput kerrokset ovat käytännössä aivan uusia. Kuitenkin niissäkin on uudelleensuunnittelun periaatteiden mukaisesti tuo- maan mukaan vanhasta ohjelmasta käsitteitä, jotka on modernisoinnissa uudistettu.

Jatkossa managerin tarkoituksena on tarjota vain komponenttien ja komponenttien ha- kuun liittyviä palveluita. Merkittävimpänä hyötynä manageri mahdollistaa tehokkaat haut kirjastoihin ja komponentteihin. Managerin avulla komponenttien hakemiset voidaan te- hokkaasti kohdistaa saman tyyppisiin kirjastoihin ilman, että kutsujalle tarvitsee palauttaa kaikkia kirjastoja.

Lisäksi managerin avulla voidaan tehokkuuden lisäämiseksi puskuroida haettuja kirjasto- ja ja komponentteja. Puskuri nopeuttaa erityisesti tilanteita, joissa automaattisesti tuote- taan malleja. Samojen kirjastojen komponentteja käytetään useita kertoja eri paikoissa ja niiden malleja tuottaessa tiedot haetaan useita kertoja uusiksi kirjastosta.

6.2 Moduuli

Moduuli toimii kirjastoja ryhmittelevänä luokkana, jonka päätehtävä on huolehtia sen si- sältämien kirjastojen päivittämisestä ja aktiivisuuksista. Moduuli voi kirjastojen lisäksi si- sältää toisia moduuleja. Aktivoitaessa tai päivittäessä moduulia pitää siis kirjastojen li- säksi huolehtia, että alimoduulitkin tekevät samat toimenpiteet. Moduulit muodostavat tä- tä varten yksisuuntaisen linkitetyn listan, jonka avulla toimenpiteet koko moduuliketjulle saadaan helposti ja nopeasti suoritettua.

Moduuleita aktivoimalla muodostetaan joukko-opillisesti ajatellen moduulien ja kirjastojen unioni. Rajoitteena joukko-oppiin verrattuna on kuitenkin se, että moduulit eivät voi sisäl- tää kirjastojen komplementteja eli tässä tapauksessa moduuli ei voi kytkeä pois päältä tiettyjä kirjastoja. Näin samojen kirjastojen kuuluminen moneen moduuliin ei ole ongel- ma. Teoriassa poiskytkentä ei ole ongelma, mutta käytännössä se voi aiheuttaa rikkinäi- sen ympäristön. Tämä johtuu siitä, että kirjastot eivät ole täysin itsenäisiä ja ne voivat olla riippuvaisia toisista kirjastoista. Lisäksi poiskytkennät hankaloittavat tarpeettomasti koko järjestelmän hahmottamista.

Moduulimanagerin tehtävänä on lukea tiedot moduuleista ja ylläpitää listaa kaikista mo- duuleista. Listan ylläpitoon kuuluu aktiivisuuksien päivittäminen tarvittaessa sekä varmis- taa listan eheys. Listan eheys voi rikkoutua esimerkiksi tilanteessa, jossa moduuleista muodostuvaan linkitettyyn listaan syntyy muokattaessa silmukka. Kaikkien moduulien si- sältämän listan myötä moduulimanagerin avulla voidaan helposti aktivoida yksittäisiä mo- duuleja. Moduulimanageri tehtävänä onkin myös pitää listaa näistä käyttäjän aktivoimista moduuleista ja hoitaa niiden aktiivisuuden säilyminen käyttökertojen välillä.

Kuva 6.2.Luokkakaavio moduulikerroksesta

Kuvassa 6.2 on esitetty luokkakaaviona koko moduulikerros. Moduulien hallinnoinnin li- säksi moduulimanageri toimii myös julkisivuna moduuleihin liittyville palveluille, joita ma- nageri tarvitsee. Kokonaisarkkitehtuurissa manageri pystyy ohittamaan moduulikerrok- sen ja pääsee käsiksi suoraan kirjastoihin ilman moduulikerrosta. Moduulit taas toimivat lähes itsenäisesti ja noudattaen kerrosarkkitehtuuria. Moduulit tarvitsevat moduulimana- gerin palveluita vain silloin, kun käskyjä välitetään alimoduuleille. Kirjaston palveluja taas moduuli ei tällä hetkellä vielä tarvitse, sillä niiden päivittäminen on ainoa moduulin tarvit- sema palvelu kirjastolta ja se hoidetaan toistaiseksi käsin.

6.3 Kirjasto

Kirjastokerroksen tärkeinpänä tehtävänä on tarjota komponenttien hakuun, muokkauk- seen ja poistoon liittyvät palvelut. Lisäksi kerros tarjoaa kirjaston omiin tietoihin liittyviä palveluita. Näihin kuuluu kirjaston perustietojen lisäksi palveluita, joiden avulla esimerkik- si kirjasto osataan näyttää oikein käyttöliittymässä. Erilaisia kirjastotyyppikohtaisia palve- luita voidaan tarjota periyttämällä kirjastoluokka. Näin kantaluokka pysyy tiiviinä ja help- pokäyttöisenä.

Kuva 6.3.Luokkakaavio kirjastokerroksesta

Kuvassa 6.3 on kuvattu kirjastokerroksen tämän hetkiset luokat. Lisäksi kuvassa näkyy tyhjinä luokkina muihin kerroksiin kuuluvat luokat, jotka ovat yhteydessä kirjastokerrok- seen. Kirjasto-luokassa on myös korostettu tiedon käsittelystä vastaava luokka, sillä se ei myöskään kuulu kirjastokerrokseen. Kirjaston ja siitä perittyjen luokkien lisäksi kirjaston aktiivisuuksista vastaava luokka kuuluu myös olennaisesti mukaan kirjastokerrokseen.

Etenkin siirtymävaiheessa on tärkeää, että kirjastokohtaisesti voidaan säätää kirjastojen aktiivisuuksia. Näin siirtymästä tehdään käyttäjäyställinen, sillä käyttäjän ei tarvitse heti omaksua kaikkia uusia toimintatapoja. Kuitenkin pidemmällä aikavälillä kirjastojen aktii- visuudet tullaan hallitsemaan pääsääntöisesti moduulien avulla. Silloin kirjastokohtaisia

aktiivisuuksia käyttäjä voi tarvita lähinnä yksittäisten hyvin moneen moduuliin kuuluvien kirjastojen poiskytkentään.

6.4 Datan käsittelijä ja komponentti

Datan käsittelystä vastaava luokka noudattaa komponenttiarkkitehtuuria mahdollisimman paljon. Abstrakti kantaluokka toimii vaadittuna rajapintana, jotka siitä perityt luokat to- teuttavat. Näin komponenteista pyrittiin tekemään mahdollisimman itsenäisiä ja helposti vaihdettavia. Muiden kerroksien sisältämät toteutetukset riippuvat jonkin verran muista kerroksista ja tietävät toisten kerrosten rakenteista hajanaisia asioita. Datan käsittelyssä taas kaikkea tällaista lähdettiin välttämään. Vielä kuitenkin joitain tiedostopolkuihin liittyviä palveluita tarvitaan managerilta. Näiden palveluiden siirto tässä kohtaa vaatisi liikaa työtä, sillä moni vanha toteutus on vielä riippuvainen kyseisistä palveluista. Kuitenkin muulloin datan luvusta vastaavat luokat ovat hyvin riippumattomia muista luokista.

Kuva 6.4.Luokkakaavio komponentista ja datan käsittelystä vastaavista luokista

Kuvassa 6.4 on esitetty luokkakaavio, jossa keskeisesti kuvattu datan luku ja komponent- ti. Pilvipalvelua hyödyntävää lukijaa ei ole vielä toteutettu. Se on kuitenkin oleellista ottaa huomioon suunnittelussa ja siksi se on myös lisätty valmiiksi luokkakaavioon. Kompo- nentin ja datan käsittelijän välillä ei ole assosiaatiota, vaikka luettua dataa hyödynnetään komponentin avulla. Tämä johtuu siitä, että komponentit rakennetaan vasta kirjaston si- sällä, sillä kirjastolla voi tarve muokata tietoa, ennen kuin se annetaan komponentille.

Komponentin tehtävänä on tallentaa data ja tarjota palveluita, joilla sitä on helppo lu- kea. Komponentista yksinkertaisuudestaan huolimatta muodostui tärkeä tapa kommuni- koida rajapinnan lävitse sekä rajapinnan ulkopuolelta että rajapinnan sisällä. Komponen- tin avulla päästään helposti käsiksi kirjastoon ja sen avulla voidaan välittää muokattavat tiedot datan käsittelijälle.

7 ARVIOINTI JA JATKOKEHITYS

7.1 Arkkitehtuurin arviointi

Arkkitehtuurin arviointiin päätettiin käyttää DCAR-arviointimallia. Tähän päädyttiin, sillä ATAM koettiin liian raskaaksi ja lisäksi toteutettava kokonaisuus ei sisällä kriittisiä laatu- kriteereitä joita tulisi arvioida. Kuitenkin varhaisessa vaiheessa huomattiin myös DCAR:n olevan liian raskas sellaisenaan. Pienellä kehittäjäporukalla toteutettavan sisäisen projek- tin arviointiin ei ole mielekästä käyttää arviointimallia kokonaisuudessaan. Lisäksi haluttiin arkkitehtuurin arvioinnin olevan mahdollisimman helppoa ja kevyttä, jotta kynnys ottaa se käyttöön tulevaisuudessa olisi matala.

Toiveiden mukaisesti DCAR:a kevennettiin jättämällä priorisointi ja asiakkaan esittelyt pois. Sisäisessä projektissa ei ole suuri tarve esitellä asiakasta. Lisäksi päätöksiä ei prio- risoitu, sillä niiden määrä oli ennalta määrätty. Helppoutta haettiin käyttämällä käyttäjäta- rinoita (engl. user story) voimien rinnalla tukemaan päätösten arviointia. Käyttäjätarinat kuuluvat olennaisena osana nykypäivän ketterään ohjelmistokehitykseen. Ketterässä oh- jelmistokehityksessa käyttäjätarinoiden avulla arvioidaan ja testataan kehitysjakson (engl.

sprint) tehtäviä, joten niiden käyttäminen myös arkkitehtuurin arvioinnissa oli hyvin luon- tevaa.

Arkkitehtuurin arvioinnissa päätettiin keskittyä suurimmaksi osaksi moduuleihin, sillä ne ovat kokonaan uusi kokonaisuus komponenttikirjastoja uudistaessa. Täysin uutena osa- na moduuleihin liittyy todennäköisimmin suuremmat riskit kuin muihin arkkitehtuurin osiin.

Lisäksi moduulit olivat hyvä arvioinnin kohde, sillä niistä ei ollut luonnollisesti ollenkaan dokumentaatiota olemassa. Arvioinnissa keskityttiin erityisesti moduulien perusperiaattei- siin, jotta saadaan rakennettua vankka pohja moduulien suunnittelua varten. Perusperi- aatteiden dokumentoinnilla saadaan aikaan helposti vaatimukset, jotka ohjaavat moduu- lien toteutuksen suunnittelua.

Yksi tärkeimmistä perusperiaatteista oli moduulien muodostaminen kirjastoista. Kuinka moduulit muodostetaan, vaikuttaa paljon siihen, kuinka helppo niitä on ylläpitää ja käyt- tää. Tätä kokonaisuutta tarkastettiin BD ympäristön näkökulmasta, sillä se tullaan jatkos- sa koostamaan moduuleista. Lopullisessa arvioinnin lopputuloksissa korostui ylläpidon merkitys niin käyttäjän kuin sovelluksen toimittajan näkökulmasta.

Kuva 7.1.Dokumentoitu arkkitehtuuripäätös itsenäisistä moduuleista

Ensimmäisenä vaihtoehtona oli tehdä moduuleista täysin itsenäisiä (Kuva 7.1). Lopulli- nen ympäristö koostuisi vain yhdestä moduulista, jossa on määritelty kaikki sen sisältä- mät kirjastot. Kaksi muuta päätöstä taas perustuvat siihen, että moduulit voivat sisältää muita moduuleita. Tällöin kirjastomäärittelyt jakaantuvat monen eri moduulien kesken ja yksittäisten ympäristöjen ylläpito hankaloituu. Monet kirjastot ovat kuitenkin eri ympäris- töille yhteisiä, joten niiden määrittely moneen kertaan ei ole viisasta. Lisäksi tämä han- kaloittaa kokonaisuudessa ympäristöjen ylläpitoa, mikä muodostuu itsenäisten moduu- lien isoimmaksi ongelmaksi. Itsenäiset moduulit ovat myös käyttäjän näkökulmasta liian joustamattomia. Näin ollen yksimielisesti todettiin itsenäisen moduulin olevan sopimaton ratkaisu moduulien muodostamiseen

Ylläpidon näkökulmasta on mielekästä määrittää moduuleita niin, että ne voivat sisältää muita moduuleita. Näin pystytään vähentämään redundantin datan määrää ja tuomaan joustavuutta, jota ei saavutettu itsenäisten moduulien kanssa. Seuraavat kaksi ratkaisua perustuvat juurikin siihen, että moduulit voivat sisältää muita moduuleja. Ainoana erona on se, että saavatko moduulit mukauttaa alimoduuleitaan.

Ensin otetaan käsittelyyn päätös, jossa moduuleita saa muokata (kuva 7.2). Muokkauk- sella tarkoitetaan tässä tapauksessa vain aktiivisuuden muokkaamista eli kirjastojen pii-

Kuva 7.2.Dokumentoitu arkkitehtuuripäätös muokattavista moduuleista

lottamista käyttöliittymästä. Kirjastoja ei poisteta, vaan ne jätetään toisten kirjastojen käyt- töön. Kirjastojen piilotus on tärkeä ominaisuus suunnittelijan kannalta, jotta vain oleelliset kirjastot näkyvät käyttöliittymässä. Kirjastoja ei voida kuitenkaan poistaa kokonaan, sillä vielä ei ole mekanismia selvittää kirjastojen riippuvuuksia. Ei voida siis tietää, että onko tiettyyn kirjastoon viittauksia muista kirjastoista.

Muutettavien moduulien suurin ongelma kuitenkin liittyy aktiivisuuksien säätämiseen. Ak- tiivisuuksien säätö on hyvä ominaisuus, mutta siinä ajaudutaan helposti ongelmatilantei- siin. Kaksi eri moduulia voivat helposti määrätä saman kirjaston samaan aikaa aktiivisek- si ja ei-aktiiviseksi. Lopputuloksena helposti syntyvät loogiset ongelmat aiheuttavat sen, että muokattavista moduuleista ei ollut lopulliseksi ratkaisuksi.

Viimeinen päätös on hyvin samanlainen kuin muokattavat moduulit. Muokkaamattomat moduulit myös voivat sisältää muita moduuleita ja niistä koostetaan lopullinen ympäris- tö (kuva 7.3). Toisin kuin aiemmassa päätöksessä nyt ei sallita edes muokata moduulin kirjastojen aktiivisuutta. Syynä tähän on aiemmin mainitut loogiset ongelmat, jotka ai- heuttivat muilta osin hyvän päätöksen hylkäyksen. Muokkaamattomat moduulit voivat olla

Kuva 7.3.Dokumentoitu arkkitehtuuripäätös muokkaamattomista moduuleista

riittämättömiä käyttäjän kannalta, mutta ongelma täytyy ratkaista muuten kuin muokkaa- malla moduuleja. Toinen mahdollinen ongelma voi olla sisäisesti tarpeet korvata tiettyjä kirjastoja moduuleissa. Silti muokkaamattomat moduulit ovat selkeästi paras vaihtoehto ja siitä kannattaa lähteä liikkeelle.

Muut arvioinnit liittyivät myös moduuleihin. Ensimmäisissä arvioinneissa haettiin perus- teita moduulien ja kirjaston käyttöön tuoteversioiden ja ylläpidon vähentämiseksi sekä etsittiin vaihtoehtoisia lähestymistapoja. Sen jälkeen arvioitiin erilaisia tapoja kirjastojen jakamiseksi moduuleihin. Tämän jälkeen arvioitiin aiemmin esiteltyjen moduulien muo- dostamisen periaatteet. Moduulien muodostamiseksi oli päätetty sallia sisäkkäiset mää- rittelyt eli moduuli voi sisältää muita moduuleja. Viimeiseksi arvioitiin sitä kuinka monta peräkkäistä moduuliviitettä kannattaa olla peräkkäin lopullisessa ympäristörakenteessa.

Kaikkiin arviointeihin osallistui yhteensä kolme henkilöä. Arviointeihin osallistuneilla hen- kilöillä oli hyvä tietämys arvioinnin kohteen taustaympäristöstä ja sovelluksen nykytilasta.

Arvioinneissa muodostui käsitys siitä, että moduulit ovat perusteltu ratkaisu ympäristöjen ylläpidon keventämiseksi ja tuoteversioiden vähentämiseksi. Arvioinneissa saatiin aikaan myös selkeät periaatteet moduuleille. Itse arvioinnit koettiin onnistuneeksi, sillä konkreet- tisten dokumenttien ja päätösten lisäksi jokaisen osallistujan ymmärrys arvioinnin koh- teista kasvoi merkittävästi.

Yksittäisenä epäonnistumisena koettiin osittain moduulien jakoon liittyvän päätöksen ar- viointi. Siinä pitkälti valmistelussa oli päätöksen ongelma rajattu huonosti. Tämä johti sii- hen, että pitkälti ongelman reunaehdot sanelivat lopputulosta. Siitä johtuen itse päätök- sestä ja ongelmasta ei löydetty merkittävästi uusia näkökulmia. Paremmalla valmistelulla voidaan vähentää riskiä joutua arviointitilanteessa umpikujaan.

Tällä kertaa ei nähty tarvetta arvioida päätöstä uusiksi uudella ongelman rajauksella. Uu- delleenrajauksen lisäksi voitaisiin tehdä myös yksittäisten päätösten uudelleenarviointi- kin, mikäli argumentit ja niiden taustalla olevat voimat ovat huomattavasti muuttuneet.

7.2 Toiminnallisuuden arviointi

Vanhan toiminnallisuuden modernisoinnissa suurimmat saavutukset ylläpidon näkökul- masta olivat koodin koherenssin ja muokattavuuden lisääntyminen. Koodin koherenssi kasvoi merkittävästi, kun kirjastotieto erotettiin rajapintojen taakse. Kerrosarkkitehtuuria hyödyntämällä saatiin selkeytettyä ja tiivistettyä eri luokkien välistä työnjakoa. Selkeää työnjakoa kuvaa hyvin uusi kirjaston sisältämille komponenteille tehty oma luokka. Täs- tä komponenttiluokasta saatiin aikaan luokka, jonka avulla voidaan jakaa kirjaston tietoja erityyppisistä kirjastoista riippumatta. Komponentti saatiin pidettyä mahdollisimman ylei- senä, mikä helpottaa huomattavasti uusien kirjastojen luontia. Tiedon tulkintaa varten oli jo olemassa luokkia ja uusi komponentti oli luontevaa antaa parametrina näille luokille.

Näin komponentin ei tarvitse ymmärtää sisältämästään tiedosta ja näin komponentti py- syy siistinä, selkeänä ja yleiskäyttöisenä.

Merkittävin muutos muokattavuuden osalta saavutettiin kuitenkin eristämällä itse datan luku muista luokista erilleen. Eristämisen lisäksi pyrittiin siihen, että datan luvusta huo- lehtiva luokka noudattaisi komponenttiarkkitehtuuria. Kirjastodatan hyvin paljon vaihtele- va muoto hankaloittaa eniten olemassa olevien kirjastojen yhteinäistämistä, siksi datan luvusta huolehtivasta luokasta pyrittiin tekemään mahdollisimman itsenäisiä ja helposti vaihdettavia. Nämä vaatimukset saatiin täytettyä hyvin komponenttiarkkitehtuurin avulla.

Näkyvin muutos tällä hetkellä on komponenttien lisäämiseksi tehty käyttöliittymä, joka on esitetty kuvassa 7.4. Uudessa selaimessa on esitetty levyn valinta levykirjastoista. Va- semmalla on listattu kaikki aktiiviset levykirjastot ja oikealla valitun levykirjaston levyt. En-

Kuva 7.4.BD:n uusi selain komponentin valinnalle

nen eri kirjastotyypin valinnoille tehtiin valintakohtaisesti erikseen tietokantalistoja, alasve- tovalikoita ja valintadialogeja. Ylläpidon helpottamiseksi uuden rajapinnan avulla voidaan karsia pois erilaisia tapoja tehdä valintoja. Uusi selain soveltuu korvaamaan kaikki vanhat tavat valita kirjastokomponentteja ja se on helposti toteutettavissa kaikille kirjastotyypeille.

Kuitenkin jossain tilanteissa vanha tapa voi olla nopeampi ja kätevämpi, mutta ero ei ole merkittävä. Sen sijaan monen eri valintatavan korvaamisella yhdellä yleisellä selaimella saadaan keskitettyä ylläpito- ja kehitystyötä yhteen kohteeseen, mikä lisää huomattavasti tuotekehityksen tehokkuutta.

Vielä suurempi hyöty tullaan saavuttamaan, kun kirjastojen muokkaamiselle saadaan val- miiksi uusi kaikille kirjastoille yhteinen käyttöliittymä. Sen avulla kyetään aiempaa tehok- kaammin ohjaamaan ja auttamaan käyttäjää kirjaston muokkaamisessa. Tällä hetkellä kaikille kirjastoille ei ole muokkausta varten käyttöliittymää, sillä kirjastoja on totuttu muok- kaamaan tiedostojärjestelmän kautta tai suoraan muuttamalla tietokannan arvoja. Tämä johtaa nykytilanteeseen, jossa kirjastoja kopioidaan tarpeettomasti ja muokataan vapaas- ti. Vapaasti muokattaessa ne saadaan helposti virheellisillä tai yhteensopimattomilla ar- voilla tilaan, jossa kirjastoa ei voi käyttää.