Olio-ohjelmointi Johdanto suunnittelumalleihin. 1. Yleistä
|
|
- Risto Järvenpää
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Olio-ohjelmointi Johdanto suunnittelumalleihin Hyvin toimivan olio-ohjelmointiparadigmaa noudattavan ohjelman suunnitteleminen ei ole helppo tehtävä. On löydettävä sopiva luokkarakenne kuvaamaan ratkaistavaa ohjelmointiongelmaa ja toteutettava luokkien väliset suhteet asianmukaisesti. Kokeneet suunnittelijat pyrkivät ratkaisemaan ongelmat niin, että ratkaisu olisi sovellettavissa myös muihin samankaltaisiin tilanteisiin. Kun ratkaisu kuvataan sopivasti, syntyy suunnittelumalli. Tässä esitettävät asiat perustuvat pääasiassa lähteisiin [Bud] (luku 24) ja [Gam]. Viimeksi mainittu kuvaa 23 suunnittelumallia, joista on tullut alan standardeja. Tässä dokumentissa esitetään enimmäkseen asioita, joihin perehdytään myös kurssilla Oliosuuntautunut analyysi ja suunnittelu. 1. Yleistä Suunnittelumalleja on käytetty eri yhteyksissä hyvin kauan. Systemaattisen mallien kuvauksen alkuna voidaan pitää Alexanderin 1970-luvulla luomaa mallikieltä, jota käytettiin rakennusten ja kaavoitusten suunnittelussa ([Ale]). Olio-ohjelmointimalleja voidaan tunnistaa ainakin jo luvulta, jolloin Smalltalk-ympäristön graafisen käyttöliittymän toteutuksessa käytettiin ns. Model-View-Controller-mallia. Siitä voidaan eristää ainakin kaksi yleistä suunnittelumallia. Olio-ohjelmoinnissa sovellettavien mallien kuvauksia alettiin julkaista 1990-luvulla; merkittävin teos tältä ajalta on ns. Gang of Fourin (Gamma, Helm, Johnson, Vlissides) julkaisu Design Patterns: Elements of Reusable Object-Oriented Software ([Gam]). Suunnittelumallista voidaan tunnistaa yleensä seuraavat neljä pääosaa: 1. Mallilla on oltava osuva nimi, jota käytetään siitä puhuttaessa. Nimen täytyy liittyä mallin ominaispiirteisiin. Tällöin nimi lisää sanastoa, jota käytetään kommunikoitaessa toisten suunnittelijoiden kanssa. 2. Malliin liittyvä ongelma kuvaa tilanteita, joihin mallia voi soveltaa. Voidaan kuvata tiettyjä, mallin avulla ratkeavia suunnitteluongelmia tai hankalia luokkarakenteita, joita mallin käyttäminen parantaa. Voidaan myös antaa ehtoja, joiden vallitessa mallia on järkevää käyttää. 3. Ratkaisu kuvaa mallin olennaiset osat, niiden suhteet, vastuut ja yhteistoiminnan. Yleensä ei kuvata konkreettista toteutusta, vaan annetaan abstrakti kuvaus siitä, miten luokkien ja olioiden rakenne ja toiminta ratkaisee suunnitteluongelman. 4. Seuraukset kuvaavat mihin ratkaisun soveltaminen johtaa ja minkälaisia kompromisseja sen soveltaminen aiheuttaa. Nämä on huomioitava ratkaisumallia valittaessa. Riippuu näkökulmasta ja käytettävistä välineistä, mitä voidaan pitää suunnittelumallina. Jos olisimme tuomitut käyttämään ei-oliokieltä, saattaisivat periytyminen ja monimuotoisuus olla suunnittelumalleja. Koska käytössä on kieliä, joissa ne ovat perusrakenneosia, ei mainittuja asioita yleensä pidetä malleina. Näin ollen valittu ohjelmointikieli vaikuttaa käytettäviin malleihin, koska kielen valinta vaikuttaa näkökulmaan, josta ongelmaa tarkastellaan. Toisaalta myöskään hyvin monimutkaisia ohjelman kuvauksia ei lasketa malleiksi. Tässä käsiteltävät suunnittelumallit kuvaavat rakenteen, jonka luokat ja oliot yhteistyöllään ratkaisevat jonkin yleisen, tietyssä yhteydessä esiintyvän ongelman. 1
2 2. MVC-malli 1980-luvulla esitellyssä Smalltalk-ohjelmointijärjestelmässä käytettiin ns. MVC (Model-View- Controller)-mallia käyttöliittymän rakentamisessa. Malli koostuu luokkien kolmikosta, jonka toiminta sisältää ainakin kahdenlaisia suunnittelumalleja. Model on sovellusolio, View on ruudun näkymä ja Controller määrittelee tavat, joilla käyttöliittymä reagoi käyttäjän syötteisiin. MVC-mallin perusidea on eristää nämä kolme oliota toisistaan. Näkymä ja malli erotetaan toisistaan toteuttamalla luokkien välille rekisteröitymiseen ja ilmoittamiseen perustuva protokolla. Samaa mallia voi vastata useita näkymiä, jotka rekisteröityvät tietyn mallin tarkkailijoiksi. Kun malli muuttuu, Controller ilmoittaa muutoksesta kaikille mallin tarkkailijoille, jotka voivat päivittää itsensä vastaamaan mallin tilaa. Esimerkiksi seuraavassa kuviossa mallia tarkkailee kolme näkymää. Kuvioon ei ole merkitty Controlleria. Kuva 1. Esimerkki MVC-mallista. (Lähde: [Gam]) Asetelma voidaan yleistää tilanteeseen, jossa eristetään oliot toisistaan siten, että muutos yhden olion tilassa vaikuttaa muiden olioiden tiloihin. Näin syntyykin suunnittelumalli, joka on sovellettavissa moniin tapauksiin. Tätä mallia kutsutaan Tarkkailija- eli Observersuunnittelumalliksi. Käyttöliittymä koostuu tyypillisesti komponenteista, jotka sisältävät käyttöliittymäelementtejä. Monimutkaisissa käyttöliittymissä komponenttien sisältämät elementit voivat olla edelleen komponentteja, jotka sisältävät käyttöliittymäelementtejä jne. MVC-mallissa näkymät voivat tämän vuoksi sisältyä toisiin näkymiin ja yhdistettyjä näkymiä käsitellään niin kuin yksinkertaisia komponenttejakin. Tämäkin asetelma voidaan yleistää: Toteutetaan luokkarakenne, jonka olioiden muodostamia ryhmiä voidaan käsitellä kuten yksittäistä oliota. Taas kehittyy monissa yhteyksissä sovellettava suunnittelumalli, ns. Kooste- eli Composite- 2
3 malli. MVC-mallin rakenteesta voidaan tunnistaa muitakin hyväksi havaittuja suunnittelumalleja (ks. esim. [Gam], Introduction - Design Patterns in Smalltalk MVC). 3. Suunnittelumallin kuvaaminen Kun suunnittelumalli on tunnistettu, se on pystyttävä kuvaamaan riittävän hyvin, jotta muutkin voivat käyttää mallia. Yleensä malli kuvataan luonnollisella kielellä, jota täydennetään UMLkaavioilla sekä esimerkkikoodilla. Alla on mainittu tärkeimmät Gamman et. al. ([Gam]) mallista kuvaamat seikat Mallin nimi ja luokittelu Hyvin valittu nimi auttaa mallin tunnistamisessa ja siitä puhumisessa. Gamma et. al. jakavat mallit olioiden luomiseen liittyviin malleihin, rakenteellisiin malleihin ja käyttäytymiseen liittyviin malleihin. Tarkoitus Lyhyt kuvaus mallin toiminnasta ja siitä, minkälaisiin suunnitteluongelmiin se soveltuu ratkaisuksi. Perustelu Skenaario, joka kuvaa millä tavoin luokkien ja olioiden rakenne ratkaisee suunnitteluongelman. Soveltuvuus Kuvaa tilanteita, joihin mallia voidaan soveltaa. Rakenne Mallin luokkakaavio. Saattaa myös sisältää vuorovaikutuskaavioita. Osallistujat Mallin luokat ja oliot sekä niiden vastuut. Yhteistyösuhteet Toimijoiden yhteistoiminta vastuidensa toteuttamisessa. Seuraukset Kuvaa, mihin ratkaisun soveltaminen johtaa ja minkälaisia kompromisseja sen soveltaminen aiheuttaa. Voi myös kuvata, mitä ohjelman ominaisuuksia voidaan muutella mallin toteutusta häiritsemättä. Toteutus Antaa vihjeitä mallin implementointiin, listaa hankaluuksia joihin on varauduttava ja tekniikoita, joita voidaan käyttää implementoinnissa. Esittää myös mahdollisia kieliriippuvuuksia. Lisäksi annetaan mahdolliset muut nimet, joilla malli tunnetaan sekä malliin läheisesti liittyviä muita malleja. Malliin voidaan myös liittää esimerkkikoodia ja tunnettuja reaalimaailman käyttötapauksia. 3
4 4. Suunnittelumalleille asetettuja tavoitteita Suunnittelumallien toivotaan parantavan olio-ohjelmien laatimista useilla tavoilla. Ensinnäkin suunnittelumallien luokittelu ja niiden nimeäminen antaa suunnittelijoille yhtenäisen sanaston, jota voidaan käyttää pohdittaessa ratkaisuja vastaan tuleviin ongelmiin. Yleisesti katsotaan, että käytössä oleva sanasto vaikuttaa ajatteluun: suunnittelumalleja apuna käyttäen voidaan ongelmaa käsitellä korkeammalla abstraktiotasolla. Yleisimpien suunnittelumallien tunteminen auttaa ymmärtämään ohjelmakoodia paremmin, koska suuri osa laajoista oliopohjaisista ohjelmista käyttää suunnittelumalleja. Mikäli koodin dokumentoinnista käy ilmi, mitä mallia on käytetty, ohjelman rakenne ja toiminta aukeaa mallin tuntevalle lukijalle helpommin. Suunnittelumallien toivotaan lisäksi täydentävän muita oliosuuntautuneita suunnittelumetodeja, jotka eivät samalla lailla hyödynnä kokeneiden suunnittelijoiden tietoja. Ohjelman kehittyessä ja joutuessa mukautumaan uusiin vaatimuksiin, se on joskus refaktoroitava, eli osia sen luokkarakenteesta on suunniteltava uudelleen. Tällöin suunnittelumalleista on hyötyä uuden luokkarakenteen laatimisessa. Lisäksi hyväksi havaittujen mallien soveltaminen jo kehityksen varhaisessa vaiheessa voi poistaa myöhemmän refaktoroinnin tarpeen. 5. Suunnitteluongelmien suhde suunnittelumalleihin Suunniteltaessa oliosuuntautunutta ohjelmaa sen oliorakenne muodostuu pääosin luonnollisella tavalla mallista, joka kohdejärjestelmästä on tehty. Yleensä näin löydetään oliot, joilla on suora vastine reaalimaailmassa. Monesti ohjelmaan on kuitenkin toteutettava toimintoja, joilla ei ole vastinetta ulkomaailmassa. Ohjelmassa voi esiintyä jokin algoritmi tai toiminto, joka on välttämätön halutun ratkaisun saamiseksi. Silloin tarvitaan olio tai joukko olioita toteuttamaan tämä. On olemassa suunnittelumalleja (esimerkiksi Strategy eli Strategia), jotka avustavat ohjelmoijaa löytämään tarkoituksenmukaisen oliorakenteen. Monet suunnittelumallit ratkaisevat myös ongelmia, joita kohdataan, kun ohjelmassa on luotava olioita erityisen suuria määriä ja käsiteltävä niitä. Tällaisia ovat esimerkiksi Facade- eli Julkisivu- ja Flyweight- eli Hiutalemallit. Joskus syntyy erityisen massiivisia olioita; on olemassa malleja, jotka kuvaavat miten niitä voidaan jakaa osiksi. Ohjelmissa kohdataan myös tilanteita, jolloin on luotava olio, jonka tarkkaa tyyppiä ei käännösaikana tunneta; jotkin suunnittelumallit vastaavat tällaiseen ongelmaan (Builder eli Rakentaja, Abstract Factory eli Abstrakti tehdas) samoin kuin jonkin luokkahierarkian olioiden läpikäymiseen (Visitor eli Vierailija, Command eli Komento). Luokkien rajapintojen suunnittelussa avustavia malleja on myös olemassa. Edellä oli kysymys enimmäkseen ohjelman olioiden tunnistamisesta ja niiden keskinäisen toiminnan suunnittelusta. Kun rakennetta lähdetään implementoimaan, on suunniteltava olioiden ominaisuudet eli määriteltävä luokat, joista olioita luodaan. Gamman et al. ([Gam]) mukaan kaikkein olennaisin asia uudelleenkäytettävän olio-ohjelman suunnittelussa on keskittyä nimenomaan rajapintoihin. Luokkahierarkian kantaluokan olisi tästä syystä oltava abstrakti ja hierarkian olioita tulisi käsitellä ainoastaan tämän luokan määrittelemän rajapinnan kautta. Näin ohjelman osajärjestelmien väliset riippuvuudet vähenevät. He esittävät tämän periaatteen muodossa Program to an interface, not an implementation. Luontimallit eli olioiden 4
5 luomiseen liittyvät mallit (Factory Method eli Tehdasmetodi, Prototype eli Prototyyppi, Singleton eli Ainokainen) varmistavat, että tätä periaatetta käytetään. Olio-ohjelmoinnin tulisi suosia uudelleenkäytettävyyttä. Ohjelmaa rakennettaessa luokkien välille syntyy helposti riippuvuuksia, jotka haittaavat luokkien siirtämistä toiseen yhteyteen. Periytyminenkin voi olla rasite, jos jotakin aliluokkaa haluttaisiin käyttää uudelleen. Aliluokka perii kuitenkin yliluokkansa piirteet, joita ei voi muuttaa, ellei kirjoita koko rakennetta uudelleen. Monessa tapauksessa kannattaakin käyttää koostetta: lisätään toisen luokan olio luokkaan attribuutiksi. Näin voidaan rajoittaa yhden luokan vastuut yhteen toimintaan. Gamman et al. ([Gam]) esittämän periaatteen mukaan ohjelmoijan tulisikin suosia koosteita perimisen sijaan: Favor object composition over class inheritance. Myös useimmissa suunnittelumalleissa käytetään koostamista ahkerasti. Delegointi liittyy olennaisesti koostamiseen: delegoinnissa jokin olio täyttää sille esitetyn pyynnön ohjaamalla sen edelleen jollekin osaoliolleen. Delegointi voi dynaamisen luonteensa vuoksi tehdä ohjelmakoodista vaikeammin ymmärrettävää, mutta jos sitä käytetään standardimaisten suunnittelumallien implementoinnissa, ongelma poistuu. On useita suunnittelumalleja, joiden toiminta perustuu nimenomaan delegointiin. Esimerkiksi Vierailija- eli Visitor-mallissa tehdään oliorakenteen kaikille olioille jokin operaatio, jonka suorittaminen on delegoitu erityiselle Visitor-oliolle. Jotkin ohjelmat ovat vaikeasti hahmotettavia, koska niiden staattinen muoto ei kerro kaikkea olennaista niiden toiminnasta. Niissä voidaan luoda monimutkaisia suorituksenaikaisia rakenteita, joiden käyttäytyminen ei selviä helposti staattisesta luokkarakenteesta. Ohjelmaa voi ymmärtää paremmin, mikäli tuntee sopivia suunnittelumalleja. Esimerkiksi Kooste-mallia käytetään monimutkaisten ajonaikaisten rakenteiden luomiseen. Toisaalta Tarkkailija-mallia käyttävää ohjelmaa on vaikea ymmärtää koodia lukemalla, ellei tunne mallin rakennetta. Ohjelmaan kohdistuu sen eliniän aikana erilaisia muutospaineita. Hyvin suunniteltu ohjelma voi taipua kohtuullisilla muutoksilla vaatimusten muuttumiseen. Ohjelma olisikin hyvä suunnitella alun perin sellaiseksi, että osia siitä voidaan muokata aiheuttamatta suuria muutosvaatimuksia toisiin osiin. Taitavasti käytetyt suunnittelumallit voivat auttaa siinä: yleensä jokainen malli antaa ohjelman muille osille ainakin jonkinlaisia vapauksia. Lisäksi mallin kuvauksen tulisi kuvata rajoitteet. Mainittakoon tässä muutamia ongelmia, jotka haittaavat ohjelman sujuvaa muokkaamista: 1. Kun luodaan olioita suoraan jostakin luokasta käyttämällä luokan nimeä, sitoudutaan sen implementaatioon eikä rajapintaan. Mikäli annetaan olion luominen jonkin toimijan vastuulle, voidaan implementaatiota muuttaa. Epäsuoraan olion luomiseen käytetään esimerkiksi Prototyyppi- eli Prototype-suunnittelumallia. 2. Riippuvuus tietyistä algoritmeista. Eräiden suunnittelumallien avulla algoritmit voidaan eristää niiden käyttäjistä. Esimerkiksi Template Method- eli Operaatiorunko-malli on tällainen. 3. Olioiden ja luokkien väliset riippuvuudet johtavat usein siihen, että yksittäistä ohjelman osaa on vaikea muuttaa tekemättä muutoksia moniin muihin kohtiin. Useat suunnittelumallit löyhentävät riippuvuuksia; mm. jo aiemmin mainittu Observer-malli tekee näin. 4. Joskus tulisi käyttää valmista luokkaa sellaisessa yhteydessä, johon sen rajapinta ei suoraan sovellu tai rajapinnan käyttö on vaivalloista. Mikäli luokkaa ei voi muuttaa, on ongelma ratkaistava muuten. Adapter- eli Sovitin-suunnittelumallia käytetään usein tällaisissa tilanteissa: tehdään erityinen sovitinluokka toimijoiden välille. 5
6 6. Suunnittelumallien luokittelu Suunnittelumalleja voidaan luonnollisesti luokitella hyvin monin eri tavoin. Gamma et al. ([Gam]) jakavat mallinsa taulukoksi kahden kriteerin perusteella: 1. Mallin tarkoitus (olioiden luominen, rakenteellinen, käyttäytyminen) 2. Mallin kohde (käytetäänkö pääasiassa luokkia vai olioita) Näin saadaan Gamman et. al. suunnittelumalleille seuraava taulukko: Kuva 3. Mallien luokittelu. (Lähde: Lasse Harjumaan luentokalvot) Luokkamallit keskittyvät luokkien välisiin suhteisiin, jotka määräytyvät käännösaikana. Näin ollen nämä mallit ovat luonteeltaan enimmäkseen staattisia. Oliomallit puolestaan käsittelevät olioiden välisiä suhteita, jotka voivat muuttua ohjelman suorituksen aikana. Siten oliomallit ovat luonteeltaan dynaamisempia kuin luokkamallit. Olioiden luomiseen liittyvät luokkamallit siirtävät olion luomisen aliluokkiin, kun taas vastaavat oliomallit siirtävät sen jonkin olion vastuulle. Rakenteelliset luokkamallit käyttävät periytymistä luokkien rakentamisessa; rakenteelliset oliomallit kuvaavat tapoja yhdistellä olioita. Käyttäytymiseen perustuvat luokkamallit kuvaavat, miten periytymistä käyttämällä voidaan toteuttaa algoritmeja ja erilaisia suorituspolkuja. Vastaavat oliomallit kuvaavat, miten joukko olioita voi yhteistuumin suorittaa jonkin tehtävän. 7. Suunnittelumallin valinnasta ja käyttämisestä Suunnittelumalli on tietysti valittava niin, että se ratkaisee kohdatun ongelman. Jotta sopiva malli pystytään löytämään, on tutustuttava tapoihin, joilla suunnittelumalleja sovelletaan. Oikean mallin valitseminen vaatii kokemusta ja erilaisten ratkaisujen tuntemusta sekä mallien ominaisuuksien ja niiden suhteiden tuntemista. 6
7 Gamma et. al ([Gam]) antavat ohjeellisen toimintatavan valitun mallin soveltamiseksi: 1. Tutustu ensin malliin kokonaiskuvan saamiseksi. Sovellettavuus ja seuraukset vahvistavat, että ongelmaan soveltuva malli on valittu. 2. Tutustu huolellisesti mallin kuvauksesta osallistujiin, rakenteeseen ja yhteistoimintaan. 3. Tutki, onko mallista annettu esimerkkikoodia, jotta näet konkreettisen esimerkin sen implementoinnista. 4. Valitse mallin toimijoille sovelluskontekstiin sopivat nimet. Tämä auttaa mallin implementoinnissa. 5. Määrittele luokat. Toisin sanoen konstruoi niiden rajapinnat, niiden perimissuhteet sekä määrittele luokkiin jäsenmuuttujat. Tunnista uusien luokkien vaikutukset sovelluksen aiemmin määriteltyihin luokkiin ja tee niihin tarvittavat muutokset. 6. Valitse mallin luokkien metodeille sovelluskontekstiin sopivat nimet. Sopivat valinnat lisäävät koodin luettavuutta. 7. Implementoi operaatiot toteuttamaan mallin osallistujien yhteistoiminta ja vastuut. Suunnittelumallia ei kuitenkaan ole syytä soveltaa vain soveltamisen ilosta; mallin toteuttaminen lisää yleensä ohjelman kompleksisuutta. On arvioitava mallin mukanaan tuomat hyödyt sen mahdollisiin haittavaikutuksiin nähden. Päätöksen tekemisessä voi auttaa mallin seurauksiin tutustuminen. Lähteet [Ale] Alexander, Ishikawa, Silverstein, Jacobson, Fiksdahl-King, Shlomo Angel. A Pattern Language. Oxford University Press, New York, 1977 [Bud] Budd, Timothy A: An Introduction to Object-Oriented Programming, Addison-Wesley 2002 [Gam] Gamma, Helm, Johnson, Vlissides: Design Patterns: Elements of Reusable Object- Oriented Software, Addison-Wesley
812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton
2015 syksy 2. vsk IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton Sisältö 1. Johdanto luontimalleihin 2. Proxy 3. Factory Method 4. Prototype 5. Singleton Suunnittelumallit Proxy et.
Lisätiedot812347A 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ätiedotOhjelmistotekniikan menetelmät, suunnittelumalleja
582101 - Ohjelmistotekniikan menetelmät, suunnittelumalleja 1 Suunnittelumallit (design patterns) Kuvaus sellaisesta luokkarakenteesta & olioiden vuorovaikutuksesta, joka ratkaisee tietyn yleisen ongelman
Lisätiedot812347A 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ätiedotOlio-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ätiedot812347A Olio-ohjelmointi, 2015 syksy 2. vsk. VI Johdanto suunnittelumalleihin
2015 syksy 2. vsk VI Johdanto suunnittelumalleihin Sisältö 1. Taustaa 2. Model View - Controller 3. Suunnittelumallin kuvaamisesta 4. Tavoitteita 5. Suunnitteluongelmien suhde malleihin 6. Suunnittelumallien
LisätiedotT SEPA - päiväkirja: Design Patterns. ETL työkalu
T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty
LisätiedotOhjelmistojen 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ätiedotKertaus: yleistys-erikoistus ja perintä
Kertaus: yleistys-erikoistus ja perintä Nauta, Lehmä ja Kuttu ovat Kotieläimiä, Kotieläimet Eläimiä Kotieläimillä (siis myös Naudoilla, Lehmillä ja Kutuilla) on Omistaja Kuttu ja Lehmä toteuttavat rajapinnan
LisätiedotT SEPA - päiväkirja: Design Patterns. ETL työkalu
T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty
LisätiedotHirviö. 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ätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
LisätiedotOhjelmistojen mallintaminen, suunnittelumalleja
582104 Ohjelmistojen mallintaminen, suunnittelumalleja 1 Suunnittelumallit (design patterns) Kuvaus sellaisesta luokkarakenteesta & olioiden vuorovaikutuksesta, joka ratkaisee tietyn yleisen ongelman tiettyjen
LisätiedotSisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.
Sisällys Ratkaisumallien historia Jaakko Vuolasto 25.1.2001! Ratkaisumalli! Christopher Alexander! Ohjelmistotuotannosta arkkitehtuuriin! Henkilöhistoriaa! Ensimmäisiä käyttökokemuksia! Yhteenveto 25.1.2001
Lisätiedot812347A 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ätiedothttp://www.enteract.com/~bradapp/docs/patterns-intro.html http://www.hillside.net/patterns/
5. Suunnittelumallit Suunnittelumallin käsite Suunnittelumallien hyötyjä Suunnittelumallien kuvaaminen Esimerkki: Rekursiokooste Antisuunnittelumallit Suunnittelumallit ja UML Mallikielet Suunnittelumallit
LisätiedotTä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ätiedotSisällys. JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta. Abstraktin luokan idea. Abstrakti luokka ja metodi. Esimerkki
Sisällys JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta Abstrakti luokka ja metodi Rajapintamäärittely (interface) Eero Hyvönen Tietojenkäsittelytieteen laitos Helsingin yliopisto 13.10.2000 E.
LisätiedotOliosuunnittelu. Oliosuunnittelu
Oliosuunnittelu Perinnän ja dynaamisen sidonnan hyödyntäminen Tarkastellaan ohjelmaa, jonka tehtävänä on tuottaa erilaisista kuvioista muodostuva kuvaesitys Ratkaisu 1: perinteinen malli - ei perintää
Lisätiedot4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T
SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen
LisätiedotAnalyysi, 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ätiedotSuunnittelumallit (design patterns)
Suunnittelumallit (design patterns) Ohjelmoinnissa Rakennusarkkitehtuurissa Käyttöliittymäsuunnittelussa Sear ch Ohjelmointi Suunnittelumallit Usein toistuvia ohjelmointiongelmia ja niiden ratkaisuja:
LisätiedotOpintojakso 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ätiedotOhjelmistoarkkitehtuurit kevät
Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 5. Suunnittelumallit Suunnittelumallin käsite Suunnittelumallien hyötyjä Suunnittelumallien kuvaaminen Esimerkki:
LisätiedotMuutamia peruskäsitteitä
Muutamia peruskäsitteitä Huom. 1: nämä peruskäsitteet eivät muodosta hyvin määriteltyä keskenään yhteensopivien käsitteiden joukkoa, vaan käsitteet ovat osittain päällekkäisiä ja eri yhteyksissä niillä
LisätiedotTenttikysymykset. + 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ätiedotOhjelmistoarkkitehtuurit. Syksy 2010
Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin
LisätiedotSuunnittelumalleja, 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ätiedotSEPA - 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ätiedotMitä on periytyminen?
8. Periytyminen 8.1 Sisällys Mitä on periytyminen? Yksittäis- ja moniperiytyminen. Oliot ja perityt luokat. Filosofinen ja käytännönläheinen näkökulma periytymiseen. Periytymisen soveltaminen. 8.2 Mitä
LisätiedotOhjelmistojen mallintaminen Luokkakaaviot Harri Laine 1
Ohjelmistojen mallintaminen Luokkakaaviot 5.12.2008 Harri Laine 1 Olioiden palvelut Palvelun kuvauksessa annettavat tiedot näkyvyys (kuten attribuuttien kohdalla) nimi (ainoa välttämätön osa) parametrit
LisätiedotTenttikysymykset. + 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ätiedotInteraktiivisten 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ätiedotSisällys. Mitä on periytyminen? Yksittäis- ja moniperiytyminen. Oliot ja perityt luokat. Periytymisen käyttö. 8.2
8. Periytyminen 8.1 Sisällys Mitä on periytyminen? Yksittäis- ja moniperiytyminen. Oliot ja perityt luokat. Periytymisen käyttö. 8.2 Mitä on periytyminen? Periytyminen (inheritance) tarkoittaa luokan piirteiden
LisätiedotOlio-ohjelmoinnissa luokat voidaan järjestää siten, että ne pystyvät jakamaan yhteisiä tietoja ja aliohjelmia.
4. Periytyminen 4.1. Johdantoa Käytännössä vähänkään laajemmissa ohjelmissa joudutaan laatimaan useita luokkia, joiden pitäisi pystyä välittämään tietoa toisilleen. Ohjelmien ylläpidon kannalta olisi lisäksi
LisätiedotTIE-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ätiedotGraafisen käyttöliittymän ohjelmointi Syksy 2013
TIE-11300 Tietotekniikan vaihtuva-alainen kurssi Graafisen käyttöliittymän ohjelmointi Syksy 2013 Luento 8 Suunnittelumallit käyttöliittymäohjelmoinnissa Juha-Matti Vanhatupa Yleistä Suunnittelumalli on
LisätiedotKäyttöliittymät II. Käyttöliittymät I Kertaus peruskurssilta. Keskeisin kälikurssilla opittu asia?
Käyttöliittymät II Sari A. Laakso Käyttöliittymät I Kertaus peruskurssilta Keskeisin kälikurssilla opittu asia? 1 Käyttöliittymät II Kurssin sisältö Käli I Käyttötilanteita Käli II Käyttötilanteet selvitetään
LisätiedotMuusta 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ätiedotRajapinnasta ei voida muodostaa olioita. Voidaan käyttää tunnuksen tyyppinä. Rajapinta on kuitenkin abstraktia luokkaa selvästi abstraktimpi tyyppi.
11. Rajapinnat 11.1 Sisällys Johdanto. Abstrakti luokka vai rajapinta? Rajapintojen hyötyjä. Kuinka rajapinnat määritellään ja otetaan käyttöön? Eläin, nisäkäs, kissa ja rajapinta. Moniperiytyminen rajapintojen
LisätiedotTIE-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ätiedotOliosuunnitteluesimerkki: 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ätiedotOhjelmistotekniikan 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ätiedotHirviö. Design Patterns
Hirviö SEPA-päiväkirja Design Patterns Anssi Kalliolahti Liia Sarjakoski 15. maaliskuuta 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ätiedotOhjelmistojen mallintaminen, kesä 2009
582104 Ohjelmistojen mallintaminen, kesä 2009 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin
LisätiedotConcurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo
Concurrency - Rinnakkaisuus Group: 9 Joni Laine Juho Vähätalo Sisällysluettelo 1. Johdanto... 3 2. C++ thread... 4 3. Python multiprocessing... 6 4. Java ExecutorService... 8 5. Yhteenveto... 9 6. Lähteet...
Lisätiedot812341A 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ätiedotAnalyysi, 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ätiedotSisällys. 11. Rajapinnat. Johdanto. Johdanto
Sisällys 11. ajapinnat. bstrakti luokka vai rajapinta? ajapintojen hyötyjä. Kuinka rajapinnat määritellään ja otetaan käyttöön? Eläin, nisäkäs, kissa ja rajapinta. Moniperiytyminen rajapintojen avulla.
LisätiedotSuunnittelumallien käyttö ohjelmistosuunnittelussa
Suunnittelumallien käyttö ohjelmistosuunnittelussa Mika Rantakeisu Rovaniemen ammattikorkeakoulu Avoin ammattikorkeakoulu mika.rantakeisu@edu.ramk.fi Tiivistelmä Tämä on selvitys suunnittelumallien käytöstä
LisätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
LisätiedotJoskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita.
Moniperintä 2 Joskus yleistäminen voi tapahtua monen ominaisuuden pohjalta. Myös tällöin voi tulla moniperintätilanteita. Oliomallinnus TITE.2040 Hannu K. Niinimäki 1 Delegointi 1 Moniperinnän toteuttaminen
Lisätiedot812341A Olio-ohjelmointi, I Johdanto
812341A Olio-ohjelmointi, 2016 I Johdanto Sisältö 1. Abstraktiosta 2. Olio-ohjelmoinnin historiaa 3. Olioparadigmasta 4. Peruskäsitteiden kertausta 812341A Olio-ohjelmointi, Johdanto 2 1 Abstraktiosta
Lisätiedot5. Suunnittelumallit. TTY Ohjelmistotekniikka
5. Suunnittelumallit Suunnittelumallin käsite Suunnittelumallien hyötyjä Suunnittelumallien kuvaaminen Antisuunnittelumallit Esimerkki: Rekursiokooste Suunnittelumallit ja kehykset Suunnittelumallit ja
Lisätiedot12. Kehysarkkitehtuurit
12. Kehysarkkitehtuurit Johdanto Kehystyypit Kehysten osittaminen Kehykset ja suunnittelumallit Kehysten etuja ja ongelmia Yhteenvetoa Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Johdanto
LisätiedotT 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ätiedot812341A 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ätiedotOhjelmistojen 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ätiedotT-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Arkkitehtuuri- ja suunnittelumalli
T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Arkkitehtuuri- ja suunnittelumalli Lasse Lindqvist Lasse Lopperi llindqvi@cc.hut.fi lmlopper@cc.hut.fi
Lisätiedotohjelman arkkitehtuurista.
1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä
LisätiedotOhjelmistoarkkitehtuurit. Kevät
Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto 2 Kurssin tavoitteet
LisätiedotTIE-20200 Ohjelmistojen suunnittelu. Luento 8..9: moniperintä
TIE-20200 Ohjelmistojen suunnittelu Luento 8..9: moniperintä 1 Ajankohtaista Harjoitustyön suunnittelusessiot pidetty, työt jatkuvat, välivaiheen esittely seuraavana Viimeinen viikkoharjoituskerta, palataan
LisätiedotLuokka- 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ätiedotOlio-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ätiedotKäyttötapausanalyysi ja testaus tsoft
Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten
Lisätiedot15. Ohjelmoinnin tekniikkaa 15.1
15. Ohjelmoinnin tekniikkaa 15.1 Sisällys For-each-rakenne. Lueteltu tyyppi enum. Override-annotaatio. Geneerinen ohjelmointi. 15.2 For-each-rakenne For-rakenteen variaatio taulukoiden ja muiden kokoelmien
LisätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
Ohjelmistoarkkitehtuurit Syksy 2009 Kai Koskimies Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto (Kajaani), Tampereen yliopisto, Turun yliopisto,
LisätiedotAalto Yliopisto T-106.2001 Informaatioverkostot: Studio 1. Oliot ja luokat Javaohjelmoinnissa
Aalto Yliopisto T-106.2001 Informaatioverkostot: Studio 1 Oliot ja luokat Javaohjelmoinnissa Vesa Laakso 22.9.2012 Sisällysluettelo Sisällysluettelo... 1 Johdanto... 2 1. Luokka... 2 2. Olio... 2 3. Luokan
Lisätiedot15. Ohjelmoinnin tekniikkaa 15.1
15. Ohjelmoinnin tekniikkaa 15.1 Sisällys For-each-rakenne. Geneerinen ohjelmointi. Lueteltu tyyppi enum. 15.2 For-each-rakenne For-rakenteen variaatio taulukoiden ja muiden kokoelmien silmukoimiseen:
LisätiedotUudelleenkäytön jako kahteen
Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta
LisätiedotSuunnittelumallit. OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Oliosuuntautunut analyysi ja -suunnittelu 27. joulukuuta 2003
Suunnittelumallit OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Oliosuuntautunut analyysi ja -suunnittelu 27. joulukuuta 2003 Mikael Kujanpää mahead@ee.oulu.fi LuTK / TOL -03 Tiivistelmä Suunnittelumallit
LisätiedotOhjelmoinnin peruskurssien laaja oppimäärä, kevät
Ohjelmoinnin peruskurssien laaja oppimäärä, kevät Luento 2: Ohjelman suunnittelua, miten oliot toimivat Riku Saikkonen (osa kalvoista on suoraan ei-laajan kurssin luennoista) 21. 1. 2013 Sisältö 1 Suunnittelua:
LisätiedotLuokkakaavion laatiminen
Luokkakaavion laatiminen Kartoita luokkaehdokkaita Karsi ehdokkaita Tunnista olioiden väliset yhteydet Täsmennä luokkakuvauksia määrittelemällä attribuutit Määrittele yhteyksiin liittyvät osallistumisrajoitteet.
LisätiedotRatkaisumallien historia
Ratkaisumallien historia Jaakko Vuolasto Helsinki 25.1.2001 Seminaariesitelmä HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Sisällys 1 Johdanto... 1 2 Ratkaisumallin käsite ohjelmistotuotannossa...
LisätiedotTarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen
Tarjolla tänää: Ohjelmiston toteutuksesta JOT2007 CRC-kortit Testilähtöinen kehittäminen Uudelleenrakentaminen Voisiko ohjelmointi olla sittenkin suunnittelua? Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit
LisätiedotOhjelmistotuotanto. Luento 9 23.4.2012
Ohjelmistotuotanto Luento 9 23.4.2012 Lisää suunnittelumalleja Olion rikastaminen dekoraattorilla Joskus eteen tulee tarve lisätä olioon jotain ekstraominaisuuksia, pitäen kuitenkin olio sellaisena että
LisätiedotOlio-ohjelmointi Johdanto olio-ohjelmointiin
Olio-ohjelmointi Johdanto olio-ohjelmointiin Ohjelmistoa kehitettäessä voidaan tunnistaa ainakin kaksi abstraktiota: prosessiabstraktio ja dataabstraktio. Prosessiabstraktio huomattiin jo varhain, koska
LisätiedotOhjelmistotekniikan 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ätiedotUML -mallinnus LUOKKAKAAVIO EERO NOUSIAINEN
UML -mallinnus LUOKKAKAAVIO EERO NOUSIAINEN SISÄLLYS 3. Luokkakaavio UML -mallinnuskielessä 3.1 Luokkakaavion luokan rakenteet 3.2 Luokan kuvauksesta C++ ohjelmakoodiksi 3.3 Luokkakaavion luokkien yhteystyypit
LisätiedotInteraktiivisten 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ätiedot2. Olio-ohjelmoinnin perusteita 2.1
2. Olio-ohjelmoinnin perusteita 2.1 Sisällys Esitellään peruskäsitteitä yleisellä tasolla: Luokat ja oliot. Käsitteet, luokat ja oliot. Attribuutit, olion tila ja identiteetti. Metodit ja viestit. Olioperustainen
LisätiedotOlio-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ätiedotOhjelmistojen 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ätiedotHELIA 1 (14) Outi Virkki Käyttöliittymät ja ohjlmiston suunnittelu
HELIA 1 (14) Luento 7 Käyttöliittymäolio... 2 Olioajattelun perusteet... 3 Tavoitteet... 3 Peruskäsitteet... 4 Olio / Olioinstanssi / Olion esiintymä... 4 Ominaisuudet... 4 Toiminnot... 4 Olioluokka /
Lisätiedot9. Periytyminen Javassa 9.1
9. Periytyminen Javassa 9.1 Sisällys Periytymismekanismi Java-kielessä. Piirteiden näkyvyys periytymisessä. Ilmentymämetodien korvaaminen. Luokkametodien peittäminen. Super-attribuutti. Override-annotaatio.
LisätiedotSEPA päiväkirja. Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen
SEPA päiväkirja Aihe: Suunnittelumallit Tekijät: Tuukka Laakso ja Antti Kettunen 1. Johdanto...3 2. Menetelmän käyttö...4 3. Kokemukset ja muutokset...5 1. Johdanto SEPAn aiheenamme meillä on suunnittelumallit
LisätiedotOhjelmistojen 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ätiedotSisä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ätiedotT Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Analyysimalli
T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Analyysimalli Lasse Lindqvist Lasse Lopperi llindqvi@cc.hut.fi lmlopper@cc.hut.fi Andrey Rusanovich
LisätiedotTIE-20200 Ohjelmistojen suunnittelu
TIE-20200 Ohjelmistojen suunnittelu Luento 1: Virtuaalifunktiot, Template method 1 Seuraavaksi tarjolla: Otekn-asiaa vähän pintaa syvemmältä Virtuaalifunktiot ja erikoistaminen, olioiden kopiointi ja elinaika
LisätiedotUML-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ätiedotOhjelmoinnin peruskurssien laaja oppimäärä
Ohjelmoinnin peruskurssien laaja oppimäärä Luento 7: UML, suunnittelumalleja Riku Saikkonen (osa kalvoista on suoraan ei-laajan kurssin luennoista) 25. 2. 2012 Sisältö 1 Lisää ohjelmien suunnittelusta
LisätiedotYhteydelle voi antaa nimen kumpaankin suuntaan Sille ei tarvise antaa lainkaan nimeä Yhteysnimen asemasta tai lisäksi voidaan käyttää roolinimiä
DO NOT PRINT THIS DOCUMENT DO NOT PRINT THIS DOCUMENT Olioiden väliset yhteydet Yhteyden nimi Nimen lukusuunta pankkitili 0..10 Omistaja-> 1..3 asiakas
LisätiedotOhjelmistotekniikan 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ätiedotOhjelmistokehykset (software frameworks)
Ohjelmistoarkkitehtuurit 1 (software frameworks) Osittain abstraktiksi jätettyjä ohjelmistorunkoja, joita eri tavoin täydentämällä saadaan rakennettua kokonaisia uusia sovelluksia tai sovelluksen osia
LisätiedotT740103 Olio-ohjelmointi Osa 5: Periytyminen ja polymorfismi Jukka Jauhiainen OAMK Tekniikan yksikkö 2010
12. Periytyminen Johdantoa Käytännössä vähänkään laajemmissa ohjelmissa joudutaan laatimaan useita luokkia, joiden pitäisi pystyä välittämään tietoa toisilleen. Ohjelmien ylläpidon kannalta olisi lisäksi
LisätiedotOhjelmoinnin 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ätiedotUML Luokkakaavio 14:41
UML Luokkakaavio UML Olio-ohjelman luokkien pääpiirteet voidaan kätevähkösti esittää ns. UML-luokkakaaviona. Näin usein tehdäänkin esim. suunniteltaessa, millaisia luokkia ohjelmaan on tarkoitus laatia,
LisätiedotSisällys. 9. Periytyminen Javassa. Periytymismekanismi Java-kielessä. Periytymismekanismi Java-kielessä
Sisällys 9. Periytyminen Javassa Periytymismekanismi Java-kielessä. Piirteiden näkyvyys periytymisessä. Metodien korvaaminen ja super-attribuutti. Attribuutin peittäminen periytymisen kautta. Rakentajat
Lisätiedot