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 arkeoloAnalo-gian 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 arkkitehtuurisisListatuis-ta 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 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ötetietie-don 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 kannatmut-tavin mut-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 suorimainit-tuskyky, joka voi heiketä kerrosten takia. Suorimainit-tuskyvyn ohella kerrosarkkitehmainit-tuuri 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 erilaismon-ta, ja ne vasmon-taavat hyvin erilaisiin mon-tarpeisiin. HD-, ED- ja InD-ohjelmat on mon- 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 huolimatEroavaisuuksis-ta Eroavaisuuksis-tahto uudisEroavaisuuksis-taa 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 mitlaajen-taan, 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 puhuttaesjatkos-sa 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 silreagoin-ti 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 abstrakKomponent-ti 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ä
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ä