Suunnittelumallien käyttö ohjelmistosuunnittelussa

Koko: px
Aloita esitys sivulta:

Download "Suunnittelumallien käyttö ohjelmistosuunnittelussa"

Transkriptio

1 Suunnittelumallien käyttö ohjelmistosuunnittelussa Mika Rantakeisu Rovaniemen ammattikorkeakoulu Avoin ammattikorkeakoulu Tiivistelmä Tämä on selvitys suunnittelumallien käytöstä ohjelmiston kehitysprosessissa. Esittelen useita käytössä olevia suunnittelumalleja ja sovellan niitä käytännössä ohjelman sovellusarkkitehtuurin luomiseen. Käsittelen myös suunnittelumallien yleistä merkitystä ohjelmistokehitykselle ja niiden hyötyjä ja haittoja ohjelmiston arkkitehtuurin luomisessa. Esittelen uusimpia ohjelmoinnin periaatteita ja sovellan niitä suunnittelumallien kanssa ohjelmistokehitysprosessissa. Näytän aikaisemmin tekemäni ohjelman sovellusarkkitehtuurin ja luon suunnittelumalleja käyttäen uuden version tämän ohjelman arkkitehtuurista. Lopuksi esittelen käyttämiäni suunnitteluratkaisuja ja analysoin näiden ratkaisujen hyötyjä ja haittoja verrattuna alkuperäiseen ohjelmaan. Suunnittelumallit ja ohjelmat esitellään tekstikuvauksena sekä UMLkaaviona. Sisällysluettelo JOHDANTO 1.0 Mitä suunnittelumallit ovat? 1.1 Suunnittelumallien hyödyt 1.2 Suunnittelumallien haitat 1.3 Ohjelmisto alan käsitteitä 2.0 SUUNNITTELUMALLIEN ESITTELYJÄ 2.1 Tila suunnittelumalli 2.2 Tarkkailija suunnittelumalli 2.3 Tehdasmetodi suunnittelumalli 2.4 Kehysmetodi suunnittelumalli 3.0 ALKUPERÄINEN OHJELMA 3.1 Mikä on Boulder Dash? 3.2 Lopputulos 3.3 Ajatus uuden version kehitystyöhön 4.0 OHJELMAN UUDELLEENKEHITYS KÄYTTÄEN SUUNNITTELUMALLEJA 4.1 Uuden sovellusarkkitehtuurin rakenne 5.0 LOPPUTULOKSET 5.1 Suunnittelumallien vaikutus ohjelmointiprosessiin 5.2 Suunnittelumallien vaikutus arkkitehtuurin suunnitteluun. 5.3 Johtopäätökset LÄHTEET JOHDANTO Suunnittelumallit ovat valmiita ratkaisuja niihin ongelmiin, joita ohjelmoija kohtaa koostaessaan tietokoneohjelman eri osia. Ne ovat loistava tapa ohjelmoijien siirtää tietoa muille ohjelmoijille suullisesti tai dokumentaation kautta. Käytän tässä julkaisussa ohjelman tilalla synonyymia sovellus. Esittelen aikaisemmin tekemäni sovellusarkkitehtuurin ja kuvaan sovelluksen toimintaa ja kuinka se on tehty. Käytän suunnittelumalleja sen sovellusarkkitehtuurin uudistamiseen ja analysoin uuden arkkitehtuurin hyötyjä sekä haittoja. Lopuksi kerron tämän prosessin aikana tekemiäni havaintoja suunnittelumallien vaikutuksesta siihen mitä ohjelmistokehitysprosessin eri vaiheissa tapahtuu. 1.0 MITA SUUNNITTELUMALLIT OVAT? Suunnittelumallit ovat tärkeä osa ohjelmistokehitysprojektia. Niitä voisi kuvata kokeneiden ohjelmoijien kansanperinteeksi, joka tarjoaa valmiita suunnitteluratkaisuja moniin toistuviin ongelmiin, joita ohjelmoija kohtaa koostaessaan tietokoneohjelman komponenttia arkkitehtuurisuunnittelussa ennalta määrättyyn tarkoitukseen vastaamaan parhaan mukaan sovelluksen spesifikaatiossa määriteltyjä toiminnallisuus- ja laatuvaatimuksia. Erilaisia suunnittelumalleja on satoja ja ne jakaantuvat käyttökontekstinsa mukaan toiminta-, rakenne- ja luontimalleihin. Rakennemalleissa määritellään miten komponentin luokat rakennetaan. Luontimalleissa määritellään miten komponentin oliot luodaan. Toimintamalleissa kuvataan miten komponentin oliot toimivat. 1.1 Suunnittelumallien hyödyt Tuntemalla suunnittelumalleja ohjelmoijat voivat siirtää keskenään paljon tietoa sovellus-spesifeihin ratkaisuihin liittyen. Päätös käyttää jotain suunnittelumallia sovelluksen komponentin tekemiseen määrittelee pitkälti sen, miten se rakennetaan ja toimii. Periaatteessa suunnittelumallia voi verrata talon rakennuspiirustuksiin, jotka määrittelevät talon rakenteen ja rakennustavan. Samoin kuin rakentajalla tehtäväksi jää talon rakentaminen rakennuspiirustusten mukaisiksi, niin ohjelmoija pyrkii ohjelmoimaan komponentin mahdollisimman pitkälle suunnittelumallin määritelmässä viitekehyksessä.

