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

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

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

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

Mainosankkuri.fi-palvelun käyttöohjeita

Mainosankkuri.fi-palvelun käyttöohjeita Mainosankkuri.fi-palvelun käyttöohjeita Sisällys 1. Johdanto... 1 2. Sisäänkirjautuminen... 1 3. Palvelussa navigointi... 2 4. Laitteet... 2 5. Sisällönhallinta... 4 6. Soittolistat... 7 7. Aikataulut...

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702)

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

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Ohjelmoinnin perusteet Y Python

Ohjelmoinnin perusteet Y Python Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2009 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2009 1 / 28 Puhelinluettelo, koodi def lue_puhelinnumerot(): print "Anna lisattavat nimet ja numerot." print

Lisätiedot

Automaattinen yksikkötestaus

Automaattinen yksikkötestaus Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä

Lisätiedot

Tietorakenteet ja algoritmit

Tietorakenteet ja algoritmit Tietorakenteet ja algoritmit Kurssin sisältö pääpiirteittäin Tarvittavat pohjatiedot Avainsanat Abstraktio Esimerkkiohjelman tehtäväkuvaus Abstraktion käyttö tehtävässä Abstrakti tietotyyppi Hyötyjä ADT:n

Lisätiedot

Interfacing Product Data Management System

Interfacing Product Data Management System Interfacing Product Data Management System Tekijä: Työn valvoja: Mats Kuivalainen Timo Korhonen Esitelmän sisältö Työn suorituspaikka - Ideal Product Data Oy Käsitteitä Työn tavoitteet Työn tulokset 1/5

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

Kurssin hallinta -työväline

Kurssin hallinta -työväline Kurssin hallinta -työväline Kurssin hallinta -työvälineellä muokataan kursseja A&Ooppimisympäristöalustalla Kurssi koostuu - ohjelmasta (linkit työkaluihin& muihin resursseihin), - materiaaleista, - keskusteluryhmästä,

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

13/20: Kierrätys kannattaa koodaamisessakin

13/20: Kierrätys kannattaa koodaamisessakin Ohjelmointi 1 / syksy 2007 13/20: Kierrätys kannattaa koodaamisessakin Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen 1 FYSIIKKA Fysiikan päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta fysiikan opiskeluun T2 ohjata

Lisätiedot

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio 1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...

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

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

Valppaan asennus- ja käyttöohje

Valppaan asennus- ja käyttöohje Versio Päiväys Muokkaaja Kuvaus 0.9 16.2.2006 Tuukka Laakso Korjattu versio 0.1 Antti Kettunen Alustava versio Sisällysluettelo 1 Johdanto...2 2 Valppaan asennus...3 2.1 Valppaan kääntäminen...3 2.2 Valmiiksi

Lisätiedot

Uutta Remote Support Platform 3.0 -versiossa

Uutta Remote Support Platform 3.0 -versiossa Uutta Remote Support Platform for SAP Business One Asiakirjaversio: 1.0 2012-10-08 Kaikki maat Typografiset merkintätavat Kirjasintyyli Esimerkki Näytöstä lainatut sanat tai merkit. Näitä ovat kenttien

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

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisuus kahdella tasolla Oppimisaihiot ( Learning Objects

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen KEMIA Kemian päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta kemian opiskeluun T2 ohjata ja

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

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } } Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.

Lisätiedot

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

Lisätiedot

VYPEdit verkkosivualusta SVY-toimijoille

VYPEdit verkkosivualusta SVY-toimijoille VYPEdit verkkosivualusta SVY-toimijoille www.vy.fi/admin/vypedit TieVie 26.8.2005 Hely Lahtinen VypEdit sisällönhallintajärjestelmällä voi www.vy.fi/admin/vypedit tuottaa ja ylläpitää www-sivustoja SVY:n

Lisätiedot

Juulin kehittäminen: tilannekatsaus

Juulin kehittäminen: tilannekatsaus Juulin kehittäminen: tilannekatsaus VIRTA-julkaisuyhteyshenkilöiden kokous, 4.11.2016 Jyrki Ilva Juuli-julkaisutietoportaali Juuli-portaali (www.juuli.fi) ollut käytössä kesäkuusta 2013 lähtien Uutta dataa

