Verkkosovellusten uudistaminen

Koko: px
Aloita esitys sivulta:

Download "Verkkosovellusten uudistaminen"

Transkriptio

1 Minna Hillebrand Verkkosovellusten uudistaminen Tietotekniikan pro gradu -tutkielma 11. joulukuuta 2003 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä

2 Tekijä: Minna Hillebrand Yhteystiedot: Työn nimi: Verkkosovellusten uudistaminen Title in English: Webware Reengineering Työ: Tietotekniikan pro gradu -tutkielma Sivumäärä: 92 Tiivistelmä: Tietokonesovellusten on kehityttävä jotta ne pysyisivät käyttökelpoisina. Lähdekoodiin tehdyt muokkaukset kuitenkin rapauttavat sovelluksen rakennetta hankaloittaen uusien muutosten tekemistä. Uudistaminen on keino rapautuneen rakenteen eheyttämiseksi. Joitain yleisiä metodeja ja työkaluja on kehitetty perinteisten ohjelmien uudistamisprosessin tueksi. Yhä suurempi osa nykypäivän sovelluksista on kuitenkin integroitu tietoverkkoon. Perinteiset uudistamisen keinot eivät yleensä riitä verkkosovelluksille, jotka luonnostaan kehittyvät nopeasti ja jatkuvasti. Tässä työssä kartoitetaan perinteisten sovellusten uudistamismallien ja erityisesti uudelleenrakentamisen menetelmien soveltamismahdollisuuksia dynaamisissa verkkosovelluksissa. Sovelluskohteeksi on valittu osia Jyväskylän yliopistossa käytetystä WWW-pohjaisesta opintotietojärjestelmästä. English abstract: All computer programs must evolve in order to stay vital. However, when the source code of the system is modified, the changes eventually corrupt the designed structure of the software. As the structure declines, further changes become even more difficult. These corruptions can be straightened by reengineering the software. Some methods and tools exist to help the reengineering process of legacy systems. The problem is that most new programs are implemented on web and these webwares differ from legacy systems in many ways. In this thesis some of the basic reengineering methods of the legacy systems are adapted to support the maintenance of a web-based course management system used in the University of Jyväskylä. Avainsanat: uudistaminen, uudelleenrakentaminen, verkkosovellus, JSP, Java Keywords: reengineering, refactoring, webware, JSP, Java

3 Sisältö 1 Johdanto 1 2 Termejä Uudistamiseen liittyviä termejä WWW-tekniikoihin liittyviä termejä Esimerkkisovelluksen toteutustekniikan termejä Uudistamisen merkitys Uudistamisesta käsitteenä Uudistamisen välttämättömyydestä Uudistamisen riskit Uudistamisen etuja Uudistamisen suhteesta ylläpitoon Rapautumisen ennaltaehkäisy Uudistamismenetelmiä Prosessikaavio Yht äkkinen uudistaminen Vähittäinen uudistaminen Uudistamismalleista Takaisinmallinnuksen vaihe Muokkaamisvaihe Muutosten toteutus kooditasolla Arkkitehtuurin uudistaminen Rakenteen visualisointi Konkreettisen mallin muodostaminen Mallien käyttö uudistamisessa Olioarkkitehtuuriksi muuntaminen Verkkosovellukset erityisalana Verkkosovellusten toimintaympäristö Yhtäläisyyksiä ja eroja perinteiseen ohjelmaan i

4 6.3 Tiedon ja rakenteen suhteesta Verkkosovellusten kehittämisestä Verkkosovellusten uudistaminen Uudistamismenetelmien käytöstä Näkökulmia rakenteen hahmottamiseen Ennaltaehkäisy Korppi uudistamiskohteena Soveltuvuus uudistamiskohteeksi Korpin ylläpidon muodot Kehitystyön aloittamisen ongelmia Kehitysympäristön ja -tekniikoiden ongelmia Rakenteessa havaitut ongelmakohdat Piilevien ongelmakohtien kartoittaminen Uudistamiskohteiden valinta Sivujen alustustoimien siistiminen Alustustoimien kapselointi tiedostoon Erillisen tiedoston etuja ja ongelmia Oliopohjaiseksi toiminnaksi muuntaminen Yksinkertaistaminen ja optimoinnit Parametrien välittämisen kapselointi Uudistettu rakenne Navigointipuun muokkaaminen Navigointipuun ongelmakohdat Uusi luokkajako Puun haarojen oliointi Parannusten ja menetysten vertailu Suorituskyvyn muutokset Kokemuksia uudistamisesta Kokemuksia muista projekteista Muokkaustoimien suhde perinteisiin menetelmiin Korpin uudistamisprosessissa esiintyneitä ongelmia Korpin uudistamisen vaikutuksista Seuraavat uudistamisprosessit ii

5 11 Yhteenveto Kirjallisuutta 87 iii

6 1 Johdanto Tietokoneohjelman elinkaari on perinteisesti kuvattu nelivaiheisena prosessina, jonka vaiheet ovat suunnittelu, toteutus, testaus ja käyttöönotto. Ohjelman elinkaaresta on kuitenkin tunnistettu myös viides vaihe, ylläpito, jonka osuus ohjelman elinajasta on usein kaikkein suurin. Ylläpidon tehtävänä ei ole pelkästään korjata ohjelmasta löytyneitä virheitä, sillä usein vasta käyttöönoton jälkeen huomataan, että ohjelmaan halutaankin lisää toiminnallisia ominaisuuksia. Ohjelman toimintaa tai sen käyttämiä algoritmeja voidaan joutua optimoimaan. Myös ohjelmassa käytetty tietorakenne voidaan havaita puutteelliseksi. Useimpia ohjelmia voidaan ylläpitää jonkin aikaa niiden valmistumisen jälkeen. Hyvin suunniteltu ohjelma voi kestää laajojakin muokkauksia pysyen luettavana, muokattavana ja alkuperäisen arkkitehtuurinsa mukaisena. Ohjelman sisäinen rakenne kuitenkin kärsii muutoksista ja lähdekoodin toistuvat muokkaukset alkavat rapauttaa ohjelman rakennetta. Ennen pitkää päädytään tilanteeseen, jolloin valtaosa ylläpitoon käytettävästä ajasta kuluu ohjelman rakenteen tutkimiseen: mille koodiriveille muutokset tulisi tehdä ja minne muutokset vaikuttavat. Rapautumista voidaan kuitenkin ehkäistä, ja jo rapautuneen ohjelman rakennetta voidaan parantaa olemassa olevaa sovellusta muokkaamalla. Prosessilla on useita nimiä, muun muassa uudelleenkonstruointi, uudistaminen ja uudelleenmuokkaus (reengineering). Tässä työssä prosessille käytetään pääasiassa termiä uudistaminen. Ohjelman uudistamisella pyritään siihen, että jatkossa ohjelman kanssa olisi helpompi työskennellä. Uudistamista on tutkittu aktiivisesti lähes 20 vuoden ajan ja uudistamisprosessin tueksi on kehitetty joitakin toimintamalleja ja työkaluja. Kuluneena aikana sovellusten luonne on kuitenkin muuttunut. Aikaisemmin sovellukset suunniteltiin yhden käyttäjän käyttöön, pääasiassa yhdessä työasemassa ajettaviksi. Sovelluksen ylläpito koostui lähinnä toiminnan täydellistämisestä johtuvista muutosvaatimuksista. Nykyään valtaosa järjestelmistä on jollain tasolla yhdessä toimivia tuotteita, jotka kommunikoivat keskenään tietoverkon välityksellä. Monet sovellukset sijaitsevat fyysisesti käyttäjän työaseman ulkopuolella, jolloin käyttäjän työasema esittää vain sovelluksen käyttöliittymän. Koska tietoverkossa sijaitsevien ohjelmien osuus kasvaa jatkuvasti, tämän työn tarkoituksena on keskittyä uudistamiseen verkkosovellusten näkökulmasta. Työssä kartoitetaan verkkosovellusten eroja perinteiseen ohjelmaan nähden sekä pohdi- 1

7 taan, millä tavoin sovellettuna perinteisten ohjelmien uudistamisprosesseja voidaan hyödyntää verkkosovellusten uudistamiseen. Aiheesta ei ole juurikaan tutkimustuloksia, sillä useimmat tutkimukset ovat keskittyneet staattisten WWW-sivustojen uudistamiseen ja niiden käänteistekniikoihin. Tässä työssä näytetään esimerkkisovellusta uudistamalla, kuinka perinteisiä menetelmiä voidaan soveltaa dynaamisten verkkosovellusten uudistamiseen ja millaisia sovellusalan ongelmia tällöin kohdataan. Työn seuraaminen edellyttää olio-ohjelmoinnin perustietojen hallintaa. WWWtekniikoiden tunteminen helpottaa huomattavasti työn loppuosan ymmärtämistä. Lukuun 2 on koottu tässä työssä käytettyjä uudistamiseen ja WWW-ohjelmointiin liittyviä termejä. Luvussa 3 esitetään tarkemmin uudistamista käsitteenä sekä perustellaan uudistamisen merkitys oleellisena osana ohjelmiston kehittymistä. Luvussa 4 esitetään perinteisille ohjelmille kehitettyjä uudistamismenetelmiä ja -malleja. Näihin läheisesti liittyvän ohjelman rakenteen kartoittamis- ja uudistamismenetelmiä kuvataan luvussa 5. Verkko- ja perinteisen sovelluksen eroja vertaillaan luvussa 6. Samassa luvussa esitetään myös yleisiä keinoja dynaamisen verkkosovelluksen uudistamisprosessin käynnistämiseen ja sovelluksen rakenteen hahmottamiseen. Luvussa 7 esitellään esimerkkinä käytetty WWW-pohjainen Korppi-sovellus, kartoitetaan sen kehittämisen ongelmia ja etsitään potentiaalisia uudistamiskohteita. Tämän jälkeen Korppi-sovelluksen osille tehdään kaksi uudistusta: luvussa 8 kapseloidaan sovelluksen osiin liittyviä alustustoimia selittäen melko tarkasti sovelluksessa käytetyn toteutustekniikan periaatteita, ja luvussa 9 kuvataan, kuinka navigointipuun rakenne muunnetaan aidosti oliomaiseksi uusia luokkia lisäämällä. Luvussa 10 pohditaan uudistamisen onnistumista erityisesti Korppi-sovelluksessa ja ehdotetaan muokkauskohteita seuraaviin uudistamisprosesseihin. Luvussa 11 esitetään yhteenveto työn tuloksista. 2