2 Suunnittelumallien kautta voidaan toteuttaa modernin ohjelmistokehityksen käytäntöjä, joita suositellaan sovellettavaksi sovellusarkkitehtuurin suunnittelussa. Nämä käytännöt ovat: [3, s608] 1. Suosi koostamista yli perimisen 2. Luokkien pitää olla avoimia laajennettavuutta varten, suljettuja muokkausta varten 3. Pyri löyhästi sidottuun ratkaisuun komponenttien rajapintojen ja toteutuksen välillä 4. Komponentin sisäiset ratkaisut eivät saa näkyä rajapinnan ulkopuolella 5. Suosi rajapintojen muokkausta/lisäämistä, metodien toteutuksen muuttamisen sijaan 6. Kapseloi se mikä muuttuu 7. Oliot ovat suoraan yhteydessä ainoastaan vierekkäisen arkkitehtuurikerroksen olioiden kanssa 8. Ohjelmoi rajapintoja vastaa älä toteutuksia Lisäksi modernin Java-ohjelmistokehityksen paradigma on pyrkiä siihen että, ohjelman toiminta määräytyy dynaamisesti ohjelman ajovaiheessa, ennenmin kuin se tapahtuisi staattisesti ohjelman kääntämisvaiheessa. [3, s69] 1.2 Suunnittelumallien haitat Suunnittelumallit monimutkaistavat ohjelmaa ja lisäävät erilaisten luokkien ja metodien sekä koodin määrää. Lisäksi ne luovat rajoituksia ohjelman kehitykseen. 1.3 Ohjelmisto alan käsitteitä Suunnittelumallien käyttöön liittyy monia sovellusarkkitehtuuriin liittyviä käsitteitä, jotka kannattaa ymmärtää ainakin yleisellä tasolla. Luokkaa käytetään ohjelmistosuunnittelussa mallittamaan, jonkun abstraktin tai reaalimaailman käsitteen ilmentymää ohjelmistossa. Käytännossä luokassa määritellään tietty loogiseen kokonaisuuteen kuuluva algoritmi ja mitä tietoa siihen talletetaan. Olio on luokan ilmentymä ohjelmaa ajettaessa. Ohjelman toiminnan aikana se toimii algoritmiensa mukaan, joilloin siihen kapseloidaan tietoa sekä se on yhteydessä muihin luokista toteutettuihin olioihin. Rajapinta tarkoittaa tapaa jolla oliot ovat yhteydessä toisiinsa. Kaikki olioiden väliset yhteydet eivät tapahtu rajapintojen kautta, mutta komponenttien, kerroksien ja myös moduuleilla on omia rajapintoja, joilla niihin pitää olla yhteydessä. Periaatteessa rajapinta antaa komponenttia käyttävälle asiakkaalle tietyn rajatun näkymän komponentin tietoihin ja toimintoihin. Yleensä tämä tarkoittaa vain niitä tietoja ja toimintoja, joita kyseisen asiakkaan arkkitehtuuri suunnittelun perusteella tarvitsee käyttää. Ohjelmistoprosessissa sanalla komponentti voi olla monta merkitystä. Se voi tarkoittaa luokkaa, olioden kokonaisuutta tai vain yhtä oliota. Komponentti joka tapauksessa toteuttaa tiettyjä toimintoja, joita sille on asetettu arkkitehtuurisuunnittelussa ja yhteydet komponenttiin tapahtuvat sen rajapintojen kautta näin se on helposti uudelleen käyttävissä muissa ohjelmissa kuin se jossa on määritelty. Monet ohjelmointikielet tarjoavat valmiita komponentteja, jotka on suoraan käytettävissä ohjelmassa. Moduuli voidaan määritellä luokaksi, paketiksi, komponentiksi. Moduuli on yleensä koodin hallinnallinen kokonaisuus. Ohjelma kannattaa jakaa monitasomallin mukaisiin kerroksiin. Kerros käsittää kaikki tiettyyn loogiseen kokonaisuuteen tarkoitetut oliot. Kerrokset ovat yhteydessä toisiinsa rajapintojen kautta vain monitasomallin vierekkäisten kerrosten välillä. Eri kerrokset saattavat sijaita eri tietokoneilla. Yleisin tapa jakaa sovellus kerroksiin on niin sanottu kolme kerrosarkkitehtuuri, jossa on käytössä käyttöliittymä-, toimintalogiikka-, ja infrastruktuurikerrokset. Arkkitehtuuri tarkoittaa perustaa, jonka varaan kaikki sovelluksen myöhemmät suunnittelu- ja toteutusratkaisut rakennetaan. Arkkitehtuurikuvaus toimii järjestelmän yleisrakenteen dokumentaationa.[2] 2 SUUNNITTELUMALLIEN ESITTELYJÄ Erilaisia suunnittelumalleja satoja ja ne jakaantuvat sen ongelma kontekstinsa mukaan, jonka ne ensisijaisesti ratkaisevat rakenne-, luonti-, ja käyttäytymismalleihin. Yleensä tarvitsee osata joitakin keskeisiä suunnittelumalleja. [3] 2.1 Tila suunnittelumalli Tila-suunnittelumallissa (State Pattern) määritellään rajapinta, jolla voidaan samalle oliolle määritellä monia toteutuksia niistä luokista, jotka toteuttavat rajapinnan. Tilasiirtymät voivat tapahtua ohjelman sisäisesti olion tilan mukaan tai ulkoisesti. Tila-suunnittelumalli ei ota kantaa siihen mikä muuttaa olioiden tilaa. Toteutuksessa on määriteltävä miten tila oliot luodaan ja tuhotaan.[3, s22] Käytännössä suunnittelumalli voidaan toteuttaa seuraavasti (UML luokkakaavio kuva[1]). Määritellään rajapinta (State) ja rajapinnan toteuttavia luokkia (ConcreteState1, ConcreteState2). Rajapintaa käyttävässä asiakas (Context) luokassa on jäsen muuttuja jonka tyyppi on rajapinta State. Sekä jäsenmuuttujat, jotka viittaavat State liittymän toteuttaviin ConcreteState1 ja ConcreteState2 luokkiin. Myös ConcreteState1 ja ConcreteState2 luokissa on jäsenmuuttuja joka viittaa samaan Context luokkaan. Tilojen vaihto tapahtuu niin että Context luokka asettaa State muuttujan viittaamaan milloin esimerkiksi ConcreteState1 luokkaan tai ConcreteState2 muuttujaan, näiden omien setstate(state : State) metodien kautta. [3]

3 tapa toteuttaa Tehdasmetodi-suunnittelumalli (virtual constructor) on seuraava (kuva[3]). Suunnittelumallissa on yliluokka (Object), josta määritellään aliluokkia (ConcreteObject1, ConcreteObject2). Suunnittelumallissa on FactoryMethod-niminen luokka, jossa on factory niminen metodi. Tämä metodi luo oliota Object yliluokan aliluokista, Joita on esimerkiksi ConcreteObject1 ja ConcreteObject2.[3] kuva[1] Tila-suunnittelumalli sopii ohjelmiin, joissa olion käyttäytyminen riippuu tilasta ja olion on vaihdettava käyttäytymistään ajon aikana. Esimerkki tällaisesta on TCP-yhteys, jossa kolme tilaa jotka ovat suljettu, muodostettu ja kuuntelee.[1] 2.2 Tarkkailija suunnittelumalli Tarkkailija-suunnittelumallissa (Observer-pattern) määritellään Subject rajapinnan toteutta olio (kuva[2]) (ConcreteSubject) sekä ConcreteObserver oliota, jotka toteuttavat Observer rajapinnan. ConcreteSubject oliossa on viittaus ConcreteObserver oliohin (yleensä jonkinlainen lista). Ja samoin ConcreteObserver oliossa on viittaus samaan ConcreteSubject olioon. [3, s52] Tarkkailijan toiminta tapahtuu niin että Concrete- Observer rekisteröi itsensä ConcreteSubject olion tarkkailijaksi (lisää itsensä listaan). Jos Concrete-Subject olion tila muuttuu niin se ilmoittaa siitä kaikille Tarkkailijoilleen (ConcreteObserver oliot listassa), jotka muuttavat omaa toimintaansa. ConcreteSubject tilan mukaan. Jokainen ConcreteObserver olio voi lisätä ja poistaa itsensä listasta koska tahansa.[3] kuva[3] Tehdasmetodi suunnittelumallia käytetään sovelluksissa, joissa ei tiedetä mitä eri oliota milloinkin käytetään eri tilanteissa sovelluksen ajon aikana.[1] 2.4 Kehysmetodi suunnittelumalli Kehysmetodi-suunnittelumalli (kuva[4]) on perussuunnittelumalleja. Siinä määritellään yliluokka, jonka aliluokat perivät laajentaen ja muuttaen yliluokan toimintaa. kuva[4] Kehysmetodia käytetään laajasti ohjelmoinnissa. Itse asiassa tavallinen luokanperintä toteuttaa kehysmetodisuunnittelumallin. kuva[2] Tarkkailija suunnittelumalli sopii hyvin järjestelmiin, joissa järjestelmän tietyn olion tilan muuttuessa halutaan tiedottaa siitä järjestelmän muihin olioihin ilman että tarvitsee tietää minkälainen tämä olio on. Olion tarvitsee vain toteuttaa vaaditut Subject ja Observer rajapinnat. Tarkkailija on kaikkein yleisimmin käytetty suunnittelumalli. 2.3 Tehdasmetodi suunnittelumalli Tehdasmetodi suunnittelumallissa luodaan halutun yliluokan toteuttavia olioita algoritmin mukaan. Yksi 3 ALKUPERÄINEN OHJELMA Tein alkuperäisen ohjelman heinä-elokuussa Halusin kehittää ohjelmointitaitojani ja etsin siihen sopivaa haastetta. Keksin että voisin tehdä oman version klassisen Commotore 64 pelistä nimeltään Boulder Dash. Kyseinen peli tuntui sopivalta haasteelta kehittää ohjelmointitaitojani.