Lisätiedot

BlueJ ohjelman pitäisi löytyä Development valikon alta mikroluokkien koneista. Muissa koneissa BlueJ voi löytyä esim. omana ikonina työpöydältä

BlueJ ohjelman pitäisi löytyä Development valikon alta mikroluokkien koneista. Muissa koneissa BlueJ voi löytyä esim. omana ikonina työpöydältä Pekka Ryhänen & Erkki Pesonen 2002 BlueJ:n käyttö Nämä ohjeet on tarkoitettu tkt-laitoksen mikroluokan koneilla tapahtuvaa käyttöä varten. Samat asiat pätevät myös muissa luokissa ja kotikäytössä, joskin

Lisätiedot

11/20: Konepelti auki

11/20: Konepelti auki Ohjelmointi 1 / syksy 2007 11/20: Konepelti auki Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/11 Tämän luennon

Lisätiedot

arvioinnin kohde

arvioinnin kohde KEMIA 9-lk Merkitys, arvot ja asenteet T2 Oppilas tunnistaa omaa kemian osaamistaan, asettaa tavoitteita omalle työskentelylleen sekä työskentelee pitkäjänteisesti T3 Oppilas ymmärtää kemian osaamisen

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

Ketterän. Hannu Salmela, Mikko Hallanoro, Seppo Sippa, Tommi Tapanainen, Jari Ylitalo organisaation IT

Ketterän. Hannu Salmela, Mikko Hallanoro, Seppo Sippa, Tommi Tapanainen, Jari Ylitalo organisaation IT Ketterän Hannu Salmela, Mikko Hallanoro, Seppo Sippa, Tommi Tapanainen, Jari Ylitalo organisaation IT Talentum Helsinki 2010 Talentum Media Oy ja tekijät ISBN 978-952-14-1505-0 Kansi: Jarkko Nikkanen Taitto:

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

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

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Terveyden

Lisätiedot

SOVELLUSPROJEKTIN ARVIOINTILOMAKE

SOVELLUSPROJEKTIN ARVIOINTILOMAKE SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa

Lisätiedot

Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen

Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Vaatimusluettelo versio 0.17 Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Yleiset vaatimukset 1 Koodistopalvelujärjestelmä on selainkäyttöinen 2 Käyttöliittymän tulee

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

Tietotekniikan Sovellusprojektit

Tietotekniikan Sovellusprojektit Tietotekniikan Sovellusprojektit Jukka-Pekka Santanen Tietotekniikan laitos 16.2.2010 Tavoitteena taitoja ja kokemusta projektimuotoisesta työtavasta ja ryhmätyöstä, projektin hallinnasta ja johtamisesta,

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

Action Request System

Action Request System Action Request System Manu Karjalainen Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 25.10.2000 Action Request System (ARS) Manu Karjalainen Ohjelmistotuotantovälineet

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

Lisätiedot

Ohjelmistojen laadun parantaminen refaktoroinnilla Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto

Ohjelmistojen laadun parantaminen refaktoroinnilla Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto Ohjelmistojen laadun parantaminen refaktoroinnilla Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto Mäkinen / Ohjelmistojen laadun parantaminen / Ohjelmistoprosessit ja ohjelmistojen laatu

Lisätiedot

ADM Arkkitehtuuritason automaatio #tdarc

ADM Arkkitehtuuritason automaatio #tdarc ADM Arkkitehtuuritason automaatio #tdarc Kalle Launiala http://abstractiondev.wordpress.com kalle.launiala@citrus.fi Ohjelmistoteollisuus elää murrosta Ohjelmistoteollisuudesta halutaan perusteollisuutta

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

815338A Ohjelmointikielten periaatteet Harjoitus 3 vastaukset

815338A Ohjelmointikielten periaatteet Harjoitus 3 vastaukset 815338A Ohjelmointikielten periaatteet 2015-2016. Harjoitus 3 vastaukset Harjoituksen aiheena ovat imperatiivisten kielten muuttujiin liittyvät kysymykset. Tehtävä 1. Määritä muuttujien max_num, lista,