8 2 Termejä Tässä työssä on mahdollisuuksien mukaan pyritty käyttämään suomenkielisiä vastineita englanninkielisille termeille uudistamisen, yleisten WWW-tekniikoiden ja työssä esitellyn Korppi-sovelluksen alueilta. Uudistamiseen liittyvissä termeissä on noudatettu alan ainoan suomentajan, Harsun [12, 13] valitsemaa linjaa. Kaikille termeille ei kuitenkaan ole vakiintuneita suomennoksia. Esimerkiksi ohjelmien suunnittelumalleille [11] on esitetty suomennoksia, mutta ne eivät ole saavuttaneet kovin vakiintunutta asemaa. Tästä syystä useimmille menetelmille ja malleille käytetään tässäkin työssä niiden englanninkielistä alkuperäisnimeä. 2.1 Uudistamiseen liittyviä termejä Ohjelman uudistaminen (renovation, myös modernization) on laaja käsite, joka kattaa ohjelman rakenteen tulkitsemisen, ohjelman nykytilaa kuvaavan dokumentaation tuottamisen, ohjelman rakenteen ja luettavuuden parantamiseksi tehdyt suunnitelmat ja lopulta myös itse lähdekoodin muokkaamisen suunnitelmia vastaavaksi. Tässä työssä termiä uudistaminen käytetään vain prosessista, joka käsittää kaikki edellä mainitut työvaiheet. Erityisen tärkeää on, että uudistamisessa muokataan ohjelmaa siten, että lopputuloksena ohjelmalla on parempi rakenne kuin lähtötilanteessa. Uudistaminen voidaan jakaa karkeasti kolmeen vaiheeseen. Ensimmäisenä vaiheena on abstraktioiden tuottaminen nykyisen lähdekoodin pohjalta. Tämä tehdään takaisinmallinnuksen eli käänteistekniikoiden (reverse engineering) avulla. Vaiheen suorittamista tukevilla työkaluilla voidaan tuottaa sovelluksesta esimerkiksi UML:n mukaisia luokka- tai sekvenssi-kaavioita. UML (Unified Modeling Language) on pääasiassa oliopohjaisten järjestelmien rakenteen kuvaamiseen käytetty graafinen notaatio. Luokkakaaviot mallintavat, kuinka tieto on tallennettuna sovelluksessa ja millä tavoin tieto ja toiminta on liitetty toisiinsa. Sekvenssikaaviot puolestaan esittävät ohjelman vuorovaikutuksen (kontrollin) etenemisen sovelluksessa eri olioiden välillä. Käänteistekniikkatyökaluilla ei koskaan muuteta ohjelman tilaa, eikä niillä myöskään lisätä uusia toimintoja ohjelmaan. Suurin hyöty työkaluista saadaan, kun niitä sovelletaan sellaiseen ohjelmaan, jonka rakenteesta ei ole kunnollista mieliku- 3

9 vaa, eikä järjestelmän alkuperäisiä kehittäjiä tai ylläpitäjiä ole käytettävissä. Uudistamisen toinen vaihe on uuden rakenteen suunnittelu. Riittävän korkealla abstraktiotasolla toimittaessa voidaan tehdä suuriakin muokkauksia järjestelmän rakenteessa. Tämän työn kannalta sovelluksen uudelleenmuokkaaminen (reengineering) on uudistamisen oleellisin vaihe. Muokkausten edellytyksenä on olemassa olevan rakenteen tuntemisen lisäksi myös halutun lopputuloksen hahmottaminen. Muokkausvaiheessa voidaan ottaa huomioon myös uusien toiminnallisuuksien asettamat vaatimukset ohjelman rakenteelle. Ellei uudistamiselle ole asetettu konkreettisia tavoitteita, ei muokkausprosessiakaan voida tehdä kunnolla. Muokkausvaiheessa tuotetut suunnitelmat sovelluksen paremmasta rakenteesta täytyy vielä konkretisoida lähdekooditasolle. Uudistamisen kolmannessa vaiheessa lähdekoodia muunnetaan uudelleenrakentamisen (refactoring) keinoin. Uudelleenrakentamisen tyypillisiä toimintoja ovat esimerkiksi yliluokkien lisääminen ohjelman luokkarakenteeseen tai useaan kertaan toistuvien koodilohkojen eriyttäminen omiksi aliohjelmikseen. Kyseessä ei kuitenkaan ole täysin mekaaninen vaihe, vaan se vaatii sekä sovellusalueen että ohjelmoinnin asiantuntijoiden työpanosta. Uudelleenmuokkauksen vaihetta voidaan kuvata monilla lähes samansisältöisillä termeillä: parantaminen (improvement), uusiminen (renewal), kohentaminen (refurbishing) ja uudelleenkehittämistekniikoiden (redevelopment engineering) soveltaminen. Arnoldin [2, s. 5 ja 11 16] mukaan nämä kuvaavat kuitenkin erityisesti ohjelmiston laadun parantamista. Ajanmukaistaminenkin (modernization) voi liittyä laadun parantamiseen, mutta tämän lisäksi ajanmukaistamisella voidaan viitata itse ohjelmistokehityksen parantamiseen. Pelastaminen (reclamation) ja uudelleenkäyttötekniikat (reuse engineering) viittaavat sellaisiin muokkauksiin, joilla lähdekoodista saadaan erotettua uudelleenkäytettäviä osia. Kääriminen (wrapping) on eräs tunnetuimmista menetelmistä uudelleenkäytettävien osien kapseloimiseksi sovelluksesta. Yleisemmin käärimisellä voidaan eheyttää rajapintoja myös järjestelmän sisällä tai kapseloida toiminnallisesti hankalia ohjelmanosia omiin moduuleihinsa. 2.2 WWW-tekniikoihin liittyviä termejä Perintönä kulkevilla tai perinteisillä sovelluksilla (myös perinnejärjestelmä, legacy system) viitataan usein sellaisiin sovelluksiin, jotka ovat olleet olemassa pitkään. Usein tällaiset sovellukset ovat saavuttaneet merkittävän aseman työskentelyympäristössään, eikä niitä sen vuoksi ole voitu korvata muilla sovelluksilla. Ohjelmien olemassaolon aikana monet kehittäjät ovat päässeet ylläpitämään niitä. Käytännössä kaikki tällaiset sovellukset on kehitetty yhden käyttäjän ajettavaksi omalla 4

10 työasemalla. Verkkosovellukset eroavat näistä siinä mielessä, että yleensä verkkosovellusta ei ajeta käyttäjän työasemalla vaan tietoverkon kautta erilliseltä palvelimelta. Useimmat verkkosovellukset käyttävät WWW (World Wide Web)-selainta sovelluksen käyttöliittymän esittämiseen. Yksinkertaisin esimerkki tällä tavoin toimivasta verkkosovelluksesta on staattinen WWW-sivusto. Staattisella sivustolla tarkoitetaan sitä, että palvelimelta pyydetyt sivut eivät muutu käyttäjän toimintojen mukaan, eikä sivuston sisältöä tuoteta ohjelmallisesti. Joissain teoksissa sivujen dynaamisuudella viitataan esimerkiksi kuviin, jotka ladataan sivun tietojen mukaan vasta selaimen päässä. Tässä työssä tällaisia ominaisuuksia pidetään kuitenkin staattisina. Dynaaminen sivusto tai sovellus tarkoittaa, että sen sisältö generoidaan ohjelmallisesti palvelimella, jolloin sovellukseen liittyy väistämättä jokin juonto (eli skripti)- tai ohjelmointikieli. Sovellus voidaan luoda kerralla valmiiksi kokonaisuudeksi, tai sen osia voidaan kääntää lennosta käyttäjien esittämien pyyntöjen mukaan. Tässä työssä verkkosovelluksilla tarkoitetaan poikkeuksetta dynaamisia sovelluksia. Asiakkaan esittämä sivupyyntö palautetaan usein käyttäjälle HTML (Hypertext Markup Language)-muodossa riippumatta siitä, onko taustalla staattinen vai dynaaminen sovellus. HTML-dokumentti sisältää rakenteisessa muodossa käyttäjälle esitettävän tiedon. Dokumentin rakenne määritellään DTD (Document Type Definition)- kielen avulla. DTD:n avulla selain osaa esittää HTML-dokumentin käyttäjälle. Mikäli dokumentin rakenne vastaa sitä DTD:tä joka dokumentille on määritelty, sivun sanotaan olevan virheetön (valid). Virheettömälle dokumentille on olemassa tarkkaan määritelty esitystapa, vaikkakin useimmat selaimet ovat ottaneet vapauksia myös virheettömien dokumenttien esittämisessä. HTML on vain yksi esimerkki rakenteisesta dokumentista. Yleisemmin XML (Extensible Markup Language)-formaatti sisältää sekä dokumentissa käytetyn DTD:n kuvauksen että varsinaisen tiedon. HTML-muotoisen esityksen suurin puute on siinä, että se ei tarjoa käyttäjälle juurikaan mahdollisuuksia vuorovaikutukseen sivun kanssa. Parhaimmillaan staattiset sivustot voivat tarjota linkkejä toisille sivuille, jolloin käyttäjä pystyy siirtymään hallitusti sivuston eri osien välillä. Todelliseen vuorovaikutukseen päästään vasta syöttökenttien ja painikkeiden kautta, mutta nämä vaativat sivustolta dynaamisia ominaisuuksia. Näiden kahden ääripään väliin on kehitetty DHTML (Dynamic HTML) -tekniikka, joka mahdollistaa selaimella suoritettavia dynaamisia toimintoja. Tunnetuimmat esimerkit DHTML-tekniikasta lienevät JavaScript-kielellä toteutetut funktiot ja elementit, joilla saadaan aikaiseksi esimerkiksi syötteen oikeellisuuden tarkastuksia asiakaspäähän. DHTML ei kuitenkaan riitä yksinään kovin laajojen sovellusten tekemiseen. 5