4 3.1 Mikä on Boulder Dash? kuva[5] Boulder Dash (kuva[5] ja kuva[6]) on kaksiulotteinen toiminnallinen pulmanratkontapeli, jossa pelaaja kaivautuu kentän läpi keräten tietyn määrän timantteja päästäkseen seuraavaan kenttään. 3.2 Lopputulos Ohjelmoin Boulder Dash pelin Java-ohjelmointikielellä. Tuolloin en varsinaisesti suunnitellut ohjelmaa, vaan koostin sen askel askeleelta kehittäen siihen vaadittuja ominaisuuksia, joita olin siihen määritellyt vaatimusmäärittelyssä. Tuloksena oli vaatimusmäärittelyn toiminnallisenmäärittelyn kohtuudella täyttävä, mutta laatuvaatimukset huonosti toteuttava ohjelma, jonka koodia ulkopuolisten oli vaikea ymmärtää. Sovelluksen koodissa ei juurikaan ollut mitään rakennetta, enkä käyttänyt edes olio-ohjelmoinnin yleisiä perusperiaatteita, joita on esimerkiksi periminen ja kapselointi sekä saman olion käyttö useassa kohteessa. Vaan loin jokaista toiminnallisuutta varten oman olion, joka oli hyvin monesti hyvin samanlainen jo toteuttamieni olioiden kanssa. Myös sellaiset käsitteet kuin komponentti ja rajapinta olivat minulle tuntemattomia. Kuitenkin huonoin sovellusarkkitehtuurin (kuva[7]) ratkaisu oli se että, suurin osa koodista sijaitsi yhdessä luokassa nimeltään Peli. Tämä teki Peli-luokasta todella suuren ja vaikeasti ymmärrettävän. Arkkitehtuuri kannalta sovelluksen luokat olivat tiukasti sidottu toisiinsa (vertaa periaate 3). Eikä sen koodia voinut siksi käyttää muissa ohjelmissa. Koodi oli muutenkin epäjohdonmukaista ja huonosti suunniteltua. Alkuperäisen ohjelman sovellus-arkkitehtuuri on kuvassa 7. kuva[6] kuva[7] 3.3 Ajatus uudenversion kehitystyöhön Ajatus uuden version tekemiseen syntyi, kun aloin perehtymään sellaisiin ohjelmoinnissa keskeisiin käsitteisiin kuin monisäikeisyys, rajapinta, komponentti ja ennen kaikkea suunnittelumallit. Opin myös monia

5 yleisiä ohjelmoinnin periaatteita, joita kannattaa soveltaa ohjelmien kehityksessä. Ymmärsin pystyisin tekemään ohjelmasta laatuvaatimukset paremmin toteuttavan version. 4 OHJELMAN UUDELLEENKEHITYS KÄYTTÄEN SUUNNITTELUMALLEJA Vaatimusmäärittelyn pohjalta tein arkkitehtuurisuunnitelman, jossa päädyin käyttämään seuraavia suunnittelumalleja Tehdasmetodi, Tila, Kehysmetodi sekä Tarkkailija. Käytän myös modernin ohjelmistokehityksen yleisiä periaatteita ohjelman toteutuksessa. Myös Java Code Conventions tyylioppisääntöjä käyttäminen muuttujien ja luokkien nimeämiseen on tärkeää saadakseni ohjelmasta enemmän standartien ja käytäntöjen mukaiseksi, tämä tekee ohjelmasta ymmärrettävämmän. Ohjelman suoritus tulee myös jakaantumaan usealle säikeelle. Uudistettu sovellusarkkitehtuuri näkyy kuvassa Uuden sovellusarkkitehtuurin rakenne Uudessa arkkitehtuurissa (kuva[8]) on toteutettu Tarkkailija-suunnittelumallia Peli-luokan ja KäyttoLiittyma -luokan välillä, joka nimensä mukaisesti toimii käyttöliittymänä peliin. Peli luokka toteuttaa Subject-rajapinnan ja KayttoLiittyma-luokka toteuttaa Observer rajapinnan. Tämän suunnittelun suurin hyöty on se että Peli luokalla voi olla lukuisia erilaisia käyttöliittymiä, joita voidaan käyttää ja vaihtaa dynaamisesti ohjelman ajon aikana. Peli luokalla voi olla jopa useita käyttöliittymiä yhtä aikaa. Mutta on epäselvää onko tästä hyötyä tässä vaiheessa. kuva[8] KeyListener rajapinta (Interface) ja NappainKuuntelija luokka toteuttavat Kehysmetodi-suunnittelumallia. KeyListener rajapinnan toimintaa laajennetaan ja muutetaan NappainKuuntelija luokassa. Haamu ja TuliKarpanen luokissa on jäsenmuuttujina Liikkuminen niminen rajapinta tyyppinen jäsenmuuttuja sekä Liikkuminen liittymän toteuttaviin LiikkuuVasempaan ja LiikkuuOikeaan luokkiin viittaavia jäsenmuuttujia. Haamu ja TuliKarpanen vaihtavat Liikkuminen tyyppisen muuttujan viittaamaan ajon aikana dynaamisesti, joko LiikkuuVasempaan tai LiikkuuOikeaan luokasta muodostettuun olioon. Nämä luokat toteuttavat yhdessä Tila-suunnittelumallin. TehdasMetodi luokka toteuttaa luonnollisesti TehdasMetodi-suunnittelumallin. TehdasMetodiluokalla luodaan ohjelman ajon aikana dynaamisesti abstraktin PeliHahmo-luokan toteuttavia oliota (esimerkiksi Kivi, Haamu, TuliKarpanen). Sovelluksessa on nyt määritelty komponentteja, joita voi käyttää muissa ohjelmissa. Komponentti 1 on samalla käyttöliittymäkerros. Siinä on kaikki sovelluksen käyttöliittymään osat. Siihen ollaan yhteydessä tarkkailija-suunnittelumallin Observerrajapinnan kautta. Komponentti 2 taas tarjoaa rajapinnan kuunnella näppäin komentoja. Komponenttiin ollaan yhteydessä KeyListener rajapinnan kautta. Komponentti 3 tarjoaa erilaisia algoritmi ratkaisuja näytön komponenttien liikkumiseen. Sovellus voidaan myös jakaa eri kerroksiin monikerrosmallin mukaisesti. Yleisimmin käytetään kolme kerron arkkitehtuuria (three tier architecture), jossa sovellus on jaettu käyttöliittymä-, toimintalogiikka- ja infrastruktuuri kerroksiin. Tässä tapauksessa voidaan nähdä että sovellus on jakaantunut käyttöliittymä kerrokseen ja toimintalogiikka kerrokseen. Käyttöliittymä kerrokseen kuuluu KayttoLiittyma ja Observer luokat. Kaikkien muiden luokkien kuuluessa toimintalogiikka-kerrokseen. Kyseessä on kaksi kerros arkkitehtuuri. PeliHahmojenKasittely-luokka perii Runnable-luokan, joka mahdollistaa sen että metodien kutsut PeliHahmojenKasittely luokassa voidaan suorittaa omassa säikeessään käyttämällä run()-metodia. Sovelluksen suoritus on näin jaettu monelle säikeelle. 5 LOPPUTULOKSET Suunnittelumalleista oli hyötyä sekä ohjelman suunnittelussa ja sekä ohjelmoinnissa. 5.1 Suunnittelumallien vaikutus ohjelmointiprosessiin Suunnittelumallien hyöty sovelluksen kehityksessä tuli esiin jo sovelluksen arkkitehtuurin suunnittelu vaiheessa. Päätös käyttää jotain suunnittelumallia sovelluksen komponentin tekemiseen määrittelee pitkälti sen miten se rakennetaan ja toimii. Suunnittelumallien kautta voidaankin suullisesti ja dokumentaation kautta jakaa sellaista tietoa ohjelmointiprosessista, jota muuten on vaikea siirtää.