Lisätiedot

UML-kielen formalisointi Object-Z:lla

UML-kielen formalisointi Object-Z:lla UML-kielen formalisointi Object-Z:lla Kalvot ja seminaarityö WWW:ssä: http://users.jyu.fi/~minurmin/opiskelu/form/ UML UML == Unified Modelling Language. OMG:n standardoima kieli ohjelmistojärjestelmien,

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

INTINU13A6 Java sovellukset

INTINU13A6 Java sovellukset Johdanto Kurssin tavoitteena oli luoda tietokantaa käyttävä websovellus Java EE ohjelmointikielellä, sekä hyödyntää muun muassa servlettejä sekä JSP sivuja ja muita tekniikoita monipuolisesti. Webserverinä

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Muutamia ajatuksia siitä, miten testaus pärjää lama-ajan säästötalkoissa. Laman patologioita ja mahdollisuuksia. Säästämisen strategioita.

Lisätiedot

arvioinnin kohde

arvioinnin kohde KEMIA 8-lk Merkitys, arvot ja asenteet T2 Oppilas asettaa itselleen tavoitteita sekä työskentelee pitkäjänteisesti. Oppilas kuvaamaan omaa osaamistaan. T3 Oppilas ymmärtää alkuaineiden ja niistä muodostuvien

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Ajankohtaista Ilmoitin.fi:stä

Ajankohtaista Ilmoitin.fi:stä Ajankohtaista Ilmoitin.fi:stä Verohallinnon ohjelmistotalotapaaminen 13.5.2016 Markus Virolainen Tieto, Tietokarhu Oy markus.virolainen@tieto.com Kolme asiaa 1. Ilmoitin.fi ja kansallinen palveluarkkitehtuuriohjelma

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

Lisätiedot

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 582101 - Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 1 Lähestymistapoja Kokonaisvaltainen lähestymistapa (top-down) etsitään kerralla koko kohdealuetta kuvaavaa mallia hankalaa, jos kohdealue

Lisätiedot

AVL-puut. eräs tapa tasapainottaa binäärihakupuu siten, että korkeus on O(log n) kun puussa on n avainta

AVL-puut. eräs tapa tasapainottaa binäärihakupuu siten, että korkeus on O(log n) kun puussa on n avainta AVL-puut eräs tapa tasapainottaa binäärihakupuu siten, että korkeus on O(log n) kun puussa on n avainta pohjana jo esitetyt binäärihakupuiden operaatiot tasapainotus vie pahimmillaan lisäajan lisäys- ja

Lisätiedot

käyttötapaukset mod. testaus

käyttötapaukset mod. testaus käyttötapaukset Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Kartta hyväksyntä määrittely suunnittelu suunnittelu mod. testaus integrointi sys. testaus Ylläpito koodaus (toteutus)

Lisätiedot

Sisällönhallinnan menetelmiä

Sisällönhallinnan menetelmiä Sisällönhallinnan menetelmiä Airi Salminen Jyväskylän yliopisto http://www.cs.jyu.fi/~airi/ Suomalaisen lainsäädäntötyön tiedonhallinta: suuntana semanttinen web RASKE2-projektin loppuseminaari Eduskunnassa

Lisätiedot

Suvi Junes Tietohallinto / Opetusteknologiapalvelut 2012

Suvi Junes Tietohallinto / Opetusteknologiapalvelut 2012 Tiedostot Uudet ominaisuudet: - Ei Tiedostot-kohtaa alueen sisällä, vaan tiedostonvalitsin, jolla tiedostot tuodaan alueelle siihen kohtaan missä ne näytetään - Firefox-selaimella voi työpöydältä raahata

Lisätiedot

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli

Lisätiedot

Ohjelmointi 1 / syksy /20: IDE

Ohjelmointi 1 / syksy /20: IDE Ohjelmointi 1 / syksy 2007 10/20: IDE Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/8 Tämän luennon rakenne