11 Dynaamisten sovellusten peruskäsitteistöön liittyy tieto siitä, kuka sovellusta käyttää. Palvelin tarjoaa tätä varten istunnon (session) eli käytännössä muistitilan asiakkaan käyttöön. Asiakaspäässä istuntoa vastaa usein eväste (cookie). Näiden yhteistietona voidaan toteutusteknisesti tunnistaa palvelimella yksittäinen käyttäjä satojen samanaikaisten sivupyyntöjen joukosta. Koko ohjelman tilaa ylläpidetään sovellusavaruudessa (application), joka tarjoaa kaikille istunnoille yhteisiä elementtejä. Käyttämättömät istunnot vanhentuvat palvelimella määrätyn ajan kuluttua käyttäjän viimeksi suorittamasta toiminnosta, oletuksena noin puolen tunnin kuluttua. Sovellusavaruuden tiedot säilyvät puolestaan sovellukseen kohdistuneesta ensimmäisestä pyynnöstä (request) siihen saakka, kunnes palvelimella oleva ohjelma sammutetaan. 2.3 Esimerkkisovelluksen toteutustekniikan termejä Esimerkkinä käytetty WWW-pohjainen Korppi-järjestelmä on dynaaminen verkkosovellus, joka palauttaa käyttäjälle HTML-muotoisia dokumentteja. Järjestelmä rakentuu yksittäisistä JSP (Java Server Pages)-sivuista, jotka muodostuvat Java-koodista ja käyttöliittymän esittämiseksi tarkoitetusta HTML-koodista. JSP-sivun tarkoituksena onkin sekä esittää tietoa käyttäjälle että tehdä tarvittavat operaatiot annetun tiedon tallentamiseksi. Tiedon tallentamiseen käytetään PostgreSQL-tietokantaa. Tietokantaa ohjataan SQL (Structured Query Language)-kyselyillä, joilla voidaan sekä hakea, tallentaa että muokata tietoa. Korppi-järjestelmä toimii yhdellä palvelimella, jonka sivupyynnöt ohjautuvat Tomcat-palvelulle. Tomcat vastaa yksittäisiin sivupyyntöihin luomalla tarvittaessa pyydetystä JSP-sivusta käännetyn palvelinsovelman (servlet), joka koostuu pelkästään Java-koodista. Palvelinsovelmat suorittavat tarvittavat tietokantahaut ja - muokkaukset SQL-kyselyillä, ja muokkaavat tulokset asiakkaalle palautettavaksi HTML-koodiksi. 6

12 3 Uudistamisen merkitys Jokaisen ohjelmistotuotantoprosessin tuloksena pyritään valmistamaan asiakkaalle luovutettava valmis ohjelma. Tällöin ohjelmaan suunniteltu (as-designed) ja toteutettu (as-built) rakenne ovat melko lähellä toisiaan. Yleisesti sovelluksen määrittelyn, rakenteen ja lähdekoodin tuntevat tällöin ohjelman toteutuksesta vastanneet asiantuntijat siis melko suuri joukko kehittäjiä. Kuva 3.1 esittää, kuinka ohjelman rakenteen tuntevien asiantuntijoiden joukko pienenee, kun sovellukseen tehdään muutoksia. Kuvassa vaaleat alueet esittävät sovelluksen alkuperäisen rakenteen tai lähdekoodin mukaista osuutta ohjelman kulloisessakin tilanteessa. Mustat alueet ilmaisevat muutoksia ja rapautumia alkuperäiseen rakenteeseen. Muutosten myötä rapautuneen osan osuus kasvaa ohjelman rakenteessa ja lähdekoodissa. Rapautuminen ei välttämättä etene tasaisesti rakenteessa, vaan saattaa kasvaa joissain muutoksissa huomattavastikin. Yleensä rapautuminen koskee koko sovellusta eikä keskity pelkästään tiettyihin ohjelmanosiin. Lukuisten muutosten jälkeen ohjelman rakenteen tuntee vain hyvin pieni joukko ylläpitäjiä. muutos 1 muutos 2...muutos n asiantuntijat rakenne lähdekoodi Kuva 3.1: Ohjelman rakenteen tuntevien asiantuntijoiden joukko pienenee ja ohjelman rakenne rapautuu, kun ohjelmaan tehdään muutoksia [2]. Sovelluksen rakenteen rapautuminen voi olla huonon suunnittelun tai toistuvien muutosten seurausta. Uudistamisprosessi aloitetaan silloin, kun ohjelman rakenne havaitaan rapautuneeksi. Prosessin tarkoituksena on helpottaa ohjelman tulevaa ylläpitoa antamalla kehittäjille abstraktin tason mielikuva ohjelman sisäisestä rakenteesta ja muokkaamalla ohjelmaa myös kooditasolla rakenteellisesti järkevämmäksi kokonaisuudeksi. 7

13 Tässä luvussa selitetään, mitä uudistaminen sisältää käsitteenä ja perustellaan uudistamisen välttämöttämyys sovelluksen rakennetta parantavana toimintona. Prosessiin liittyy kuitenkin sekä riskejä että etuja. Nämä täytyy tunnistaa ja niiden valossa tulee arvioida millä ylläpidon muodolla sovelluksen kehitystä kannattaa jatkaa. Lopuksi esitetään arvioita siitä, kuinka sovelluksen rapautumista voidaan ennaltaehkäistä ja tällä tavoin välttää sovelluksen joutumista uudistamisen kohteeksi. 3.1 Uudistamisesta käsitteenä Ohjelman uudistamiselle on olemassa useita määritelmiä. Uudistaminen voidaan määrittää ohjelman rakenteen parantamiseksi joko sen toiminnallisia ominaisuuksia tai tiedon esitystapaa muokkaamalla. Nämä vaihtoehtoiset määritelmät ovatkin Arnoldin [2, s. 3 5] mukaan uudistamisen toteutuslähtökohtia. Hän painottaakin, että uudistamisprosessi kokonaisuutena voi käsittää molempia tekniikoita, sillä niiden rinnakkaisella käyttämisellä saadaan huomattavasti laajempia muokkausmahdollisuuksia. Vaihtoehtoisissa määritelmissä pitäytymisellä on kuitenkin oma etunsa: silloin voidaan helpommin säilyttää ohjelman sisältämät rajapinnat entisellään. Yleisemmin Arnold esittää uudistamisen prosessina, jonka tarkoitus on parantaa sovelluksen ymmärtämistä. Tällä määrittelyllä myös pelkkä dokumentaation generoiminen sovelluksen nykyisestä tilasta on eräs uudistamismuoto. Määrittely mahdollistaa myös ohjelman ylläpidettävyyden, uudelleenkäytettävyyden tai kehitettävyyden parantamisen suunnittelun osaksi uudistamista. Nämä prosessit eivät kuitenkaan muuta olemassa olevan ohjelman rakennetta. Todelliseen muutokseen ja jatkokehityksen turvaamiseen voidaan päästä vain ohjelmaa konkreettisesti muokkaamalla. Tästä syystä uudistamisella tarkoitetaan tässä työssä vain ohjelman muokkaamiseen johtavaa toimintaa. Uudistamisessa on kolme erillistä vaihetta: olemassa olevan koodin esittäminen abstraktimmassa muodossa käänteistekniikoiden (reverse engineering) avulla, rakenteen ja koodin uudelleenmuokkaus (reengineering) sekä muokkausten toteuttaminen. Käänteistekniikat eli takaisinmallinnus on itsenäinen keino tuottaa dokumentaatiota sovelluksen todellisesta tilasta ja saada tarvittava tietämys uudelleenmuokkauksen pohjaksi. Mikäli ohjelman alkuperäisiä kehittäjiä tai ylläpitäjiä on käytettävissä, voidaan vastaava tieto saada myös heiltä. Uudelleenmuokkauksen vaiheessa tehdään varsinainen työ eli sovelluksen abstraktion avulla hahmotellaan sovellukselle uusi rakenne. Prosessin loppuunsaattamiseksi täytyy suunnitellut muutokset myös toteuttaa järjestelmään. Demeyer et al. [5] ovat esittäneet uudistamisprosessin tueksi malleja, jotka kattavat sekä takaisinmallinnuksen että muokkaamisen vaiheet 8