6 Itse sovelluksen ohjelmointiprosessin suunnittelumallin käyttäminen teki johdonmukaisen tavoitetietoisen tapahtuman, koska suunnittelumallin käyttö tietyn komponentin tekemiseen antaa viitekehyksen miten se rakennetaan. Kun komponentti rakennetaan ennalta määrätyllä tavalla vastaamaan toiminnallisuus vaatimuksia on eri suunnitteluratkaisujen vaikutus lopputulokseen paremmin ennakoitavissa. Eikä ohjelmoijan enää tarvitse ratkoa miten komponentti on parhainta rakentaa, näin säästetään paljon aikaa sovelluksen kehityksessä ja vähennetään mahdollisuutta ennalta odottamien ongelmien syntymiseen ohjelmaa kehitettäessä. 6 LÄHTEET [1]Immonen Mirja, Suunnittelumallit Kuopion yliopisto [2]Helsingin yliopisto, Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja ma_08-arkkitehtuurisuunnittelua.pdf [3]Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra 2004 Head First Design Patterns: O'Reilly Media 5.2 Suunnittelumallien vaikutus arkkitehtuurinsuunnitteluun Ohjelmointikontekstista katsottuna uusi arkkitehtuurisuunnittelu tekee ohjelmointiprosessista enemmän rajapintoja vastaan ohjelmointia ja on komponentteihin perustuvaa. Näin on toteutettu monia modernin ohjelmistokehityksen periaatteita, joita on esimerkiksi pyri löyhään sidontaan rajapintojen ja toteutusten välillä (periaate 3) sekä komponenttien sisäiset ratkaisut eivät näy rajapinnan ulkopuolelle (periaate 2). Lisäksi toiminnallisuutta voidaan tulevaisuudessa laajentaa tai muuttaa rajapintoja muokkaamalla. Ennemmin kuin muutettaisiin metodien toteutuksia (periaatteet 4, 5). Ohjelma on helpommin skaalattavissa ja sen komponentteja voidaan uudelleen käyttää muissa ohjelmissa, joissain tapauksissa eri ohjelmat voivat jopa jakaa saman komponentin. Ohjelmasta tulee paremmin tarkoitukseen sopiva, johdonmukaisempi, helpommin muiden ymmärrettävä. Lisäksi ohjelmistokehitysprojektissa sovelluksen kehitys voidaan jakaan komponentteihin, jonka kukin ohjelmoija voi tehdä itsenäisesti. Ohjelmoijan tarvitsee tietää vain komponenttien rajapinnat (periaate 8). Koostamalla (periaate 1) on voitu kapseloida se mikä eri luokissa muuttuu omiin luokkiinsa (periaate 6) näin on myös toteutettu modernin Java-ohjelmisto-kehityksen paradigma eli toiminnallisuuden määrittely (luokkien liittäminen toisiinsa) tapahtuu nyt ennemmin dynaamisesti ohjelman ajon aikana kuin staattisesti perimällä. Ohjelman sovellusarkkitehtuuri voidaan nyt myös jakaa toimintalogiikka- ja käyttöliittymäkerroksiin. Käyttöliittymäkerros ja toimintalogiikka kerrokset ovat yhteydessä keskenään Tarkkailija-suunnittelumallin rajapintojen kautta, näin sovellus täyttää periaatteen 7 ohjelmistokehitykseen liittyen. 5.3 Johtopäätökset Suunnittelumalleista oli paljon hyötyä ohjelman kehityksessä eri ohjelmistokehityksen eri vaiheissa ja arkkitehtuurin suunnittelussa.

Sokkelon sisältö säilötään linkitetyille listalle ja tekstitiedostoon. Työ tehdään itsenäisesti yhden hengen ryhmissä. Ideoita voi vaihtaa koodia ei.

Sokkelon sisältö säilötään linkitetyille listalle ja tekstitiedostoon. Työ tehdään itsenäisesti yhden hengen ryhmissä. Ideoita voi vaihtaa koodia ei. Harjoitustyö 1 Harjoitustyö Tehtävä: ohjelmoi olioperustainen sokkeloseikkailu peli Javakielellä. Sokkelon sisältö säilötään linkitetyille listalle ja tekstitiedostoon. Työ tehdään itsenäisesti yhden hengen

Lisätiedot

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VIII Suunnittelumallit Observer ja State

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VIII Suunnittelumallit Observer ja State 2015 syksy 2. vsk VIII Suunnittelumallit Observer ja State Sisältö 1. Johdanto käyttäytymismalleihin 2. Observer 3. State Suunnittelumallit Observer ja State 2 VIII.1 Johdanto käyttäytymismalleihin Päätarkoitus