Lisätiedot

itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance

itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance Markus Leinonen M.Sc. (Econ.), CIA, CISA Senior Manager, Internal Controls Cargotec Oyj 1984 1986 1992 1995 1997 1997 2002 2002 2008

Lisätiedot

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan 1(7) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ Tutkinnon osa: Palvelujen käyttöönotto ja tuki Tutkinnon osaan kuuluvat opinnot: Työasemaympäristön suunnittelu ja toteuttaminen Kouluttaminen ja asiakastuki

Lisätiedot

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k 1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.

Lisätiedot

HELIA 1 (11) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu

HELIA 1 (11) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu HELIA 1 (11) Luento 4 Käytettävyyden tuottaminen... 2 Käytettävyys ja systeemityöprosessi... 3 Määrittely... 3 Suunnittelu... 3 Toteutus ja testaus... 3 Seuranta... 3 Kriittiset tekijät käytettävyyden

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi

Lisätiedot

Luokka- ja oliokaaviot

Luokka- ja oliokaaviot Luokka- ja oliokaaviot - tärkeimmät mallinnuselementit : luokat, oliot ja niiden väliset suhteet - luokat ja oliot mallintavat kuvattavan järjestelmän sisältöä ja niiden väliset suhteet näyttävät, kuinka

Lisätiedot

Päivitys Navigo Portalin versioon 5.1

Päivitys Navigo Portalin versioon 5.1 Päivitys Navigo Portalin versioon 5.1 Mikä muuttuu? 1 Johdanto...2 2 Sivun asetukset...2 3 Piilotetut Portlet-otsikot ja painikkeet...2 4 Portletin toimintolinkit ovat kuvakkeina...2 5 Uusi sisältö luodaan

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

Digitaalisen median tekniikat. JSP ja XML Harri Laine 1