14 abstraktilla tasolla kuvattuna. Uudistamisen malleja ja työn etenemistä on lyhyesti lueteltu luvuissa Fowler [8] on esittänyt huomattavasti konkreettisempia malleja uudelleenrakentamisen tueksi kooditasolta lähtien. 3.2 Uudistamisen välttämättömyydestä Lehmanin lait [19] esittävät huomioita sovelluksen kehittymisestä käyttöönoton jälkeen. Lehmanin kolme ensimmäistä lakia on esitetty jo vuonna Luetteloa on täydennetty vuosina 1978 ja 1995 käsittämään kahdeksan kohtaa. Tässä yhteydessä esitellään niistä uudistamisen merkityksen kannalta oleellisimmat; siten kolmas ja kahdeksas laki puuttuvat luettelosta. I Jatkuva muutos (Continuing Change), 1974 II Monimutkaistuminen (Increasing Complexity), 1974 IV Säännönmukaisuus (Conservation of Organisational Stability), 1978 V Muutosmäärän vakiintuminen (Conservation of Familiarity), 1978 VI Jatkuva kehitys (Continuing Growth), 1978 VII Laadun heikkeneminen (Declining Quality), 1994 Lehmanin ensimmäinen laki väittää, että toteutettuja tietokonesovelluksia täytyy jatkuvasti muuttaa. Muutoin sovellukset eivät enää vastaa niille asetettuihin odotuksiin ja ne jäävät pois käytöstä. Kuudes laki täydentää ensimmäistä lakia esittämällä, että sovellukseen täytyy tuoda koko ohjelman elinkaaren ajan uusia toiminnallisia ominaisuuksia, jotta käyttäjät pysyisivät tyytyväisinä. Yhdessä nämä lait väittävät, ettei ole tarkoituksenmukaista yrittää suunnitella sovellusta ja sen kaikkia mahdollisia käyttötarpeita yhdellä kerralla, sillä muutoksia joudutaan väistämättä tekemään. Toinen laki huomauttaa, että kun järjestelmään tehdään muutoksia, sen rakenne monimutkaistuu. Monimutkaistuminen voidaan estää vain panostamalla erikseen sovelluksen rakenteen yksinkertaistamiseen. Seitsemäs laki täsmentää, että ellei tätä panostusta tehdä säännöllisesti, koko järjestelmän laatu heikkenee. Uudistaminen on osa rakennetta yksinkertaistavaa toimintaa ja pyrkii siten nostamaan järjestelmän laatua. Lehmanin neljäs ja viides laki esittävät, että järjestelmän kehitysvauhti pysyy samana, esimerkiksi järjestelmässä tehdyt muutokset pysyvät vakiokokoisina tai pienenevät. Tämä selittyy sillä, että muutosten tekeminen suurissa järjestelmissä on aina hyvin riskialtista: toiminnan muuttaminen voi kumuloida niin paljon virheitä, 9

15 ettei niiden korjaaminen olisi mahdollista normaalissa kehitysvauhdissa. Tämän vuoksi järjestelmiin ei voida tehdä kovin isoja muutoksia. Lehmanin lait on koottu kuluneiden vuosikymmenten aikana sovellusten ylläpidosta saadun kokemuksen nojalla. Ne vaikuttavat pitävän paikkaansa: ainakin ne kuvaavat hyvin luvussa 7 esitettävän Korppi-järjestelmän kehitystä. Lehmanin lait auttavat myös ymmärtämään, miksi perinteisten ohjelmien ylläpito on niin vaikeaa. Koska sovellukset on koettu tärkeiksi, niitä on kehitetty käytettävissä olevien resurssien puitteissa. Kehitystyössä on kuitenkin usein ollut mukana lukuisia ohjelmoijia. Siten yhtenäistä ohjelmointityyliä on ollut vaikea säilyttää. Vanhoissa järjestelmissä käytettyjä ohjelmointikieliä ja -työkalujakaan ei välttämättä ole enää saatavilla, jolloin sovellus on pakko kääntää toiselle kielelle, jos siihen halutaan tehdä täydennyksiä. Pitkään kehitettyjen järjestelmien dokumentit eivät pysy ajan tasalla. Tämä tekee sovelluksen rakenteen hahmottamisen vaikeaksi uusille kehittäjille. Toisaalta tehtyjen muutosten myötä sovelluksen rakenne voi olla hyvinkin kirjava erilaisista ohjelmointityyleistä johtuen. Koodin optimointi puolestaan vaikeuttaa sekä lähdekoodin luettavuutta että ylläpidettävyyttä. Suurissa järjestelmissä esiintyy usein myös tietorakenteiden ja toiminnan päällekkäisyyttä. 3.3 Uudistamisen riskit Kuten kaikkiin sovellusten tuotantoprosesseihin, myös sovellusten uudistamiseen liittyy riskejä. Arnold [2, s. 15] on koonnut riskeistä luettelon, josta esitellään muutamia. Suurin osa riskeistä liittyy resurssienhallintaan, sillä ohjelmistotuotannossa ja erityisesti ohjelmien ylläpidossa resurssit ovat rajallisia. Valitettavan usein raha ratkaisee. Uudistamisprosessin alkuvaiheen eli takaisinmallinnuksen tukemiseen on kehitetty työkaluja, mutta itse muokkausvaiheeseen ei: sovelluksen ongelmakohtia tunnistavia automaatteja on tosin yritetty kehittää, mutta niiden toimintaan liittyy vielä liikaa ratkaisemattomia kysymyksiä. Muokkausten soveltamiseen on kuitenkin olemassa uudelleenrakentamistyökaluja. Jos uudistustyö joudutaan tekemään sovelluskohteessa kokonaan käsin, voi työ tulla todella kalliiksi. Käsin muokattaessa myös virheiden todennäköisyys lisääntyy. Päteviä uudistamisen asiantuntijoita voikin olla vaikeaa löytää. Uusien ohjelmien kehittäminen on huomattavasti trendikkäämpää kuin vanhojen ohjelmien uudistaminen. Lisäksi uudistaminen ei tuota juurikaan näkyviä tuloksia, vaan vain parantaa entisen ohjelmiston rakennetta vaikuttamatta suoranaisesti edes sovelluksen suorituskykyyn tai muihin käyttäjälle näkyviin osa-alueisiin. 10

16 Näistä syistä projektin johtoa voi olla vaikea saada sitoutumaan uudistamisprosessiin. Mikäli prosessin tukeminen lopetetaan kesken, voi uudistaminen jäädä vain sovelluksesta tuotettujen dokumenttien tasolle, mutta konkreettiset tulokset jäävät puuttumaan, mikä voi vähentää halukkuutta käyttää uudistamista muissa kohteissa. Uudistamiseen ryhdyttäessä pitäisi olla selkeä näkemys siitä, mihin uudistamisella pyritään kyseisessä sovelluksessa. Mikäli työn tekijöillä ei ole riittävän laajaa perspektiiviä, voivat tuloksetkin olla heikkoja. Rahgozar ja Oroumchian [21] ovat havainneet, että uudistamisessa pyritään liian usein pikaisiin tuloksiin esimerkiksi käärimällä vanhoja ohjelmanosia uusien rajapintojen taakse. Tämä ei kuitenkaan poista ohjelman rakenteellisia ongelmia. Väärillä uudistamistoimilla saatetaan jopa hankaloittaa sovelluksen kehittämistä. Lisäksi Harsu [12] varoittaa, että uudistamiseen varataan usein aivan liian vähän aikaa. Uudistamisprosessille voidaan asettaa liikaa vaatimuksia, ja uutta toiminnallisuutta yritetään lisätä ilman selkeitä välitavoitteita. Tekninen uudistaminen käsittää sovelluksen rakenteen selkeyttämisen. Toiminnallinen uudistaminen puolestaan liittyy sovellukseen liitettäviin uusiin ominaisuuksiin. Sneed [22] varoittaa, ettei uudistamisessa tule sekoittaa näitä kahta uudistamisen osa-aluetta. Yleensä tekninen uudistaminen täytyy tehdä ennen toiminnallisia muutoksia, jotta toiminnallisille muutoksille saadaan riittävän vakaa perusta. Mikäli mahdollista, toiminnalliset muutokset tulisi jättää seuraavaan versioon, jotta teknisen muutoksen mahdollisesti aiheuttamat ongelmat ehditään havaita. Rahgozar et al. [21] esittävät teknisille muutoksille vielä yksityiskohtaisempia vaatimuksia, kuten että sovelluksiin liittyviin asetus- tai data-tiedostoihin ei saa tehdä muutoksia, uudelleenmuokattaessa ei saa jäljitellä vanhoja ratkaisuja tai tietomalleja eikä prosessissa saa tuottaa uutta, tarpeetonta dataa. Rahgozarin vaatimuksista kuitenkin tärkein on se, ettei uudistaminen saisi muuttaa sovelluksen toimintalogiikkaa. Tämä korostaa sitä, että uudistamisen tehtävänä ei ole tuottaa uutta toiminnallisuutta sovellukseen. Toisaalta voi olla aiheellista kysyä, ovatko uudistamiselle esitetyt riskit yhtään sen suuremmat kuin perinteisessä ohjelmistotuotantoprosessissa. Täysin riskitöntä menetelmää ei liene olemassakaan. Ylittyvä budjetti, ammattitaitoisen henkilökunnan löytäminen, projektijohdon suostuttelu ja ylittyvät aikataulut liittyvät yhtä oleellisina riskeinä myös uuden ohjelman tuotantoon. Lisäksi uuden sovelluksen tuottaminen vaatii paljon aikaa ennen kuin sovelluksesta saadaan näkyviä tuloksia. Lähdekoodin muokkaaminen sisältää kuitenkin sellaisia ongelmia, joita puhtaalta pöydältä kirjoitettaessa ei esiinny. Harsu [13] huomauttaa, että esimerkiksi olio- 11