Lisätiedot

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Rajapinnat ja sisäluokat

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Rajapinnat ja sisäluokat Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Rajapinnat ja sisäluokat Rajapinnat Java-kieli ei tue luokkien moniperintää. Jokaisella luokalla voi olla vain yksi välitön yliluokka. Toisinaan olisi

Lisätiedot

Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja

Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja 582104 Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja 1 Arkkitehtuurisuunnittelu Ohjelmistoarkkitehtuurin määritelmä & arkkitehtuurisuunnittelun lähtökohta ja tavoitteet Kerrosarkkitehtuuri

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

Olio-ohjelmointi Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton. 1. Proxy (Edustaja)

Olio-ohjelmointi Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton. 1. Proxy (Edustaja) Olio-ohjelmointi Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton Tässä osassa tutustutaan yhteen rakennemalliin (Proxy) ja kolmeen luontimalliin (Factory Method, ) teoksen [Gam] pohjalta.

Lisätiedot

Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä

Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä 582104 Ohjelmistojen mallintaminen luokkamallin lisäpiirteitä 1 Luokkamallin lisäpiirteitä Erilaiset yhteystyypit kooste kompositio Muita luokkien välisiä suhteita riippuvuudet periytyminen eli luokkahierarkia

Lisätiedot

UML:n yleiskatsaus. UML:n osat:

UML:n yleiskatsaus. UML:n osat: UML:n yleiskatsaus - voidaan hyödyntää hyvin laajasti. - sopii liiketoimintamallinnukseen, ohjelmistomallinnukseen sen jokaiseen vaiheeseen tai minkä tahansa pysyviä ja muuttuvia ominaisuuksia sisältävän

Lisätiedot

Muusta kuin vesisioista

Muusta kuin vesisioista Muusta kuin vesisioista Janne Käki 8.12.2006 Metodin kuormittaminen (overloading) Samannimisestä metodista on määritelty samassa luokassa (tai samassa yli- ja aliluokkien jatkumossa) useita versioita,

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

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. II Johdanto olio-ohjelmointiin

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. II Johdanto olio-ohjelmointiin 812347A Olio-ohjelmointi, 2015 syksy 2. vsk II Johdanto olio-ohjelmointiin Sisältö 1. Abstraktiosta 2. Olio-ohjelmoinnin historiaa 3. Olioparadigmasta 4. Peruskäsitteiden esittely 2 II.1 Abstraktiosta

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

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

Olio-ohjelmointi Johdanto suunnittelumalleihin. 1. Yleistä

Olio-ohjelmointi Johdanto suunnittelumalleihin. 1. Yleistä Olio-ohjelmointi Johdanto suunnittelumalleihin Hyvin toimivan olio-ohjelmointiparadigmaa noudattavan ohjelman suunnitteleminen ei ole helppo tehtävä. On löydettävä sopiva luokkarakenne kuvaamaan ratkaistavaa

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

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VII Suunnittelumallit Adapter ja Composite

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VII Suunnittelumallit Adapter ja Composite 2015 syksy 2. vsk VII Suunnittelumallit Adapter ja Composite Sisältö 1. Johdanto rakennemalleihin 2. Adapter (Sovitin) 3. Composite (Rekursiokooste) Suunnittelumallit Adapter ja Composite 2 VII.1 Johdanto

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

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

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

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

812341A Olio-ohjelmointi Peruskäsitteet jatkoa

812341A Olio-ohjelmointi Peruskäsitteet jatkoa 812341A Olio-ohjelmointi 2106 Peruskäsitteet jatkoa Luokkakohtaiset piirteet n Yhteisiä kaikille saman luokan olioille n Liittyvät luokkaan, eivät yksittäiseen olioon n Kaikki ko. luokan oliot voivat käyttää

Lisätiedot

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Tällä kurssilla on tutustuttu ohjelmistojen mallintamiseen oliomenetelmiä ja UML:ää käyttäen Samaan aikaan järjestetyllä kurssilla on käsitelty

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

Rajapinnat ja olioiden välittäminen

Rajapinnat ja olioiden välittäminen Rajapinnat ja olioiden välittäminen Moduulit/oliot kutsuvat toisiaan kapseloitujen rajapintojen läpi Kutsuissa välitetään usein olioita paikasta toiseen Jos olion omistus (= tuhoamisvastuu) säilyy koko

Lisätiedot

7/20: Paketti kasassa ensimmäistä kertaa

7/20: Paketti kasassa ensimmäistä kertaa Ohjelmointi 1 / syksy 2007 7/20: Paketti kasassa ensimmäistä kertaa Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007

Lisätiedot

A) on käytännöllinen ohjelmointitekniikka. = laajennetaan aikaisemmin tehtyjä luokkia (uudelleenkäytettävyys)

A) on käytännöllinen ohjelmointitekniikka. = laajennetaan aikaisemmin tehtyjä luokkia (uudelleenkäytettävyys) 1(37) PERIYTYMINEN (inheritance) YLILUOKKA (superclass) ALILUOKKA (subclass) A) on käytännöllinen ohjelmointitekniikka = laajennetaan aikaisemmin tehtyjä luokkia (uudelleenkäytettävyys) B) on käsitteiden

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

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 Henkilökohtainen harjoitus: FASTAXON

T Henkilökohtainen harjoitus: FASTAXON T-76.115 Henkilökohtainen harjoitus: FASTAXON Suunnittelumallit Group: Muuntaja Pentti Vänskä 52572W 2 1. Toteutus Tämä henkilökohtainen harjoitustyö käsitteli suunnittelumallien (Design Patterns) käyttöä

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

18. Abstraktit tietotyypit 18.1

18. Abstraktit tietotyypit 18.1 18. Abstraktit tietotyypit 18.1 Sisällys Johdanto abstrakteihin tietotyyppeihin. Pino ja jono. Linkitetty lista. Pino linkitetyllä listalla toteutettuna. 18.2 Johdanto Javan omat tietotyypit ovat jo tuttuja:

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia tehtäviä:

Lisätiedot

812341A Olio-ohjelmointi, IX Olioiden välisistä yhteyksistä

812341A Olio-ohjelmointi, IX Olioiden välisistä yhteyksistä 2016 IX Olioiden välisistä yhteyksistä Sisältö 1. Johdanto 2. Kytkentä 3. Koheesio 4. Näkyvyydestä 2 Johdanto n Ohjelmassa syntyy kytkentöjä olioiden välille Toivottuja ja epätoivottuja n Näkyvyys vaikuttaa

Lisätiedot

Hirviö. Design Patterns

Hirviö. Design Patterns Hirviö SEPA-päiväkirja Design Patterns Anssi Kalliolahti Liia Sarjakoski 8. helmikuuta 2005 1 Sisältö 1 Johdanto 3 2 Menetelmän käytäntöön soveltaminen 3 3 Kokemuksia ja muutoksia 3 3.1 PP..........................................