Digitaalisen median tekniikat. JSP ja XML Harri Laine 1 Digitaalisen median tekniikat JSP ja XML 28.4.2004 Harri Laine 1 JSP hyvin lyhyesti JSP on Java-pohjainen skriptikieli JSP:llä laadittu sivu käännetään java-servletiksi (sivun toteutus vastaa servlettiluokan

Lisätiedot

REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN

REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN Arkistolaitos REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN Ohje v. 1.0 (16.10.2012) Kansallisarkisto Rauhankatu 17 PL 258, 00171 Helsinki Puh. Tel. (09) 228 521 arkisto@narc.fi Riksarkivet

Lisätiedot

Harjoitustyön testaus. Juha Taina

Harjoitustyön testaus. Juha Taina Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida

Lisätiedot

Harjoitus 7: NCSS - Tilastollinen analyysi

Harjoitus 7: NCSS - Tilastollinen analyysi Harjoitus 7: NCSS - Tilastollinen analyysi Mat-2.2107 Sovelletun matematiikan tietokonetyöt Syksy 2006 Mat-2.2107 Sovelletun matematiikan tietokonetyöt 1 Harjoituksen aiheita Tilastollinen testaus Testaukseen

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

VÄLI- JA LOPPURAPORTOINTI

VÄLI- JA LOPPURAPORTOINTI Tuija Nikkari 2012 VÄLI- JA LOPPURAPORTOINTI Raportointikoulutus 23.8.12 Raportoinnin tarkoitus Raportoinnin tehtävänä on tuottaa tietoa projektin etenemisestä ja tuloksista rahoittajalle, yhteistyökumppaneille

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2010

Ohjelmistoarkkitehtuurit. Syksy 2010 Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin

Lisätiedot

JWT 2016 luento 11. to 21.4.2016 klo 14-15. Aulikki Hyrskykari. PinniB 1097. Aulikki Hyrskykari

JWT 2016 luento 11. to 21.4.2016 klo 14-15. Aulikki Hyrskykari. PinniB 1097. Aulikki Hyrskykari JWT 2016 luento 11 to 21.4.2016 klo 14-15 Aulikki Hyrskykari PinniB 1097 1 Viime luennolla o AJAX ja JSON, harjoitustyön tehtävänanto, vierailuluento avoimesta datasta Tänään o APIt rajapinnoista yleisesti

Lisätiedot

Verkoston kehittäminen Oppivat tuotantokonseptit -oppaan avulla

Verkoston kehittäminen Oppivat tuotantokonseptit -oppaan avulla Verkoston kehittäminen Oppivat tuotantokonseptit -oppaan avulla Oppivat tuotantokonseptit välineitä verkoston kehittämiseen 17.4.2012 Aalto-yliopiston perustieteiden korkeakoulu Helsingin yliopisto Lappeenrannan

Lisätiedot

WWW-ohjelmoinnin kokonaisuus. WWW-OHJELMOINTI 1 Merkkauskielet. Merkkauskielten idea. Merkkauskielet (markup languages) Merkkauskielten merkitys

WWW-ohjelmoinnin kokonaisuus. WWW-OHJELMOINTI 1 Merkkauskielet. Merkkauskielten idea. Merkkauskielet (markup languages) Merkkauskielten merkitys WWW-OHJELMOINTI 1 WWW-ohjelmoinnin kokonaisuus SGML, XML, HTML WWW-selaimen sovellusohjelmointi WWW-palvelimen sovellusohjelmointi Eero Hyvönen Tietojenkäsittelytieteen laitos Helsingin yliopisto 26.10.2000

Lisätiedot

Teoksen portfolion edellyttää osallistumista välipalavereihin ja päättötyönäyttelyyn sekä oman päättötyösi esittelyn

Teoksen portfolion edellyttää osallistumista välipalavereihin ja päättötyönäyttelyyn sekä oman päättötyösi esittelyn PÄÄTTÖTYÖOPAS SISÄLLYSLUETTELO Mikä on päättötyö... 1 Päättötyö ja päättötodistus... 2 Milloin päättötyön voi suorittaa... 3 Miten päättötyö suoritetaan... 4 Portfolio... 5 Näitä asioita voisit portfoliossasi

Lisätiedot

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7 Viitearkkitehtuurin suunnitteluprosessi Ohje v.0.7 Viitearkkitehtuurin suunnitteluprosessi XX.XX.201X 2 (13) Sisällys 1. Johdanto... 3 2. Viitearkkitehtuurin suunnitteluprosessin vaiheet... 3 2.1. Vaihe

Lisätiedot

<e.g. must, essential, conditional> Käyttötapaukset Kurssin malli käyttötapauksille: Tila < List of users and the other systems that interacts directly with a system>

Lisätiedot

Tietorakenteet ja algoritmit syksy Laskuharjoitus 1

Tietorakenteet ja algoritmit syksy Laskuharjoitus 1 Tietorakenteet ja algoritmit syksy 2012 Laskuharjoitus 1 1. Tietojenkäsittelijä voi ajatella logaritmia usein seuraavasti: a-kantainen logaritmi log a n kertoo, kuinka monta kertaa luku n pitää jakaa a:lla,

Lisätiedot

ATK tähtitieteessä. Osa 3 - IDL proseduurit ja rakenteet. 18. syyskuuta 2014

ATK tähtitieteessä. Osa 3 - IDL proseduurit ja rakenteet. 18. syyskuuta 2014 18. syyskuuta 2014 IDL - proseduurit Viimeksi käsiteltiin IDL:n interaktiivista käyttöä, mutta tämä on hyvin kömpelöä monimutkaisempia asioita tehtäessä. IDL:llä on mahdollista tehdä ns. proseduuri-tiedostoja,

Lisätiedot

Valtakunnallinen tallennustyönjako valmistunut miten tästä eteenpäin

Valtakunnallinen tallennustyönjako valmistunut miten tästä eteenpäin Valtakunnallinen tallennustyönjako valmistunut miten tästä eteenpäin T E E M U A H O L A T A K O - S E M I N A A R I 2 9. 1. 2 0 1 3 S U O M E N K A N S A L L I S M U S E O Haasteellinen kokonaisuus Valtakunnallisen

Lisätiedot