17 ohjelmissa olioiden muokkaaminen automaattisesti on vaikeaa. Tehdyt muutokset heijastuvat moneen paikkaan. Rakenteellinen muutos lähdekoodissa, esimerkiksi tietotyypin tai muuttujan näkyvyyden muuttaminen, vaikuttaa koko ohjelmaan. Ongelma on toki tekninen mutta osoittaa, ettei uudistaminen ole missään nimessä helppo prosessi. 3.4 Uudistamisen etuja Mikäli sovelluksen uudistaminen tehdään hallitusti, ohjelman rakenne on prosessin jälkeen selkeämpi ja helpommin muokattavissa. Ennen kaikkea sovelluksen rakenne on saatu visualisoitua ja sovelluksen kehittäjäjoukko on sisäistänyt sovelluksen rakenteen. Voidaankin olettaa, että muokattu rakenne kestää jonkin aikaa tuleviakin muutoksia ja sovellus pysyy käytössä vähintään yhtä kauan kuin puhtaalta pöydältä kirjoitettu versio. Parantunut ohjelman rakenne ja rakenteen dokumentoituminen ovat uudistamisen näkyvimpiä tuloksia. Prosessista voidaan kuitenkin saada muitakin kuin suoraan tavoiteltuja hyötyjä. Arnold [2, s. 9 11] korostaa, että uudistamisen soveltamisesta saadaan arvokasta kokemusta. Saadun kokemuksen kautta voidaan myöhemmin rakentaa ohjelmia, jotka automaattisesti päättelevät uudistettavien ohjelmien ongelmakohdat. Sitä ennen pienenä parannuksena voidaan kehittää työvälineitä, jotka tukevat ongelmien paikantamisen ja korjaamisen prosessia. Uudistamisen läpikäyminen voi kohentaa myös työhön osallistuneiden ohjelmoijien ammattitaitoa. Jos heidän olisi annettu kirjoittaa sama ohjelma kokonaan uusiksi, osa sovelluksen virheistä olisi voinut huomaamatta siirtyä uuteen koodiin viimeistään toisissa projekteissa. Vanhan koodin kehittäminen pakottaa ohjelmoijat ajattelemaan ongelmia eri näkökulmista. He saavat mahdollisuuden korjata aiemmin tehdyt virheet. Tämän jälkeen he luultavasti käyttävät uudistamisprosessissa saamaansa kokemusta ja osaavat tehdä paremman vaihtoehdon mukaisen ratkaisun. Siten uudistaminen vahvistaa ohjelmoijien ammattitaitoa ja samalla koko yrityksen kilpailukykyä. 3.5 Uudistamisen suhteesta ylläpitoon Pressman [20, s ] ja Harsu [12] jakavat ohjelman ylläpidon neljään eri tyyppiin toiminnan tavoitteiden mukaan: Vaikka sovelluksista yritetään rakentaa mahdollisimman virheettömiä, jää niihin 12

18 väistämättä virheitä (bug, defect), jotka huomataan vasta myöhemmissä testaus- ja käyttövaiheissa. Korjaavalla ylläpidolla (corrective maintenance) pyritään paikkaamaan löytyneitä virheitä ja tätä kautta parantamaan ohjelman laatua. Virheen laadusta riippuen sen korjaaminen voi olla joko hyvin yksinkertaista tai melko vaikeaa; joskus virheen korjaaminen voi kumuloida lisää virheitä sovellukseen. Korjaavan ylläpidon osuus kaikesta ylläpidosta on noin viidennes. Tekniikan kehittyessä laiteympäristöjä päivitetään. Siten ohjelma joutuu toimimaan erilaisessa ympäristössä kuin jossa sitä on kehitettiin ja testattiin. Laiteympäristön muuttamisen yhteydessä voidaan tarvita ohjelman mukauttavaa ylläpitoa (adaptive maintenance) Esimerkiksi ohjelmasta suoritettujen käyttöjärjestelmäkutsujen rajapinta saattaa muuttua, mikäli laitteiston käyttöjärjestelmää muutetaan. Tällä hetkellä noin neljännes ylläpidon ajasta kuluu ympäristön muutoksen aiheuttamien ongelmien ratkaisemiseen. Sovelluksen rakenteen uudistaminen etukäteen voisi helpottaa mukauttamisen onnistumista. Kun käyttäjät esittävät ohjelmalle uusia toiminnallisia vaatimuksia, niiden toteuttamiseen tarvitaan täydellistävää ylläpitoa (perfective maintenance). Tämä ylläpidon muoto esiintyy luvussa 3.2 esitettyjen Lehmanin lakien ensimmäisenä ja kuudentena kohtana ja on näiden perusteella välttämätöntä ohjelmien selviämistaistelussa. Tehtyjen tutkimusten perusteella täydellistävä ylläpito viekin puolet [20, s ] kaikesta ylläpitoon käytetystä ajasta. Tämän ylläpidon muodon suurin ongelma on siinä, että se muuttaa ohjelman toimintaa. Toiminnalliset muutokset edellyttävät usein myös rakenteellisia muutoksia, jotka puolestaan lisäävät virheiden syntymahdollisuutta. Uudistaminen on ehkäisevää ylläpitoa (preventive maintenance). Sen tarkoituksena on helpottaa tulevia ylläpitotehtäviä. Ehkäisevään ylläpitoon käytetään kuitenkin vain kymmenes kaikesta ylläpidon ajasta. Tämä vaikuttaa olevan aivan liian vähän. Jos alkuoletuksena ohjelmalla on ollut suhteellisen hyvä rakenne mutta ylläpidon seurauksena sen rakenne on rapautunut, täytyy kolmen ensimmäisen ylläpidon muodon heikentää sovelluksen rakennetta nopeammin kuin ehkäisevällä ylläpidolla pystytään paikkaamaan. Toisaalta järjestelmän rakenteen rapautuminen saatetaan hyväksyä, sillä sovellukselle hahmotetaan vain rajallinen elinkaari. Tämän vuoksi rakenteen parantamiseen ei haluta haskata niitä resursseja, jotka on varattu laadun ja toiminnan kehittämiseen. Lopulta näin lyhytnäköinen ajattelutapa voi kostautua sovelluksen kehittämisessä: liian monimutkaista järjestelmää ei voida enää ylläpitää käytettävissä olevilla resurseilla. Ohjelman ylläpidettävyydellä tarkoitetaan sitä helppoutta, jolla halutut muutok- 13

19 muutettavuus ylläpidä hylkää jatkokehitä uudista liiketaloudellinen arvo Kuva 3.2: Ohjelman ylläpito- ja uudistamispäätöksiin vaikuttavat sovelluksen muutettavuus ja sen liiketaloudellinen arvo [15]. set voidaan tehdä korjaavassa, mukauttavassa tai täydellistävässä ylläpidon tyypissä. Ehkäisevä ylläpito on keino parantaa ylläpidettävyyttä. Aina siihen ei kuitenkaan kannata uhrata resursseja. Jacobson ja Lindström [15] ovat arvioineet kuvan 3.2 mukaisesti, kuinka sovelluksen muutettavuus ja liiketaloudellinen arvo vaikuttavat ylläpitoratkaisuihin. Jos ohjelma on helposti muutettavissa, sitä kannattaa ylläpitää täydellistävän ylläpidon keinoin. Jos ohjelman muuttaminen on vaikeaa mutta sovelluksen liiketaloudellinen arvo on kuitenkin suuri, sovellus kannattaa uudistaa. Luvussa 7 esitetty Korppi-sovellus sijoittuu erinomaisesti tähän matriisiin. Joiltain osin sen rakenne on hieman heikko, mutta järjestelmä kokonaisuutena on liian laajassa käytössä, jotta sen voisi hylätä ja korvata uudella. Toisaalta järjestelmään kohdistuu niin paljon kehittäviä muutostoiveita, että sitä on pakko ylläpitää. Siten järjestelmän osien uudistaminen on järkevä vaihtoehto. Sovelluksen ylläpidettävyyttä voidaan mitata myös laskemalla sovellukselle SMI (software maturity index)-arvo. Arvo määräytyy sovelluksen sisältämien moduulien sekä viimeisimmän julkaisun jälkeen lisättyjen, muutettujen ja poistettujen moduulien lukumäärän mukaan. Mitä vähemmän järjestelmässä on muuttuneita osia, sitä vakaammaksi SMI:n antama arvo luokittelee tarkasteltavan järjestelmän. Pressman [20, s. 518] ehdottaa, että ylläpitotoimia tulisi suunnitella siten, että sovelluksen SMI saadaan mahdollisimman vakaaksi. Tämä tosin voi vääristää sovelluksen luonnollista kehittymistä, jos muutosten määrää aletaan tietoisesti pienentämään. Arnold [2] huomauttaa, että ylläpidettävyyden saavuttaminen uudistamisen kautta ei vielä riitä, koska ohjelman kehitys jatkuu vielä uudistamisen jälkeenkin. Tämän vuoksi ohjelman tulee säilyttää ylläpidettävyytensä myös tulevaisuudessa. Viimeistään uudistamisen jälkeen tarvitaan käänteistekniikoita lähdekoodin visualisoimiseen esimerkiksi UML-kaavioina. Tulevat muunnokset tulisikin suunnitella tällä abstraktiolla jo ennen kuin muutokset tehdään sovelluksen lähdekoodiin, jotta 14