Lisätiedot

JavaRMI 1 JAVA RMI. Rinnakkaisohjelmoinnin projekti 1 osa C Tekijät: Taru Itäpelto-Hu Jaakko Nissi Mikko Ikävalko

JavaRMI 1 JAVA RMI. Rinnakkaisohjelmoinnin projekti 1 osa C Tekijät: Taru Itäpelto-Hu Jaakko Nissi Mikko Ikävalko JavaRMI 1 JAVA RMI Rinnakkaisohjelmoinnin projekti 1 osa C Tekijät: Taru Itäpelto-Hu Jaakko Nissi Mikko Ikävalko JavaRMI 2 Table of Contents...1 JAVA RMI...1 Yleistä...4 Arkkitehtuuri...5 Java RMI kerrosarkkitehtuuri...5

Lisätiedot

Sonera Viestintäpalvelu VIP

Sonera Viestintäpalvelu VIP Sonera Viestintäpalvelu VIP Loma- ja Poissaoloviestitoiminnallisuuden käyttöopas v 1.2 Toiminnallisuuden kuvaus Poissaoloviestin aktivoit päälle suorittamalla seuraavat toimenpiteet: Valitse aktiviteetiksesi

Lisätiedot

Ohjelmistotekniikan menetelmät, UML

Ohjelmistotekniikan menetelmät, UML 582101 - Ohjelmistotekniikan menetelmät, UML 1 Sisältö DFD- ja sidosryhmäkaavioiden kertaus Oliomallinnus UML:än kaaviotyypit 2 Tietovuokaaviot Data flow diagrams, DFD Historiallisesti käytetyin kuvaustekniikka

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

Suunnittelumalleja, MVC. Juha Järvensivu 2008

Suunnittelumalleja, MVC. Juha Järvensivu 2008 Suunnittelumalleja, MVC Juha Järvensivu juha.jarvensivu@tut.fi 2008 Sisältö Tarkkailija Strategia Rekursiokooste Tehdas-metodi MVC Tarkkailija suunnittelumalli Tarkkailijamalli (Observer) Määrittelee olioiden

Lisätiedot

Osio 4: Graafinen käyttöliittymä

Osio 4: Graafinen käyttöliittymä Javan Swing-tekniikan perusteet: Muistutus: Tarvitset seuraavia komponentteja harjoituksissa: otsikkoteksti (label) muokkausruutu (text field) komentopainike (button) yhdistelmäruutu (combo box) paneeli

Lisätiedot

Harjoitustehtävät ja ratkaisut viikolle 48

Harjoitustehtävät ja ratkaisut viikolle 48 Harjoitustehtävät ja ratkaisut viikolle 48 1. Tehtävä on jatkoa aiemmalle tehtävälle viikolta 42, missä piti suunnitella älykodin arkkitehtuuri käyttäen vain ennalta annettua joukkoa ratkaisuja. Tämäkin

Lisätiedot

6. Suunnittelu. Suunnittelun tulos

6. Suunnittelu. Suunnittelun tulos 6. Suunnittelu Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja. Tavoitteena on

Lisätiedot

Suunnittelun tulos. 6. Suunnittelu. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi. 6.1 Arkkitehtuurisuunnittelu.

Suunnittelun tulos. 6. Suunnittelu. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi. 6.1 Arkkitehtuurisuunnittelu. 6. Suunnittelu Suunnittelun tulos Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja.

Lisätiedot

SEPA - Design Patterns

SEPA - Design Patterns SEPA - Design Patterns Kimmo Karlsson, 51066R & Antti Pirinen, 51406N 15. maaliskuuta 2005 1 Sisältö 1. Sisältö 2. Johdanto 3. Käyttöönotto 4. Käyttökokemukset 2 Johdanto Valitsemamme ohjelmistonkehityskäytäntö

Lisätiedot

Sonera Viestintäpalvelu VIP

Sonera Viestintäpalvelu VIP Sonera Viestintäpalvelu VIP Loma- ja Poissaoloviestitoiminnallisuuden käyttöopas v 1.2 Toiminnallisuuden kuvaus Poissaoloviestin aktivoit päälle suorittamalla seuraavat toimenpiteet: Valitse aktiviteetiksesi

Lisätiedot

Ohjelmistotekniikan menetelmät, arkkitehtuuria ja rajapintoja

Ohjelmistotekniikan menetelmät, arkkitehtuuria ja rajapintoja 582101 - Ohjelmistotekniikan menetelmät, arkkitehtuuria ja rajapintoja 1 Arkkitehtuurisuunnittelu Ohjelmistoarkkitehtuurin määritelmä & arkkitehtuurisuunnittelun lähtökohta ja tavoitteet Kerrosarkkitehtuuri

Lisätiedot

Tietojärjestelmien integroiminen hyödyntämällä palvelupohjaista arkkitehtuuria. CASE: Metropolia. Jaakko Rannila & Tuomas Orama 1

Tietojärjestelmien integroiminen hyödyntämällä palvelupohjaista arkkitehtuuria. CASE: Metropolia. Jaakko Rannila & Tuomas Orama 1 Tietojärjestelmien integroiminen hyödyntämällä palvelupohjaista arkkitehtuuria CASE: Metropolia 31.10.2012 Jaakko Rannila & Tuomas Orama 1 Aiheet Tietojärjestelmien integrointi Integrointiin liittyvät

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 1.0 19.10.2007 Suanto 0.3 18.10.2007 Matti Eerola 0.2 17.10.2007

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

KODU. Lumijoen peruskoulu

KODU. Lumijoen peruskoulu KODU Lumijoen peruskoulu Sisällysluettelo 1. Aloitus... 2 1.1 Pelin tallennuspaikka... 2 1.2 Kodu Game lab... 3 2 Maan luominen... 4 2.1. Seinän tekeminen... 5 2.2. Vesialueen tekeminen peliin... 6 2.3.

Lisätiedot

CODEONLINE. Monni Oo- ja Java-harjoituksia. Version 1.0

CODEONLINE. Monni Oo- ja Java-harjoituksia. Version 1.0 CODEONLINE Monni Oo- ja Java-harjoituksia Version 1.0 Revision History Date Version Description Author 25.10.2000 1.0 Initial version Juha Johansson Inspection History Date Version Inspectors Approved

Lisätiedot

Työ tehdään itsenäisesti yhden hengen ryhmissä. Ideoita voi vaihtaa koodia ei.

Työ tehdään itsenäisesti yhden hengen ryhmissä. Ideoita voi vaihtaa koodia ei. Harjoitustyö 1 Harjoitustyö Tehtävä: ohjelmoi lötköjen kansoittamaa alkulimaa simuloiva olioperustainen ohjelma Java-kielellä. Lötköt säilötään linkitetyille listalle ja tekstitiedostoon. Työ tehdään itsenäisesti

Lisätiedot

Javan perusteita. Janne Käki