20 kokonaiskuva sovelluksesta säilyisi paremmin. Käänteistekniikoiden automaation ansiosta abstraktit kuvaukset on helppo pitää ajan tasalla myös muutosten jälkeen. 3.6 Rapautumisen ennaltaehkäisy Luvussa 3.2 lueteltujen Lehmanin lakien valossa uudistaminen vaikuttaa sellaiselta prosessilta, johon väistämättä ajaudutaan jossain vaiheessa pitkäikäisen ohjelman elinkaarta. Onko tämän kehityksen estämiseksi mitään keinoja? XP (Extreme Programming)-ohjelmoinnin [25] perusideana on tehdä työtä mahdollisimman pienissä paloissa. Jokainen muutos suunnitellaan etukäteen ja muutoksen on oltava niin pieni, että sen suunnittelu, toteutus ja testaus voidaan suorittaa lyhyen ajanjakson, yleensä yhden työviikon, aikana. Alkuoletuksena muutettava ohjelma on täydellisesti toimiva, ja sellainen sen tulisi olla myös jokaisen muutoksen jälkeen. Muutosvaiheessa kaksi kehittäjää koodaavat muutosta samanaikaisesti: yksi keskittyy muutoksen syntaktiseen toteutukseen ja toinen pitää huolen siitä, että toteutus tehdään oikeaan asiayhteyteen järjestelmän kannalta. Tämä auttaa säilyttämään kokonaiskuvan ohjelmasta koko muutosprosessin ajan. XP rikkoo perinteisen ohjelmoinnin rajoja myös siinä suhteessa, että se ei kannusta kehittäjiä ottamaan vastuuta sovelluksen yksittäistä moduuleista. XP-ohjelmoinnissa jokainen ohjelmoija on vastuussa koko sovelluksen toiminnasta, ja siten jokaisella kehittäjällä säilyy kokonaiskuva sovelluksen toiminnasta hyvinkin yksityiskohtaisella tasolla. Tämä vähentää riskejä myös henkilöstön vaihdoksissa, sillä kriittisten toimintojen ylläpito ei perustu vain yhden kehittäjän tietämykseen. XP:n mukainen toimintatapa voisikin olla keino ehkäistä uudistamisen tarvetta, sillä uudistamisprosessi elää pienessä mittakaavassa XP-kehitysprosessin sisällä. Tietyssä mielessä ohjelman uudistaminen on XP:tä jälkikäteen sovellettuna, sillä uudistamisen tarkoituksena on palauttaa kehittäjien tekemät muutokset siihen kontekstiin, johon ne alunperin olisi pitänyt tehdä. 15

Ohjelmistojen ylläpito. JOT 7.12.2006 Minna Hillebrand

Ohjelmistojen ylläpito. JOT 7.12.2006 Minna Hillebrand Ohjelmistojen ylläpito JOT 7.12.2006 Minna Hillebrand À la carte Sovelluksen elinkaari Mitä tapahtuu lopussa ja miksi Ylläpidon muodot Uudistaminen Onko helpompaa tapaa? Korppi Sovelluksen/projektin elinkaari

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

ohjelman arkkitehtuurista.

ohjelman arkkitehtuurista. 1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä

Lisätiedot

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

AJAX-konsepti AJAX. Asynkronisuus. Nykyisten web-ohjelmien ongelmia. Asynchronous JavaScript And XML

AJAX-konsepti AJAX. Asynkronisuus. Nykyisten web-ohjelmien ongelmia. Asynchronous JavaScript And XML AJAX-konsepti AJAX Asynchronous JavaScript And XML Viimeisin muoti-ilmiö web-ohjelmoinissa, termi Ajax tuli käyttöön vuoden 2005 aikana Joukko teknologioita, joiden avulla voidaan toteuttaa uudenlaisen

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

Testidatan generointi

Testidatan generointi Testidatan generointi Anu Ahonen Kevät 2008 Tämä työ on tehty Creative Commons -lisenssin alla Työn tarkasti 9.4.2008 Jouni Huotari (JAMK/IT) 1 SISÄLTÖ 1 TYÖN LÄHTÖKOHDAT JA TOTEUTUS...2 2 TESTIDATAN GENEROINTI

Lisätiedot

Visual Case 2. Miika Kasnio (C9767) 23.4.2008

Visual Case 2. Miika Kasnio (C9767) 23.4.2008 Visual Case 2 Miika Kasnio (C9767) 23.4.2008 Työn tarkasti: Jouni Huotari 24.4.2008 1 SISÄLTÖ 1. TYÖN LÄHTÖKOHDAT... 2 2. PERUSTIEDOT... 2 3. ASENTAMINEN... 2 4. OMINAISUUDET... 3 4.1. UML-kaaviot... 4

Lisätiedot

Tietorakenteet ja algoritmit - syksy 2015 1

Tietorakenteet ja algoritmit - syksy 2015 1 Tietorakenteet ja algoritmit - syksy 2015 1 Tietorakenteet ja algoritmit - syksy 2015 2 Tietorakenteet ja algoritmit Johdanto Ari Korhonen Tietorakenteet ja algoritmit - syksy 2015 1. JOHDANTO 1.1 Määritelmiä

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari Korhonen

Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari Korhonen Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari 1 1. JOHDANTO 1.1 Määritelmiä 1.2 Tietorakenteen ja algoritmin valinta 1.3 Algoritmit ja tiedon määrä 1.4 Tietorakenteet ja toiminnot 1.5 Esimerkki:

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

Lyseopaneeli 2.0. Käyttäjän opas

Lyseopaneeli 2.0. Käyttäjän opas Lyseopaneeli 2.0 Käyttäjän opas 1. Esittely Lyseopaneeli on Oulun Lyseon lukion käyttäjätietojen hallintapalvelu jonka tarkoitus on niputtaa yhteen muutamia oleellisia toimintoja. 2. Yleistä paneelin käytöstä

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

L models. Käyttöohje. Ryhmä Rajoitteiset

L models. Käyttöohje. Ryhmä Rajoitteiset Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Käyttöohje Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset 0.1

Lisätiedot

Asiakas ja tavoite. Tekninen toteutus

Asiakas ja tavoite. Tekninen toteutus Asiakas ja tavoite Heikieli on vuonna 2015 perustettu yhden hengen asiantuntijayritys, joka tarjoaa käännös- ja oikolukupalveluita englannista ja saksasta suomeksi. Freelance-kääntäjiä on Suomessa paljon,

Lisätiedot

Verkkopalveluiden saavutettavuus

Verkkopalveluiden saavutettavuus Verkkopalveluiden saavutettavuus Puhuja: Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Paikka: Helsinki, Tieteiden talo, 24.3.2011 Johdanto Verkkopalvelun saavutettavuus

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Software design and specification methods Kurssin henkilökunta ja sponsori Luennoitsija DI Antti Karanta, Napa Oy www.napa.fi Assistentti TkL

Lisätiedot

Opas koulujen VALO-hankintaan. Elias Aarnio Avoimet verkostot oppimiseen -hanke Educoss Innopark Oy

Opas koulujen VALO-hankintaan. Elias Aarnio Avoimet verkostot oppimiseen -hanke Educoss Innopark Oy Opas koulujen VALO-hankintaan Elias Aarnio Avoimet verkostot oppimiseen -hanke Educoss Innopark Oy Mikä ihmeen VALO? VALO = vapaat ja avoimen lähdekoodin ohjelmistot Kyse on siis Open Sourcesta eli vapaista

Lisätiedot

AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin

AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin Raimo Nikkilä Aalto-yliopiston sähkötekniikan korkeakoulu - Automaation tietotekniikan tutkimusryhmä 17. tammikuuta 2013

Lisätiedot

Pedacode Pikaopas. Java-kehitysympäristön pystyttäminen

Pedacode Pikaopas. Java-kehitysympäristön pystyttäminen Pedacode Pikaopas Java-kehitysympäristön pystyttäminen Pikaoppaan sisältö Pikaoppaassa kuvataan, miten Windowstyöasemalle asennetaan Java-ohjelmoinnissa tarvittavat työkalut, minkälaisia konfigurointeja

Lisätiedot

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,

Lisätiedot

WWW-sivut HTML-kielellä esitettyä hypertekstiaineistoa

WWW-sivut HTML-kielellä esitettyä hypertekstiaineistoa WWW ja tietokannat WWW-sivut HTML-kielellä esitettyä hypertekstiaineistoa tekstiä, kuvia, hyperlinkkejä Staattiset sivut kirjoitettu kerran, muuttaminen käsin ongelmana pysyminen ajantasalla Ylläpito hankalaa,

Lisätiedot

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

Software product lines

Software product lines Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product

Lisätiedot

Kirja on jaettu kahteen osaan: varsinaiseen- ja lisätieto-osioon. Varsinainen

Kirja on jaettu kahteen osaan: varsinaiseen- ja lisätieto-osioon. Varsinainen Alkusanat Tämän tieto- ja viestintätekniikan oppikirjan ensimmäinen versio (1. painos) syntyi vuonna 2006 Jyväskylän yliopiston tietotekniikan laitokselle tekemäni pro gradu -tutkielmani yhteydessä. Tutkimuksessani

Lisätiedot

www.solita.fi solita@solita.fi

www.solita.fi solita@solita.fi www.solita.fi solita@solita.fi JAVA-SOVELLUSTEN RAKENTAMINEN INTEGROITUUN YMPÄRISTÖÖN Jarno Peltoniemi Solita Oy 10.5.2005 Aiheet Johdanto Portaalit, portletit Oracle Portal Java-sovelluksen rakentaminen

Lisätiedot

Lomalista-sovelluksen määrittely

Lomalista-sovelluksen määrittely Thomas Gustafsson, Henrik Heikkilä Lomalista-sovelluksen määrittely Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikka Dokumentti 14.10.2013 Tiivistelmä Tekijä(t) Otsikko Sivumäärä Aika Thomas

Lisätiedot

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

Lisätiedot

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi 1. Luento: Sulautetut Järjestelmät Arto Salminen, arto.salminen@tut.fi Agenda Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu

Lisätiedot

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu KÄYTTÖOHJE. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu KÄYTTÖOHJE. LiKe Liiketoiminnan kehityksen tukiprojekti Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu JÄRJESTELMÄN KÄYTTÖOHJE LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

DXL Library ja DXL-kielen olemus. Pekka Mäkinen Pekka.Makinen@softqa.fi SoftQA Oy http/www.softqa.fi/

DXL Library ja DXL-kielen olemus. Pekka Mäkinen Pekka.Makinen@softqa.fi SoftQA Oy http/www.softqa.fi/ DXL Library ja DXL-kielen olemus Pekka Mäkinen Pekka.Makinen@softqa.fi SoftQA Oy http/www.softqa.fi/ DOORS extension Language DXL on DOORSin laajennuskieli, jolla voidaan kehittää lisätoiminnallisuutta.

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat Järjestelmäarkkitehtuuri (TK081702) SOA yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus

582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus 582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus Sisältö Mikä on web-sovellus? Selaimen rooli web-sovelluksessa Palvelimen rooli web-sovelluksessa Aineistopyynnöt Tiedon välittäminen

Lisätiedot

Tekninen suunnitelma - StatbeatMOBILE

Tekninen suunnitelma - StatbeatMOBILE Tekninen suunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 13.12.2013 Pöyry Alustava rakenne ja sisältö 1.1 22.12.2013 Pöyry Lisätty tekstiä ilmoituksiin, turvallisuuteen ja sisäiseen API:in

Lisätiedot

19/20: Ikkuna olio-ohjelmoinnin maailmaan

19/20: Ikkuna olio-ohjelmoinnin maailmaan Ohjelmointi 1 / syksy 2007 19/20: Ikkuna olio-ohjelmoinnin maailmaan Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007

Lisätiedot

Ohjelmistojen virheistä

Ohjelmistojen virheistä Ohjelmistojen virheistä Muutama sana ohjelmistojen virheistä mistä niitä syntyy? Matti Vuori, www.mattivuori.net 2013-09-02 1(8) Sisällysluettelo Ohjelmistojen virheitä: varautumattomuus ongelmiin 3 Ohjelmistojen

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

TIE-20200 Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely

TIE-20200 Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely Lyhyt UML-opas UML -pikaesittely UML, Unified Modeling Language Standardoitu, yleiskäyttöinen mallinnuskieli, jota ylläpitää/hallitsee (Object Management Group) OMG Historiaa: 90-luvulla oli paljon kilpailevia

Lisätiedot

Avoin lähdekoodi. Jani Kylmäaho Maanmittauslaitos www.oskari.org

Avoin lähdekoodi. Jani Kylmäaho Maanmittauslaitos www.oskari.org Avoin lähdekoodi Jani Kylmäaho Maanmittauslaitos www.oskari.org Avoimen lähdekoodin määritelmä (OSI) Ohjelman täytyy olla vapaasti levitettävissä ja välitettävissä. Lähdekoodin täytyy tulla ohjelman mukana

Lisätiedot

Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla

Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla Viimeksi muokattu 5. toukokuuta 2012 Maastotietokannan torrent-jakeluun sisältyy yli 5000 zip-arkistoa,

Lisätiedot

Skanska Ruskeasuo Larkas & Laine

Skanska Ruskeasuo Larkas & Laine Skanska Ruskeasuo Larkas & Laine Rakennussuunnittelu on muuttunut piirtämisestä rakennusten simuloinniksi. Pelkkä paperikopio ei enää riitä, vaan tilaaja haluaa rakennuksesta usein tietomallin, joka sisältää

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

TermBase NET versio 1.0.1. (Beta)

TermBase NET versio 1.0.1. (Beta) TermBase NET versio 1.0.1. (Beta) Sulautettu sanasto- ja termikanta OHJEET TÄRKEÄÄ: Copyright M. Tuittu, 2005 Kaikki oikeudet pidätetään. TermBase NET on toteutettu java -tekniikalla. Java and all Java-based

Lisätiedot

11.4. Context-free kielet 1 / 17

11.4. Context-free kielet 1 / 17 11.4. Context-free kielet 1 / 17 Määritelmä Tyypin 2 kielioppi (lauseyhteysvapaa, context free): jos jokainenp :n sääntö on muotoa A w, missäa V \V T jaw V. Context-free kielet ja kieliopit ovat tärkeitä

Lisätiedot

Tiedonhallinnan perusteet. Viikko 1 Jukka Lähetkangas

Tiedonhallinnan perusteet. Viikko 1 Jukka Lähetkangas Tiedonhallinnan perusteet Viikko 1 Jukka Lähetkangas Kurssilla käytävät asiat Tietokantojen toimintafilosofian ja -tekniikan perusteet Tiedonsäilönnän vaihtoehdot Tietokantojen suunnitteleminen internetiä

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit

Lisätiedot

Ylläpito-ohje. Matematiikan oppifoorumi. Carl Johansson Jukka Kariola Outi Marttila Helena Venäläinen Sampsa Virtanen. Ohjaaja.

Ylläpito-ohje. Matematiikan oppifoorumi. Carl Johansson Jukka Kariola Outi Marttila Helena Venäläinen Sampsa Virtanen. Ohjaaja. Matematiikan oppifoorumi Ylläpito-ohje Carl Johansson Jukka Kariola Outi Marttila Helena Venäläinen Sampsa Virtanen Ohjaaja Jukka Eskola Ohjelmistotuotantoprojekti 17.12.1999 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen

Lisätiedot

P e d a c o d e ohjelmointikoulutus verkossa

P e d a c o d e ohjelmointikoulutus verkossa P e d a c o d e ohjelmointikoulutus verkossa J2EE web-ohjelmointi Teoria ja ohjelmointitehtävät J2EE web-ohjelmointi 3 JOHDATUS OPISKELUUN...7 Opiskelu kurssilla... 7 Kurssin sisältö... 7 Aikataulu...

Lisätiedot

1. Olio-ohjelmointi 1.1

1. Olio-ohjelmointi 1.1 1. Olio-ohjelmointi 1.1 Sisällys Olio-ohjelmointi on eräs ohjelmointiparadigma. Olio-ohjelmoinnin muotoja. Ohjelmiston analyysi ja suunnittelu. Olioparadigman etuja ja kritiikkiä. 1.2 Ohjelmointiparadigmoja

Lisätiedot

Liikkuva työ pilotin julkinen raportti 30.06.2014

Liikkuva työ pilotin julkinen raportti 30.06.2014 Liikkuva työ pilotin julkinen raportti 30.06.2014 2 / 9 Green ICT pilotin raportti SISÄLLYSLUETTELO 1. Tiivistelmä koekäytöstä... 3 2. Toteutus... 4 2.1.Tavoite... 4 2.2.Mobiilisovellus... 4 2.3.Käyttöönotto...

Lisätiedot

KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka. Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012

KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka. Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012 KYMENLAAKSON AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma / Tietoverkkotekniikka Joni Korjala APACHE WWW-PALVELIN Seminaarityö 2012 SISÄLLYS 1 JOHDANTO 3 2 WWW-PALVELIMEN TOIMINTA 4 3 OMINAISUUDET

Lisätiedot

Heuristisen arvioinnin muistilista - lyhyt versio

Heuristisen arvioinnin muistilista - lyhyt versio Alla oleva kymmenkohtainen muistilista on sovellettu Jakob Nielsenin heuristisen arvioinnin muistilistasta (Nielsen, 1994), hyödyntäen Keith Instonen wwwpalveluiden arviointiin muokattua samaista listaa