Javan perusteita. Janne Käki Javan perusteita Janne Käki 20.9.2006 Muutama perusasia Tietokone tekee juuri (ja vain) sen, mitä käsketään. Tietokone ymmärtää vain syntaksia (sanojen kirjoitusasua), ei semantiikkaa (sanojen merkitystä).

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

Olio-ohjelmointi Suunnittelumallit Observer ja State. 1. Observer (Tarkkailija)

Olio-ohjelmointi Suunnittelumallit Observer ja State. 1. Observer (Tarkkailija) Olio-ohjelmointi Suunnittelumallit Observer ja State Käyttäytymismallien päätarkoitus on algoritmien toteuttaminen ja vastuiden jakaminen olioiden välillä. Näin ollen käyttäytymismallit kuvaavat luokkien

Lisätiedot

Ohjelmoinnin perusteet Y Python

Ohjelmoinnin perusteet Y Python Ohjelmoinnin perusteet Y Python T-106.1208 15.3.2010 T-106.1208 Ohjelmoinnin perusteet Y 15.3.2010 1 / 56 Tiedostoista: tietojen tallentaminen ohjelman suorituskertojen välillä Monissa sovelluksissa ohjelman

Lisätiedot

TIE-20200 Ohjelmistojen suunnittelu

TIE-20200 Ohjelmistojen suunnittelu TIE-20200 Ohjelmistojen suunnittelu Luento 1: Virtuaalifunktiot, Template method 1 Yleistä asiaa Muistakaa harkkatyöilmoittautuminen 23 ryhmää (mm. lihansyöjäkirahvi), vajaita ryhmiäkin on 44 henkeä vielä

Lisätiedot

20. Javan omat luokat 20.1

20. Javan omat luokat 20.1 20. Javan omat luokat 20.1 Sisällys Application Programming Interface (API). Pakkaukset. Merkkijonoluokka String. Math-luokka. Kääreluokat. 20.2 Java API Java-kielen Application Programming Interface (API)

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

Sisällys. 20. Javan omat luokat. Java API. Pakkaukset. java\lang