Lisätiedot

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen Tietojärjestelmä tuotantoympäristössä Tausta ja tavoitteet Tausta Kurssilla on opiskeltu suunnittelemaan ja toteuttamaan tietokanta, joka on pieni perustuu selkeisiin vaatimuksiin on (yleensä) yhden samanaikaisen

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri Järjestelmäarkkitehtuuri (TK081702) ja Järjestelmäarkkitehtuuri Sovellukset ovat olemassa Järjestelmien uudistaminen vie yleensä arvioitua enemmän resursseja ja kestää arvioitua kauemmin Migration (Migraatio

Lisätiedot

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta.

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Malli-näkym kymä-ohjain arkkitehtuurit (Model-View View-Controller, MVC) Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Lähtökohdat: Sovelluksen

Lisätiedot

Kirja on jaettu kahteen osaan: varsinaiseen- ja lisätieto-osioon. Varsinainen

Kirja on jaettu kahteen osaan: varsinaiseen- ja lisätieto-osioon. Varsinainen Alkusanat Tämä tieto- ja viestintätekniikan oppikirja on päivitetty versio vuonna 2007 julkaisemastani Tieto- ja viestintätekniikka -oppikirjasta. Päivityksessä kirjan sisällöt on ajantasaistettu ja samalla

Lisätiedot

Esimerkkiprojekti. Mallivastauksen löydät Wroxin www-sivuilta. Kenttä Tyyppi Max.pituus Rajoitukset/Kommentit

Esimerkkiprojekti. Mallivastauksen löydät Wroxin www-sivuilta. Kenttä Tyyppi Max.pituus Rajoitukset/Kommentit Liite E - Esimerkkiprojekti E Esimerkkiprojekti Olet lukenut koko kirjan. Olet sulattanut kaiken tekstin, Nyt on aika soveltaa oppimiasi uusia asioita pienen, mutta täydellisesti muotoiltuun, projektiin.

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

Palomuurit. Palomuuri. Teoriaa. Pakettitason palomuuri. Sovellustason palomuuri

Palomuurit. Palomuuri. Teoriaa. Pakettitason palomuuri. Sovellustason palomuuri Palomuuri Teoriaa Palomuurin tehtävä on estää ei-toivottua liikennettä paikalliseen verkkoon tai verkosta. Yleensä tämä tarkoittaa, että estetään liikennettä Internetistä paikallisverkkoon tai kotikoneelle.

Lisätiedot

KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0

KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0 KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014 Käyttäjätutkimus ja käsitteellinen suunnittelu Järjestelmän nimi versio 1.0 Jakelu: Tulostettu: 201543 Samuli Hirvonen samuli.hirvonen@student.tut.fi

Lisätiedot

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt. Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.fi Avoimen tuotteenhallinta Esityksen sisältö Mitä on tuotteenhallinta?

Lisätiedot

Uutiskirjesovelluksen käyttöohje

Uutiskirjesovelluksen käyttöohje Uutiskirjesovelluksen käyttöohje Käyttäjätuki: Suomen Golfpiste Oy Esterinportti 1 00240 HELSINKI Puhelin: (09) 1566 8800 Fax: (09) 1566 8801 E-mail: gp@golfpiste.com 2 Sisällys Johdanto... 1 Päänavigointi...

Lisätiedot

CHERMUG-pelien käyttö opiskelijoiden keskuudessa vaihtoehtoisen tutkimustavan oppimiseksi

CHERMUG-pelien käyttö opiskelijoiden keskuudessa vaihtoehtoisen tutkimustavan oppimiseksi Tiivistelmä CHERMUG-projekti on kansainvälinen konsortio, jossa on kumppaneita usealta eri alalta. Yksi tärkeimmistä asioista on luoda yhteinen lähtökohta, jotta voimme kommunikoida ja auttaa projektin

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

työryhmien SharePoint-yhteistyötä helpottava ratkaisu

työryhmien SharePoint-yhteistyötä helpottava ratkaisu työryhmien SharePoint-yhteistyötä helpottava ratkaisu LIIKKEENJOHDON SUURIN HAASTE Modernin yrityksen on muutoksen kyydissä pysyäkseen suunniteltava tehokas strategia ja seurattava sitä. Siinä piilee kuitenkin

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA

Lisätiedot

Sukupuu -ohjelma. Ossi Väre (013759021) Joni Virtanen (013760641)

Sukupuu -ohjelma. Ossi Väre (013759021) Joni Virtanen (013760641) Sukupuu -ohjelma Ossi Väre (013759021) Joni Virtanen (013760641) 7.11.2011 1 Johdanto Toteutimme C -kielellä sukupuuohjelman, johon käyttäjä voi lisätä ja poistaa henkilöitä ja määrittää henkilöiden välisiä

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

AS-0.3200 Automaatio- ja systeemitekniikan projektityöt

AS-0.3200 Automaatio- ja systeemitekniikan projektityöt AS-0.3200 Automaatio- ja systeemitekniikan projektityöt A11-17 Ikäihmisten kotona asumista tukevien järjestelmien kehittäminen AikatauluValpas Salla Ojala Paula Laitio 1. Projektin tavoite Projektimme

Lisätiedot

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Arkkitehtuuriin vaikuttavat ympäristötekijät Jo kehittämisen alkuvaiheessa on tarpeellista hahmotella arkkitehtuurin perusratkaisu. Lähtökohdat

Lisätiedot

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op FT Ari Viinikainen Tietokoneen rakenne Keskusyksikkö, CPU Keskusmuisti Aritmeettislooginen yksikkö I/O-laitteet Kontrolliyksikkö Tyypillinen Von Neumann

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

VALO-ohjelmat ja LTSP kouluissa. Elias Aarnio Innopark, AVO-hanke elias.aarnio@innopark.fi 040-8204614

VALO-ohjelmat ja LTSP kouluissa. Elias Aarnio Innopark, AVO-hanke elias.aarnio@innopark.fi 040-8204614 VALO-ohjelmat ja LTSP kouluissa Elias Aarnio Innopark, AVO-hanke elias.aarnio@innopark.fi 040-8204614 Mikä ihmeen VALO? VALO = Vapaat ja avoimen lähdekoodin ohjelmat Kyse on siis Open Sourcesta eli avoimesta

Lisätiedot

2009 Mat-2.4177 Operaatiotutkimuksen Projektityöseminaari L

2009 Mat-2.4177 Operaatiotutkimuksen Projektityöseminaari L 2009 Mat-2.4177 Operaatiotutkimuksen Projektityöseminaari L Väliraportti 25.2.2009 Puustokuvioiden korjuukelpoisuus- ja saavutettavuusanalyysi Juha Valvanne Juho Matikainen Joni Nurmentaus Lasse Östring

Lisätiedot

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.

Lisätiedot

XML prosessori. XML prosessointi. XML:n kirjoittaminen. Validoiva jäsennin. Tapahtumaohjattu käsittely. Tapahtumaohjattu käsittely.

XML prosessori. XML prosessointi. XML:n kirjoittaminen. Validoiva jäsennin. Tapahtumaohjattu käsittely. Tapahtumaohjattu käsittely. XML prosessointi Miten XML dokumentteja luetaan ja kirjoitetaan XML prosessori lukee ja välittää XML dokumentin sovellukselle. Se sisältää entieettikäsittelijän (mahdollisesti) XML jäsentimen Sovellus

Lisätiedot

PDF-tiedostojen optimointi hakukoneille

PDF-tiedostojen optimointi hakukoneille PDF-tiedostojen optimointi hakukoneille PDF-tiedostojen optimointi herättää ristiriitaisia tunteita. Jotkut väittävät, että PDF:illä ei ole mitään arvoa hakukoneoptimointimielessä, toiset taas puhuvat

Lisätiedot

MatTaFi projektin HAKA-pilotti

MatTaFi projektin HAKA-pilotti projektin HAKA-pilotti Matti Harjula matti.harjula@hut.fi Matematiikan ja systeemianalyysin laitos Teknillinen korkeakoulu 15. tammikuuta 2008 1 2 Materiaalin tuottajat ongelmana 3 Uusien sovellusten yksinkertaisempi

Lisätiedot

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Matti Luukkainen 10.12.2009 Tässä esitetty esimerkki on mukaelma ja lyhennelmä Robert Martinin kirjasta Agile and Iterative Development löytyvästä

Lisätiedot

KUVANKÄSITTELY THE GIMP FOR WINDOWS OHJELMASSA

KUVANKÄSITTELY THE GIMP FOR WINDOWS OHJELMASSA KUVANKÄSITTELY THE GIMP FOR WINDOWS OHJELMASSA Ohjeistuksessa käydään läpi kuvan koon ja kuvan kankaan koon muuntaminen esimerkin avulla. Ohjeistus on laadittu auttamaan kuvien muokkaamista kuvakommunikaatiota

Lisätiedot

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ylläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari

Lisätiedot

24h Admin V1.00 20.11.2004 / 24h_Admin_v100.pdf 1/9

24h Admin V1.00 20.11.2004 / 24h_Admin_v100.pdf 1/9 24h Admin V1.00 20.11.2004 / 24h_Admin_v100.pdf 1/9 Copyright Yleiskuvaus 1. Perusasioita kirjautumisesta 2. Kirjautuminen 3. Sivut 4. Yläpalkki 5. Sivujen kuvaukset 5.1 Versiotiedot 5.2 Pääsivu 5.3 Valikon

Lisätiedot

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013 Virtualisointi Pertti Pennanen DOKUMENTTI 1 (5) SISÄLLYSLUETTELO Virtualisointi... 2 Virtualisointiohjelmia... 2 Virtualisointitapoja... 2 Verkkovirtualisointi... 2 Pertti Pennanen DOKUMENTTI 2 (5) Virtualisointi

Lisätiedot

Ohjelmien automaattisen verifioinnin reunamailla

Ohjelmien automaattisen verifioinnin reunamailla Ohjelmien automaattisen verifioinnin reunamailla Antti Siirtola Tietotekniikan laitos, Perustieteiden korkeakoulu, Aalto-yliopisto, antti.siirtola@aalto.fi Suomalainen Tiedeakatemia, Nuorten akatemiaklubi,

Lisätiedot