Sisällys. 20. Javan omat luokat. Java API. Pakkaukset. java\lang Sisällys 20. Javan omat luokat Application Programming Interface (API). Pakkaukset. Merkkijonoluokka String. Math-luokka. Kääreluokat. 20.1 20.2 Java API Java-kielen Application Programming Interface (API)

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

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

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Olioiden yhteistoiminta

Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Olioiden yhteistoiminta Opintojakso TT00AA11 Ohjelmoinnin jatko (Java): 3 op Olioiden yhteistoiminta Tausta Rectangle - length : double - width : double + Rectangle() + Rectangle(len : double, wid : double) + setlength(len :

Lisätiedot

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena Ohjelmointikielet ja -paradigmat 5op Markus Norrena Ko#tehtävä 4 Viimeistele "alkeellinen kuvagalleria". Käytännössä kaksi sivua Yksi jolla voi ladata kuvia palvelimelle (file upload) Toinen jolla ladattuja

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

Paikkatiedon mallinnus Dokumentoinnin ymmärtäminen. Lassi Lehto

Paikkatiedon mallinnus Dokumentoinnin ymmärtäminen. Lassi Lehto Paikkatiedon mallinnus Dokumentoinnin ymmärtäminen Lassi Lehto INSPIRE-seminaari 23.08.2012 Sisältö Tietotuoteselosteen rakenne (ISO 19131) Unified Modeling Language (UML) Luokkakaaviotekniikan perusteet

Lisätiedot

Yhdessä tehden, oppien ja yrittäen -peli

Yhdessä tehden, oppien ja yrittäen -peli Yhdessä tehden, oppien ja yrittäen -peli PELIOHJEET JOHDANTO Yhdessä tehden, oppien ja yrittäen -pelin tarkoituksena on oppia uutta mielekkäällä ja hauskalla tavalla. Pelissä ei varsinaisesti ole voittajaa,

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia tehtäviä:

Lisätiedot

Ohjelmistojen mallintaminen Unified Modeling Language (UML)

Ohjelmistojen mallintaminen Unified Modeling Language (UML) 582104 Ohjelmistojen mallintaminen Unified Modeling Language (UML) 1 Olioperustaisuus Olio toimii mallinnuksen perusyksikkönä eri abstraktiotasoilla Järjestelmän rajaus, suunnittelu, ohjelmointi, suoritus..

Lisätiedot

12. Monimuotoisuus 12.1

12. Monimuotoisuus 12.1 12. Monimuotoisuus 12.1 Sisällys Johdanto. Periytymismekanismi määrittää alityypityksen. Viitteiden sijoitus ja vertailu. Staattinen ja dynaaminen luokka. Parametrinvälitys eräs monimuotoisuuden sovellus.

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

Sisällys. JAVA-OHJELMOINTI Osa 6: Periytyminen ja näkyvyys. Luokkahierarkia. Periytyminen (inheritance)

Sisällys. JAVA-OHJELMOINTI Osa 6: Periytyminen ja näkyvyys. Luokkahierarkia. Periytyminen (inheritance) Sisällys JAVA-OHJELMOINTI Osa 6: Periytyminen ja näkyvyys Periytyminen (inheritance) Näkyvyys (visibility) Eero Hyvönen Tietojenkäsittelytieteen laitos Helsingin yliopisto 13.10.2000 E. Hyvönen: Java Osa

Lisätiedot

815338A Ohjelmointikielten periaatteet 2015-2016. Harjoitus 5 Vastaukset

815338A Ohjelmointikielten periaatteet 2015-2016. Harjoitus 5 Vastaukset 815338A Ohjelmointikielten periaatteet 2015-2016. Harjoitus 5 Vastaukset Harjoituksen aiheena ovat aliohjelmat ja abstraktit tietotyypit sekä olio-ohjelmointi. Tehtävät tehdään C-, C++- ja Java-kielillä.

Lisätiedot

Pong-peli, vaihe Aliohjelmakutsu laskureita varten. 2. Laskurin luominen. Muilla kielillä: English Suomi

Pong-peli, vaihe Aliohjelmakutsu laskureita varten. 2. Laskurin luominen. Muilla kielillä: English Suomi Muilla kielillä: English Suomi Pong-peli, vaihe 7 Tässä vaiheessa lisäämme peliin pistelaskun. Pong-pelissä pelaaja saa pisteen kun pallo ohittaa toisen pelaajan mailan. 1. Aliohjelmakutsu laskureita varten

Lisätiedot

Kurssin sisältö. Kurssilla vähemmän. Johdatus ohjelmistotekniikkaan. Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan?

Kurssin sisältö. Kurssilla vähemmän. Johdatus ohjelmistotekniikkaan. Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan? Kurssin sisältö Johdatus ohjelmistotekniikkaan 2 0 0 8 Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan? Mitä työkaluja ohjelmistoja kehitettäessä käytetään ja miten? Historiaa

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

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Epäonnistuneen ohjelmistoarkkitehtuurin seurauksia 1.4 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi

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

Ohjelmistojen mallintaminen, suunnittelumalleja

Ohjelmistojen mallintaminen, suunnittelumalleja 582104 Ohjelmistojen mallintaminen, suunnittelumalleja 1 Suunnittelumallit (design patterns) Kuvaus sellaisesta luokkarakenteesta & olioiden vuorovaikutuksesta, joka ratkaisee tietyn yleisen ongelman tiettyjen

Lisätiedot

Kehitysohje. ETL-työkalu. ExtraTerrestriaLs / Aureolis Oy

Kehitysohje. ETL-työkalu. ExtraTerrestriaLs / Aureolis Oy Kehitysohje ETL-työkalu Versio Pvm Tekijä Kuvaus 0.1 15.1.2005 Timo Sallinen Ensimmäinen versio 0.2 26.1.2005 Timo Sallinen Täydenetty pohjaa 0.3 06.02.2005 Mika Suvanto Pieniä täydennyksiä ja oikolukua

Lisätiedot

Mikä sitten on kallista? Milloin raha on viisaasti käytetty? Miten kallis määritellään toimintopistelaskennan näkökulmasta?

Mikä sitten on kallista? Milloin raha on viisaasti käytetty? Miten kallis määritellään toimintopistelaskennan näkökulmasta? Mikä sitten on kallista? Milloin raha on viisaasti käytetty? Miten kallis määritellään toimintopistelaskennan näkökulmasta? ICT hyödyttämään liiketoimintaa siis oikeesti ja vähän äkkiä Mikko Paalasmaa,

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

Ohjelmoinnin peruskurssien laaja oppimäärä

Ohjelmoinnin peruskurssien laaja oppimäärä Ohjelmoinnin peruskurssien laaja oppimäärä Luento 7: Olio-ohjelmointia: UML ja suunnittelumallit Riku Saikkonen (osa kalvoista on suoraan ei-laajan kurssin luennoista) 14. 3. 2012 Sisältö 1 UML-luokkakaaviot

Lisätiedot

2. Olio-ohjelmoinista lyhyesti 2.1

2. Olio-ohjelmoinista lyhyesti 2.1 2. Olio-ohjelmoinista lyhyesti 2.1 Sisällys Yleistä. Oliot ja luokat. Attribuutit. Olioiden esittely ja alustus. Rakentajat. Olion operaation kutsuminen. 2.2 Yleistä Olio-ohjelmointia käsitellään hyvin

Lisätiedot

on ohjelmoijan itse tekemä tietotyyppi, joka kuvaa käsitettä

on ohjelmoijan itse tekemä tietotyyppi, joka kuvaa käsitettä LUOKAN MÄÄRITTELY Luokka, mitä se sisältää Luokan määrittely Olion ominaisuudet eli attribuutit Olion metodit Olion muodostimet ja luonti Olion tuhoutuminen Metodin kutsu luokan ulkopuolelta Olion kopioiminen

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

Olio-ohjelmointi Suunnittelumallit Adapter ja Composite. 1. Adapter

Olio-ohjelmointi Suunnittelumallit Adapter ja Composite. 1. Adapter Olio-ohjelmointi Suunnittelumallit Adapter ja Composite Rakennemalleissa päähuomio kohdistetaan siihen, miten luokkia ja olioita yhdistellään muodostamaan laajempia rakenteita. Rakenteelliset luokkamallit

Lisätiedot

815338A Ohjelmointikielten periaatteet

815338A Ohjelmointikielten periaatteet 815338A Ohjelmointikielten periaatteet 2015-2016 V Abstraktit tietotyypit ja olioohjelmointi Sisältö I. Abstraktit tietotyypit II. 1. Johdatus abstrakteihin tietotyyppeihin 2. Abstraktit tietotyypit Adassa

Lisätiedot

AutoCAD-natiiviobjektin toteutus

AutoCAD-natiiviobjektin toteutus AutoCAD-natiiviobjektin toteutus Kontiotuote OY Maailman toiseksi suurin hirsitalotoimittaja Aloittanut toimintansa 70-luvulla Liikevaihto vuonna 2003-37,355 Milj. euroa josta vientiä 7,376 Milj. euroa

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

KERROSARKKITEHTUURIN SUUNNITTELUMALLIT. Kuisma Lehtonen. 15.8.2006 Joensuun yliopisto Tietojenkäsittelytiede Pro gradu -tutkielma

KERROSARKKITEHTUURIN SUUNNITTELUMALLIT. Kuisma Lehtonen. 15.8.2006 Joensuun yliopisto Tietojenkäsittelytiede Pro gradu -tutkielma KERROSARKKITEHTUURIN SUUNNITTELUMALLIT Kuisma Lehtonen 15.8.2006 Joensuun yliopisto Tietojenkäsittelytiede Pro gradu -tutkielma TIIVISTELMÄ Suunnittelumallit ovat yleisiä ratkaisuja tiettyihin oliopohjaisiin

Lisätiedot

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

HOJ J2EE & EJB & SOAP &...

HOJ J2EE & EJB & SOAP &... HOJ J2EE & EJB & SOAP &... Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/18 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 582101 - Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 1 Toteutuksesta ja testauksesta Suunnitteluprosessista Tarkan tason luokkasuunnittelu Siirtyminen UML-kaavioista Java-toteutukseen

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

4. Lausekielinen ohjelmointi 4.1

4. Lausekielinen ohjelmointi 4.1 4. Lausekielinen ohjelmointi 4.1 Sisällys Konekieli, symbolinen konekieli ja lausekieli. Lausekielestä konekieleksi: - Lähdekoodi, tekstitiedosto ja tekstieditorit. - Kääntäminen ja tulkinta. - Kääntäminen,

Lisätiedot

Ohjelmointi 1 C#, kevät 2013, 2. tentti

Ohjelmointi 1 C#, kevät 2013, 2. tentti ITKP102 Ohjelmointi 1 C# 15.5.2013 1 / 6 Ohjelmointi 1 C#, kevät 2013, 2. tentti Tentaattori Antti-Jussi Lakanen Tässä tentissä saa olla mukana omia muistiinpanoja yhden arkin verran. Tentin valvojalla

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

Ikivihreä kirjasto loppuraportti määrittelyprojektille

Ikivihreä kirjasto loppuraportti määrittelyprojektille loppuraportti määrittelyprojektille Mikkelin Ammattikorkeakoulu Oy Sähkö ja informaatiotekniikan laitos Versiomuutokset 29.1.2014 viimeisin tilanne tietokantakonversiosta Mirja Loponen 7.2.2014 tarkennettu

Lisätiedot

Tavallisimmat kysymykset

Tavallisimmat kysymykset Autodesk Design- ja Creation Suite -paketit Tavallisimmat kysymykset Tässä dokumentissa on vastauksia tavallisimpiin kysymyksiin Design- ja Creation Suite -pakettien myynnin loppumisesta. 24.5.2016 Sisällysluettelo

Lisätiedot